Все статьи
6 практик SAFe® для небольших команд
Дата: 30.06.2017
Есть ли что-то в SAFe® (Scaled Agile Framework®) для небольших проектов, где всего одна или несколько команд, или для них достаточно Scrum?
SAFe – Scaled Agile Framework — был создан для решения проблем средних и очень крупных проектов. Над такими проектами работают несколько Agile-команд общей численностью от 50-100 до нескольких сотен или даже тысяч специалистов. Есть ли что-то в SAFe для небольших проектов, где всего одна или несколько команд, или для них достаточно Scrum? Если команда разработки относительно независима и проект короткий, Scrum (или Kanban) подойдут. Однако, часть практик SAFe могут быть полезны и небольшой команде при следующих обстоятельствах.
- Стратегический программный продукт с длительным сроком эксплуатации. Чем дольше планируется использовать программный продукт, тем важнее согласовать его разработку со стратегией компании. Scrum не предоставляет способов согласования разработки программного обеспечения (ПО) с более долгосрочными стратегическими целями, чем спринт.
- Вероятность масштабирования от небольшого до среднего размера. Если стартап (новый бизнес или внутренний стартап) обладает сильной перспективой роста, имеет смысл подготовиться к ней и использовать подходы масштабирования, когда это потребуется. Масштабирование может проходить очень медленно и сложно, если возможности для масштабирования не будут заложены сразу.
- Зависимость от нескольких (не разрабатывающих ПО) команд. Нередко в компании относительно небольшая команда разработчиков поставляет ПО для интеграции нескольким другим командам. Так работают команды разработки в компаниях, создающих аппаратное обеспечение, или сервисных компаниях с небольшой долей ПО, но приличным портфелем продуктов. Компании-разработки ПО, которые сильно дорабатывают продукт для каждого клиента в проектах внедрения, также сталкиваются с кросс-проектными сложностями. Все зависимые команды должны быть согласованы по приоритетам и проводить совместное планирование.
- Необходимость инвестировать в долгосрочные возможности, такие как DevOps. Сосредоточившись на реализации следующего набора пользовательских историй, спринт за спринтом, легко откладываются долгосрочные инвестиции в собственные возможности команды. Нельзя не согласиться с тем, что способности DevOps необходимы, но для того, чтобы стать настоящей командой DevOps, нужно прилагать усилия, которые следует планировать и выполнять как проект. Изменение технологий разработки или развитие программной архитектуры — это еще один пример долгосрочных инвестиций в возможности, которые по сути являются проектами.
Есть способы решения всех четырех случаев с помощью только Scrum, но мой опыт говорит о том, что лучше использовать следующие 6 практик SAFe.
1. Стратегические темы
Все компании, большие или малые, нуждаются в стратегии для достижения успеха. Крайне важно понять, как продукты компании создают ценность для клиентов с точки зрения влияния на процессы/выполнение и конкретные выгоды, получаемые клиентами. Качество продукта и пользовательский опыт одинаково важны для долгосрочного успеха. Команда разработки должна понимать стратегию развития продукта и иметь представление о том, как постоянно совершенствовать свои инженерные практики для повышения производительности и конкурентоспособности.
Хотя SAFe не предлагает явных инструментов для определения логики создания стоимости и построения стратегии, в нем есть Стратегические Темы, которые являются бизнес-целями, связывающими портфель команды со стратегией компании.
Я использовал Стратегические Темы при итеративном планировании (Планирование Инкремента Программы, а также Планирование Спринта), чтобы команда работала над стратегически значимыми элементами. Некоторые инструменты, такие как Visual Studio Team Services (VSTS, который использует моя текущая команда), позволяют пометить рабочие элементы ключевыми словами, что также помогает анализировать соответствие элементов бэклога со стратегией. Если стратегия существует, определить стратегические темы несложно, поэтому, я думаю, что это того стоит.
2. Эпики Программы
Scrum-команды обычно интерпретируют эпики, как слишком большие пользовательские истории, которые не вписываются в один спринт. SAFe содержит богатую иерархию эпиков для обеспечения масштабирования: Бизнес-эпики (портфеля) и Enabler-эпики, Эпики Value Stream, Эпики Программы. Эпики портфеля и Value Stream для небольших разработок не нужны в отличие от Эпиков Программы.
SAFe определяет Эпики Программы как «достаточно значимые инициативы, которые требуют анализа на основе бизнес-кейса и финансового одобрения перед реализацией». Мне кажется, что суть не в том, чтобы подготовить сам по себе бизнес-кейс, а в том, что Эпик — это то, что принесет желаемую значительную ценность и он реализуем. Таким образом, когда команда работает над Эпиком Программы, связанным со Стратегической Темой, усилия команды вносят вклад в нечто ценное, соответствующее стратегии компании.
Эпики полезны для небольших команд, поскольку они описывают ключевые инициативы команды, которые реализуются или предлагаются к реализации заинтересованными лицами команды или же придуманы самой командой. Команда разработки должна также иметь некоторые Enabler-эпики в своем портфеле в дополнение к Бизнес-эпикам, например, улучшение архитектуры или возможностей DevOps.
Поскольку «достаточно значимые инициативы», как правило, требуют значительных инвестиций (ресурсов), для каждого Эпика стоит разработать простой бизнес-кейс, прежде чем бросаться в реализацию или отказываться от нее. Это особенно полезно, когда у команды несколько заинтересованных лиц и их инициативы должны быть приоритизированы и соответствовать ресурсам команды, чтобы сделать решения по приоритетам обоснованными.
3. Kanban Программы
SAFe содержит масштабируемую систему Kanban для управления портфелями инициатив на уровне компании, Value Stream и программы. Уровня программы достаточно для небольшой команды, и он особенно полезен в том случае, если у команды есть несколько заинтересованных лиц, предлагающих к реализации свои собственные Эпики.
Kanban Программы в SAFe обеспечивает простой и прозрачный процесс рассмотрения предложений по инициативам. Он используется для сбора, анализа, утверждения и отслеживания Эпиков. Эпики в процессе выполнения проходят через стадии: Воронка, Обзор, Анализ, Бэклог Портфеля, Реализация — в конце переходят в стадию Готово. Для небольшой команды процесс изучения Эпиков может быть намного более простым, но логика таких шагов должна присутствовать в любом случае, когда Владелец Продукта думает о следующей инициативе (инициативах) и о том, как команда может создать большую ценность. Управление ключевыми инициативами с помощью Эпиков в Kanban Программы требует фасилитации, но обеспечивает хорошую прозрачность приоритетов команды как на уровне портфеля, так и для членов команды.
4. Фичи
Scrum не описывает такое понятие как фича. В нем есть только пользовательские истории. Большие пользовательские истории помечаются как эпики, а связанные группы пользовательских историй как темы.
SAFe определяет Фичу как «сервис, предоставляемый системой, который удовлетворяет одну или несколько потребностей пользователя». Эпики разрабатываются посредством Фич, которые определяются с точки зрения их преимуществ и критериев приемки. Фичи — это обычно функциональные характеристики продукта, в которых заинтересованы «все». Мне было сложно объяснить план и прогресс команды с помощью пользовательских историй клиентам, зависимым проектам или руководству, но фичи, описанные в SAFe, отлично подходят для этой цели. Они имеют подходящий размер и понятны, в то время как Истории, как правило, слишком мелкие и их много.
Что особенно важно для Фич, так это то, что они имеют размер, соответствующий одному Инкременту Программы. Это позволяет Фичам отражать конкретные результаты и обеспечивать понятное взаимодействие с заинтересованными лицами.
5. PI-планирование
Scrum определяет только цикл спринта, как правило, 1-3 недели (2 недели, вероятно, самый популярный вариант) в качестве итерации планирования и выполнения. Чаще всего Scrum-команды обеспечивают реальную прозрачность своих планов только на следующий спринт, плюс бэклог, который отражает порядок, в котором пользовательские истории возможно будут реализованы. Различные варианты дорожных карт в PowerPoint и Excel используются для удовлетворения потребности в визуализации более длительного планирования, чем только следующий спринт. Обычно инструменты управления бэклогом позволяют планировать истории на будущие спринты, а некоторые предоставляют прогнозы, основанные на скорости команды и порядке элементов бэклога.
Инкремент Программы (Program Increment, PI) в SAFe — это «регулярно повторяющийся временной интервал, в течение которого создается и проверяется полный инкремент системы, демонстрируется ценность и собирается быстрая обратная связь». Продолжительность одного Инкремента Программы обычно составляет 8-12 недель, то есть 4-6 спринтов (итерации в терминологии SAFe) по 2 недели. Последним спринтом Инкремента Программы является Итерация Планирования и Инноваций, которая будет описана ниже в качестве шестой практики.
Ровно как Планирование Спринта в Scrum, так и SAFe обеспечивает практику планирования таких супер-итераций: PI-планирование. Я проводил сессию PI-планирования в SAFe более или менее в соответствии с книгой также и для проектов небольшого размера. Горизонт планирования в 8-12 недель достаточно короткий для точного планирования и достаточно длинный для того, чтобы команда достигла чего-то действительно ценного в виде набора Фич, потенциально готовых к поставке. Я думаю, что сессия PI-планирования — это хорошая инвестиция времени для всех: команда получает понимание общей картины и приоритетов, проводит Agile-планирование. Заинтересованные лица могут непосредственно внести свой вклад в планирование и получить представление о всех рабочих элементах, над которыми работает команда. Для небольшой команды сессия PI-планирования может быть сокращена до одного дня, чтобы временные затраты стали целесообразны преимуществам.
6. Итерация Инноваций и Планирования
Томас Эдисон описывал свой инновационный подход как «один процент вдохновения и девяносто девять процентов труда», то есть инновации требуют времени и усердной работы, а не только творчества. Особенно безостановочное непрерывное развитие продукта рискованно тем, что команда просто выполняет спринт за спринтом без перерывов, что в конечном счете изматывает ее. Спринты, как правило, задают напряженный график работы и поэтому небольшим командам еще труднее найти время для работы над более рискованными и, казалось бы, менее приоритетными новаторскими идеями.
В SAFe нет серебряной пули, которая магически освобождает много времени разработчиков для внедрения инновации, как у Эдисона, но Итерация Инноваций и Планирования в конце каждого Инкремента Программы — это то, что команды должны попробовать. В этом спринте не должно быть разработки никаких новых историй, разве что некоторые действия по системной интеграции и тестированию, к примеру, тестирование производительности или безопасности. Также в это время демонстрируются достижения Инкремента Программы заинтересованным лицам и проводится PI-планирование следующего Инкремента Программы. Но, как следует из названия, во время этого спринта команда может также провести хакатон или иным образом поработать над инновациями или, например, над улучшением инфраструктуры. И последнее, что, безусловно, немаловажно: команда может отдохнуть от безостановочной поставки ПО. Часть перерыва может быть использовано, например, для развития компетенции в разработке.
Это были мои полдюжины практик SAFe, которые я нашел полезными и для небольших команд.
- Стратегические темы включают стратегические приоритеты и помогают команде согласоваться с ними.
- Эпики Программы определяют ценность ключевых инициатив, над которыми должна работать команда, как следствие, они определяют приоритетность.
- Kanban Программы отражает приоритеты и статус Эпиков для заинтересованных лиц.
- Эпики разрабатываются с помощью фич, которые обеспечивают общий язык между командой и ее заинтересованными лицами и имеют такой размер, чтобы входить в один Инкремент Программы в 8-12 недель.
- PI-планирование проводится во время каждого Инкремента Программы, обеспечивая общее понимание приоритетов и целей на следующие 8-12 недель.
- Итерация Инноваций и Планирования в конце каждого Инкремента Программы дает команде заслуженный перерыв и позволяет потратить некоторое время на инновации и развитие своих возможностей.
