В этом уроке наш разговор будет о таком интересном и эффективном Agile-инструменте, как пользовательские истории. Чтобы реализация пунктов, утвержденных владельцем продукта в бэклоге спринта, приводила к созданию тех функций, которые нужны заказчикам, команда активно использует в своей работе пользовательские истории. В общем виде пользовательские истории представляют собой краткое описание того, как именно предполагается использовать и эксплуатировать создаваемый продукт. Или, иначе говоря, это пожелания будущих пользователей, которые помогают команде создать наиболее ценный и функциональный продукт. Предназначение пользовательских историй в том, чтобы наиболее точно определить конкретные потребности пользователей. Записывается пользовательская история, как правило, на карточках в виде нескольких предложений. Запись может быть произведена или в определенном формате, или, реже, в произвольной форме. Большинство пользовательских историй обычно содержат не более четырех предложений. Пользовательские истории помогают всем членам команды, при этом каждый рассматривает их со своих позиций. Для владельца продукта пользовательская история является той ценностью, которую он обязан предоставить заказчику. Пользовательская история предоставляет ему хорошую возможность видеть связь между тем, что создает его команда, и тем, что будут делать пользователи с созданным продуктом. Пользовательские истории нужны ему и для более дотошного разговора с клиентами, для правильного понимания того, что они ждут от разрабатываемого продукта. И для подтверждения полной уверенности в том, что каждая история содержит именно то, о чем на самом деле мечтает пользователь. Scrum-мастер в каждой пользовательской истории видит конкретную работу, которую нужно сделать и предоставить клиенту. Каждую историю-карточку он держит на контроле. Конкретный разработчик воспринимает пользовательскую историю, как определенную часть всего функционала, написанную в доступной для понимания форме. В ходе работы он разбивает историю на задачи, создает учетную карточку для каждой из них, а закончив разработку, перемещает их в ту часть доски, где размещаются выполненные задачи. Важный аспект работы команды над пользовательской историей заключен в том, чтобы каждый член коллектива, работая над своей частью истории, видел и понимал, как используют данную историю другие участники. Такой подход исключает разделение пользовательской истории на отдельные малосвязанные между собой части и нацеливает на формирование у команды ясного и четкого представления о потребности заказчика, ориентирует на создание конкретной функции, заявленной пользователем. При таком подходе команда не станет создавать лишние функции, ведущие к удорожанию продукта. Для более или менее равномерного распределения работы при выполнении бэклога каждого из спринтов Scrum-команда использует при планировании итераций различные методы. Одним из наиболее удобных и эффективных методов в данном контексте является использование очков (баллов) пользовательских историй. Цель заключается в определении того, сколько усилий, трудозатрат необходимо при создании функции конкретной пользовательской истории. При этом не существует каких-либо жестких правил, предопределяющих, сколько баллов следует присваивать той или иной пользовательской истории. Чаще всего это шкала от одного до десяти баллов. Но продвинутые Agile-команды предпочитают использовать шкалу из последовательности чисел Фибоначчи — это один, два, три, пять, восемь, или относительные единицы измерения — например, размеры одежды (XS, S, M, L, XL). Главное, чтобы установленные значения не менялись от спринта к спринту. Одна пользовательская история, оцененная, скажем, в четыре балла, должна требовать столько же работы, сколько и другая история, которой присвоили такой же уровень сложности. Дело в том, что мы намного хуже даем оценку в часах, то есть в абсолютном времени. Поэтому в силу ряда причин в Agile используются относительные шкалы измерения. Использование системы начисления баллов при оценке пользовательских историй помогает команде достаточно четко определить, сколько очков будет в данном спринте. Если команда выполняет, допустим, за один спринт в среднем пользовательских историй на 30 очков, то можно сказать, что скорость данной команды составляет 30 очков истории за спринт. Если средняя скорость команды, как мы говорили, 30 очков за спринт, и на следующий очередной спринт заложены работы на 28 очков, то добавить можно уже только одну историю в два очка или две истории по одному очку. При этом лучше не поддаваться соблазну брать на себя повышенные обязательства, поскольку, как правило, это верный способ разочаровать заказчиков при ретроспективном анализе сделанного в ходе реализации такого спринта. При всех возможных издержках применение этого подхода, то есть не всегда взвешенной оценке пользовательских историй, болезни кого-то из членов команды, увольнении или других факторах, для большинства команд со временем очки истории становятся весьма надежным ориентиром в работе. Это объясняется тем, что они просты в применении, позволяют эффективно использовать накопленный реальный опыт в последующей работе команды. Они побуждают участников коллектива реально оценивать свою работу и дают возможность наглядно контролировать ее выполнение. Другим популярным и часто используемым Scrum-командным методом оценки затрат на реализацию пользовательских историй является так называемое покерное планирование. Суть его такова. Перед началом планирования все участники получают по колоде карт. На каждой карточке указывается одна из возможных оценок. Модератор — обычно это Scrum-мастер — зачитывает описание каждой пользовательской истории, которая должна быть оценена. Оценщики задают любые вопросы владельцу продукта. После завершения обсуждения каждый оценщик выбирает из колоды карту, отражающую его мнение по данной истории. По команде модератора все карточки одновременно переворачиваются, и все участники могут видеть оценки, выставленные каждому из них за данную пользовательскую историю. Большой плюс таких подходов состоит еще и в том, что они способствуют улучшению коммуникации внутри команды, поскольку верные оценки предстоящих трудозатрат при реализации пользовательских историй могут формироваться только в ходе дискуссий и неизбежных споров. При этом оба метода помогают каждому участнику воспользоваться имеющимся у него опытом, а команде в целом получить взвешенную и согласованную оценку по каждому вопросу. Итак, как же правильно писать пользовательские истории? Текст самой истории должен объяснять роль действия пользователя в системе, его потребность и ценность, которую пользователь получит после того, как история случится. Обычно используется вот такой шаблон. Как роль, или персона пользователя, я хочу что-то получить с такой-то целью. Например, я, как преподаватель, хочу видеть полный список участников курса, чтобы иметь возможность отправить им рассылку по электронной почте. Чтобы понять, хорошей ли получилась пользовательская история, удобно использовать следующий чек-лист на основе акронима INVEST. INVEST-модель является достаточно распространенной, и многие гибкие команды оценивают свои истории, исходя из этих атрибутов. "I" — "independent" ("независимость"). "Независимость" означает, что история может быть разработана, оттестирована и, возможно, даже доставлена сама по себе. В силу этого она может нести независимую ценность. "N" — "negotiable" ("обсуждаемость"). В отличие от традиционных требований, пользовательская история не является соглашением об определенной функциональности, а скорее, вместилищем для таких требований, которые еще предстоит обсудить, реализовать, оттестировать и принять. Этот процесс обсуждения между бизнесом и командой адекватно отображает правомерность и первоочередность информации, исходящей от бизнеса. Но также и предрасполагает к исследованию через сотрудничество и обратную связь. "V" — "value" ("польза"). Цель гибкой команды проста: доставить максимальную пользу в рамках доступного времени и ресурсов. Поэтому "польза" — иногда мы ее называем "ценность" — является наиболее важным атрибутом в INVEST-модели. И каждая пользовательская история должна представлять определенную ценность пользователю, заказчику или стейкхолдеру продукта. "E" — "estimable" ("измеримость"). Хорошая пользовательская история измерима. Несмотря на то, что в бэклоге может лежать история любого размера, для того, чтобы ее можно было реализовать и оттестировать в рамках одной итерации, команда должна быть способна предоставить приблизительную оценку ее сложности и объема работы, необходимой для ее завершения. "S" — "size" ("адекватный размер"). Пользовательские истории должны быть достаточно небольшими, чтобы их можно было выполнить в рамках итерации. В противном случае они не будут представлять ценности и не будут рассматриваться, как завершенные, под конец истории. "T" — "testable" ("тестируемость"). В полноценном Agile весь результат является оттестированным. Отсюда следует тестируемость истории. Если история оказывается нетестированной, значит, она плохо сформирована либо излишне сложна или, может быть, зависит от других пользовательских историй в бэклоге. Бывают ситуации, в которых пользовательскую историю приходится разбивать на несколько частей. Во-первых, пользовательские истории требуют разбивки, когда они слишком велики и не укладываются в одну итерацию. Иногда история не укладывается в итерацию потому, что просто больше нее. Понятно, что историю с такой ситуацией необходимо разбить. Или история меньше планируемой итерации, но не укладывается в нее из-за недостатка места. Команда может решить, что времени достаточно для разработки за итерацию только части этой истории. Во-вторых, может быть полезно разбить крупную пользовательскую историю, также называемую эпопеями, если требуется более точная оценка. Приведу пример. Один из моих клиентов рассматривал возможность реализации новых функций, которые должны были обеспечить расширенный доступ в его систему работавшим в других компаниях представителям службы по поддержке клиентов. Первый вопрос, на который нужно было ответить владельцу продукта: стоит ли овчинка выделки? Вместо того чтобы составлять кучу индивидуальных пользовательских историй, он написал одну большую историю и изложил свое видение этой истории команде. Команда оценила ее в 70 пунктов. Это было достаточно хорошо, чтобы владелец продукта захотел добавить новые функции. Он знал, что с оценкой связана большая неопределенность. Но даже если бы ошибка составляла 100 процентов, реализация функций все равно имела бы смысл. Если бы возникла проблема с включением дополнительных 70 пунктов в один релиз, владелец продукта мог бы разбить большую историю на части и предложить команде оценить несколько более мелких историй. Итак, подведем итог. Пользовательские истории — это основная единица планирования в Agile. На основе оцененных пользовательских историй формируется бэклог продукта, бэклог спринта и измеряется скорость команды. Пользовательские истории имеют свои правила и критерии написания. И навык корректно формулировать пользовательские истории чрезвычайно важен в Agile-командах. В следующем уроке я хотел бы продемонстрировать некоторое популярное программное обеспечение, с помощью которого можно на практике использовать многие уже изученные нами Agile-инструменты.
