При разработке программного обеспечения большинство практик необходимы и обусловлены критериями завершенности: непрерывная интеграция, разработка через тестирование и т. д.
14.2 Характеризация контекста
Разработка вписывается в рамки одной или нескольких организаций. У организации есть культура, ноу-хау – другими словами, условия, влияющие на проекты, в которых будут внедряться Scrum и Agility. Очевидно, процесс будет сложнее в компаниях, чьи ценности и принципы далеки от перечисленных в Agile-манифесте.
Во время прелюдии (глава 13), как мы уже поняли, необходимо с самого начала принимать во внимание людей, контактирующих с командой – заинтересованные стороны. Мы вернемся к влиянию организации в главе 22.
Все проекты подвержены какому-либо внешнему влиянию, но оно выражается по-разному. Поэтому следует прежде всего определить контекст проекта.
Термин проект используется в силу привычки и его простоты, хотя и не фигурирует в лексике Scrum.
Scrum-мастер, как гарант Scrum, играет ключевую роль в контекстуализации. Если он в этом новичок, он может обратиться за помощью к консультанту, называемому Agile-коучем.
Команда также приглашается к участию.
Контекстуализация начинается во время прелюдии. Ее основные результаты помещаются в одну из граф шаблона прелюдии и используются для оценки жизнеспособности экосистемы.
Это уже требует определенного опыта в Agility. Из-за того, что контекст сложно определить на момент прелюдии, хорошо бы возвращаться к нему в конце каждого сезона, во время интерлюдии.
Во время первого Agile tour в Тулузе в 2008 мы с Филиппом Крухтеном представили ситуационную Agility.
Идея в том, что контекст разработки может быть определен при помощи нескольких характеристик. Мы предложили модель, основанную на работах Филиппа.
В модели представлены десять характеристик, позволяющих описать контекст. Модель адаптирована для разработки ПО, но может применяться и в других сферах деятельности.
Рисунок 14.2 – Характеристики для определения контекста проекта
14.3 Влияние на Scrum
В этом разделе речь не о пригодности или непригодности Scrum для того или иного контекста с его основными характеристиками.
Речь пойдет об адаптации практик к возможным ограничениям и о том, какие усилия необходимы для контекстуализации Scrum.
Потребуется много усилий, но это не означает, что использование Scrum не рекомендуется: они оправданы и существенно перекрываются положительными результатами внедрения практик.
Прежде чем приступать к адаптации, нужно ценности организации привести в соответствие с Agile-принципами. Scrum – это прежде всего система ценностей, образ мышления и состояние души. Нет смысла в адаптации практик без приверженности ценностям и этике. В этом цель прелюдии.
Адаптация – это про паттерны, представленные в главах с 1 по 12; дополнение – это про пракики, которые будут рассмотрены в главах с 15 по 22.
За перечисленными паттернами и антипаттернами следует номер главы, в которых они представлены.
Характеристики относятся к области, в которой разрабывается продукт.
• Динамика изменения
Под динамикой понимается частота изменений продукта, технологии его разработки или пользовательских запросов.
Возможность изменений во время разработки – зачастую есть фактор перехода к Agility. Люди часто думают: по правде говоря, мы не особо понимаем, что хотим, но думаем, что это изменит что-то в процессе разработки. Традиционный подход не работает, попробуем Аgile.
Scrum действительно открыт для перемен. Но команда защищена во время спринта. Никто не может добавить ей работы или изменить цель без ее одобрения.
Во многих организациях – и не обязательно маленьких – сложно соблюдать это правило: там сохраняется привычка работать в атмосфере суеты и срочности. Scrum вынуждает отложить все срочные задачи на следующий спринт, чтобы не мешать работе команды. Это не всегда возможно, и для некоторых компаний такое изменение может показаться слишком радикальным.
Поэтому важно, чтобы динамика изменений была высокой.
Высокая динамика изменений
✓ Попробовать паттерн: ограничение в процессе (20)
✓ Избегать антипаттерны: бэклог тикетов (6), планирование vs доработка (9)
✓ Дополнительная практика: применение Kanban в Scrum (20).
• Критичность
В случае сбоя программного обеспечения на кону могут стоять люди и экономика.
Критичность высока, если речь о человеческих жизнях или значительных экономических последствиях. При высокой критичности разрабатываемого продукта нужно подтверждать соответствие стандартам и проводить внешние аудиты, часто связанные с документами.
Высокая критичность
✓ Попробовать паттерны: эксперт внутри границ (3), сториотип (6)
✓ Избегать антипаттерны: цикл по V-модели (2), границы и зависимости (7), возвращение к начальному проектированию (13)
✓ Дополнительная практика: все инженерные практики (глава 19) – в частности, те, что касаются тестирования; планирование на среднесрочную перспективу, чтобы предвосхитить аудиты.
• Развертывание
Здесь встает вопрос относительно количества экземпляров конечного продукта, а также способа и частоты их развертывания.
Число развернутых экземпляров варьируется от одного до нескольких миллионов.
Единичное развертывание
В случае размещения одного онлайн (облачного) экземпляра, развертывание контролируется организацией и может происходить довольно часто. Ввод в эксплуатацию не синхронизирован со спринтами и проводится сразу по завершении работы над функциональностью во время спринта.
✓ Попробовать паттерны: сезонный ритм (2), 6К (7).
✓ Избегать антипаттерны: искажение по незнанию (14), Dark Scrum (14).
✓ Дополнительная практика: продолжительное развертывание (19).
Многократное развертывание
И наоборот, развертывание программного обеспечения на устройствах, распространяемых в тысячах копий – например, в области телефонии или видеоигр – делает обновления сложными и дорогостоящими, а этап тестирования – трудоемким. Scrum-команда, как правило, не участвует в развертывании, из-за чего появляются зависимости и задержка обратной связи.
✓ Попробовать: критерии завершенности (9), цикл по V-модели (2).
✓ Дополнительная практика: планирование на среднесрочную перспективу (20) для синхронизации со всеми людьми, вовлеченными в цепочку создания ценности.
Характеристики зависят от команды разработчиков.
• Масштаб проекта
Масштаб проекта соответствует количеству вовлеченных в него людей. Идеальный размер команды – от пяти до девяти человек. Однако по результатам опроса, который я провел в июне 2013 года, 10 % команд состоят из 1–3 человек, и примерно столько же – из 10 и больше.
Несколько команд
При количестве человек от 10 и более следует создавать несколько Scrum-команд.
✓ Попробовать паттерн: бэклог поставки/рабочий бэклог (6).
✓ Избегать антипаттерны: фокус на скорость команды (16), неоконсерваторы (21).
Глава 21 посвящена применению Scrum несколькими командами.
Маленькая команда
Практика показывает, что применение Scrum возможно в небольших командах при количестве участников менее четырех.
✓ Попробовать паттерн: вращающийся Scrum-мастер (5).
✓ Избегать антипаттерны: Scrum-мастер – разработчик (5), призрачная работа (6).
• Кроссфункциональность команды
Под кроссфункциональностью понимается способность участников команды использовать инженерные практики, сочетая образование и опыт каждого.
Scrum-команда – сами участники или с привлечением экспертов – должна делать все необходимое для получения продукта к концу спринта. Если она не приходит к ожидаемым результатам, она не кроссфункциональна.
Слабо кроссфункциональная команда
✓ Попробовать паттерн: эксперт внутри границ (3), 6К (7) – с целью минимизации рисков.
✓ Избегать антипаттерны: специалисты (3), недоступные эксперты (3), улучшение других (12).
✓ Дополнительные практики: парное программирование (19) и вообще работа в паре с целью обучения.
• Географическая разобщенность
Разобщенность относится к количеству офисов, сотрудники которых входят в команду.
В идеале вся команда находится в одном рабочем пространстве. Географическая разрозненность усложняет применение практик и увеличивает риски неудачи. В частности, людям – а это ключевой элемент Agility – становится сложнее общаться между собой. Команда должна найти приемлемое решение для проведения схваток: видеоконференции, аудио, фото, инструменты для совместной работы и т. д.
Удаленная работа
Если один или два участника работают удаленно, остальная команда приспосабливается к проведению схваток с их участием. Работающие дистанционно приезжают в офис для проведения обзоров и ретроспектив.
✓ Избегать антипаттерны: затянувшаяся схватка (10), контекстуализация при помощи инструментов (14), использование в одиночку (17).
Пример команды Peetic.
Жозе, один из разработчиков команды Peetic, работает из дома в городе Авейрон. Остальная команда находится в Тулузе. Это влияет на проведение схваток и других событий. Было решено, что на собраниях Scrum-мастер будет на связи с Жозе по телефону, а после – отправлять ему фотографию обновленной таблицы.
Чтобы принять участие в обзоре, ретроспективе и планировании следующего спринта, Жозе приезжает в Тулузу. Для удобства команда решает проводить все три события в один день: обзор в 10:00, ретро в 14:00, планирование в 15:30.