|
|
www.it4business.ru
|
Читайте не торопясь
Дата публикации: Февраль 5, 2010 в 12:22 am.
Темы: Библиотека, 2010, Мат.часть, Agile, XP, Методологии и модели, Разработка ПО
Распечатать
Авторы: Дин Леффингуэл (Dean Leffingwell, ), Пит Беренс (Pete Behrence)
Перевод: Александр Якима ()
Карточка, диалог и подтверждение
Рон Джеффрис (Ron Jeffries), другой среди создателей XP, дал описание, ставшее для нас наиболее предпочтительным представлением о пользовательских историях. Он воспользовался словосочетанием: Карточка, Диалог и Подтверждение4, для описания трех элементов стори, где:
Карточка представляет собой 2-3 предложения для описания намерения стори. Карточка служит запоминающимся символом, резюмирующим намерение и представляет собой более детальное требование, дальнейшие подробности которого еще будут подлежать определению.
Карточка представляет собой 2-3 предложения для описания намерения стори. Карточка служит запоминающимся символом, резюмирующим намерение и представляет собой более детальное требование, дальнейшие подробности которого еще будут подлежать определению.
В XP и agile, стори часто пишутся вручную на физических карточках. Более привычно для большой компании, однако, когда «карточка» фиксируется в виде текста с приложениями в экселевской таблице или в средстве управления гибкими проектами, но команды все еще часто пользуются бумажными карточками для планирования на ранних стадиях и брейнсторминга, как мы это увидим позже.
Диалог представляет собой обсуждение между командой, заказчиком, продакт оунером и другими стейкхолдерами, необходимое для определения более детального поведения системы, требуемого для реализации намерения. Другими словами, карточка представляет собой «заявку на диалог», темой которого — намерение.
Подтверждение представляет собой приемочный тест, с помощью которого заказчик или продакт оунер сможет подтвердить, что стори реализована, как им это было нужно. Другими словами, подтверждение представляет собой условия выполнения, которые будут применены для определения того, выполняет ли стори намерение равно как и более детальные требования.
Это простое словосочетание (карточка, диалог и подтверждение) дает нам вещественную иллюстрацию того, как качество в agile достигается скорее во время, нежели после собственно разработки кода. Мы достигаем этого просто удостоверившись, что каждая пользовательская история:
а) обсуждена и детализирована, насколько это необходимо и
б) оттестирована, так что удовлетворяет требованиям стейкхолдеров.
За последние несколько лет вошел в оборот новый, стандартизированный шаблон, который существенно усиливает конструкцию стори. Шаблон этот выглядит следующим образом:
Как <роль> я могу <действие>, так что <бизнес-ценность>
где:
Мы называем эту конструкцию5 «голосом пользователя» и находим ее крайне полезной, поскольку она охватывает проблемную область (доставляемую <бизнес ценность>) и область решения (<действие>, производимое пользователем с помощью системы). Она также выдвигает пользователя (<роль>) на приоритетное место для команды, фокусируя таким образом команду на бизнес ценностях и решении настоящих проблем для настоящих людей.
Этот шаблон стори существенно уточняет все «зачем» и «как» на пути обретения видения того, что разработчики должны создать систему в действительности удовлетворяющую потребности пользователей.
Например, пользователь бытовой системы управления энергопотреблением желал бы следующего6:
Как потребитель (<роль>), я хочу иметь возможность видеть мое ежедневное потребление электроэнергии (<то, что я делаю с системой>), чтобы обрести представление о том, как уменьшить финансовые затраты с течением времени (<бизнес-ценность, которую я получаю>).
Каждый элемент представляет собой важный, детализирующий контекст. Роль позволяет сегментировать функциональность продукта и обычно позволяет очертить и другие потребности для этой роли и контекст действия. Действие обычно представляет собой «требование», нужное роли. И, наконец, ценность объясняет, зачем нужно действие, а это часто может привести команду к обнаружению возможных альтернативных действий, дающих ту же ценность, но с меньшими трудозатратами.
Детали пользовательских историй передаются в основном через диалог между продакт оунером и командой, держа команду вовлеченной с самого начала. Однако же, если нужно больше подробностей о стори, они могут быть предоставлены в виде прикрепленных к пользовательской истории файлов (макета, таблицы, алгоритма или чего-нибудь еще). В этом случае стори служит «символом», который также несет в себе и специфику поведения системы. Дополнительная детализация должна производиться с течением времени («точно в срок») посредством обсуждения и сотрудничества с командой и другими стейкхолдерами перед и во время разработки.
Вдобавок к формулировке пользовательской истории, дополнительные комментарии, предположения и критерии приемки могут держаться вместе со стори. Множество обсуждений пользовательской истории командой и заказчиком будет происходить перед и во время имплементации стори. Альтернативные сценарии, допустимые границы значений и другие уточнения следует запечатлеть вдобавок к самой стори. Большая часть из этого может быть превращена в приемочные тест-кейсы или другие функциональные тест-кейсы для стори.
Например,
Как пользователь, я хочу иметь возможность видеть мое ежедневное потребление электроэнергии, чтобы обрести представление о том, как уменьшить финансовые затраты с течением времени.Критерий принятия:
- Считывать показатели счетчика Декаватт каждые 10 сек. и показывать на портале в виде 15-минутных инкрементов и отображать на бытовом дисплее каждую вычитку
- Считывать показатели в Киловаттах, как только появляются новые данные и показывать на портале каждый час, а на домашнем дисплее после каждой вычитки
- Никакого многодневного трендинга пока что (попадет в другую стори)
- И т. д. …
Приемочный критерий — это не то же самое, что функциональные или юнит-тесты, а скорее условия, которым должна удовлетворять система. Функциональные же и юнит-тесты нисходят глубже в тестирование всех функциональных сценариев, исключительных ситуаций, граничных условий и другой функциональности, связанной со стори.
ПРОДОЛЖЕНИЕ:
Последние новости и пресс-релизы компаний
Статистика
Исправляйте ошибки
Мы рекомендуем
