Советы по проведению оценки

22 июля 2009, 12:23
Данные советы взяты из книги Стива МакКоннела, опубликованной в рамках серии Microsoft Best Practices. Эта книга общепризнанна в качестве ценного источника знаний и рекомендована всем тем, кому приходится заниматься оценкой проекта – менеджерам проектов разработчикам, тимлидам и т.д. Разумеется, данные советы, перечисленные в этом посте, не являются исчерпывающими, и рассматриваются в первую очередь в их первоначальном контексте. Но, тем не менее.

Концепции критической оценки

  • Когда вас просят провести оценку, определите точно, что от вас требуется – именно оценка или описание того, каким путём в данном случае можно добиться желаемого результата.
  • Цель – это описание желаемого результата. Обязательство (commitment) – это обещание предоставить в конкретные сроки конкретный функционал конкретного уровня качества. Обязательство может совпадать с оценкой, быть её агрессивнее или консервативнее, но необходимо понимать, что это не одно и тоже.
  • Не используйте точечные оценки каких-то параметров и результатов, используйте диапазоны значений. Избегайте использования искусственно зауженных диапазонов, чтобы не подорвать доверия к вашему эстимэйту.
  • Никогда намеренно не занижайте оценку. В любом случае последствия недооценки будут куда более суровыми, нежели в случае переоценки. Вопросы по переоценке аргументируйте необходимостью планирования и контроля, а не какой-то предвзятостью своей оценки.
  • Возникающие расхождения между тем, что выполняется согласно оценке и бизнес-целью проекта лучше разрешать на как можно более ранней стадии иначе это ставит под угрозу весь проект.
  • Рассмотрите точность своих оценок в рамках данного Конуса Неопределённости. Ваша оценка не может быть более точной в соответствующей точке, то есть фактически стадии проекта, где вы находитесь в рамках конуса в данный момент. Используйте диапазоны точности оценки дальнейшего развития проекта при проведении последующих оценок.
  • Включайте в ваши оценки не только кодирование и тестирование, но и затраты на другие виды деятельности, при разработке. Например:
  • - Обучение новичков на проекте - Развёртывание - Уточнение требований - Техревью - Работа над производительностью системы - Создание тестовых данных
  • Для проектов, длящихся более нескольких недель, закладывайте в оценки допуски времени и бюджета на отпуска, больничные, а также непроизводственную деятельность – обучение и митинги.
  • Никогда не давайте никаких оценок навскидку. Даже 15минутная оценка окажется гораздо точнее и аккуратнее.
  • Всегда документируйте допуски и предположения, добавленные в оценку.
  • Приводите в соответствие цифры в оценке к её точности. Например:
  • - «Этот проект займёт один год» - не совсем конкретно, но может быть для данной оценки достаточно точно. - «Этот проект займёт 7,214 человеко-часов» - предельно конкретно, но может оказаться совсем неточным.
  • Не думайте, что объём необходимых для реализации проекта усилий растёт линейно с увеличением масштабов проекта.
  • Основные приёмы в оценке

    • Выберите какой-то элемент, типичную задачу или что-нибудь в этом роде, которые бы являлись значимой мерой объема работ в данной среде.
    • Соберите исторические данные о предыдущем опыте работы над подобными проектами в вашей компании. Производительность труда вашей организации в предыдущих проектах - лучший индикатор для оценки проекта от объёма работ, «чужие», то есть средние данные по индустрии в данном случае куда менее надёжны и адекватны.
    • После завершения каждого проекта сразу подводите статистические данные о длительности разработки в целом и поэтапно.
    • Так или иначе, лучше избегать внесения «экспертных» поправок и мнений в оценку, подготовленную на основе расчетов.
    • Для создания task-level оценок необходимо стараться привлекать тех людей, кто непосредственно будет их выполнять
    • Создавайте сразу как самый оптимистичный, так и наиболее пессимистичный варианты оценок, чтобы полностью представлять картину возможных последствий
    • Оценку новых проектов проводите в сравнении с похожими предыдущими проектами, желательно при этом разбивая эстимейт на как минимум пять частей.
    • Учитывайте важность различных элементов функционала заказчика. Допустим, составляя подобную «майку» расчёта важности той или иной функции для потребителя проекта. (В данном случае имеется в виду использовать шкалу размеров маек, принятую в США – от S самый маленький, до XL самый большой. Верхняя таблица служит для получения цифрового числа важности элемента в зависимости от затрат, приходящихся на его разработку. Пример: если функция не имеющего особого значения (S) обходится в разработке большими затратами (XL) получаем вес -7). Определив значимость каждой функции, получаем нижнюю табличку, так сказать картину полезности функционала)
    • Попросите каждого члена команды оценить части проекта в индивидуальном порядке и замет просмотрите их эстимейты. Важно их не усреднить просто для конечной оценки, а найти консенсус, устраивающих всех.
    • Используйте специальный софт для оценки проекта, для проверки вменяемости вашей ручной оценки. Правда, не воспринимайте результат автомата, как какое-то божественное откровение. Пример подобного софта - http://www.construx.com/Page.aspx?nid=68
    • Первым делом оцениваете масштабность проекта, его размер, так сказать. Потом уже, исходя из этих знаний, прикидывайте, сколько потребуется на это затратить усилий и средств.
    • Проводите переоценку на каждом этапе разработки. Ориентируйтесь при оценке оставшейся части проекта на актуальные данные, а не запланированные.
    • Заранее обсуждайте возможность и ваши действия по переоценке проекта в процессе разработки с заказчиком.

    Некоторые аспекты составления графика работ при оценке.

    • Не сокращайте время разработки в оценке, не увеличивая адекватно оценку необходимых усилий, количества человек и т.д.
    • Чем больше команда, тем больше необходимо закладывать время на менеджмент и координацию усилий
    • В больших командах больше путей коммуникации, а поэтому больше шанс возникновения недопонимания, а вследствие чего и ошибок.
    • Чем меньше сроки реализации проекта, тем больше работы запаралелливается. Чем больше задач пересекается и накладывается, тем больше шанс разработать новый кусок кода на основе дефектного старого, и потом переделывать уже сразу два.
    • Сокращайте расходы при необходимости за счёт удлинения проекта и проведения разработки меньшей командой.
    • Сочетайте расписание проведения различных видов деятельности согласно выбранному подходу к разработке (например, грамотно распределяйте нагрузку на тестеров в течение процесса разработки).
    • Источник | Оригинал
    подписка на главные новости 
    недели != спам
    # ит-новости
    # анонсы событий
    # вакансии
    Обсуждение