Fixed Price: Как НЕ нужно эстимировать

Автор: Александр Якима (www.enter-agile.com)

Fixed-Price контракт - неидеальная среда для agile-разработки. Говоря более точно: просто для разработки. Мы не всегда можем более-менее точно оценить, сколько времени у нас уйдет на приготовление завтрака или на поход на работу, хотя делаем эту рутину регулярно. Что уж говорить о разработке ПО, где элемент уникальности - наиболее характерная черта...

Тем не менее, Fixed-price - это реальность в мире разработки, в частвности в аутсорсинге. И так или иначе, FP-проекты приходится оценивать и давать коммитмент. В этом посте мы абстрагируемся от практически всего и кратко постараемся рассмотреть ключевой вопрос:

Как эстимировать Fixed-Price проект?

Как обычно проходит эстимирование? Ответить можно "наоборот", рассмотрев, что обычно приводится в качестве эстимейта в пропоузале или каком-то другом подобном документе. Картина обычно следующая:

Таблица 1. Традиционная разбивка при оценивании Fixed-price проекта.

Более или менее детализировано, но идея одна и та же - декомпонируем по задачам. Грубо говоря, вот вам время на разработку, вот на работу с требованиями и т д. При большей детализации выяснится, что мы рассчитываем столько-то времени на разработку схемы базы данных, столько на написание хранимых процедур и триггеров, столько на ORM-уровень, бизнес-логику мы напишем за столько, а вот столько-то у нас займет UI. Конечно, при этом (в частвности при самом процессе эстимирования) особой уверенности нам добавляет часто то, что мы комбинируем "лэйерную" декомпозицию с разбивкой "модульной", получается что-то вроде матрицы. Ну как тут можно ошибиться???

Особенно иронично то, что так часто выглядят эстимейты проектов, которые команды-аутсорсеры клянутся сделать в рамках методологии "agile" (кавычки обязательны). В любом случае, вот моя принципиальная рекоммендация:

Не делать декомпозицию по задачам / модулям / лэйерам!

А как же делать? Отвечу вопросом: а как вы собираетесь имплементировать этот agile-проект? Ясно ведь как: закоммитимся на определенный объем пользовательских историй в первой итерации, потом так же во второй и т. д. Прекрасно, значит так нужно и эстимировать. Отсюда правило:

Декомпонируйте исходя из ценности для пользователя - разбивайте проект на фичи или пользовательские истории.

Оценка тогда выглядит совершенно сходно с бэклогом релиза (в данном случае предполагая, что результат работы над текущим FP-проектом как раз и является этим релизом), а процесс разбиения и эстимирования очень близко должен напоминать типичную процедуру планирования Agile-релиза.

Таблица 2. Agile-оценка.


Таким образом достигается несколько принципиально важных целей:

1. При разбиении по пользовательским историям или фичам "анализ требований" получается более полным и адекватным, так как служит критической цели - оченке проекта. В случае №1 это не так, четкой внутренней необходимости для команды в адекватном анализе требований нет.

2. Заказчик и команда получают дполнительную степень свободы в планировании и выполнении: теперь заказчику понятно, что он может отложить на будущее, а что важно делать в первую очередь. Когда перед тобой список задач (напр., разработка, тестирование...) то как увидеть, чем можно пожертвовать? Тестированием модуля А или разработкой модуля Б?

3. Вероятность "вписаться" в рамки обещаний значительно выше, так как планироание иммитирует ход разработки, а не является иным по природе. Более того, если оценку дает команда уже работвашая совместно и если (при некоторых допущениях) можно говорить, что проект "типичен" или хотя бы не экзотичен, то априори команда уже имеет полезную для этого случая способность оченивать пользовательские истории ( напр., в стори-поинтах). Стори-поинт - это ни что иное, как единица измерения трудозатрат команды по разработке полностью всей истории, всех 100% - от анализа требований до разработки и тестирования. Этот факт обуслалвливает большую надежность оценки.

Точных оценок вам!

No comments:

Post a Comment

 
Powered by Blogger