Основы пользовательских историй. Часть 2: Форма

Дин Лэффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)

Перевод: Александр Якима (www.enter-agile.com)


Карточка, диалог и подтверждение


Рон Джеффрис (Ron Jeffries), другой среди создателей XP, дал описание, ставшее для нас наиболее предпочтительным представлением о пользовательских историях. Он воспользовался словосочетанием: Карточка, Диалог и Подтверждение [4], для описания трех элементов стори, где:

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

В XP и agile, стори часто пишутся вручную на физических карточках. Более привычно для большой компании, однако, когда “карточка” фиксируется в виде текста с приложениями в экселевской таблице или в средстве управления гибкими проектами, но команды все еще часто пользуются бумажными карточками для планирования на ранних стадиях и брейнсторминга, как мы это увидим позже.

Диалог представляет собой обсуждение между командой, заказчиком, продакт оунером и другими стейкхолдерами, необходимое для определения более детального поведения системы, требуемого для реализации намерения. Другими словами, карточка представляет собой “заявку на диалог”, темой которого - намерение.

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

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


Шаблон пользовательской истории

За последние несколько лет вошел в оборот новый, стандартизированный шаблон, который существенно усиливает конструкцию стори. Шаблон этот выглядит следующим образом:

Как <роль> я могу <действие>, так что <бизнес-ценность>

где:

Роль означает того, кто выполняет действие или того, кто получает пользу от действия. Это даже может быть другая система, если она инициирует действие.
Действие представляет собой выполняемую системой активность.
Бизнес ценность представляет собой пользу для бизнеса.

Мы называем эту конструкцию [5] “голосом пользователя” и находим ее крайне полезной, поскольку она охватывает проблемную область (доставляемую <бизнес ценность>) и область решения (<действие>, производимое пользователем с помощью системы). Она также выдвигает пользователя (<роль>) на приоритетное место для команды, фокусируя таким образом команду на бизнес ценностях и решении настоящих проблем для настоящих людей.

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

Например, пользователь бытовой системы управления энергопотреблением желал бы следующего [6]:


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


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


Детали пользовательских историй

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


Критерий принятия стори


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

Например,


Как пользователь, я хочу иметь возможность видеть мое ежедневное потребление электроэнергии, чтобы обрести представление о том, как уменьшить финансовые затраты с течением времени.
Критерий принятия:
• Считывать показатели счетчика Декаватт каждые 10 сек. и показывать на портале в виде 15-минутных инкрементов и отображать на бытовом дисплее каждую вычитку
• Считывать показатели в Киловаттах, как только появляются новые данные и показывать на портале каждый час, а на домашнем дисплее после каждой вычитки
• Никакого многодневного трендинга пока что (попадет в другую стори)
• И т. д. ...


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

ПРОДОЛЖЕНИЕ СЛЕДУЕТ...

--------------------------------------------
4. http://xprogramming.com/xpmag/expcardconversationconfirmation/

5. В поисках происхождения этой конструкции я получил комментарий от Майка Кона (Mike Cohn): “Я начинал работу с командой в компании Connextra в Лондоне и это было упомянуто на XP2003. Я стал использовать это и в дальнейшем и написал об это м в моей книге, изданной в 2004 году, User Stories Applied.”

6. Автор приносит благодарность Дженнифер Фосетт (Jennifer Fawcett), сотруднику компании Tendril Networks, за предоставление примеров

No comments:

Post a Comment

 
Powered by Blogger