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