Пользовательские истории, скорость работы команды и общепринятые практики Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 5.2. История пользователя, написанная на карточке