Agile: оценка и планирование проектов

Избегайте конца квартала

Несмотря на соблазн совместить итерации с концом месяца, я всеми силами стараюсь не допустить этого. Если вы привяжете итерации к концу месяцев, одна из каждых трех итераций будет совпадать с концом финансового квартала. Хотя это не такая уж проблема в частных компаниях, этого нельзя сказать о публичных компаниях, для которых очень важно выполнение квартальных целевых показателей по выручке.

Мне довелось участвовать в одном проекте, в котором выпуск нового релиза был запланирован на пятницу 31 марта 2000 г. Этот релиз был ключевой целью девятимесячного периода работы компании (такой срок является предельным для отдельно взятого релиза). За две недели до срока выпуска релиза наш владелец продукта отправился в отпуск со своими детьми школьного возраста. Находясь в Диснейленде, он доблестно пытался решить по телефону несколько очень важных для нас вопросов. Однако его отсутствие пришлось на критический момент, и нам так и не удалось завершить определенную работу в последней итерации перед выпуском крупного релиза.

После возвращения владельца продукта мы смогли решить все оставшиеся вопросы в течение более короткой однонедельной итерации. Это отодвинуло дату выпуска релиза с 31 марта на 7 апреля. Хотя задержка на одну неделю не кажется критической для проекта со сроком выполнения девять месяцев, на практике она привела к переносу поставки продукта с одного квартала на другой, а это имело огромное значение для публичной компании. Из-за того, что плановая поставка нескольких сотен копий, намеченная на 31 марта, не состоялась, выручку от продаж и обновлений уже нельзя было признать в первом квартале. С таким же успехом эту поставку можно было осуществить 30 июня, а не 7 апреля.

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

Резюме

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

• длина релиза, над которым ведется работа;

• уровень неопределенности;

• простота получения обратной связи;

• продолжительность сохранения неизменности приоритетов;

• готовность продолжать работу без получения внешней обратной связи;

• издержки итерационного подхода;

• быстрота появления ощущения цейтнота.

Вопросы для обсуждения

1. Какая длина итерации больше всего подходит для вашего текущего проекта?

2. Что изменится в вашем проекте при использовании однонедельных итераций? Что изменится в случае использования двухмесячных итераций?

Глава 16 Оценка скорости