Руководство по Agile · Основы Agile
Зачем использовать Agile-управление проектами? Преимущества и компромиссы
Agile популярен, но популярность — не причина его внедрять. В этом руководстве описано, что Agile действительно улучшает, чего он стоит и как понять, подходит ли он вашему проекту.
Главное
- Главное преимущество Agile — снижение риска создать не то, что нужно.
- Для этого нужны доступный человек, принимающий решения, работа, которую можно разделить, и стабильная команда.
- Если этих условий нет, предиктивный или гибридный подход может оказаться лучше.
Основные преимущества
- Меньший риск создать не то, что нужно. Частые обзоры с реальными пользователями выявляют недопонимание за недели, а не за месяцы.
- Более ранняя ценность. Пригодные к использованию части выпускаются, как только они готовы, поэтому выгоды появляются ещё до завершения проекта.
- Наглядный прогресс. Рабочие результаты и простые диаграммы делают статус наглядным, что укрепляет доверие заинтересованных сторон.
- Лучшая работа с изменениями. Новые приоритеты попадают в бэклог и рассматриваются на следующем планировании, без громоздкого процесса управления изменениями.
- Более высокое качество. Тестирование и проверка проходят в каждом цикле, а не втискиваются в конец.
- Более вовлечённые команды. Люди, которые сами планируют свою работу и видят её результат, как правило, более мотивированы.
Что нужно, чтобы Agile работал
- Владелец продукта или представитель клиента, который может принимать решения и участвовать в обзорах.
- Работа, которую можно разделить на небольшие части, каждая из которых приносит определённую ценность.
- Стабильная кросс-функциональная команда с навыками, позволяющими завершать работу без длительной передачи между исполнителями.
- Руководители, которые принимают, что содержание будет меняться, и оценивают успех по результатам, а не по следованию исходному плану.
- Время, чтобы команда могла проанализировать работу и улучшить её.
Когда предиктивный подход может быть лучше
Agile подходит не для каждого проекта. Предиктивный или гибридных подход часто подходит лучше, когда:
- Требования зафиксированы нормативными актами или контрактом и вряд ли изменятся.
- Результат нельзя использовать по частям: половина моста или половина миграции центра обработки данных не приносит ценности.
- Изменения на поздних этапах проекта крайне дороги или небезопасны.
- Клиент не может участвовать в регулярных обзорах.
Распространённые причины неудачного внедрения Agile
- Переименование старых практик («мы называем наше совещание по статусу стендапом») без изменения того, как принимаются решения.
- Фиксированные содержание, сроки и стоимость при ожидании гибкости Agile.
- Перегрузка команд работой, которую они не могут завершить за итерацию.
- Пропуск ретроспектив, из-за чего процесс никогда не улучшается.
- Оценка команд по скорости и их сравнение друг с другом.
См. как внедрить Agile с практическими шагами, позволяющими избежать этих ловушек.
Частые вопросы
Быстрее ли Agile-управление проектами, чем Waterfall?
Не обязательно по общей продолжительности, но Agile обычно даёт первые пригодные к использованию результаты гораздо раньше и тратит меньше времени на функции, которые никому не нужны.
Обходится ли Agile-управление проектами дешевле?
Может быть, в основном за счёт того, что не тратятся усилия на ненужную работу. Однако он требует больше времени клиента, а частое тестирование и релизы имеют свою стоимость.
Каковы основные преимущества Agile-управления проектами?
Меньший риск создать не то, что нужно, более ранняя ценность благодаря пригодным к использованию релизам, наглядный прогресс, более простая работа с изменениями, более высокое качество благодаря тестированию в каждом цикле и более вовлечённые команды.
Каковы недостатки Agile-управления проектами?
Он требует больше времени клиента, делает долгосрочные сроки и затраты менее определёнными и может плохо сочетаться с фиксированными контрактами или работой, которую нельзя разделить на пригодные к использованию части.
Когда не стоит использовать Agile-управление проектами?
Когда требования зафиксированы нормативными актами или контрактом, результат не имеет ценности до полного завершения, поздние изменения очень дороги или небезопасны, либо клиент не может участвовать в регулярных обзорах. Лучше может подойти предиктивный или гибридный подход.
Почему Agile-управление проектами иногда терпит неудачу?
Распространённые причины: отсутствие владельца продукта с реальными полномочиями, руководители, фиксирующие одновременно содержание и сроки, команды, которые на самом деле не кросс-функциональны, и внедрение встреч без соответствующего мышления. См. как внедрить Agile.
Повышает ли Agile-управление проектами качество?
Как правило, да, потому что тестирование и проверка проходят в каждом цикле, а не втискиваются в конец, и проблемы обнаруживаются, пока их ещё дёшево исправить.
Снижает ли Agile-управление проектами риски проекта?
Да, в основном за счёт раннего выявления ошибочных предположений. Частые обзоры с реальными пользователями уже через несколько недель показывают, создаёт ли команда то, что нужно.
Подходит ли Agile-управление проектами для небольших проектов?
Часто да. В небольших проектах можно применять облегчённые Agile-практики, такие как бэклог, доска и короткие циклы обзора, без полной нагрузки фреймворка.
Как убедить руководство использовать Agile-управление проектами?
Начните с пилота на подходящем проекте, заранее согласуйте несколько показателей результата и как можно раньше покажите рабочие результаты. Факты из вашей собственной организации убеждают сильнее, чем общие утверждения.
Можно ли сочетать Agile-управление проектами с каскадной моделью (Waterfall)?
Да. Многие организации используют предиктивный план с вехами для управления, а внутри каждой фазы — Agile-поставку. См. Agile или Waterfall.