Но порой возникают сложности. Часто во время планирования нужно думать о том, чего хотят пользователи, что ценят, и при этом выясняется, что никогда раньше вам не приходилось об этом задумываться. Когда люди говорят, что Scrum сложен, то они имеют в виду именно это.
К счастью, успешные scrum-команды имеют для решения этой проблемы не самое секретное оружие – владельца продукта. Когда этот человек действительно тратит время на попытки понять, чего хотят стейкхолдеры и что представляет для них ценность, он может помочь команде определить цели каждого спринта и те проблемы, которые компания должна решать в первую очередь. Визуализируя эти ценности для команды и участвуя в составлении нового плана для каждого спринта, он превращает поэтапный процесс в непрерывный. И когда в конце каждого спринта команда проводит ретроспективу, владелец продукта помогает ей извлечь уроки, чтобы ожидания команды соответствовали тому, чего она на самом деле может достичь.
Какова ценность каждого нового релиза, получаемого в конце спринта?
Если вы планируете ограниченные по времени спринты, то придерживайтесь такой стратегии: когда время спринта подходит к концу, останавливайте всю работу по разработке, поскольку если команда будет поставлять работающее программное обеспечение в конце каждого спринта, то подобная стратегия принесет существенную пользу. Вы получите стандартные контрольные точки, помогающие поддерживать высокое качество ПО. Это позволяет владельцу продукта, пользователям и заинтересованным сторонам увидеть функционально полные версии, в которых встроенные опции хорошо сочетаются друг с другом. Таким образом значительно снижаются риски, потому что команде не придется дожидаться окончания проекта, чтобы интегрировать функции, созданные разными людьми, и обнаружить, что они не работают вместе.
Проведем мысленный эксперимент, который поможет понять проблемы интеграции. Представим себе, что два члена команды трудятся над разными функциями программы, сохраняющими текущий рабочий файл пользователей, но делают это по-разному. Знаете ли вы, сколько вариантов «конфликтных ситуаций» может возникать между этими функциями? Вот лишь некоторые из них: одна функция использует значок «сохранить», а другая – «файл» в меню, две характеристики имеют несовместимые способы доступа к общим ресурсам, или сохраняют файлы в несовместимых форматах, или могут перезаписать общие данные, которые управляют приложением. Возможны и другие проблемы интеграции. Можете ли вы вспомнить иные потенциальные проблемы, возникающие в процессе интеграции? Если вы давно разрабатываете ПО, то вам не нужно ничего придумывать, так как наверняка приходилось не раз сталкиваться с подобными вещами.
Объединяя все разработки вместе в конце каждого спринта, не дожидаясь для этого окончания проекта, команда может распознать и предотвратить многие подобные проблемы. Существуют и другие преимущества такого подхода: улучшение коммуникации, более активное участие стейкхолдеров и легко измеримый статус проекта. Разбивка проекта на этапы называется инкрементальной разработкой. Scrum-спринты – еще один способ разделить ваш проект на инкременты. Вот почему Scrum – это инкрементальный подход.
Но Scrum – это нечто большее. Scrum-спринты – не просто поставка работающего программного обеспечения в ограниченные сроки. Это также понимание ценности, которую данный программный продукт обеспечивает, точно определяя, какая именно ценность будет поставлена, и осознание необходимости смены курса, если есть способ, позволяющий поставить большую ценность. Когда методологии или процессы, такие как Scrum, работают таким образом, это называется итеративная разработка. То есть Scrum – это одновременно и инкрементальный, и итеративный подход.
Майк Кон в своей замечательной книге «Пользовательские истории. Гибкая разработка программного обеспечения»[37] хорошо объясняет главные отличия между понятиями «итеративный» и «инкрементальный»:
Итеративный процесс позволяет достигать прогресса за счет последовательных уточнений. Команда разработчиков берет первый отрезок системы, зная, что он неполный или слабый в некоторых (а возможно, во многих) областях. Затем она многократно совершенствует эти области до тех пор, пока продукт не станет удовлетворительным. С каждой итерацией программное обеспечение улучшается путем добавления дополнительных деталей.
В инкрементальном процессе программное обеспечение создается и поставляется частями. Каждая часть, или инкремент, представляет собой полный ряд функций. Инкременты могут быть маленькими или большими, возможно, это будет только логин системы на экране или очень гибкий набор управления данными экрана. Каждый инкремент полностью закодирован и протестирован, и считается, что работу, проделанную в этой итерации, уже не нужно будет пересматривать.
У нас уже есть план мероприятий для принятия первой части системы, пусть и известно, что она неполная или слабая в некоторых областях, и мы в несколько приемов усовершенствуем эти области, используя цикл «обзор-контроль-адаптация». Scrum-команда, применяющая инкрементальную разработку, так же как она применяет цикл «обзор-контроль-адаптация» во время ежедневных scrum-митингов, использует эту технологию для проекта в целом. В этом цель планирования спринтов, управления бэклогом спринта и проведения ретроспектив.
Вот почему владелец продукта так важен для scrum-команды и ему отводится отдельная роль. Задачи владельца продукта:
• выявить главные потребности компании и транслировать их команде разработчиков;
• понять, какие именно функции программного обеспечения команда потенциально может поставить;
• выяснить, какие функции наиболее ценны для компании, а какие второстепенны;
• работать с командой, чтобы понять, какие функции создавать легче, а какие сложнее;
• использовать понятия ценности, сложности, неопределенности, комплексности и прочие, чтобы помочь команде выбрать нужные функции для создания продукта в каждом спринте;
• делиться этими знаниями с остальными работниками компании, чтобы они могли сделать все необходимое для подготовки следующей версии программного обеспечения.
Владелец продукта выполняет очень специфические функции в проекте. Он владеет продуктовым бэклогом и выявляет наиболее приоритетные задачи, которые команда будет разрабатывать в следующем спринте. Вместе с командой участвует в планировании спринта и решает, какие из пунктов войдут в бэклог спринта, и принимает те задачи, которые были выполнены командой по поручению компании. Это означает, что владелец продукта должен иметь широкие полномочия. Если их нет (или он боится это делать), значит, человек занимает чужое место. Он также должен четко понимать, что ценно для компании. Разговаривая с людьми, владелец продукта выясняет их мнение о том или ином продукте, но окончательное решение обо всех приоритетах продуктового бэклога принимает только он.
Вот почему так важно, чтобы команда и владелец продукта с самого начала спринта договорились о том, из чего состоит каждый из этих пунктов. Когда они планируют бэклог спринта, все должны прийти к единому мнению о том, что означает слово «выполнено» для каждого пункта – это не просто «дело сделано», а «Выполнено» с большой буквы. Бэклог задач считается «выполненным», когда его принимает владелец продукта и весь результат можно поставлять клиентам. Если нет однозначного определения понятия «выполнено» по каждому пункту, то неизбежны путаница и жаркие споры в конце спринта. Но когда все имеют четкое представление о том, что это означает для каждого пункта, то команда отчетливо видит, как продвигается спринт.
Спринты ограничены по времени – обычно 30-дневным сроком (хотя некоторые scrum-команды выбирают короткие спринты – длиной в две-три недели). Когда спринт заканчивается, все «выполненные» пункты принимаются владельцем продукта. Любые пункты в статусе «не выполнено» возвращаются в продуктовый бэклог – даже если команда сделала многое (или почти все), работая над ними. Это не значит, что команда должна все начать сначала, удалить исходный код или что-нибудь отменить. Просто работа над этим пунктом не закончена до тех пор, пока он действительно не будет «выполнен» и принят владельцем продукта.
Это важно, поскольку гарантирует, что пользователи никогда не будут заблуждаться относительно того, поставлена ли ценность командой или нет. Лучше осторожничать при принятии обязательств. Обзор спринта – это специальное мероприятие, когда вся команда выступает перед пользователями и заинтересованными сторонами, чтобы продемонстрировать результаты своей работы за последние 30 дней. Если обещания не выполнены, то каждый член команды должен напрямую объяснить пользователю, что он делал и почему не справился. Это очень мощный инструмент, помогающий каждому почувствовать коллективную ответственность. Кроме того, именно в этой ситуации пользователи и стейкхолдеры могут задавать вопросы. Такое взаимодействие помогает всем объединиться и гораздо лучше понять, что действительно ценно, – и они могут начать создавать чувство настоящего доверия. Чем чаще люди встречаются и говорят о программном обеспечении (как в этом случае), тем больше доверия и свободы будет в команде и ей легче будет создавать ПО. Хотя пользователи и стейкхолдеры присутствуют на встрече и обсуждают ситуацию с командой, только владелец продукта имеет право принимать работу от имени компании.
Изредка владелец продукта и команда обнаруживают, что либо спринт был плохо спланирован, либо произошли серьезные изменения, которые не могут ждать окончания спринта. В этом случае владелец продукта имеет право остановить спринт, прекратить все работы и переместить все пункты из бэклога спринта в бэклог продукта. Подобное явление должно быть чрезвычайно редким, так как оно мож