Scrum-команда стремится к кроссфункциональности: ситуации, когда все необходимые для разработки компетенции представлены внутри команды. Может показаться, что команда пытается обойтись вовсе без заинтересованных сторон. Еще раз подчеркнем важность тесного сотрудничества с заинтересованными сторонами в экосистеме.
Необходимо контролировать и ограничивать всякую неопределенность, связанную с зависимостью команды от заинтересованных сторон. Но нельзя забывать, насколько важен обмен с ними: это и новые знания, и возможность для развития.
Мы уже видели, что в экосистему могут входить люди из разных организаций. Например, клиент, который заключил контракт с фиксированной ценой с компанией-разработчиком ПО (о влиянии на Scrum можно прочитать в главе 14).
В этом случае согласование предназначения особенно важно. Нужно проследить, чтобы отношения между участниками команды не были искажены под давлением финансовых вопросов.
Бывает ли прелюдия, в которой одновременно участвуют несколько Scrum-команд?
Фактически, ситуация, когда несколько команд работают над одним продуктом, довольно редкая и рискованная. Мне кажется, легче начинать с одной команды, а затем, если на то есть необходимость, добавить еще команды. Но при этом каждой из них нужно пройти свою прелюдию.
В таком случае экосистема включает несколько команд, которые общаются с одними и теми же заинтересованными сторонами. Во время прелюдии каждая команда проверяет свою жизнеспособность, остальные действия выполняются совместно.
Мы детальнее узнаем о работе в формате Scrum несколькими командами в главе 21.
13.5 Антипаттерны
Ситуация. Переход к Scrum осуществлен, но команда убеждена, что перед началом спринтов необходимо проектирование. Во время прелюдии участники стремятся к созданию завершенных моделей.
Последствия. Преждевременная работа над проектом приводит к тому, что команда разработчиков полностью теряет инициативу и сильно ограничена созданными моделями. Архитектуру может проверить только код, не модель.
Как сделать лучше? Приоритизировать, базируясь на рисках. Устранить наиболее значительные технические риски в спринте 1.
Ситуация. Переход к Scrum осуществлен, но над продуктом работает не команда, а просто группа людей, которая посвящает продукту лишь половину рабочего дня, потому что у всех участников есть еще свои проекты.
Последствия. В таких условиях невозможно создать ни благоприятную, доверительную атмосферу, ни сформировать ее своеобразие и самобытность. Коллективный разум не развивается.
Как сделать лучше? Привлечь других сотрудников организации, чтобы участники команды были вовлечены полностью. Если это сделать нельзя – включить всю работу участников команды в бэклог. Посвятить время обсуждению командной этики.
Ситуация. Переход к Scrum осуществлен, но руководство, как обычно, требует детальный план работы, начиная с прелюдии.
Последствия. Команда теряет время на бессмысленные расчеты. Не получается оценить производительность команды во время прелюдии.
Существует разница между тем, что хотят менеджеры (иметь план и следовать ему с самого начала) и тем, что в действительности возможно. На самом деле, как упоминается в главе 16, должно быть ясно, что невозможно провести такую оценку команды без каких-либо предшестующих данных по ее производительности (новая команда => нет данных).
Как сделать лучше? Если у команды попросят план, участники могут предложить подождать несколько спринтов, чтобы дать адекватную оценку производительности, прежде чем разрабатывать план на среднесрочную перспективу.
План на среднесрочную перспективу не фигурирует в списке ожидаемых результатов прелюдии.
Если просьба очень настойчивая, смотреть главу «Планирование на среднесрочную перспективу».
Ситуация. Менеджеры прошли этап прелюдии, чтобы составить список задач для людей, которые станут участниками спринта 1.
Последствия. Команда не согласована с экосистемой.
Как сделать лучше? Разрабатывать шаблон прелюдии сообща.
Чтобы идти дальше
Книги
‣ Frederic Laloux, «Reinventing Organizations», Diateino, 2017
Онлайн-ресурсы
‣ Joshua Kerievsky, Modern Agile
14Контекстуализация Scrum
Эта глава здесь не случайно. Она идет после глав, представляющих Scrum как фреймворк, и перед теми, которые его дополняют. Она расположена сразу после главы о прелюдии – этапе, на котором, собственно, и начинается контекстуализация.
Scrum всегда контекстуализирован. Цель этой главы – помочь определить степень контекстуализации, подходящую для каждого конкретного проекта.
Фреймворк – это не метод, и уж тем более не методология или завершенный процесс, который можно было бы внедрить и начать применять. Чтобы использовать Scrum, нужно сперва дополнить эту структуру практиками, которые варьируются в зависимости от сферы деятельности, и адаптировать все к контексту.
Рисунок 14.1 – Фреймворк Scrum адаптирован и наполнен
Что касается дополнений, вполне естественно погружаться и в другие дисциплины: определение продукта, управление проектами и инжиниринг в соответствующей области.
14.1 Практики и паттерны
Мы рассмотрим, как выглядит контекстуализация, включающая Scrum-практики и методы вне Scrum с целью получения нового, улучшенного способа работы.
В то время как Agile-ценности и принципы являются универсальными, практики варьируются в зависимости от ситуации.
Практика – конкретный и проверенный подход, который позволяет решить проблему или улучшает способ работы.
Пример. Демонстрация проходит во время обзора спринта.
Scrum насчитывает около пятнадцати практик, которые, грубо говоря, соответствуют главам этой книги:
✓ Роли: Владелец продукта, Scrum мастер, самоорганизующаяся команда.
✓ События: спринт, доработка бэклога, планирование спринта, схватка, обзор спринта, ретроспектива.
✓ Артефакты: результат спринта, бэклог, план спринта, список препятствий.
✓ Критерии готовности и завершенности.
Являются ли они обязательными? Ответ неоднозначен и часто становится причиной споров. Поскольку Scrum – это не более чем фреймворк, я считаю, что Scrum-практики должны быть обязательными (как первая ступенька в Shu Ha Ri), а способ их реализации уже может меняться в зависимости от контекста.
Термин паттерн, употребляемый в разных областях, очень близок к понятию практики.
Паттерн в данном контексте – решение часто встречающейся проблемы.
В Scrum паттерн может использоваться при применении той или иной практики. Некоторые из них мы уже рассмотрели в предыдущих главах, например, роение или 6К.
Использование паттернов может помочь команде в той или иной ситуации. Паттерны, в свою очередь, не являются обязательными, но очень важно использовать их с умом.
Также в конце каждой главы можно ознакомиться со списком антипаттернов.
Антипаттерн в данном контексте – плохое решение возникшей проблемы.
Очень важно не попасть в ситуацию применения какого-либо из антипаттернов.
В Agile-движении есть целое множество самых разнообразных практик. Их количество, названия и классификации варьируются от автора к автору, единого официального списка не существует.
Юрген Аппело, опираясь на восемь разных источников, попытался собрать известные практики в своем блоге «The Big List of Agile Practices».
Во Франции «l’Institut Agile» опубликовал список из шестидесяти Agile-практик и составил карту, которая дает представление об их происхождении [45].
Классифицировать практики можно разными способами – например, в зависимости от определенных характеристик.
✓ Происхождение практики, то есть, на основе какого подхода она появилась (Scrum, XP, Kanban, и т. д.).
✓ Действия или области разработки (архитектура, написание кода, тестирование и т. д.).
Практики, регулярно дополняющие Scrum, представлены в трех категориях:
• Для определения продукта
Если Scrum применяется при создании нового продукта, желательно добавить в него практики, упрощающие первоначальное составление бэклога. В следующих главах мы коснемся таких практик как impact mapping, story mapping, пользовательская история и приемочные тесты.
• Для управления проектом
Scrum часто воспринимается как метод управления проектом, и эмпирический подход противопоставляется прогнозному. Тем не менее, дополнительные практики управления полезны в зависимости от ситуации. Некоторые из них будут представлены в следующих главах: «Планирование на среднесрочную перспективу», «Применение Kanban в Scrum», «Наглядность при помощи индикаторов».
• Для разработки ПО
Сегодня внедрение Scrum в основном ориентировано на разработку программного обеспечения. Но Scrum не подразумевает использование конкретных техник инжиниринга для разработки, а оставляет выбор за командой. В этом основное отличие от Экстремального Программирования, которое предлагает использование определенных методов разработки ПО.