Взболтать, но не смешивать.

Джеймс Бонд, «Бриллианты вечны», Ян Флеминг, 1956 г.

Проблематика

В сети множество материалов по гибким методологиям управления проектами. Моя цель – дать конкретику в подходе, скомбинировав лучшие практики современного проектного менеджмента на основе существующих Agile практик.

Секрет состоит в том, что используемые подходы – отлично дополняют друг друга:

1. Agile дает общие основополагающие принципы.

2. Lean вносит некоторые дополнительные полезные акценты в Agile, например, позволяет правильно приоритезировать задачи, что бы обеспечить максимум пользы при экономии ресурсов.

3. SMART позволяет формировать четкие и понятные цели и задачи высокого уровня готовности к включению в бэклог.

4. SCRUM дает готовый эффективный регламент для проведения работ командой проекта.

Базовые принципы

Так уж получается, что без понимания базовых принципов сложно обойтись. Но благо они довольно простые, и они сформулированы в Agile-манифесте. Вот основные моменты, на которые хотелось бы обратить особое внимание:

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

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

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

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

Хочется добавить в список также лучшие практики из Lean, в том виде как они были задуманы в системе производства Toyota, особенно в той части где они могу усилить Agile-методологию. И это не только непрерывное улучшение (Kaizen), которое в Agile выражается в практике регулярных ретроспектив и непрерывного улучшения разработки продукта и рабочих процессов. Я имею ввиду следующее:

1. Оптимизация потока. Акцентирование внимания на гладкости и эффективности потока работы, минимизации времени цикла и работы в процессе. Это выражается в улучшении практик непрерывной интеграции и непрерывной доставки (CI/CD), а также в управлении очередями задач.

2. Управление запасами. Процесс предполагает своевременное производство и доставку. Соответствует стремлению минимизировать работу в процессе (Work in Progress –количество задач и рабочих элементов, которые находятся в работе в моменте) и проверке, что команды не перегружены и могут быстро реагировать на изменения.

3. Решение системных проблем. Ориентация на выявление корневых причин проблем, чтобы внести улучшения на системном уровне, вместо того чтобы бороться с симптомами. Помогает выявлять фундаментальных причины проблем в процессах разработки, т.е  при обнаружении проблемы важно уделить должное внимание диагностике корневых причин ее появления.

Бэклог - как основа всего процесса

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

При разработке ПО, как правило, работают с двумя ключевыми видами бэклога:

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

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

Формированием и управлением продуктового бэклога занимается Владелец продукта. Для этого последовательно проводятся следующие мероприятия:

1. Формирование видение продукта. Очень важно иметь четкое видение продукта, которое определяет его ценность и направление разработки.

2. Сбор требований. Необходимо собрать требования от всех заинтересованных сторон: клиентов, пользователей, команды разработки, продаж, маркетинга и так далее. Это могут быть функциональные и нефункциональные требования, улучшения, баги и так далее.

3. Создание пользовательских историй. Следующий шаг - преобразование требований в пользовательские истории, которые описывают функционал с точки зрения пользователя и его ценность.

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

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

Дальнейшее управление продуктовым бэклогом – это итеративный процесс. Лучшие практики и подходы к управлению бэклогом могут различаться в зависимости от конкретной команды, продукта и организационной культуры. Непрерывное совершенствование процессов, открытость к обратной связи и адаптация к изменениям – ключ к успешному управлению продуктовым бэклогом.

Как правило управление продуктовым бэклогом заключается в следующем:

1. Поддержание приоритетов. Регулярный пересмотр и адаптация приоритетов в соответствии с меняющимися бизнес-целями и условиями рынка.

2. Регулярные обзоры. Продуктовый бэклог должен постоянно пересматриваться и обновляться. Для этого используется обратная связь от ретроспектив и обзоров спринтов, чтобы вносить необходимые изменения.

3. Управление изменениями. Вы должны быть готовы к изменениям в требованиях и приоритетах. Существующие гибким методологиям управления проектами приветствуют изменения, и гибкое управление бэклогом помогает адаптироваться к ним.

4. Поддержка связи с Релизами. Для этого требуется связывать элементы бэклога с релизами продукта, планируя, какие функции будут выпущены и когда. Это поможет в планировании и предоставлении ценности пользователям.

На основании продуктового бэклога формируется бэклог спринта. Формирование и управление бэклога спринта требует чёткого общения и сотрудничества. Цель этих действий — гарантировать, что команда остается сфокусированной на задачах спринта и эффективно движется к достижению целей спринта и, в конечном счете, целей продукта.

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

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

В начале были правильные цели

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

S – Specific (Конкретность). Цель должна быть четко сформулирована.

Что конкретно нужно достичь? Кто будет задействован? Где это будет происходить?

M – Measurable (Измеримость). Цель должна быть измеримой, чтобы можно было отслеживать прогресс.

Как мы будем измерять прогресс? Какие показатели успеха?

A – Achievable (Достижимость). Цель должна быть реалистичной и достижимой с учетом ресурсов и времени.

Реально ли достичь эту цель? Какие ресурсы нам понадобятся?

R – Relevant (Релевантность). Цель должна соответствовать общим целям и стратегии.

Почему эта цель важна? Как она соотносится с другими целями?

T – Time-bound (Ограниченность во времени). Цель должна иметь четко определенные сроки.

Когда эта цель должна быть достигнута? Каковы промежуточные этапы и сроки?

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

Цели оцениваются по каждому критерию с последующем итоговым суммированием баллов. Цели с наибольшим количеством баллов получают высший приоритет. Это количественный способ приоритизации, который помогает объективно оценить, насколько хорошо каждая цель соответствует принципам Lean:

1. Создание Ценности для Клиента (макс. 10 баллов). Оцените, насколько цель напрямую увеличивает ценность для клиента. Больше баллов присваивается целям, которые явно улучшают продукт или услугу для клиента.

2. Устранение Отходов (макс. 10 баллов). Оцените, насколько эффективно цель способствует уменьшению или устранению отходов. Под отходами в IT-проекте понимаются:
   a. Разработка функций или кода, который не требуется клиенту или который идет далеко за рамки требуемой функциональности. Так что, как бы не парадоксально это звучало, усечение лишнего функционала – это один из способов убрать Отходы.
   b. Время простоя, когда команды разработчиков или члены команды ждут друг друга, например, ожидание зависимостей от других команд. Т.е. чем меньше зависимостей, тем ниже Отходы.
   c. Наличие ненужное перемещение данных или информации, которое не добавляет ценности, например, излишнее перенаправление задач между командами.
   d. Использование более сложных решений. Делать проще – один из способов устранения Отходов.
   e. Накопление незавершенной работы, т.е. устранение техдолга – еще один из способов устранения Отходов.
   f. Неэффективное использование навыков и знаний команды, например, когда высококвалифицированные специалисты выполняют рутинную или неподходящую для их уровня работу.

3. Итеративное Улучшение (макс. 10 баллов). Оцените, насколько цель поддерживает культуру постоянного улучшения и обучения. Высокие баллы – для целей, которые позволяют максимально быстро собирать обратную связь и улучшать результат.

4. Масштабируемость и Устойчивость (макс. 10 баллов). Оцените, насколько цель способствует долгосрочному росту и устойчивости. Больше баллов для целей, увеличивающих масштабируемость и устойчивость.

Определяем длительность спринта

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

1. Комплексность и размер проекта. Для больших и сложных проектов более длинные спринты могут быть более эффективными, так как они позволяют решать сложные задачи.

2. Способность команды к адаптации. Команды, способные быстро адаптироваться и реагировать на изменения, могут эффективно работать с более короткими спринтами, что позволяет чаще адаптироваться к изменениям.

3. Скорость обратной связи от заинтересованных сторон. Если проект требует частой обратной связи от клиентов или заинтересованных сторон, короткие спринты могут быть более подходящими. Это позволяет чаще демонстрировать прогресс и вносить корректировки.

4. Уровень опыта команды. Для команд, новых в Scrum или с меньшим опытом работы вместе, более короткие спринты могут помочь быстрее освоиться и улучшить коммуникацию и сотрудничество.

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

6. Работоспособность продукта. Важно, чтобы в конце каждого спринта команда могла представить работоспособный продукт или его часть. Длительность спринта должна позволять достигать этой цели.  Именно добавление ценности в конце спринта – самое важное условие успешного применения гибких методологий управления проектами. Это ключевой фактор успеха.

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

Подготовка релиза в конце спринта – не обязательно должна заканчиваться его установкой в продуктивную среду. Важно выдать сформированную и функционально протестированную поставку, готовую для дальнейшего движения по стадиям релизного цикла. В следующем спринте аналитики и разработчики переходят к новым задачам, а QA-инженеры, DevOps специалисты и релиз-менеджеры продолжают доводить релиз до установки в продуктивный контур. Так что по факту команда в рамках одного спринта параллельно ведет несколько релизов на разных стадиях релизного цикла. И это нормально. Главное, чтобы организация работы в команде позволяла эффективно поддерживать этот процесс.

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

Все это позволит получить следующие положительные аспекты:

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

2. Меньший риск. Постоянные релизы с меньшим объемом изменений снижают риск серьезных проблем по сравнению с крупными релизами.

3. Непрерывное улучшение. Регулярное обновление продукта помогает команде улучшать его в соответствии с актуальными трендами и обратной связью.

4. Улучшенное вовлечение клиентов. Постоянные обновления могут повысить уровень вовлеченности и удовлетворенности клиентов, так как они видят, что продукт постоянно развивается и улучшается.

Важные рекомендации:

1. Оценка влияния. Прежде чем переходить на такой режим, важно оценить, как это повлияет на ваших клиентов, вашу команду и качество продукта.

2. Гибкость. Будьте готовы адаптировать стратегию релизов в ответ на полученную обратную связь.

3. Автоматизация. Чтобы уменьшить нагрузку на команду, рекомендуется автоматизировать как можно больше процессов (тестирование, развертывание, мониторинг).

4. Управление ожиданиями. Ясно коммуницируйте с клиентами и пользователями о планах релизов и их частоте, чтобы управлять их ожиданиями.

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

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

Строим эффективный процесс

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

1. Планирование спринта
   
   Продолжительность: Обычно 2-3 часа в начале спринта.

   Цели: Определить, что будет сделано в спринте и как команда собирается это выполнить.

   Процесс: Владелец продукта представляет приоритетные задачи из продуктового бэклога. Команда обсуждает и выбирает задачи, которые они могут завершить в течение спринта, и планирует их выполнение.

2. Ежедневный дейли
   
   Продолжительность: 15-30 минут.

   Цели: Краткое обсуждение того, что было сделано вчера, что планируется сделать сегодня, и выявление любых препятствий.

   Процесс: Каждый член команды отвечает на три вопроса для синхронизации действий команды и идентификации препятствий

3. Обзор спринта
   
   Продолжительность: Обычно 1-2 часа в конце спринта.

   Цели: Представление работы, выполненной в спринте, заинтересованным сторонам и получение обратной связи.

   Процесс: Команда демонстрирует что было разработано в спринте и обсуждает с заинтересованными сторонами.

4. Ретроспектива cпринта
   
   Продолжительность: Обычно 1-1,5 часа в конце спринта.

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

   Процесс: Команда обсуждает процессы, инструменты и взаимодействия в рамках спринта, идентифицирует улучшения.

5. Уточнение бэклога
   
   Продолжительность: Обычно проводится в середине спринта на 1-2 часа.

   Цели: Обновление и уточнение продуктового бэклога, включая оценку и приоритизацию задач.

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

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

Оценка эффективности по метрикам

Наибольшую пользу приносят метрики, которые способствуют прозрачности, улучшению процессов и повышению эффективности работы команды. Наиболее полезные метрики для оценки эффективности команды включают:

1. Скорость команды. Отражает, сколько работы команда способна выполнить за спринт. Эта метрика помогает в прогнозировании и планировании будущих спринтов.

2. График сгорания. Показывает оставшуюся работу в спринте и помогает команде оценить, находятся ли они на пути к достижению целей спринта.

3. Время цикла. Отслеживает время от начала работы над задачей до её завершения. Помогает выявлять узкие места в рабочих процессах и способствует улучшению временной эффективности.

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

5. Качество и стабильность продукта. Метрики, такие как количество багов, время на их исправление и покрытие тестами, дают представление о качестве продукта и эффективности тестирования.

6. Удовлетворенность клиента (Customer Satisfaction). Прямой отзыв от клиентов о продукте или услуге. Это помогает понять, насколько хорошо продукт соответствует потребностям клиентов.

7. Эффективность ретроспективы. Оценивает, насколько эффективно команда использует ретроспективы для улучшения своих процессов и рабочей среды.

8. Уровень вовлеченности команды. Оценивает, насколько члены команды вовлечены и мотивированы. Высокий уровень вовлеченности часто коррелирует с высокой производительностью.

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

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