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

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

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

Но все это перестает иметь значение, если команда создает бесполезное программное обеспечение.

Вспомним цитату из книги Кена Швабера, приведенную в начале . Если вы не добьетесь коллективной ответственности, то не получите Scrum. Но что такое «коллективная ответственность»? Какие именно обещания вы даете как команда в целом?

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

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

Пока Agile не изменил мир разработки программного обеспечения, команды нередко выпускали никому не нужные продукты, чему можно привести немало примеров. Практически в любом учебнике конца 1990-х – начала 2000-х годов по разработке программного обеспечения вы найдете ссылку на доклад Standish Group’s CHAOS. В Standish Group начали готовить такие доклады в середине 1990-х, когда стало известно, что огромное количество проектов завершаются неудачей (лишь около трети были признаны успешными). Ежегодные исследования этой компании неоднократно показывали: команды разработчиков имеют основание считать, что многие функции в написанных ими программах не используются. В исследовании 2002 года этот показатель невероятно высок – 64 % (45 % не применяются вообще, а 19 % – редко).

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

Роджер и Ави попали впросак со своим редактором достижений, потому что создали чрезмерно усложненный инструмент для решения простой задачи. К сожалению, команды разработки нередко выпускают менее полезный для клиента продукт, чем могли бы. Для этого явления придуман специальный термин – золочение. Команды стремятся приукрасить программное обеспечение, то есть добавить никем не востребованные функции, причем делают это с самыми лучшими намерениями. Разработчики хотят помочь клиентам и думают, что создают нечто очень ценное. Вполне естественный порыв для разработчиков, любящих свое дело, но в то же время – одна из главных причин тех самых 64 % неиспользуемого функционала.

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

Эффективные agile-команды практически не имеют подобного опыта. В создаваемых ими продуктах лишь немногие (а вовсе не 64 %) функции остаются неиспользованными. Вот почему в этих командах зачастую воспринимают выводы доклада CHAOS как ошибочные. Нередко активные приверженцы Agile стараются поставить под сомнение результаты этого отчета. Так что же позволяет agile-командам создавать столь полезные и востребованные программы?

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

Многие команды пишут свои истории пользователей в формате Mad Libs по следующему шаблону:

Я как <роль> хочу <конкретные действия, которые я предпринимаю>, чтобы <цель>.

Вот история, которую команда Lolleaderz.com использовала в качестве отправной точки для разработки функции контроля достижений.

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

• Кто наш пользователь: «постоянный посетитель сайта, имеющий длинный список друзей».

• Что хочет сделать пользователь: «номинировать видео одного из своих друзей на достижение».

• Почему пользователь хочет это сделать: «чтобы все наши общие друзья смогли за него проголосовать».

Она также имеет название («Номинировать видео на достижение»), которое дает возможность команде легко сослаться на эту конкретную историю, когда о ней заходит речь.

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

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

Истории пользователей также дают командам простой способ управлять бэклогом. У многих эффективных agile-команд в бэклоге содержатся почти исключительно пользовательские истории.

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

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

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

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

Критерии удовлетворенности для пользовательской истории «достижения» могут выглядеть следующим образом.

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

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

Во время планирования спринта команда совместно определяет, сколько они смогут сделать в текущем цикле, чтобы создать программное обеспечение для поставки по его итогам. Но как именно команда это делает?

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

Нет никаких жестких правил, определяющих, сколько баллов (очков) следует присваивать той или иной истории. Некоторые команды назначают от 1 до 5 баллов за любую пользовательскую историю. Максимальное значение «пять» выбрано произвольно. Другие команды дают своим историям от 1 до 10 баллов или используют другие пределы, не меняющиеся от спринта к спринту. Некоторые команды используют числа из последовательности Фибоначчи либо значения экспоненциальной зависимости. Вы можете выбрать любую из работающих схем, при которой все в команде чувствуют себя комфортно. Одна история, оцененная в 3 очка, должна требовать столько же работы, сколько и другая история, оцененная так же. Когда ваша команда оценивает в очках все истории, над которыми она работает, ее члены начинают понимать, на сколько очков они могут выполнить (или «сжечь») историй в текущем спринте. Если ваша команда завершает за один спринт в среднем историй на 25 очков, то говорят, что ее скорость составляет 25 очков историй за спринт.

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

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

Сессия планирования спринта при помощи очков историй может проходить так.

1. Начните с самых ценных историй пользователей из бэклога продукта.

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

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

4. Продолжайте переходить от истории к истории, пока не наберете достаточное количество очков, чтобы заполнить спринт.

Не перегружайте бэклог текущего спринта. Полезно оставлять в нем запас и нежелательно увеличивать нагрузку сверх той, что имела место в прошлом. Если средняя скорость команды – 28 очков за спринт и на очередной спринт запланировано новых историй на сумму в 26 очков, то вы можете добавить только одну историю размером в 2 очка или две – в 1 очко. Так как разработчики – оптимисты по натуре (так и должно быть, поскольку мы созидатели), команда захочет добавить еще 3 очка, превысив свой план на один балл. Не поддавайтесь этому соблазну: нет более верного способа разочаровать пользователей при следующем обзоре спринта.

Но что делать, если вы впервые взялись за такое планирование? Вам потребуется время, чтобы наработать архив историй и сформировать у команды понимание того, насколько велика трехочковая история. Что ж, тогда для начала вам придется руководствоваться предположениями. Выберите одну историю, которая, по вашему мнению, находится примерно в середине шкалы трудоемкости, и произвольно назначьте ей 3 очка. Затем найдите самую большую историю и оцените ее в 5 очков. Теперь возьмите самую маленькую и назначьте ей 1 очко. Используйте их все в качестве отправной точки для оценки историй и наполнения своего спринта. К концу второго спринта вы будете иметь целый набор историй для сравнения, а также неплохую оценку средней скорости команды.

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

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

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

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

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

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

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

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

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

1. Начните с пустого графика. По оси Х отсчитываются даты, начиная с первого дня спринта и заканчивая последним его днем. По оси Y – очки историй с максимумом примерно на 0−20 % больше, чем общее количество очков в бэклоге спринта. Поставьте первую точку на графике: количество очков в спринте в день начала работы. Нарисуйте прямую («направляющую») линию от стартовой точки до конца периода – ноль очков должно остаться к моменту завершения спринта.

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

3. Во время ежедневного scrum-митинга вы можете обнаружить, что необходимо увеличить объем работ. Иногда вы будете делать это, так как команда «сжигает» больше баллов, чем она ожидала, и в результате работы будут закончены раньше срока окончания спринта. Или появится новая важная задача поддержки, и при этом команда и владелец продукта согласятся, что она должна быть добавлена в спринт, но объем необходимой работы пока неизвестен. Поэтому команда не знает, сколько работы надо убрать из спринта, чтобы его сбалансировать. При добавлении карточки данной работы на доску задач запланируйте встречу команды, чтобы оценить в баллах (очках историй) каждую задачу и добавить их в диаграмму. Полезно также провести дополнительную линию, которая будет показывать момент, когда новые пункты были добавлены к графику, – не бойтесь оставлять на диаграмме свои заметки!

4. По мере приближения к окончанию спринта «сгорает» все больше очков, что отражается на графике. Следите за интервалом между направляющей и вашим текущим «сгоранием», потому что он может означать, что в спринте осталось слишком много очков историй и какую-то из них нужно убрать.

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