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

Как говорилось в главе 14 «Планирование итерации», команда, на которой лежат обязанности по обслуживанию или поддержке, помимо новой разработки, всегда резервирует определенное время на работы, связанные с обслуживанием и поддержкой. На рис. 15.1 показана реальная ситуация, в которой некто предлагает команде идею, не укладывающуюся в ее резерв на обслуживание и поддержку.

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

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

Мой коллега Нильс Малото (Malotaux, 2004) подчеркивает, что «пока дата окончания проекта где-то далеко в будущем, на нас ничто не давит и мы работаем неторопливо». Когда же дата завершения появляется на горизонте, мы начинаем работать интенсивнее. Дата завершения даже четырехнедельных итераций не так уж далека. Однако до нее достаточно много времени, чтобы многие команды ощущали заметно меньшее напряжение в течение первой недели, чем в течение четвертой и последней недели итерации.

Решением в этом случае является выбор такой длины итерации, которая выравнивает давление, ощущаемое командой. Идея не в том, чтобы усилить давление на команду («Вы должны закончить работу сегодня!»). Речь идет о более равномерном распределении нормального стресса по итерации подходящей длины.

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

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

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

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