Книга: Постигая Agile

Спринты, планирование и ретроспективы

Спринты, планирование и ретроспективы

Для некоторых проектов планирование спринта – это легко. Например, когда нужно в итоге создать то, о чем люди просят на протяжении нескольких месяцев. Если есть функция, которую требуют пользователи, и вы сделаете ее высокоприоритетной, то это легкая победа. В этом случае планирование спринта – это просто следование здравому смыслу.

Но порой возникают сложности. Часто во время планирования нужно думать о том, чего хотят пользователи, что ценят, и при этом выясняется, что никогда раньше вам не приходилось об этом задумываться. Когда люди говорят, что Scrum сложен, то они имеют в виду именно это.

К счастью, успешные scrum-команды имеют для решения этой проблемы не самое секретное оружие – владельца продукта. Когда этот человек действительно тратит время на попытки понять, чего хотят стейкхолдеры и что представляет для них ценность, он может помочь команде определить цели каждого спринта и те проблемы, которые компания должна решать в первую очередь. Визуализируя эти ценности для команды и участвуя в составлении нового плана для каждого спринта, он превращает поэтапный процесс в непрерывный. И когда в конце каждого спринта команда проводит ретроспективу, владелец продукта помогает ей извлечь уроки, чтобы ожидания команды соответствовали тому, чего она на самом деле может достичь.

Какова ценность каждого нового релиза, получаемого в конце спринта?

Если вы планируете ограниченные по времени спринты, то придерживайтесь такой стратегии: когда время спринта подходит к концу, останавливайте всю работу по разработке, поскольку если команда будет поставлять работающее программное обеспечение в конце каждого спринта, то подобная стратегия принесет существенную пользу. Вы получите стандартные контрольные точки, помогающие поддерживать высокое качество ПО. Это позволяет владельцу продукта, пользователям и заинтересованным сторонам увидеть функционально полные версии, в которых встроенные опции хорошо сочетаются друг с другом. Таким образом значительно снижаются риски, потому что команде не придется дожидаться окончания проекта, чтобы интегрировать функции, созданные разными людьми, и обнаружить, что они не работают вместе.

Проведем мысленный эксперимент, который поможет понять проблемы интеграции. Представим себе, что два члена команды трудятся над разными функциями программы, сохраняющими текущий рабочий файл пользователей, но делают это по-разному. Знаете ли вы, сколько вариантов «конфликтных ситуаций» может возникать между этими функциями? Вот лишь некоторые из них: одна функция использует значок «сохранить», а другая – «файл» в меню, две характеристики имеют несовместимые способы доступа к общим ресурсам, или сохраняют файлы в несовместимых форматах, или могут перезаписать общие данные, которые управляют приложением. Возможны и другие проблемы интеграции. Можете ли вы вспомнить иные потенциальные проблемы, возникающие в процессе интеграции? Если вы давно разрабатываете ПО, то вам не нужно ничего придумывать, так как наверняка приходилось не раз сталкиваться с подобными вещами.

Объединяя все разработки вместе в конце каждого спринта, не дожидаясь для этого окончания проекта, команда может распознать и предотвратить многие подобные проблемы. Существуют и другие преимущества такого подхода: улучшение коммуникации, более активное участие стейкхолдеров и легко измеримый статус проекта. Разбивка проекта на этапы называется инкрементальной разработкой. Scrum-спринты – еще один способ разделить ваш проект на инкременты. Вот почему Scrum – это инкрементальный подход.

Но Scrum – это нечто большее. Scrum-спринты – не просто поставка работающего программного обеспечения в ограниченные сроки. Это также понимание ценности, которую данный программный продукт обеспечивает, точно определяя, какая именно ценность будет поставлена, и осознание необходимости смены курса, если есть способ, позволяющий поставить большую ценность. Когда методологии или процессы, такие как Scrum, работают таким образом, это называется итеративная разработка. То есть Scrum – это одновременно и инкрементальный, и итеративный подход.

Майк Кон в своей замечательной книге «Пользовательские истории. Гибкая разработка программного обеспечения»[37] хорошо объясняет главные отличия между понятиями «итеративный» и «инкрементальный»:

У нас уже есть план мероприятий для принятия первой части системы, пусть и известно, что она неполная или слабая в некоторых областях, и мы в несколько приемов усовершенствуем эти области, используя цикл «обзор-контроль-адаптация». Scrum-команда, применяющая инкрементальную разработку, так же как она применяет цикл «обзор-контроль-адаптация» во время ежедневных scrum-митингов, использует эту технологию для проекта в целом. В этом цель планирования спринтов, управления бэклогом спринта и проведения ретроспектив.

Вот почему владелец продукта так важен для scrum-команды и ему отводится отдельная роль. Задачи владельца продукта:

• выявить главные потребности компании и транслировать их команде разработчиков;

• понять, какие именно функции программного обеспечения команда потенциально может поставить;

• выяснить, какие функции наиболее ценны для компании, а какие второстепенны;

• работать с командой, чтобы понять, какие функции создавать легче, а какие сложнее;

• использовать понятия ценности, сложности, неопределенности, комплексности и прочие, чтобы помочь команде выбрать нужные функции для создания продукта в каждом спринте;

• делиться этими знаниями с остальными работниками компании, чтобы они могли сделать все необходимое для подготовки следующей версии программного обеспечения.

Владелец продукта выполняет очень специфические функции в проекте. Он владеет продуктовым бэклогом и выявляет наиболее приоритетные задачи, которые команда будет разрабатывать в следующем спринте. Вместе с командой участвует в планировании спринта и решает, какие из пунктов войдут в бэклог спринта, и принимает те задачи, которые были выполнены командой по поручению компании. Это означает, что владелец продукта должен иметь широкие полномочия. Если их нет (или он боится это делать), значит, человек занимает чужое место. Он также должен четко понимать, что ценно для компании. Разговаривая с людьми, владелец продукта выясняет их мнение о том или ином продукте, но окончательное решение обо всех приоритетах продуктового бэклога принимает только он.

Вот почему так важно, чтобы команда и владелец продукта с самого начала спринта договорились о том, из чего состоит каждый из этих пунктов. Когда они планируют бэклог спринта, все должны прийти к единому мнению о том, что означает слово «выполнено» для каждого пункта – это не просто «дело сделано», а «Выполнено» с большой буквы. Бэклог задач считается «выполненным», когда его принимает владелец продукта и весь результат можно поставлять клиентам. Если нет однозначного определения понятия «выполнено» по каждому пункту, то неизбежны путаница и жаркие споры в конце спринта. Но когда все имеют четкое представление о том, что это означает для каждого пункта, то команда отчетливо видит, как продвигается спринт.

Спринты ограничены по времени – обычно 30-дневным сроком (хотя некоторые scrum-команды выбирают короткие спринты – длиной в две-три недели). Когда спринт заканчивается, все «выполненные» пункты принимаются владельцем продукта. Любые пункты в статусе «не выполнено» возвращаются в продуктовый бэклог – даже если команда сделала многое (или почти все), работая над ними. Это не значит, что команда должна все начать сначала, удалить исходный код или что-нибудь отменить. Просто работа над этим пунктом не закончена до тех пор, пока он действительно не будет «выполнен» и принят владельцем продукта.

Это важно, поскольку гарантирует, что пользователи никогда не будут заблуждаться относительно того, поставлена ли ценность командой или нет. Лучше осторожничать при принятии обязательств. Обзор спринта – это специальное мероприятие, когда вся команда выступает перед пользователями и заинтересованными сторонами, чтобы продемонстрировать результаты своей работы за последние 30 дней. Если обещания не выполнены, то каждый член команды должен напрямую объяснить пользователю, что он делал и почему не справился. Это очень мощный инструмент, помогающий каждому почувствовать коллективную ответственность. Кроме того, именно в этой ситуации пользователи и стейкхолдеры могут задавать вопросы. Такое взаимодействие помогает всем объединиться и гораздо лучше понять, что действительно ценно, – и они могут начать создавать чувство настоящего доверия. Чем чаще люди встречаются и говорят о программном обеспечении (как в этом случае), тем больше доверия и свободы будет в команде и ей легче будет создавать ПО. Хотя пользователи и стейкхолдеры присутствуют на встрече и обсуждают ситуацию с командой, только владелец продукта имеет право принимать работу от имени компании.

Изредка владелец продукта и команда обнаруживают, что либо спринт был плохо спланирован, либо произошли серьезные изменения, которые не могут ждать окончания спринта. В этом случае владелец продукта имеет право остановить спринт, прекратить все работы и переместить все пункты из бэклога спринта в бэклог продукта. Подобное явление должно быть чрезвычайно редким, так как оно может разрушить с трудом заработанное доверие между командой, пользователями и стейкхолдерами.

Подумайте, что вас мотивирует, когда вы работаете. Как часто мысли, подобные перечисленным ниже, приходят вам в голову?

• «Опыт работы с этой технологией украсит мое резюме» (если вы разработчик).

• «Если я проявлю себя в этом проекте, то могу получить в команде более высокую должность» (если вы руководитель проекта).

• «Выполнение такой сложной задачи точно в срок прославит меня» (если вы менеджер проекта).

• «Если мне удастся удовлетворить такого крупного клиента, то я получу огромный бонус» (если вы менеджер по работе с клиентами, владелец продукта, стейкхолдер и т. д.).

Мы все так думаем. И это нормально.

У любого человека есть свои собственные интересы, и в этом нет ничего плохого. Но персональная мотивация не объединяет команду. Когда люди работают вместе над единой задачей, они могут достичь гораздо большего, чем каждый по отдельности. Так что, пока каждый из нас беспокоится только о том, что может дать ему работа, которую он выполняет, мы добиваемся намного меньшего, чем если бы все работали как одна команда.

Приведем пример, как личные интересы могут нанести ущерб проекту. Предположим, в команде есть человек, который может переложить неинтересные или раздражающие его задачи на другого, обычно ниже его по статусу. Большинство из нас сталкивались с такой ситуацией. Например, старшие разработчики настолько заняты созданием нового ПО, что сняли с себя обязанность исправлять ошибки. Ведь заниматься разработкой новых функций гораздо интереснее, тем более если есть возможность ознакомиться с новыми технологиями. К тому же обычно существует команда младших разработчиков (зачастую в другом городе, где меньше платят), готовая заняться исправлением ошибок. Вообще это довольно распространенная практика: набирается «команда» опытных разработчиков для создания новых функций и группа поддержки, куда входят менее опытные специалисты, которые исправляют ошибки и ставят «заплатки» в уже выпущенное программное обеспечение.

Это очень удобно для старшего разработчика, желающего «выстрелить и забыть». Ведь он уверен: допущенные им погрешности будут устранять другие люди, которых он и знать не желает. В краткосрочном плане это очень неплохой способ работы для одного человека, но с точки зрения команды и в долгосрочной перспективе это неэффективно. Без всякого сомнения, ошибки должен исправлять тот, кто их сделал. Он уже знает детали кода, потому что писал его и хорошо в нем разбирается. Чтобы исправлением занялся кто-то другой, нужно затратить усилия на коммуникацию. Правда, иногда достаточно отправить письмо по электронной почте, но порой необходимы дополнительные документы (например, отчет об ошибке и обновленная спецификация). Человеку, который займется исправлением, потребуется время, чтобы разобраться в коде. Программист, создавший его, исправит погрешность за несколько минут, а другим понадобятся часы или дни (особенно если это новички или недостаточно опытные разработчики).

В scrum-командах редко встречается ситуация, когда грязную работу спихивают на другого, потому что все сотрудники привержены общему делу. Командная культура предполагает, что более опытный разработчик сам делает грязную работу за несколько минут, а не передает ее младшему коллеге, который потратит часы. Это и есть один из источников гиперпроизводительности и «удивительных результатов» применения Scrum, которые, похоже, недоступны многим командам.

Любая (даже не гибкая) команда может стать высокопроизводительной, если введет правила, запрещающие своим старшим членам передавать «скучные» задачи младшим по должности. Но по-настоящему успешной scrum-команде не нужно создавать специальных правил для подобных ситуаций. Причина в том, что все ее участники наделены подлинным чувством ответственности за каждый аспект проекта. Поэтому старшим членам команды никогда не придет в голову желание «свалить» технические задачи на младших коллег. Они поступят разумно, выполнив ту работу, которая необходима прямо сейчас (вспомните CEO, который пошел за кофе для сотрудников)[38]. Исправление ошибок и другие задачи обслуживания просто добавляются в бэклог спринта, рассматриваются во время ежедневных scrum-митингов и выполняются надлежащими людьми в определенное время. (И последний ответственный момент для исправления ошибок, возможно, как раз именно сейчас, потому что разработчик еще ничего не забыл.)

В успешной scrum-команде все чувствуют свою сопричастность не только к коду, который создают, но и к бэклогу, и каждый старается делать все возможное, чтобы поставить работающее программное обеспечение. Бэклог спринта – это ответственность каждого, даже самый молодой разработчик ощущает, что именно он сделал для пользователей. Вот что подразумевает Кен Швабер под коллективной ответственностью в цитате, приведенной в начале этой главы: каждый член команды разделяет ответственность за бэклог и чувствует персональную ответственность за поставку наиболее ценного работающего программного обеспечения, необходимого пользователям, – включая все функции, а не только те, над которыми работает лично он.

Как же достичь такого чувства командной ответственности, чтобы каждый – от младшего разработчика, старшего технического руководителя, scrum-мастера и до владельца продукта – добровольно взял на себя решение неинтересных задач только потому, что заботится о проекте?

Вы когда-нибудь были волонтером? Содействовали проекту с открытым исходным кодом? Вступали в клуб, любительскую спортивную команду, рок-группу, церковный хор? Подумайте о том случае, когда вы присоединились к группе, не имеющей отношения к вашей работе или семье. Зачем вы это сделали?

Вы присоединились к группе и, вероятно, отдавали ей немало своего времени и сил, потому что вас интересовала главная цель ее существования. Если это был штаб избирательной кампании, то вас беспокоила явка людей на выборы. Если футбольная команда – то вас волновала победа (и качественная игра). Так почему же на работе должно быть по-другому?

Все мы стремимся к цели. По меньшей мере, работаем за деньги. Если работа перестает приносить доход, мы прекращаем ею заниматься. У нас есть счета, которые нужно оплачивать, и семьи, которые требуется кормить. Так что, когда нам платят и предоставляют комфортную, безопасную обстановку, в которой мы должны отработать положенные часы, предлагают другие элементарные блага, составляющие рабочую среду, – этого бывает достаточно, чтобы мы приходили в офис и выполняли свои служебные обязанности.

Но достаточно ли этого, чтобы нас по-настоящему волновало создание работающего программного обеспечения?

Если вам довелось работать в недостаточно мотивированной команде, то вы знаете, что ответ будет отрицательным. Дело в том, что многие из нас никогда не трудились в действительно мотивирующей обстановке. Но если вам с этим повезло, то, скорее всего, вы вспоминаете те времена с ностальгией. Когда каждый заботится о создании отличного программного продукта, все вокруг приносит удовольствие: люди больше общаются, меньше спорят (или делают это продуктивно) и, похоже, легче достигают результата.

Существует много способов мотивировать команду: дать возможность поработать с новой технологией или в области, которая интересна, помочь продвинуться по служебной лестнице, платить премии, предоставлять работу на дому. Возможна и негативная мотивация: руководитель будет злиться, кричать (меньше заплатит, уволит). Эти позитивные и негативные стимулы мотивируют отдельных людей, но неспособны объединить команду.

Действительно сплотить может только вдохновляющая цель. Стив Макконел, эксперт и автор работ на тему управления проектами, в 16-й главе своей книги Beautiful Teams дал такое определение вдохновляющей цели:

Почти все программное обеспечение создано командой, а не отдельными людьми. Чтобы команда работала эффективно, нужно мотивировать всех сотрудников. Лучше всего вдохновляет и объединяет высокая цель, не оставляющая никого равнодушным.

Поставка ценности может быть очень эффективной вдохновляющей целью, мотивирующей всю команду. Когда у нее есть эта цель, она искренне верит в нее и готова самостоятельно решать, как ее достичь (и имеет возможность рисковать), команда будет усердно работать, используя имеющиеся инструменты, чтобы устранить любые препятствия на пути к этой цели.

Вдохновляющие цели направлены на ценность, но термин «ценность» может показаться абстрактным или оторванным от реальности. Для agile-команды ценность имеет вполне конкретный смысл: программное обеспечение ценное, если делает жизнь пользователей лучше. Что произойдет, если старший вице-президент сообщит команде: «Мы увеличили ваш доход в третьем квартале на 0,024 %, потому что вы напряженно работали. Отлично, молодцы!» Это не особенно мотивирует большинство разработчиков, даже если среди них есть те, кто оплатил опционы на акции.

Другое дело, если этот же человек придет и скажет: «Обычно я тратил три часа только на то, чтобы разобраться в этих цифрах. А ваше программное обеспечение настолько просто в использовании и так хорошо работает, что теперь я могу сделать все за десять минут. Спасибо!» Это гораздо сильнее мотивирует большинство разработчиков.

Разработчиков – а таковыми можно считать всех членов agile-команды, даже тех, кто не пишет код, – очень воодушевляет гордость мастера. Мы хотим создавать такое программное обеспечение, которое приносит пользу, нравится потребителям и вызывает у них желание заботиться о нем. Мы хотим, чтобы наше ПО работало эффективно и было создано максимально хорошо, так как тратим слишком много времени на споры о дизайне, архитектуре и технологиях. Все это действительно волнует команду. Сделать жизнь пользователей лучше – вот наиболее прямой путь, которым мы поставляем ценность. А это и есть настоящая, честная, вдохновляющая цель.

Этот принцип находится в верхней части списка принципов Agile-манифеста. Обратите внимание на слова, которые мы выделили.

Причина, по которой это считается приоритетной задачей, в том, что поставка ценности пользователям – наиболее эффективный способ мотивации команд и движущая сила хорошего планирования спринта.

Начинать с бэклога – это значит начинать с пользователей

Почему мы планируем поставку специализированных функций в спринте, вместо того чтобы двигаться дальше? Потому что работали как команда, чтобы выяснить, какие функции наши пользователи считают наиболее ценными. Именно поэтому владелец продукта так важен – его задача понять потребности пользователей и своевременно информировать о них команду.

Будьте реалистичны в оценке того, что вы можете поставить заказчику

Многих менеджеров посещает безумная идея, что если не подбадривать разработчиков, то они будут бездельничать, выполнять минимум работы и устанавливать длинные сроки. Однако для большинства команд это неверно. Просто в реальности разработчики слишком большие оптимисты. Именно поэтому мы знаем немало проектов, которые завершились с опозданием, и почти не видели случаев, когда они заканчиваются раньше времени. Не пытайтесь втиснуть в спринт слишком много функций. (В конце концов, пользователи должны всего лишь дождаться следующего спринта, чтобы получить рабочее программное обеспечение, которое включает в себя очередной набор функций.) Хороший scrum-мастер помогает команде оценить работу и понять, чем можно заниматься, а чем нет.

Измените план, если это необходимо

Используйте преимущество ежедневных scrum-митингов, чтобы выяснить, действительно ли команда собирается закончить разработку тех функций, которые были запланированы в спринте. Когда необходимо изменить план, команда делает это. Если становится понятно, что не удастся закончить все работы в бэклоге спринта, то команда должна перенести некоторые из них (начиная с наименее значимых) из бэклога спринта обратно в продуктовый бэклог. Scrum-мастер обязан убедиться в том, что все члены команды понимают суть изменений. Пользователи, привыкшие видеть работающее программное обеспечение, меньше нервничают, не дождавшись во время обзора спринта ожидаемых функций, если владелец продукта предварительно их к этому подготовил.

Заставьте всех говорить о ценности

В успешных scrum-командах, как правило, многие понимают, что на самом деле нужно пользователям и что для них ценно. Единственный верный способ добиться этого – сделать так, чтобы каждый член команды понимал, что именно он будет делать для пользователей. Как это облегчит их жизнь? Что позволит им делать то, что раньше было невозможно? Все это действительно важно для agile-разработчиков. Чем больше вы обсуждаете это, тем лучше будет программный продукт.

Оглавление книги