Майк Кон - Agile - оценка и планирование проектов

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

Большой объем незавершенной работы замедляет прогресс команды. В софтверном проекте незавершенная работа связана с какой-либо функцией, разработку которой команда начала, но еще не закончила. Чем больше объем незавершенной работы, тем больше времени требуется на реализацию новой функции, поскольку все новое должно начинаться после завершения уже начатой работы. (Бывают случаи, когда реализацию новой функции необходимо ускорить, перепрыгнув через незавершенную работу, однако это лишь усугубляет проблему для следующей функции, реализацию которой невозможно ускорить.) Поэтому незавершенная работа приводит к увеличению времени цикла — в предыдущем разделе мы уже говорили о важности поддержания короткого цикла.

Одна из причин, по которым agile-планирование достигает цели, заключается в том, что вся незавершенная работа ликвидируется в конце каждой итерации. Поскольку работа не переносится автоматически вперед из одной итерации в другую, каждую итерацию планируют с чистого листа. Это означает, что работа над функцией, которая не завершена полностью в одной итерации, не обязательно продолжается в следующей. Зачастую продолжается, но не всегда. В результате мы получаем эффект полного отсутствия незавершенной работы в начале каждой итерации.

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

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

Agile-подход к оценке и планированию успешно устраняет эту проблему через отслеживание прогресса только на уровне команды. Это одна из причин, по которым в главу 14 «Планирование итерации» включена рекомендация для членов команды воздерживаться от принятия обязательств по выполнению конкретных задач во время планирования итерации. Аналогичным образом не должны составляться индивидуальные диаграммы выгорания — составляется только общекомандная диаграмма выгорания.

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

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