Текст книги "Agile. Процессы, проекты, компании"

4.4. Ритуалы

Средних менеджеров волнует, делалось ли так раньше и что подумают люди? Для хороших важно, чтобы проблема была решена.

Неизвестный источник

Спринт

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

Во время спринта не допускается внесение никаких изменений, которые бы повлияли на цель спринта; состав команды и цели остаются неизменными. Если в силу каких-то важных причин появляются новые требования, их рассмотрение и внесение в объем работ желательно перенести на конец текущего спринта. При форс-мажорных обстоятельствах под влиянием заинтересованных лиц, команды или же скрам-мастера только владелец продукта может остановить спринт до окончания его временных рамок. Спринт также отменяют и в том случае, если его цели перестают быть актуальными. Это может произойти вследствие смены направления работы компании, изменения технологий или рыночных условий либо когда в силу некоторых обстоятельств в нем уже нет необходимости. При отмене спринта все выполненные и «готовые» элементы из журнала требований продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску инкремент функциональности. Все остальные требования переоцениваются и возвращаются в журнал требований продукта. Члены команды должны перегруппироваться при планировании нового спринта и приступить к нему.

Встреча по упорядочению журнала требований продукта (Backlog Refinement Meeting, Backlog Grooming)

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

Процесс планирования спринта и встреча по его планированию

Встреча по планированию спринта проводится в самом его начале, после встречи по «причесыванию» или одновременно. Условием ее качественного проведения является определение владельцем продукта приоритетов на следующий спринт. Тогда команда совместно решает, какой план действий и что же конкретно они будут делать во время этого спринта, как достигнуть его цели. Планирование занимает обычно несколько часов и состоит из двух одинаковых по длительности частей. При планировании спринта команда отвечает на следу ющие вопросы: 1) что будет сделано в этом спринте, что будет разработано в инкременте продукта по результатам работы в следующем спринте и 2) как максимально эффективно выполнить работу по созданию этого инкремента, как будет проделана выбранная работа?

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

Отвечая на второй вопрос, команда решает, каким образом воплотить отдельную функциональность в готовый инкремент продукта, формируя журнал требований спринта. Команда планирует именно такой объем работы, который она в состоянии выполнить за спринт. Запланированная работа разбивается на требования, которые можно выполнить за день или менее. Команда сама организует свою работу, планируя поэтапность выполнения требований из журнала требований спринта. Владелец продукта может присутствовать на второй части планирования спринта, чтобы иметь возможность объяснить задания из журнала требований продукта и при необходимости помочь найти альтернативы. Если же команда исполнителей по результатам планирования решает, что у нее слишком много либо слишком мало работы, она может повторно обсудить требования журнала требований спринта с владельцем продукта. Команда может пригласить экспертов. После встречи по планированию спринта команда должна быть в состоянии объяснить владельцу продукта и скрам-мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь цели спринта и создать ожидаемый инкремент продукта. Самоуправляемость придает работе команды некоторую гибкость в отношении разработки функциональности во время спринта. Если же работа оказывается сложнее, чем ожидалось, тогда команда договаривается с владельцем продукта об изменении объема журнала требований спринта в текущем спринте. Цель спринта обязательно связана с целью всего проекта.

Летучка

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

Краткий план встречи по планированию спринта

С 09:00 до 12:30 (после каждого часа – перерыв 10 минут).

09:00–09:30. Владелец продукта разъясняет цель спринта, рассказывает про бизнес-процессы и требования из журнала требований продукта. Фиксируются время и место проведения демонстрации заказчику.

09:30–10:30. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов, и при необходимости дробит их на более мелкие. Иногда владелец продукта может изменить приоритет их исполнения. Выясняются все вопросы. Для наиболее важных заполняется поле «Как продемонстрировать сделанное заказчику».

10:30–11:30. Команда определяет набор, который войдет в спринт. Для оценки реальности обсуждается производительность команды.

11:30–12:30. Фиксируются время и место проведения ежедневной летучки. Отобранный набор историй разбивается на задачи, которые распределяются внутри спринта.

Во время летучки каждый член команды отвечает по кругу на три вопроса: 1) «Что было сделано мною после предыдущей встречи?»; 2) «Что будет сделано мною к следующей встрече?»; 3) «Какие есть проблемы или вопросы, что мне мешает продвигаться вперед?». Участники команды рассказывают друг другу о проделанной и планируемой работе, повышая свою ответственность. Обсуждается только самое важное, то, что будет двигать процесс реализации проекта вперед. Летучки усиливают вероятность достижения командой цели спринта. Интересной особенностью данных встреч является то, что они проводятся стоя (и даже иногда лежа с вытянутыми руками). Этим снижается риск затянуть мероприятие.

За активность и участие команды в летучках отвечает скрам-мастер, однако ответственность за содержательное проведение встречи лежит на команде. Поскольку скрам-мастер как ведущий встречи не наделен функцией руководителя, то он не имеет права раздавать задачи членам команды, а это значит, что они сами выбирают себе задачи к исполнению, отвечая на вопрос: «Что я планирую сделать?» Скрам-мастер обучает команду проведению такой встречи и контролирует ее срок. Иногда используется мячик или ручка и правило, что говорит тот, кто держит эти предметы.

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

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

Демонстрация

Цель демонстрации итогов работы команды заказчику – представить результаты деятельности в течение спринта всем заинтересованным лицам, включая заказчика, получить обратную связь и убедиться, что продукт спринта соответствует их ожиданиям и согласуется с целями проекта. Демонстрация иногда называется встречей по обзору спринта, sprint review или демо. Обязательно участвует вся команда. Не проводится никаких формальных презентаций, которые требуют затрат времени и усилий. Все быстро, предметно, по существу, в течение 2–3 часов. Помимо проверки созданного MVP, демонстрация способствует адаптации журнала требований продукта.

Демонстрация включает в себя следующие элементы:

♦ владелец продукта определяет, что готово, а что – нет;

♦ команда вспоминает, что прошло гладко во время спринта и с чем возникли трудности, а также то, как она с ними справилась;

♦ команда проводит демонстрацию того, что было сделано, и отвечает на вопросы по инкременту;

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

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

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

Ретроспектива

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

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

Ретроспектива в действии

Норм Керт, лидер ХР, рекомендует задавать следующие вопросы: что было сделано хорошо; что можно улучшить; чему мы научились; что поставило нас в тупик?

Длительность ретроспективы – от одного до трех часов.

Критерии готовности

Когда элемент журнала требований продукта или инкремент называют готовым, все должны понимать, что это означает. Разные команды и заказчики могут интерпретировать данный факт по-разному. Команда должна иметь общее единое определение того, что работа сделана. Без него Agile работать не будет. Это помогает команде в понимании того, сколько требований выбрать из журнала требований продукта во время планирования спринта, поскольку целью каждого спринта является разработка инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению готовности. Критерий готовности определяется владельцем продукта совместно с заказчиком и/или командой, помогает владельцу продукта принимать работу и избежать синдрома «готово на 90 %». Примерами таких критериев могут быть: «продукт установлен», «документация написана», «все найденные ошибки исправлены» и т. д.

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

Спринт 5
Другие Agile-фреймворки

Введение

Даже плохо реализованный Agile работает. Применение в небольшом количестве помогает.

Мартин Роу, колледж Петрок, Корнуолл

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

5.1. Канбан

Когда местность не совпадает с картой – ориентируйтесь по местности, а не по карте.

Инструкция швейцарской армии

Канбан как инструмент контроля времени и пополнения ресурсов «точно в срок» (just in time) в бережливом производстве (lean) уже упоминался выше. Термин «Канбан» (сначала был «камбан») в переводе с японского буквально означает «рекламный щит» или «карточка» и возник в супермаркетах, где пополнение продуктов на полках производилось по мере появления свободного места, а не в зависимости от запасов у поставщика (принцип «держи на полках только то, что нужно клиенту»). На примере такого решения по принципу «точно в срок» Тайити Оно разработал метод Канбан, который был применен в 1953 г. на главном производственном объекте компании Toyota.

В Agile-подходах Канбан обрел популярность намного позже, чем Скрам, и стал востребован как в ИТ-области, так и за ее пределами (Андерсон, 2010). Стали широко использоваться информационные канбан-доски, похожие на скрам-доски и состоящие из колонок с состояниями процесса или цикла разработки, через которые должен пройти поток работы (рис. 5.1). Самые простые доски имеют три колонки («Нужно сделать», «В работе» и «Сделано»), но их можно адаптировать с указанием состояний, которые, по мнению применяющих их команд, необходимы. Для продвижения работы в рамках процесса используется принцип «вытягивающая система» (pull system) – по завершении командой отдельного элемента она может вытянуть другой элемент в данный шаг (столбец). Карточки задач (индивидуальные карточки со всей необходимой информацией о задачах), передвигаемые по колонкам, способствуют визуализации и потоку работы через систему так, чтобы поток был представлен наглядно для всех. Количество карточек в каждой колонке фиксируется для ограничения объемов незавершенных работ (WIP) и оптимизации потока. Новая задача не может быть перемещена из одного столбца в другой, пока в нем не будут завершены задачи.

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

Рис. 5.1. Канбан-доска

Как и в случае со скрам-досками, можно применять физические или электронные доски (например, облачные решения Trello, позволяющие отображать доску у всех, даже удаленно работающих членов команды).

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

1. Максимальная прозрачность – визуализация потока задач, что позволяет видеть узкие места, очереди задач, отклонения и потери процесса и активно их устранять; равномерное распределение нагрузки среди участников проекта внутри итерации.

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

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

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

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

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

7. Команды считают главным фокусом непрерывную поставку и организацию потока работы через систему до ее завершения и не начинают новую работу до завершения текущих работ.

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

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

10. Мотивация людей на постоянное сотрудничество, совершенствование и обучение, сплоченная, замотивированная, опытная команда с хорошей коммуникацией и пересекаемыми навыками (участники с «Т-образной квалификацией», см. раздел 4.2).

Agile на практике

1. Марни Андес является директором по обучению и развитию в авиатранспортной компании скорой помощи Air Methods, работает с персоналом, включающим около 6500 медицинских и других сотрудников. До ее прихода компания не понимала, как быстро создаются все необходимые тренинги или проекты. Андес со своей командой начали использовать журналы требований продукта и их приоритизацию на доске в Trello, где перечислялись запросы на обучение, создаваемые тренинги и многое другое. При появлении нового запроса ему присваивают зеленый (сигнал к выполнению) или красный код (попадает в очередь). Каждый месяц заинтересованные стороны собираются для расстановки приоритетов, «голосуя демократически за то, что необходимо передвинуть в топ очереди». По словам Андес, применение таких журналов помогает «сотрудничать и работать с ожиданиями бизнеса относительно того, почему и как мы делаем то, что делаем». Она также говорит, что это создало синергию внутри группы. «Они видят, что делают другие группы, они не делают работу друг друга, так как всегда в курсе, что что-то уже создано… Все это повышает эффективность».

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

3. Об опыте повышения эффективности рекрутинговой команды, использовавшей канбан-доску для упорядочения телефонного скрининга кандидатов (рис. 5.2), рассказал Уильям Каммерселл (бывший тренер Agile, а сейчас старший менеджер по продуктам в CA Technologies). Обычно рекрутинговый процесс движется довольно стандартно от начала до конца, но на деле всегда существуют изменения. Рекрутинговая команда должна быть гибкой и эффективной, а также поддерживать прозрачность внутри и с заинтересованными сторонами. Если это не так, команда увязнет в процессах, кандидаты исчезнут, заказчики потеряют терпение или стоимость найма значительно возрастет. Команда стала использовать публичную физическую канбан-доску, размещая и демонстрируя работу, которую они вели для своих членов и других заинтересованных сторон. Это помогло понять, кто из команды перегружен, кто чем занят, как кто работает и как они могут помочь друг другу[7]7
  https://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/


[Закрыть].

Рис. 5.2. Канбан-доска рекрутинговой компании

В Канбане, в отличие от Скрама:

♦ команды, как правило, не связаны жесткими временными рамками и применяют итерации разной продолжительности;

♦ есть только роль владельца продукта (правда, не всегда); О члену команды можно вести несколько задач одновременно;

♦ никак не регламентированы встречи по статусу проекта, их можно проводить как удобно, где удобно или не делать вообще;

♦ каждое задание визуализируется – на какой оно стадии – и ограничивается НЗР («НеЗавершенной Работой») или WIP (Work-In-Progress);

♦ выше предсказуемость оперативного времени и большая надежность срока поставки;

♦ разрешается оставить неоконченную задачу (что-то ^отредактированное или недописанное) на одном из этапов, если ее приоритет изменился и есть другие срочные задачи.

ScrumBan/Скрамбан

Широко используется комбинация Скрама и Канбана, когда команды применяют Скрам в качестве рабочего фреймворка, а Канбан – в целях совершенствования процесса. При этом: 33 могут отсутствовать предварительно определенные роли – команда сохраняет свои текущие позиции;

✓ работа организована в небольших спринтах;

✓ истории (требования) помещаются на канбан-доску, и коман да организует свою работу с учетом ограничений на объемы текущей работы;

✓ для поддержания сотрудничества и устранения препятствий проводятся ежедневные летучки;

✓ определяется «триггер планирования», чтобы команда знала, когда снова заниматься планированием (например, когда уровень текущей работы опускается ниже предварительно установленного ограничения).