User Story
Материал из AgileWiki
Описание
Определения
- Краткое формулировка требования с целью управления требованиями и объёмом работы, являющаяся маркером для дальнейшей работы (Денис Миллер)
Формат
- Я как ______, хочу ______, для того чтобы _______
- Как <пользователь>, я могу <действие>, для того, чтобы <цель>
Критерии
| A user story is an agile practice where software system requirements are formulated as one or two sentences in the everyday language of the user. The customers should write the stories for the software project; these stories are the way they influence development. User stories are, therefore, a quick way of handling customer requirements without having to deal with large formal requirement documents. | User story это практика Agile, в которой ... |
A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. User stories are used for the specification of requirements (together with acceptance tests) in the software engineering method Extreme Programming (XP). Each story is written on a small paper note card to ensure that it does not grow too large. The stories should be written by the customers for a software project and are their main method of influence on the development.
Статьи
User Stories и Use Cases
Перевод статьи из блога tynerblain.com (Scott Sehlhorst).
Ссылка на статью:
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
User Stories – один из ключевых Agile артефактов, который позволяет командам разработчиков создавать наиболее важные возможности системы в первую очередь. Они отличаются от Use Cases по ряду значительных причин, но у них есть гораздо больше общего, чем вы можете подумать.
User Stories на практике
Майк Кон написал книгу User Stories Applied: For Agile Software Development. Это книга о том, как писать, оценивать и использовать User Stories. Если вы думаете о том, чтобы попробовать Agile в первый раз и не читали эту книгу, то вам необходимо это сделать. Автор очень подробно и с забавными историями рассказывает о том, как писать, управлять и использовать User Stories.
Что такое User Stories?
User Story – это пользовательско-ориентированное описание целей, которые люди смогут достичь, используя ваш продукт. User Stories применимы всегда, когда есть человек, взаимодействующий с интерфейсом продукта для достижения цели. Они применимы не только к программному обеспечению, хотя характер данной статьи предполагает это (в силу того, что я живу в мире программного обеспечения большую часть времени).
User Story пишется в формате
Как [человек в определенной роли] я хочу [выполнить некоторое действие], чтобы [некоторая цель была достигнута]
Вот и все. Ничего больше. Совершенно атомизированно, очень кратко и недвусмысленно. Откуда эта элегантная идея появилась?
User-Centered Design (UCD, пользовательско-ориентированный дизайн) – это подход к дизайну продуктов, который также может рассматриваться как философия. В колледже у меня была привычка говорить, что индустриальные дизайнеры проектируют вещи «снаружи внутрь» (from the outside in), а инженеры проектируют вещи «изнутри наружу» (from the inside out). Идеальные продукты – это такие продукты, в которых соединены форма (то, что снаружи) и функции (то, что внутри) в виде элегантного решения, в котором размывается разделяющая форму и функцию граница. Первые дизайнеры инженерных продуктов были инженерами, а первыми дизайнерами программного обеспечения были программисты – только они знали, что может быть сделано. Любой, кто использовал приложение с интерфейсом, созданным специалистам по базам данных, помнит, что оно из себя представляло. В итоге, кто-то успешно адаптировал образ мыслей проектирования продукта, основанный на том, что кто-то может использовать его, чтобы что-то сделать вместо того, чтобы смотреть на то, что оно умеет делать и пытаться понять, как его использовать. Это подчеркивает важность UCD, ну вы поняли идею.
Из подхода UCD следует много выводов, которые реально определяют то, как мы создаем продукты сегодня. Kessler и Sweitzer сфокусировались на понимании этих целей пользователей в книге Outside-In Software Development. Цели стейкхолдеров задают требования (возможно, это и есть требования). Но тяжело создавать практические планы из целей. Вам необходимо что-то, чтобы преодолеть этот разрыв.
User Story в Agile процессе преодолевает этот разрыв. В мире структурированных требований Вигерса, этот разрыв покрывается с помощью Use Cases.
Концептуально User Story преодолевает ту же пропасть, что и Use Case. User Story определяет, что люди должны сделать (например, более быстрое осуществление звонков) для того, чтобы достигнуть целей компании (например, снизить затраты на кол-центр), с определенным подходом к решению (написать программное обеспечение вместо того, чтобы использовать дешевых сотрудников в кол-центре).
Сейчас мы находимся в запутанной ситуации: у нас есть User Srories, Use Case Scenarios и по крайней мере три различных типа Use Cases – формальные и неформальные Use Cases и Use Case Briefs. В чем они отличаются друг от друга и в чем они схожи?
Описание использования системы
Use Cases, Use Case Scenarios и User Stories представляют собой документированное описание того, как продукт будет использован. Они могут быть отображены на одной прямой в зависимости от затрат, необходимых для их создания.
- Формальные Use Cases требуют максимальных усилий. Их написание сопровождается соблюдением определенных «церемоний», но они описывают все варианты того, как какой-либо человек будет выполнять некоторые действия (или их вариации);
- Неформальные Use Cases - по сути то же самое, только они менее формальны. Задача состоит в том, чтобы предоставить правильный уровень детализации и не прийти к формальным Use Cases;
- У Use Case Briefs нет практически никаких дополнительных затрат, но здесь также присутствует проблема «какой уровень детализации необходим», как и в случае неформальных Uses Cases, только она в этом случае более актуальна;
- User Stories имеют минимальные затраты и предоставляют минимальный контекст.
Use Case Scenarios несколько из другого рода. Как и User Story, Use Case Scenario описывает один путь в Use Case с несколькими путями. Но вы не можете (по крайней мере, я никогда не видел, чтобы кто-то делал это) создавать Use Case Scenario без предварительного создания формальных Use Cases. Этот артефакт сочетает слабость формальных Use Cases (высокая документированность) со слабостью User Stories (ограниченный контекст). Они могут быть очень удобны для разработки Test Cases, если ваша команда тестирования не очень хороша в написании Test Cases. Мы не будем рассматривать Use Case Scenarios в дальнейшей дискуссии.
Высокая документированность с соответствующими издержками несет определенное преимущество – возросшую детализированность.
Т.к. User Story описывает один путь в Use Case, при меньшей затратности она включает также и меньше деталей. Это нормально, т.к. Agile ставит коммуникацию выше исчерпывающей документации. Вы попадете в ситуацию неэффективности, когда объем обсуждений (особенно повторяющихся) станет обременительным. Необходимый объем обсуждений задается как функция от количества знаний о предметной области или контекстов, которые уже были выявлены командой разработчиков.
Мне стоит использовать User Stories или Use Cases?
Это зависит от вашей аудитории. Формальные и неформальные Use Cases помимо того, что более затратны в реализации, также предоставляют больше контекста и позволяют вам описать более сложные варианты использования вашего продукта. Некоторые пользователи настолько сложны, что вам необходимо использовать Use Cases для их описания. Некоторые настолько просты, что что-либо сложнее User Story является бесполезной тратой усилий. Интерпретация того, что является сложным, а что простым, тем не менее, не является просто оценкой того, что пользователи хотят делать, она также зависит от уровня владения предметной областью вашей командой разработчиков.
Некоторые команды просто не готовы к восприятию User Stories и Use Case Briefs. Вы должны писать ваши требования для читателей, поэтому вы должны знать, когда у людей возникают проблемы с реализацией решений, основанных на User Stories или Use Case Briefs и предоставить им больше структуры и формализованности. Вы должны адаптироваться к реалиям вашей текущей ситуации и опыта вашей команды.
Вы можете заменить слова «компетентность читателя в предметной области» (Reader Domain Expertise) на слова «уровень доверия к команде», если хотите, и диаграмма будет выглядеть примерно так же. Это другая концепция, которая критична для того, чтобы команда работала эффективно: уровень доверия приравнивается к уровню делегирования.
Если вы доверяете своей команде создать решение, которое будет соответствовать User Story, делегируйте этот «следующий уровень детализации» им. Если вы не доверяете им, тогда не стоит этого делать. Но вы должны. Одно из преимуществ Agile состоит в том, что ваша команда быстро предоставит вам решение и вы сможете дать им обратную связь. Если они не предоставят вам решение, которое было бы отражением потребностей пользователей, предоставьте им обратную связь и они изменят его. Agile процесс фактически основан на этой возможности сохранять эффектинвость «немногословных» артефактов. Кто-то из команды в общих чертах опишет, как будет выглядеть решение и получит обратную связь до начала реализации. Чем больше будет такого взаимодействия, тем более эффективной будет легковесная документация.
Заключение
Не надейтесь на банальное описание User Stories и Use Cases. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.
Оригинал: http://swpm.ru/2009/07/user-stories-and-use-cases/
Алексей Кривицкий. Об agile по-русски: User Stories, часть 1
«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья?
Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.
Эта статья рассказывает о применении «user stories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья?
Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднего звена, лидеров команд, аналитиков, программистов, инженеров по качеству – всех тех, кто понимает важность тесного взаимодействия заказчиков и команды и ищет более эффективные способы взаимодействия. Для всех тех, кого интересуют agile подходы.
Понимание agile принципов весьма приветствуется при прочтении этого материала, хотя это необязательно: вы можете выбрать для себя принцип «от частного к общему», начав с этой статьи. Ссылки в конце статьи могут быть полезны для дальнейшего ознакомления с Agile подходами.
Как структурирован этот материал?
В первой части (которая начинается буквально через пару абзацев) речь пойдет о принципах, стоящих за историями, и тем, какие преимущества получит проект от их применения.
В следующих частях я попробую изложить такие важные моменты, как планирование проектов с использованием историй, оценки стоимости и длительности проектов, также коснусь некоторых более сложных и тонких ситуаций с использованием историй, в частности таких как: возможность использования историй в аутсорсных проектах; варианты хранения историй; сложности, с которыми вы можете столкнуться (и дай Бог столкнетесь), начав использовать истории в своих проектах; также поделюсь своим личным опытом от использования историй.
Как я познакомился с User Stories
Скажу честно, пока я не прочел книги Майка Кона (3), я не верил в то, что этот подход жизнеспособен. Я читал книги по экстремальному программированию (4), про то, как заказчики высказывают требования в виде коротких фраз и обсуждают их с командой, - но все это было далеко от моего понимания, в прочем, как и другие особенности XP... И мне кажется, я был не одинок.
К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum (5), и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории. User stories: экстремальный подход
Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична, как говорят: «it’s about common sense» (5).
Если сжато, то суть историй состоит в том, что они, как основной механизм ведения требований проекта, служат не для документации требований, а скорее, напоминанием заказчику о наличии таковых для дальнейших обсуждений продукта с командой. По началу эта идея может показаться весьма экстремальной и противоречащей известным подходам. Но давайте по порядку.
Итак, вместо того, чтобы тратить время на написание, согласование и обновление спецификаций о требованиях к будущему продукту, заказчик (см сноски внизу) делает короткие высказывания о том, как пользователь будет пользоваться будущей системой. Будучи собранными в том или ином виде, эти высказывания используются для последующих обсуждений с проектной командой. В ходе обсуждений начальные идеи, заложенные в первоначальных высказываниях, обрастают деталями. Такими деталями является все, что поможет команде во время реализации истории помнить о нуждах пользователя – это различные уточнения, ограничения, немаловажные критерии готовности.
Наличие последующих обсуждений в процессе создания историй – это самый ключевой момент, так как цель всех заказчиков (конечно тех, которые заинтересованы в результатах своих проектов) – это создание проектной среды, которая благоприятствует креативности и кооперации между всеми членами проекта, а креативность и кооперация достижимы только при свободном обмене идеями.
Почему же обсуждение требований так важно?
- Заказчик не может учесть всех аспектов продукта самостоятельно, так как требования должны «лечь» на технологии. Только совместные усилия заказчика и команды в поиске решений и компромиссов дают оптимальные результаты;
- Детализация требований посредством обсуждений дает возможность всем участникам понять суть требований и, так образом, обзавестись базой для принятия оптимальных решений;
- Изначально упуская некоторые аспекты историй и оставляя тем самым место для дискуссий, заказчик расширяет область поиска решений. Это приводит к расширению кругозора участников проекта и, как следствие, к предпосылкам нахождения более приемлемых решений;
- Свобода поиска решений является отличным мотивирующим механизмом, что делает повседневную работу команды более интересной.
Принимая во внимание, что обсуждения необходимы, мы ставим процесс таким образом, чтоб без них просто нельзя было обойтись. Как вы понимаете, это можно достичь простым способом – достаточно упустить детали, описав лишь самое необходимое, - и команда будет вынуждена подискутировать с заказчиком, для выяснения упущенных деталей.
Какой заказчику от этого плюс? Кроме преимуществ перечисленных выше, - это отсутствие необходимости описывать детали до того момента, когда без них просто нельзя обойтись, что является хорошим способом сэкономить время. И вправду – зачем продумывать до мелочей то, что может существенно измениться, или что ещё хуже – вообще перестать быть необходимым.
Довольно тяжело объяснить сходу все аспекты и плюсы от использования историй – динамичной и легковесной базы для хранения требований. Давайте лучше попробуем разобрать некоторые из них на примере. Как это работает на практике? Пример написания историй
Итак, у нас (заказчиков) есть потребность в реализации системы, которая бы позволила пользователям хранить и обмениваться фотографиями. Ожидается, что прибыль от системы будет достигаться за счет процента с продаж пользователями своих фотографий, также, возможно, за счет рекламы третьих компаний.
Это короткое предложение – ничто иное как видение (vision) системы. Его вполне достаточно для того, чтобы начать описывать истории. Но сначала, давайте идентифицируем группы пользователей – истории будут рассказаны от их имени. Знание о будущих пользователях поможет нам сфокусироваться на нуждах каждого из них, не упустив важные моменты в требованиях к системе. И так, разными аспектами системы будут пользоваться такие обобщенные пользовательские роли:
- Те, которые хранят и обмениваются своими фотографиями – назовем их «пользователи».
- Те, кто размещают свою рекламу, ориентированную на «пользователей» системы – назовем эту группу «рекламодатели».
- Хотя видение системы явно и не обговаривает задачи по администрированию системы, но так или иначе у системы будут «администраторы», которые будут обеспечивать поддержку системы для блага других пользователей
Возможно, со временем мы сможем определить ещё какие-то роли. Пока мы упускаем их из виду. Чтобы начать достаточно имеющихся.
Так, имея роли пользователей и их основные задачи, попробуем описать самые важные истории, которые могли бы нам рассказать о будущей системе. Истории предлагается писать в таком формате:
Как <пользователь>, я могу <действие>, для того, чтобы <цель>
где
<пользователь> - одна из обобщенных пользовательских ролей;
<действие> - действие, выполняемое пользователем посредством взаимодействия с системой;
<цель> - конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.
Этот формат себя хорошо зарекомендовал – он поможет нам во время продумывания и последующего обсуждения историй персонализировать себя с тем или иным пользователям, помогая лучше представить детали их взаимодействия с системой. Последняя часть <цель> может быть опущена, если цель истории и так ясна. Формат – не догма. В будущем вы сможете придумать для себя тот формат, который для вас будет лучше работать, пока что предлагаю использовать предложенный Майком Коном.
Итак, истории:
- Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
- Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
- Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
Во время обсуждения первой истории, заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» - группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.
- Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
- Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.
Пользуясь принципом симметричности требований, команда и заказчик принимают решение, что пользователь должен иметь возможность удалить свою учетную запись в случае необходимости:
- Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.
Обсуждая концепцию учетных записей, рождаются также следующие истории:
- Как пользователь я могу изменить данные своей учетной записи.
- Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.
Просто? Достаточно. По крайней мере, не сложнее, чем писать спецификации. Но дальше - интереснее. Вопросы?
К этому моменту, я надеюсь, у вас появилось много интригующих вопросов, даже, может быть, их у вас стало больше, чем до начала чтения этой статьи... Я попробую вкратце разъяснить как же все-таки это все может работать. Куда делись детали?
Первый вопрос, который задает человек, который привык работать с более тяжеловесным подходом к требованиями (основанным к примеру на подходе Software Requirements Specifications из RUP), это «куда подевались детали?»
Это вопрос затрагивает ключевой аспект использования историй. Попробую коротко объяснить.
Конечно, детали есть, и их никто не отменял – как без понимания деталей программист может написать адекватный код, а тестировщик его принять? Детали необходимы. Но использование историй смещает суть и время выработки деталей.
Детали историй – это больше не неизменная часть требований, которые продумываются заказчиками во время написания требований и предъявляются команде в готовом виде. Вместо этого заказчик и команда во время обсуждений историй совместно приходят к понимаю уровня детализации, который необходим на текущей фазе, и принимают совместные решения, пополняя истории все большим количеством информации. Пример детализации.
Рассмотрим одну из историй, идентифицированную выше:
Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Во время обсуждения этой истории с командой заказчику задают вопрос о том какая информация нужна для создания пользовательской учетной записи. Обсуждая различные варианты, заказчик и команда приходят к тому, что для первой версии системы достаточно будет проверенного электронного адреса плюс имени пользователя и его пароля.
К истории дописывается этой комментарий. Теперь история выглядит так:
Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Нужен проверенный email и выбранные пользователем имя и пароль.
В ходе дальнейших высказываний кто-то из тестировщиков задает резонный вопрос о минимальной длине пароля и проверке на уникальности имени. Продолжая дискуссию, команда и заказчики приходят к мнению, что необходимо описать основные критерии готовности истории, чтобы команда понимала ожидания и знала, когда объявлять историю готовой:
Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Нужен проверенный email и выбранные пользователем имя и пароль.
Тест 1: пользователь не может ввести пароль меньше 6 символов
Тест 2: пользователь не может ввести имя меньше 3 и больше 20 символов
Тест 3: пользователь должен иметь уникальное имя в системе
Тест 4: после регистрации пользователь должен получить имейл для активизации своей учетной записи
Тест 5: пользователь не может войти в систему, если учетная запись не была активизирована
Тест 6: при успешном входе система приветствует пользователя текстом «Добро пожаловать, <имя пользователя>»
Возможно во время реализации, тестирования и приема истории возникнут ещё какие-то дополнительные моменты. В этом случае они могут быть описаны в виде уточняющих тестов или как комментарии. Возможно из этих дополнения появятся новые истории.
Таким образом истории пополняются деталями по мере необходимости, эволюционируя от коротких высказываний до детализированных и согласованных требований со встроенными критериями готовности. Мощные инструменты работы с историями: упорядочивание, разбиение и группировка
Как видно, описанные выше истории являются более-менее автономными сущностями, и, как следствие, могут быть перечислены в другом порядке. Конечно между историями существуют связи и логические цепочки - нельзя, к примеру, удалять пользовательские записи, не умея создавать их. Но все таки можно научиться составлять истории таким образом, чтоб обеспечить некоторую свободу в выборе порядка их реализации. Свободы будет, естественно, тем больше, чем больше самих историй и чем независимее они друг от друга.
Если же истории независимы, да к тому же их достаточно много, то можно смело предположить, что их ценность с точки зрения вклада в систему различна. А значит, варьируя порядком историй, можно выставить их в таком порядке, что первые «n» историй будут играть ключевую роль в полезности системы, в то время как другие истории будут скорее необязательными добавками, привлекающими пользователей или облегчающими их работу.
Пользуясь знанием рынка, а также здравым смыслом (к сожалению на сегодняшний день оба этих критерия не поддаются численной оценке), заказчик выстраивает список историй таким образом, чтобы максимизировать возврат вложений от проекта.
Вот пример, как могли бы быть отсортированы истории вышеописанного проекта (это всего лишь один из вариантов, конечно, есть и другие):
Как гость я могу зарегистрироваться в системе для получения пользовательской учётной записи и последующей работы.
Как гость я могу войти в систему, имперсонализируясь с ранее созданной учётной записью, для последующей работы.
Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
Как пользователь я могу изменить данные своей учетной записи для корректировки измененных или неверных данных.
Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.
Как пользователь я могу удалить свою учетную запись и перестать быть пользователем системы.
Как вы видете, истории выстроены в порядке, который, во-первых, логичен с точки зрения заказчика и команды, а во-вторых ценность историй уменьшается сверху вниз. Таким образом, если, к примеру, на половине проекта наступает нехватка ресурсов (скажем, после реализации истории для администратора системы), заказчики смогут получить выгоду от продукта, так как наиболее важные истории уже будут реализованы. Это ни что иное как минимизация рисков от вложений.
Конечно, порой не так легко и очевидно принять правильное решение о порядке историй, но в этом и состоит мастерство быть заказчиком (это отдельная, неисчерпаемая тема...)
Кроме инструментария ранжирования историй, в руках у заказчика есть и другие мощные средства, позволяющие повысить эффективность своих финансовых вложений. К примеру, одна из описанных на ранней фазе проекта историй в какой-то момент может показаться слишком большой в сравнении с другими, что усложняет понимание её приоритета:
Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
В этом случае заказчик и команда могут попробовать разбить ее на несколько более мелких историй, каждая из которых может получить свой приоритет:
Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать их другим пользователям.
Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность продать их другим пользователям.
При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими.
Подобный процесс разбиения сложных и больших истории на более простые может осуществляться в теории довольно долго. На практике же, заказчики и команда в скором времени вырабатывают совместное понимание адекватного размера историй и следуют ему при написании новых и разбиении существующих историй. Этот размер зависит от количества историй, реализуемых за итерацию. Но об этом поговорим подробнее, обсуждая планирование.
Механизмом, обратным разбиению, служит группировка историй. Иногда бывает полезно склеить мелкие истории в одну побольше для улучшения понимания связности историй.
Я уверен, вы неоднократно будете пользоваться этими простыми но мощными средствами управления требованиями, когда начнете использовать истории в своих проектах.
Как вы до сих пор справлялись с подобными задачами?
Динамика знаний
Программный продукт – это не только код и документация. Это также знания о пользователях, рынке, особенностях продукта, технологиях и прочее. Если же проект – это развитие продукта, то тогда в нем должны гармонично изменяться все его составные части: код, документация и знания. А, следовательно, знания динамичны. Таким образом, что вчера казалось фактом, сегодня в свете новоприобретенных знаний таковым может уже не быть. Для историй это значит, что порядок приоритезации историй, сделанный вчера, уже сегодня, возможно, должен быть изменен.
И в этом нет ничего плохого: меняется мир, также меняются наши знания о мире. И это такой же факт для индустрии программного обеспечения, как и для всего остального.
Вот ещё один плюс хранения требований в виде списка относительно независимых историй. Его в любой момент можно пересортировать, добавить новые или удалить ненужные истории. Хранение требований в виде историй не препятствует динамичности знаний, а наоборот, базируется на том, что наши знания будут и должны меняться, иначе продукт устареет, ещё не начав использоваться.
Что дальше?
Когда начальный набор историй готов, все истории обговорены и детализированы до нужной степени, ничего больше не остается, как перейти к их реализации, выпуская программный продукт, в соответствии с приоритетами заказчиков и желаниями пользователей.
Про оценивание размера историй, планирование историй по итерациям, предсказание времени готовности историй и прочие важные аспекты речь пойдет во второй части статьи.
«Agile» - Возможные переводы: «гибкие», «динамичные», «адаптивные», во избежание искажения смысла я буду использовать оригинальный термин. Смотрите другую статью из этой серии статей на тему о сложности перевода этого термина - http://www.krivitsky.com/2007/02/blog-post.html
«Заказчик» - Тут и далее под термином «заказчик» я понимаю человека или группу людей, которые отвечают за конечный вид продукта и владеют экономической и маркетинговой базой для принятия соответствующих решений. Ссылки
- Alistair Cockburn http://alistair.cockburn.us/index.php/Software_development_as_a_cooperative_game
- Agile principles - http://agilemanifesto.org/principles.html
- Mike Cohn - http://www.mountaingoatsoftware.com/books
- XP - Extreme Programming Explained: Embrace Change by Kent Beck
- Scrum. It’s about common sense - http://controlchaos.com/
Алексей Кривицкий,
Редакция от 7.04.2007
Дмитрий Лобасев. User Stories - сделайте свои требования удобными
Года четыре назад, когда мы с коллегами только начали погружаться в мир гибких методологий, наше реальное знакомство на деле с этим миром началось с внедрения модульного тестирования. Один заразился и понеслось – через некоторое время у нас уже был даже свой фреймворк для тестирования хранимых процедур на Oracle и автоматизированный сервер сборок.
Дальше настала очередь требований – очень уж привлекательно выглядели User Stories из книжки, по сравнению с нашими 20-50 страничными описаниями требований, созданные по шаблонам, с какими-то незаполненными разделами и частично утратившие актуальность. Не претендуя на звание настоящей XP команды (а про Scrum мы тогда еще вообще не знали), мы не стали стремиться к использованию маленьких карточек с историями пользователей. Нашей целью было минимизировать затраты на написание и поддержание требований в актуальном состоянии, сделать работу с требованиями удобной и приятной, особенно для разработчиков (инициатива шла оттуда :) ).
Итак, мы с командой обсудили проблемы с существующими требованиями и создали наше общее видение – как бы нам было хорошо и удобно работать.
Создали простейший шаблон в Word на полстраницы с полями: название фичи, имя аналитика, имя человка от заказчика, поле для планируемой трудоемкости и основное поле для описания самой фичи. И стали называть это User Story. Немного позже мы еще добавили одно поле для функционального теста – это существенно повысило ценность каждой истории.
Что представлял собой текст описания истории? Иногда история была оформлена в виде варианта использования, иногда в виде фраз «должно быть это, это и это», иногда еще как-то. Но всегда эти описания были сформулированы бизнес-языком, понятным пользователям; в них не было ни одного предложения технического характера. Конечно, если была такая необходимость, там описывались конкретные алгоритмы, но опять же, только на языке бизнеса. И истории эти были короткими – на одну страницу. Иногда на две, очень-очень редко на три. Потому что не нужно писать мелкие или очевидные детали – мы предпочитали их выяснять при личном общении, укрепляя отношения в команде. И, конечно же, совсем не нужно пытаться в один документ запихнуть требования ко всей системе – его все равно никто не будет потом читать.
User stories оказались действительно очень эффективным инструментом управления требованиями – из-за их размеров они были приятны для прочтения, легки для изменений; из-за отсутствия технических деталей – проще и понятнее, они давали возможность разработчикам самим думать над реализацией, повышая уровень их ответственности и уменьшая трудоемкость описания аналитикам. И, конечно же, самому заказчику было гораздо удобнее общаться с командой с использованием таких историй.
В одном из блогов нашел Best Practices, с которыми полностью согласен:
- Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn't practical, then you'll have to role-play. An example of a developer-focused story is "Add clustered index to the Orders table." This doesn't mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like "Improve Order reporting performance", captures the same information, but is understandable to everyone on the team.
- Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don't write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.
- Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren't usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.
- Make them testable. An untestable story might be something like "Make the order screen easy to use." It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: "A novice user be able to load, enter information, and submit an order within 5 minutes." Hmmm...still seems a little questionable, but I can probably write a test like "Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes."
Если вам интересно узнать больше о User Stories, рекомендую отличную книгу Mike Cohn - User Stories Applied: For Agile Software Development.
Источник: http://lobasev.ru/2008/02/user-stories.html
Борис Лебеда. AgileCast aftermath: Постановка задач в agile-проектах (user stories)
- Кто какой формат US используете?*
Самый популярный формат <role> <action> <result/value>
В ходе дискуссии мы пришли к единому пониманию result и value. Часто result очевиден из action. Что важно, так это то, что US должны открывать глаза на результат для чего нужна создаваемая функциональность. Кроме того, US
- даёт нам понимание как заказчик видит систему.
- Упрощаем запись требований
US записывается на бизнес языке. вы спрашиваете, зачем нужна функциональность ? И находите корень вопроса? Спрашиваем, не спрашиваем, но пытаемся получить контекст проекта
- Если какая-либо часть системы для разных ролей выглядит по разному это две
разные US?
- Однозначно да. Reuse функциональности - это технический аспект, не стоит
смешивать его с US
- Cтоит ли описывать нефункциональные требования как юзер стори
(производительность и иже с ней)? Если стоит, то как?
- Мнения разделились: некоторые держат неф. требования в отдельных
документах, некоторые выражают это в историях acceptance criteria = condition of satisfaction должны быть в US, что бы из них можно было бы выделить неф. требования.
- Как выделить из user stories требования?
- Лучше всего требования полностью вести в user stories. Role, action, result
- не единственные аттрибуты US, в декомпозиции истории может быть и другой материал ... Дизайн тяжело описать в US, но присоединить к истории обычно довольно просто.
- Как выделить из user stories архитектуру?
- Все технические задачи определяются при планировании итерации.
Архитектура может записываться отдельно в виде неформального документа, который просто описывает где что искать в системе.
- Как выделить из user stories задачи программистам?
- Все технические задачи определяются при планировании итерации.
Также Некоторые минорные требования (в т.ч. по дизайну)
- Кто должен создавать user stories? Заказчик (по книжке), команда или
специальный человек?
- Это не так важно по сравнению с тем, что нужно отговорить заказчика от
указания технических деталей:
- "если бы он мог сам написать функциональность, он бы не пришёл к вам"*.
- Использование историй для Web-проектов типа новостного сайта?
- Мы не почувсвтвовали разницы между ним и другими проектами
- Можно ли по US определить трудозатраты проекта? Если да, то как?
- Можно если зафиксировать команду и эстимировать в SP
Что если проект изменяется очень сильно (Появление новой роли, нового аспекта)? К сожалению, командная оценка лучше что мы можем дать: если команда никогда не работала по SCRUM, то отфонарный велосити это единственное что мы можем предложить. Затем проводить каллибровку на будущие итерации. (Например, использовать Release burndown) Можно попробовать использовать диапазон (пессимистическая - оптимистическая оценки)
- Дополнительные идеи и замечания:
- Тим Евграшин выделяет отдельно баги и дефекты. Баги - исправления возникшие
в ходе работы над новой функциональность. Дефекты - outstanding issues: ошибка/недочёт при имплементации или поздний change request.
US хорошо использользовать для планирования, дизайн и технические задачи определяются при планировании уже непосредственно итерации.
Как не прити к тому, что бы переписывать код, в следующей итерации? В US не должно быть технических деталей: тогда команда свободнее себя чувствует в плане реализации и может предусмотреть такие изменения
Оригинал: http://groups.google.com/group/agile-ukraine/browse_thread/thread/90a645d2f150eb24
QA. Что такое User Stories?
Начали внедрять у себя в проекте Scrum для QA команды и столкнулись с проблемой непонимания со стороны «новобранцев» одного из ключевых определений в скраме — юзер стори. Или даже правильнее было бы сказать, что проблема в черезчур прямолинейном понимании данного определения. Например, они целиком и полностью уверены, что под понятием user story скрываются исключительно задания, которые вносят новую функциональность в продукт. Но ведь это не всегда верно, ведь в списке задач есть такие черезвычайно сложные и трудоёмкие задачи как рефакторинг, нагрузочное тестирование или же интеграция модулей в приложении. Отсюда напрашивается первый вывод — user story в реальной жизни содержат не только описания нового функционала видимого клиенту. Мало того, данные требования в сложных системах могут быть всего лишь вершиной айсберга по сравнению с огромным количеством скрытых задач по созданию сложных алгоритмов и настройке безотказной системы.
К тому же выяснилось, что в некоторых случаях обычный task принимают за user story. Но как же отличить эти два понятия? С ходу напрашивается ответ, что юзер стори агрегирует в себя такси, а следовательно таск, в отличии от юзер стори, сущность атомарная. Это утверждение не идеально, так как понятие атомарности, как показала практика, у каждого своё. Например, тестеру нужно написать автоматизированные тесты для приёмочного тестирования, вот он и создаёт у себя в беклоге юзер стори «create selenium tests» с единственным таском, аналогичного содержания и даёт оценку этой задаче в 10 идеальных часов (при условии что юзер стори оценена в 2 story point-а, а 1SP = 5 идеальным часам). При этом он утверждает, что на более мелкие куски разделить просто на просто невозможно. Но стоит задать этому человеку несколько наводящих вопросов и мы увидим, что перед нами появиться список с 5-тью задачами и эстимейшеном в 13 часов. Итак, мысль номер два — юзер стори не предназначены для точной оценки времени и ресурсов, требуемых для решения возникшей задачи.
И теперь перейдём к последнему пункту, который отличает, на мой взгляд, task от user story (US). Любая US обязана содержать в себе элементы приёмочного тестирования. И если для команды разработчиков приёмочными тестами будут автоматизированные тесты, созданные коммандой QA, то для самой комманды тестеров эту роль уже будет играть успешное прохождение всех созданных ими тестов на continuous integration сервере.
Выходя из всего вышеперечисленного, хотелось бы дать своё определение user story.
User story — общее описание задачи, которое позволяет выполнить предварительную оценку сложности разработки (реализации) и является основой для приёмочного тестирования.
На этом спасибо и до новых встреч. Данное определение будет помещено на страницу Scrum терминологии.
Комментарии
немного комментариев к этому посту (надеюсь, это натолкнет кого-то на понимание неявных проблем):
0. во-первых (хотел сказать «в-нулевых»), спасибо alexsun за пост. истории — это важная часть функционирования scrum проекта. так что здорово, что один из ранних постов на этом сайте посвящён как раз этой теме.
1. «Начали внедрять у себя в проекте Scrum для QA команды»
если QA не являются частью SCRUM команды, то скорее всего определить критерий done для разработчиков будет весьма тяжело, так как на выходе такой «подкоманды» вместо potentially shippable product increment мы получаем набор работ по тестированию, что противоречит основам SCRUM о результатах спринта.
если зайти слишком далеко, то спринты в этом случае могут выродиться в мини waterfall, со спринтами разработка-тестирование-фиксы-тестирование...
я ни в коем случае не хочу сказать, что в проекте alexsun всё было именно так. просто хочу заострить внимание читателей этого сайта на эту проблему, так как во время тренингов, которые мы проводим, люди часто задают вопрос на эту тему.
2. “...тестеру нужно написать автоматизированные тесты для приёмочного тестирования, вот он и создаёт у себя в беклоге юзер стори “create selenium tests” с единственным таском, аналогичного содержания... “
Похоже, понятие историй и задач немного перепутано.
Истории – это требования, высказанные от имени конечных пользователей, где понятно что должен делать пользователь в системе для реализации своих нужд.
Задачи – это шаги, которые необходимо предпринять конкретными членами команды для реализации той или иной истории. Они носят технический характер. Иногда задачи не являются явно частями какой-то конкретной истории.
Так “сreate selenium tests” – это суть задача.
3. “Итак, мысль номер два — юзер стори не предназначены для точной оценки времени и ресурсов, требуемых для решения возникшей задачи.”
Мысль верная. В product backlog может быть сто и более историй. Если команде для их оценивания придётся бить их на задачи, оценивать каждую и суммировать, то мы получим во-первых избыточно детальный план, которым будем сложно управлять; во-вторых – при изменении командой понятия done (читай добавления новых задач в каждую историю) придётся переоценить все истории; в-третьих – это просто займёт слишком много времени, которое чаще всего есть на что потратить хорошей команде да и не факт, что все истории беклога (ниже уровня текущего спринта) вообще будут реализованы.
То есть мы приходим к тому, что нужно иметь более быстрый способ оценивания историй, точности которого было бы достаточно для построения долгосрочных (release) планов. Story Points для этого идеально подходят.
Для краткосрочной оценки (планирование текущего спринта) использование подхода разбития истории на задачи работает отлично. Так как он помогает команде обсудить и синхронизировать технические детали реализации, тестирования и приёма истории.
4. “Любая US обязана содержать в себе элементы приёмочного тестирования. И если для команды разработчиков приёмочными тестами будут автоматизированные тесты, созданные командой QA, то для самой команды тестеров эту роль уже будет играть успешное прохождение всех созданных ими тестов на continuous integration сервере.”
То что любая история должна содержать элементы приёмочного тестирования – это на 100% верно. Каждая история должна быть I.N.V.E.S.T.: Independent, Negotiable, Valuable, Estimatable, Testable и Sized properly.
Не могу согласиться с тем, что для различных частей SCRUM команды для одних и тех же историй приёмочные тесты будут разными.
Команда (разработчики + тестировщики) работает над одним и тем же набором историй. У них одна цель – разработать истории, которые будут удовлетворять (читай приняты) заказчиком. Отсюда вывод: и для разработчиков, как и для тестировщиков приёмочными тестами будут тесты, согласованные с заказчиком на этапе формирования и планирования истории на текущий спринт.
Мышление типа «моя история прошла мои тесты, пройдёт ли она твои меня не касается» — вредно для команды.
Удач.
Источник: http://scrum.org.ua/chto-takoe-user-story/
Mike Cohn
One of the best ways to do this is to work with user stories, which are a lightweight technique for expressing software requirements. A user story is a brief description of functionality as viewed by a user or customer of the system. User stories are free-form and there is no mandatory syntax. However, it can be useful to think of a story generally fitting the form:
As a <type of user>, I want <capability> so that <business value>.
With this template as an example, you may have the story “As a book-buyer, I want to search for a book by ISBN so that I can find the right book quickly.”
As an example, consider a travel reservation site that includes the user story, “As a user, I want to be able to cancel a reservation.” In discussing this story with the product owner, the developers learn that her conditions of satisfaction for this story include that:
- A user who cancels more than 24 hours in advance gets a complete refund
- A user who cancels less than 24 hours in advance is refunded all but a $25 cancellation fee
- A cancellation code is displayed on the site and is emailed to the user
As an example of disaggregating a story into tasks, suppose we have the story "A user can search for a hotel on various fields." That story might be turned into the following tasks:
- code basic search screen
- code advanced search screen
- code results screen
- write and tune SQL to query the database for basic searches
- write and tune SQL to query the database for advanced searches
- document new functionality in help system and user's guide
exprogramming.ru
User Story (что-то типа рассказа пользователя) - это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. Форма - один-два абзаца текста понятного пользователю (не сильно технического).
User Story пишется Заказчиком. Они похожи на сценарии использования системы, но не ограничиваются пользовательским интерфейсом. По каждой истории пишутся функциональные тесты, подтверждающие что данная история корректно реализована - их еще называют приемочными (Acceptance tests).
Каждой User Story дается приоритет со стороны бизнеса (пользователь, заказчик, отдел маркетинга) и оценка времени выполнения со стороны разработчиков. Каждая история разбивается на задачи и ей назначается время когда ее начнут реализовывать.
User Stories используются в XP вместо традиционных требований. Главное отличие User Story от требований (requirements) - уровень детализации. User Story содержит минимум информации, необходимой для обоснованной оценки того, сколько времени надо на ее реализацию.
Типичная User Story занимает 1-3 недели идеального времени. История требующая менее 1 недели слишком детализирована. История требующая более 3 недель может быть разбита на части - отдельные истории.
Наш опыт.
Поскольку наш продукт скорее коробочный чем заказной, то Заказчик для нас - это член команды который знает что надо сделать (роль сходная с Program Manager в Microsoft, или с Постановщиком Задач в советской схеме работы). Другими словами, если невозможно иметь реального Заказчика в своей команде - заведите человека, который будет играть такую роль.
Essential XP: Card, Conversation, Confirmation. Ron Jeffries
Date: 08/30/2001
The XP Circle of Life helps keep projects alive. A key aspect of this cycle is the Acceptance Test. Acceptance Tests are critical to communication among team members, especially between customer and programmer.
In Extreme Programming Installed, we describe the four elements of the XP "Circle of Life": the on-site customer, working with the programmers, uses the planning game to select user stories to make up the most valuable small releases. Critical to this cycle are the user stories.
User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.
Card
User stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It's used in planning. Notes are written on it, reflecting priority and cost. It's often handed to the programmers when the story is scheduled to be implemented, and given back to the customer when the story is complete.
Conversation
The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated (usually during release planning), and again at the iteration planning meeting when the story is scheduled for implementation. The conversation is largely verbal, but is often supplemented with documents. You'll often see spreadsheets showing calculations, sketches of proposed window layouts, even multi-page documents looking much like conventional specifications. Favor discussion when it'll work, but reflect detail on paper or computerized format.
Confirmation
No matter how much discussion or how much documentation we produce, we can't be as certain as we need to be about what is to be done. The third C in the user story's key aspects adds confirmation that we sorely need. This component is the acceptance test.
At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they've done what is needed. She defines the acceptance tests that will be used to show that the story has been implemented correctly.
The programmers implement the story, and they also implement the acceptance tests. (Some teams build tools that let the customer enter the tests herself, and other teams have QA people or testers who help with the job. But one one way or another, the acceptance tests get done.
At the end of the iteration, when the story is done, the programmers show the customer that the story is done, confirming success by showing that the acceptance tests run correctly.
The confirmation provided by the acceptance test is what makes possible the simple approach of card and conversation. When the conversation about a card gets down to the details of the acceptance test, the customer and programmer settle the final details of what needs to be done. When the iteration ends and the programmers demonstrate the acceptance tests running, the customer learns that the team can, and will, deliver what's needed. The confirmation, in terms of acceptance tests, is what keeps the Circle of Life turning. And the Circle of Life ... that's what keeps your project alive.
