Основы пользовательских историй. Часть 1. Введение.

Этим постом я начинаю серию публикаций, посвященных отдельным частям книги “Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий”, автор которой, Дин Леффингуэл любезно предоставил право на перевод и публикацию для русскоязычных читателей. Дин неоднократно приезжал в Украину и Россию, в это время (2006-2008) я управлял разработкой в компании под его началом. По этой причине я прекрасно знаю, как работают описываемые им методы на практике и ту практическую пользу, которую они приносят. Приятного прочтения!..

Основы пользовательских историй


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

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

Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях “Бережливая и масштабируемая информационная модель требований для гибких компаний” и “Общая картина гибкости компании”, обе статьи можно найти в блоге http://scalingsoftwareagility.wordpress.com/. Текущая же статья извлечена из будущей книги “Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий”, издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.

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


Они были на великом пиру языков, но довольствовались крохами.

- паж Моль к Костарду, “Напрасный труд любви”, Уильям Шекспир

Введение

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

Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:

Определить полезную стори – реализовать и оттестировать в рамках короткой итерации – продемонстрировать и/или доставить ее пользователю – получить фидбек - усвоить информацию – повторить в цикле!

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

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

Пользовательские истории: обзор

В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефикта. Хотя это значительно менее значимое “методологическое распутье”, чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.

Для наших целей мы определим пользовательскую историю так:

Пользовательская история – это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

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

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

Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.

Примеры:


- Залогиниться в мой портал мониторинга энергопотребления
- Посмотреть ежедневный уровень потребления
- Проверить мой текущий тариф



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

Пользовательские истории помогают преодолевать разрыв между разработчиками и пользователями

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

Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом[2]:

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

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


Пользовательские истории – это не требования

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

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

---------------------------------------

1. www.scalingsoftwareagility.wordpress.com



2. http://xp123.com/xplor/xp0308/index.shtml



3. Это задача разработки и поддержки приемочных тестов, определяющих поведение системы в деталях, необходимых для регрессионного тестирования.


---------------------------------------

[Cohn 2004] Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

2 comments:

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

    ReplyDelete
  2. Zmey14, прекрасный вопрос и возникает он потому, что гибкое управление требованиями как "противоположность" радиционному производит такое впечатление, что команда приступает к имплементации релиза, не имея практически никаких подробностей того, что и как нужно делать. Однако, вся суть гибкого управления требованиями с концептуальной точки зрения всего лишь означает следующее: мы объективно не можем знать всех подробностей наперед, поэтому все что знаем и в чем можем позволить себе ошибиться - детализируем априори (это случится само собой, если команда ответсвенно подходит к эстимированию релиза), а то, чего мы не можем знать сейчас, мы будем активно исследовать в процессе разработки. Таким образом, никто не пытется "убить существующий метод оценки и управления требованиями", наоборот, если бы он хорошо работал - зачем его было бы трогать. Но увы, полная детализация наперед вводит обе стороны в иллюзорный мир, где наши очень смелые гипотезы относительно требований и скоупа принимаются за действительность...

    ReplyDelete

 
Powered by Blogger