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

Мой опыт говорит о том, что в течение проекта такая возможность должна появляться не менее четырех-пяти раз. Таким образом, если общая продолжительность проекта составляет четыре месяца и более, то вполне можно рассмотреть целесообразность использования месячных или четырехнедельных итераций. Если же общая длина релиза меньше, то в проекте необходимо использовать пропорционально более короткие итерации.

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

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

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

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

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

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

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

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

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

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

Какую бы длину итерации вы ни выбрали, лучше придерживаться ее и не менять то и дело. При использовании постоянной длины итерации у команд вырабатывается естественный ритм. Когда я начал заниматься agile-разработкой и применять один из ранних вариантов методологии Scrum (Takeuchi and Nonaka, 1986; DeGrace and Stahl, 1990), мои команды обычно выбирали длину каждой итерации в зависимости от объема работ, который предполагалось выполнить. За двухнедельной итерацией могла следовать шестинедельная итерация, а за ней — четырехнедельная и т. д. Опыт, полученный в результате выполнения множества проектов, показал, что команды намного лучше подгоняют объем работ к длине итерации, а не длину итерации к объему работ.