Эта книга выпущена в сотрудничестве PMI и AgileAlliance. Материалы относятся к стандартам и руководствам. Цель издания — дать более глубокое понимание Agile, его использования, а также синхронизировать разные аспекты гибкого мышления.
Руководство гласит, что оно "служит ключом к пониманию пути перехода к гибкости в управлении проектами".
Где применяется Agile
- Разработка ПО и IT-проекты,
- промышленное производство,
- образование,
- здравоохранение и другие сферы.
Скорость изменения — вот главный фактор, которые заставляет большие компании исследовать Agile-подходы.
Основные принципы
4 ценности из Agile-манифеста и 12 уточняющих принципов распространяются не только на IT, но и на другие отрасли.
Прочитать ценности и принципы Agile
Они взаимосвязаны в следующую схему:
гибкий образ мышления > ценности > принципы > практики (методы, фреймворки и т.д.)
Авторы книги также добавляют, что в результате перехода команда не должна преследовать лишь формальное соответствие Манифесту, а должна обеспечивать поставку ценности для бизнеса.
Для каких проектов подходит Agile
Это проекты с высокой неопределённостью, сложные и рискованные разработки. Частая поставка продукта по частям помогает снизить потери и объём доработок, так как проект получает постоянную обратную связь.
Таким образом, это проекты, которые и/или:
- нуждаются в исследовании,
- быстро изменяются,
- имеют неизвестные требования,
- имеют неясную цель.
Если проект не соответствует ни одной из этих характеристик, он может рассмотреть для себя другие жизненные циклы: предикативный, итеративный, инкрементальный. Их описанию в руководстве посвящена отдельная глава. Для оценки приемлемости Agile в конце издания есть приложение с разными моделями.
Авторы не настаивают исключительно на применении Agile-подходов. В ходе работы, организации и отдельные команды могут сменить несколько моделей, что по сути является гибридным подходом. Этот же гибридный подход часто является переходным от старых принципов управления проектов к новым, основанным на гибком мышлении.
Выбор зависит от целесообразности для лучшего создания ценности.
Комбинирование Agile-подходов
Контекст каждого проекта уникален. Фреймворк не пишется под каждую команду, но участники могут адаптировать и комбинировать разные практики. Часто команды используют один фреймворк как основу и дополняют его в зависимости от потребностей. Например, распространена комбинация Scrum, Kanban и XP.
В приложении к книге перечислены некоторые конкретные факторы проекта и варианты для адаптации популярных подходов.
Создание agile-среды
Для управления проектом по Agile нужно, чтобы команда понимала и принимала Agile-мышление. Над этим придётся работать в первую очередь. Для того чтобы помочь команде понять Agile, требуется ввести роль "обслуживающего лидера" (лидера-слуги). Он помогает выстроить подход к созданию продукта:
- "почему?" — определить общую цель,
- "кто?" — вовлечь каждого и создать соответствующую среду,
- "что?" — оценить результат, поставленную ценность, а не только процесс.
Такой лидер помогает команде расти. Характеристикам и обязанностям "обслуживающего лидера" посвящена четвёртая глава.
Вторая роль, которая выделяется во всех Agile-подходах, — это роль команды разработки. Она должна быстро создавать продукт, получать обратную связь и улучшать его дальше.
Общие принципы, которые относятся к гибким командам, — это:
- количество от 5 до 9 человек,
- лучше располагаться face-to-face, в одном кабинете,
- рабочее время посвящено только одной команде,
- самоконтроль,
- весь набор компетенций для создания продукта внутри команды,
- в дополнение к профессионалам команды растят T-образных специалистов (которые имеют основные и дополнительные навыки).
Роль как команды, так и фасилитатора и владельца продукта описаны в книге более подробно.
Мы тоже писали о них в отдельных статьях:
о scrum-мастере,
о владельце продукта.
Реализация Agile
У проекта должен быть устав продукта/проекта, а команда постоянно формирует свои рабочие правила, собственный устав команды. Обычно они включают определение "Сделано", правила тестов, ценности команды, распределение работы по ролям в разных случаях, цель проекта и т. д.
Авторы выделяют ещё несколько распространённых практик Agile:
- ретроспективы,
- короткие итерации,
- подготовка бэклога,
- уточнение бэклога,
- ежедневные летучки,
- демонстрация работы заказчику,
- планирование итерации.
В дополнение к организационным практикам есть практики исполнения. Они наиболее разработаны для IT-команд. Например, это непрерывная интеграция, тестирование на всех уровнях, разработка на основе тестов, исследования перед реализацией и т. д.
В конце главы авторы приводят таблицу "болевых точек" команд и возможные решения проблем с применением разных практик.
Измерения проектов
В Agile используют метрики, которые реально отражают статус проекта. Измеряется только то, что уже сделано. Остальное носит статус прогноза, который тем точнее, чем ближе срок выполнения.
В Agile-подходах определяется скорость разработки через диаграммы сгорания или выгорания, а также средний срок цикла (особенно при работе "с внешним миром", так как в нём учитывается время ожидания). Популярные и полезные метрики для проектов перечислены в соответствующей главе.
Организация и Agile
Каждый проект находится в контексте. Лидерам важно изучить раздел книги, посвященный этому, чтобы создать оптимальную среду для своих команд. Правила кратко и конкретно сформулированы в 6-ой главе, поэтому не стоит читать их в пересказе. Этот раздел дополняет книга "Управление изменениями в организации. Практическое руководство".
Это издание дополнено примерами и заметками "на полях", которые подобрали эксперты из AgileAlliance. Несмотря на статус руководства, оно написано неформально, более простым языком. Для развития упомянутых тем даются ссылки на известные работы. Нам кажется, что эта книга подойдет для руководителей, которые слышали о гибких подходах, но ещё не решили, внедрять Agile или нет.
