Точная оценка может иметь решающее значение для вашего проекта

Введение

Один из основных навыков, необходимых любому руководителю проекта, - хорошая способность оценивать объемы работы. Владение методами оценки важно, так как от этого зависят сроки выпуска проектов. Неточная оценка оказывает существенное влияние на стоимость и рентабельность любого проекта. Она также влияет на доверие и отношение всех членов команды и клиентов к руководителю проекта. Умение оценивать работу важно для всех членов команды, потому что все они участвуют в процессе оценки. Нет никаких сомнений в том, насколько важно для всей команды повышать это умение. Тем не менее, нужно признать проблемы, с которыми мы сталкиваемся в процессе оценки в индустрии программного обеспечения, где почти невозможно просто повторить тот же проект и предположить, что по аналогии сохранятся те же оценки. Каждый проект всегда несет с собой новый набор требований, рисков, технологий, членов команды и т.п. Проблемы оценки можно описать следующим образом:

• чрезмерная оценка, которая может быть слишком оптимистичной или слишком пессимистичной;
• ошибочное представление индивидуума о том, что оценка - это обязательство;
• сопротивление адаптации к новым факторам, которые могут повлиять на оценки;
• отсутствие опыта или исторической информации, которая может служить отправной точкой для оценки;
• неопределенность области охвата или бизнес-требований проекта;
• плохой план снижения рисков;
• неизмеримые спонтанные мероприятия, такие как совещания, праздники, демонстрации, изготовление прототипов;
• недостаточное использование современных инструментов и процессов для отслеживания оценок.

Чтобы получить этот навык, каждый человек должен знать, какие варианты имеются в его распоряжении. Какие методы можно использовать, и когда? В этой статье приведены различные методы оценки, которые помогают управлять проектами и совершенствовать процесс принятия решений. Статья начинается с обзора некоторых популярных традиционных методов, а затем в ней демонстрируются отдельные приемы гибкой разработки. Заканчивается статья кратким сравнением методов гибкой разработки с обычными методами. Читатель также познакомится с набором составляющих, позволяющих улучшить оценку.

Обычные методы оценки

Многие оценки проектов строятся на использовании истории предыдущих проектов или знаниях экспертов в предметной области (Subject Matter Experts - SME). В следующем разделе мы расскажем о методах, основанных на сходстве между проектами.

Исторические сведения

PROBE (Proxy Based Estimating - оценка на основе сходства)

Этот метод предложил Уоттс Хамфри из Института программного обеспечения при Карнеги-Меллонском университете в рамках PSP (Personal Software Process - персональный процесс программирования). Он основан на предположении, что если инженер создает компонент, похожий на тот, что он уже создал, то на это уйдет примерно столько же усилий, что и в прошлый раз . При использовании метода PROBE хранят подробную информацию по каждому созданному компоненту. Затем, когда необходимо оценить новый проект, он разбивается на компоненты, которые сравниваются с исторической информацией. Затем используется формула для оценки каждой задачи.

COCOMO II

В 1980 году была разработана конструктивная модель стоимости (Constructive Cost Model - COCOMO). Она основана на анализе результатов статистического исследования 63 проектов разработки программного обеспечения. Десять лет спустя появилась обновленная версия COCOMO II, охватывающая современные жизненные циклы разработки и использующая более широкий набор данных. Новая модель принимает набор входных переменных и вычисляет целевую оценку, основанную на ранее изученных проектах.

Групповая оценка

В 1940 году был разработан процесс Wide Band Delphi. Он зависит от групповой оценки: руководитель проекта выбирает секретаря и группу оценки. Беспристрастный секретарь организует совещания. Он также обеспечивает всеобщее участие. Руководитель проекта должен быть членом группы оценки, чтобы группа знала приоритетность требований.

Процесс начинается со стартового совещания, на котором группа знакомится с целью проекта. Выходным документом совещания является общий список задач и набор предположений, составленный секретарем и распространяемый среди членов группы. Готовясь к следующему совещанию, каждый член группы оценки индивидуально создает набор предполагаемых результатов, как показано на рисунке 1. Для дальнейшего обсуждения всегда можно добавить дополнительные задачи или предположения. На совещании секретарь выдает каждому оценщику пустую форму. Каждый оценщик заполняет эту форму, исходя из своих подготовленных результатов.

Рисунок 1. Результаты подготовки

Как видно из рисунка 2, каждый оценщик заносит в форму оценки список задач с соответствующими оценками и предположениями. Затем секретарь собирает эту информацию и выписывает ее на доске для первого раунда.

Рисунок 2. Форма оценки

 

В ходе обсуждения каждый оценщик корректирует свои оценки в столбце корректировок. Секретарь в каждом раунде выписывает на доске новые оценки. Обратите внимание, что в каждом раунде согласованные оценки сближаются, как показано на рисунке 3. Это ожидаемо, потому что точки зрения членов группы проясняются.

Рисунок 3. Оценки на доске

После сеанса оценки руководитель проекта собирает все выходные данные в таблицу и выписывает все оценки, наилучший сценарий и наихудший сценарий. Большая разница в оценках помечается для дальнейшего обсуждения. Руководитель проекта созывает заключительное обзорное совещание, чтобы поделиться с оценщиками обобщенными результатами и провести дальнейшее обсуждение или прийти к консенсусу.

Параметрическая оценка

Параметрические методы оценки используют связь между историческими данными и другими параметрами, чтобы получить оценку посредством математической формулы. Вот простой пример: если оценка для написания одного метода составляет 2 часа, то для написания 50 методов потребуется 100 часов. В этом разделе представлены различные виды параметрических оценок.

Use Case Point (UCP)

Этот метод разработан в 1993 году. Он основан на использовании для оценки размера программного обеспечения примеров из унифицированного языка моделирования (Unified Modeling Language - UML). UCP оценивает многие элементы, такие как исполнители, техническая сложность и сложность среды. Затем все они вставляются в формулу для расчета общего размера.

Где:

• UUCW: нескорректированный вес прецедента;
• UAW: нескорректированный вес исполнителя;
• TCF: коэффициент технической сложности;
• ECF: коэффициент сложности среды.

Function Point Analysis (FPA)

Концептуально этот метод очень похож на метод Use Case Point. Функциональные требования подразделяются на пять категорий: выходы, запросы, входы, внутренние файлы и внешние интерфейсы. Затем функции присваивается число функциональных баллов в зависимости от ее сложности. Оценки рассчитывается по следующей формуле:

Где:

• FP: функциональный балл;
• UAF: нескорректированный функциональный балл;
• VAF: поправочный коэффициент.

Трехточечные оценки

Этот метод снимает неопределенности оценки с использованием метода оценки и анализа программы (Program Evaluation and Review Technique - PERT). Метод PERT вычисляет общую оценку по трем оценкам и анализирует результат с помощью математической формулы.

Где:

• E: оценка;
• O: оптимистический сценарий для наилучшего случая;
• P: пессимистический сценарий для наихудшего случая;
• M: наиболее вероятный сценарий.

Гибкие методы оценки

Одно из основных различий между оценками на основе традиционных методов и гибких методов заключается в использовании концепции относительной оценки. При гибкой оценке не существует абсолютной оценки в днях или часах. Вместо этого используются сюжетные баллы (story points). Многие исследования показали, что при использовании сравнений оценки становятся точнее. Например, взяв в руки две сумки, вы сможете оценить, что одна из них тяжелее другой, но не сможете с уверенностью сказать, сколько весит каждая сумка. В следующих разделах мы расскажем о некоторых наиболее популярных методах гибкой оценки.

Покер планирования

Покер планирования - один из самых популярных методов гибкой оценки. Он гарантирует активное участие всех членов через игру. Игра начинается с раздачи каждому члену группы набора карт. Каждый набор карт содержит собственный номер, в значительной степени соответствующий последовательности чисел Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34 и т.д. Как видно из рисунка 4, эти числа представляют собой относительную оценку описания функциональности (сюжета). Ноль означает, что сюжет слишком тривиальный; 20 означает, что сюжет нужно разбить на более мелкие. Числа Фибоначчи используются для того, чтобы создать неопределенность, которая ведет к обсуждению, особенно при больших числах. Но вернемся к игре. Каждый член команды начинает оценивать некоторый сюжет и показывает карту с оценкой этого сюжета. Члены группы, давшие наибольшую и наименьшую оценки, излагают свои аргументы. Эти объяснения заставляют команду переосмыслить рассуждения, после чего участники обмениваются опытом и предположениями. Вся команда переоценивает сюжет снова и снова, пока не придет к консенсусу. Подробнее см. на веб-странице Planning poker.

Рисунок 4. Пример карт покера планирования

Определение размера футболки

При этом методе раздаются карты размеров. Каждая карта содержит определенный размер: очень малый (XS); малый (S); средний (M); большой (L) и очень большой (XL). Карты раскладываются на столе горизонтально. Члены команды сообща распределяют сюжеты по категориям соответствующего размера. Когда все сюжеты рассортированы, команда присваивает каждому размеру эквивалентный сюжетный балл, как показано в таблице 1. Например, размер XS соответствует 1 баллу, S - 2 баллам, M - 4 баллам и т.д. Этот метод гарантирует, что все сюжеты будут оценены в баллах.

Таблица 1. Размеры футболки в сюжетных баллах

Размер футболки	Сюжетные баллы
XS	1
S	2
M	4
L	6
XL	10

Аналогично, другие методы поощряют использование более творческих и интересных методов оценки. Например, используется вес собаки, причем чихуахуа считается самой легкой, а датский дог - самым тяжелым. В другом методе используются размеры животных, например, мышь самая маленькая, а слон самый большой.

Оценка большого числа сюжетов

Что делать, если нужно быстро оценить большое количество сюжетов? В этом случае используется оценка относительных масс. Это быстрый способ классифицировать и оценивать большие объемы работ. Каждому сюжету отводится карта. Секретарь берет из колоды сюжетных карт, лежащей на столе, одну и спрашивает у команды: "Считать ли этот сюжет большим, средним или малым?" В зависимости от ответа команды карта помещается в определенное место на столе. Если сюжет большой, карта кладется с левой стороны стола. Если малый, то с правой. Если средний, карта кладется в центре стола. Затем переходят к следующей карте, задается тот же вопрос, и новый сюжет размещается относительно предыдущего. Этот процесс продолжается до тех пор, пока на столе не будут рассортированы все сюжеты.

Еще один подобный метод, предназначенный для быстрой оценки больших объемов работы, называется стеной оценок. Для сортировки сюжетов в нем используется большая пустая стена. Верхние сюжеты имеют наивысший приоритет, а нижние - самый низкий. Размер сюжета также может определяться на стене по горизонтали. Слева располагаются наименьшие, а справа - самые большие.

Сравнение между гибкими и обычными методами оценки

Первые вопросы, которые приходят на ум: "Какой же метод следует использовать?" и "Какой метод лучше?". Это спорные вопросы, на которые нет точного ответа. Существует множество исследований в этой области, которые доказывают, что это зависит от многих факторов, таких как тип проекта. Эти факторы приведены в таблице 2.

Таблица 2. Сравнение гибких методов с обычными

	Гибкие методы	Обычные методы
Размеры проекта	Малые и средние проекты	Крупные проекты
Жизненный цикл программного обеспечения	Гибкий жизненный цикл. Например, экстремальное программирование (XP) и scrum	Традиционный жизненный цикл. Например, водопад и спираль
Размер группы оценки	Как правило, от пяти до девяти человек.	Может быть меньше пяти человек. Может быть один, если это эксперт в предметной области.
Сотрудничество в команде	Высокая степень участия всех членов группы, таких как ответственный за продукт, группа разработчиков, группа тестирования.	Не все методы требуют участия всех членов группы.
Исторические сведения	Методы оценки не требуют исторической информации.	Большинство методов зависит от исторической информации.
Время оценки	оценка может занимать много времени, так как она основана на достижении консенсуса.	Может занимать меньше времени по сравнению с гибкими методами.
Система присвоения баллов	Сложность баллов. Например, размеры сюжетных баллов.	Параметрические баллы. Например, Functional Point Analysis и Use Case Points.
Принцип оценки	Относительная оценка.	Абсолютная оценка.

Составляющие лучшей оценки

Выбор хорошего метода оценки - необходимое условие успеха вашего проекта. Оценка - один из наиболее важных элементов планирования. Чем точнее оценка, тем выше качество управления конечными результатами и меньше простоев. Так как же измерить, хороши ли ваши оценки? Определите разницу между оценкой и реальностью. По определению, хорошая оценка в 75% случаев находится в пределах 25% от фактического результата (Конте, Дансморе и Шэнь, 1986 г.).
Какой бы метод оценки вы ни выбрали, существуют составляющие, которые непременно улучшат его.

• Понимание методов оценки. Чтобы определить, какой метод лучше всего подходит для вашего проекта, нужно знать все методы оценки.
• Использование мелких задач. Если разбить задачи на более мелкие части, будет проще понять, сколько времени займет их решение. Обычно ожидаемое время решения задачи должно отличаться от фактического менее чем на два дня.
• Сотрудничество в команде. Участие в оценке всей команды исключает любые неясности, связанные с задачей. Это помогает обмениваться информацией и опытом, повышая качество оценки. Это также повышает степень ответственности за оценку и задачу.
• Задавайте правильные вопросы. Каждая задача содержит неопределенность. Чтобы устранить эту неопределенность, нужно задавать правильные вопросы и пытаться найти ответы. Отбросьте предположения, чтобы добиться общего понимания границ задачи и рисков.
• Храните отчеты о своих реальных усилиях. Обучение на предыдущих оценках, безусловно, повышает их точность. Храните отчеты о фактических результатах оценки для последующего использования.

Заключение

Чтобы делать лучшие оценки, необходимо понимать и изучать разные методы. Важно знать возможные варианты и понять, какой из них отвечает потребностям вашего проекта. В этой статье приведен полный список методов оценки при использовании как гибких, так и обычных методов разработки. Он дает достаточно информации для понимания основ и ознакомления с каждым методом. Таблица сравнения гибких методов с традиционными поможет вам решить, какой из них выбрать. А общие рекомендации и обзор методов - стать лучшим оценщиком.