Искусство Agile-разработки. Теория и практика гибкой разработки ПО - страница 26



Выберите команде подходящую для обучения задачу

У любой команды есть цель: ее место в общей стратегии организации. (См. раздел «Цель» главы 7.) Когда команда только начинает учиться Agile, важно выбрать цель, которая поможет в учебе. В практическом смысле это означает три вещи.

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

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

• Совершенно новая кодовая база (green-field codebase). Команды, изучающие практики поставки, должны многому научиться, и это проще делать с нуля. В конце концов им придется научиться работать с существующим кодом. Команды, у которых есть опытный коуч в области поставки, могут игнорировать это требование, если тот согласится. Таким же образом могут поступить и те команды, которые изучают уровни, отличные от поставки.

Если есть важный дедлайн…

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

Если нет значимой работы с нуля…

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

Смените водопадные подходы в управлении

Руководство (Governance) – это процесс того, как работа согласовывается, отслеживается и управляется на высоком уровне. В большинстве организаций политики такого руководства предполагают водопадный подход в разработке. Часто это требует подготовки предварительной документации или четких переходов от фазы к фазе (phase gates). Все это означает предиктивный подход к планированию.

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

Если требуется водопадная модель управления…

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

Чаще всего руководство требует составления четких предварительных планов и бюджета. Простейший способ удовлетворить это требование – использовать сначала любой доступный вам подход, а затем, после того как вы пройдете через согласование проекта, начать Agile-часть процесса. В качестве альтернативы для команд, свободно владеющих навыками на уровне как фокусировки, так и поставки, вы можете заложить 4–8 недель на планирование, начать нормально работать и создать качественную дорожную карту (Roadmap). (См. раздел «Дорожные карты» главы 10.)