1) Что такое User-Stories?
2) Зачем, и когда применяют User-Stories?
3) Типичные ошибки при внедрении User-Stories.
4) Чем User-Stories отличаются от Use Cases?
User stories are an agile approach to requirements
that help shift the focus from writing about
requirements
to talking about them.
1. Что такое «Юзер-стори» (user story)?
Одной из основополагающих практик Scrum являются Пользовательские Истории (User Stories). Scrum предлагает использовать истории при разработке и/или сборе требований к программному обеспечению – метод пользовательских истории ускоряет процесс сбора ключевых требований к ожидаемому продукту, и помогает очертить границы продукта еще на начальной стадии проекта.
Если говорить коротко, Пользовательская история – это небольшой абзац текста, сформулированный на повседневном или деловом языке заказчика, и повествующий о том, какое действие сможет выполнять пользователь с помощью системы, какого класса пользователь, и для решения какой бизнес-задачи (или бизнес-задач) он это будет делать.
Нет строго формата для формулирования пользовательских историй. Каждый имеет право выбрать для себя формат, который будет для него наиболее подходящим, и наиболее эффективным именно в данном проекте.
В свое время Майк Кон предложил шаблон написания пользовательских историй, который и до нынешних пор остается достаточно популярным: «Как пользователь с ролью такой-то я хочу в системе делать то-то».
Но опять-таки, «Формат – не догма», соглашусь с А. Кривицким (ведущим координатором украинского сообщества Agile-ukraine). У самого Майка Кона в его книге «User stories applied» практически все (возможно, все) примеры историй не соответствуют предложенному им же шаблону. Аналогично, пользовательские истории Хенрика Книберга в его книге «Скрам с передовой» сформулированы иначе (т.е. не по шаблону).
2. Зачем, и когда применяют Юзер-стори?
«Пользовательские истории не являются конечными требованиями к системе, и не предназначены быть полезными в конце итерации», – отмечает Майк Кон в своей книге «User stories applied».
Назначение пользовательских историй – как можно быстрее «выудить» (извлечь) из заказчика хоть какие-то фразы о ключевых бизнес-сервисах требуемого продукта. Заказчику предлагается в любой, наиболее удобной для него формулировке, ответить на простые вопросы: кто будет пользоваться системой, какие действия будет выполнять в системе, и как выполнение этих действий поможет ему при выполнении его ежедневных задач в бизнесе.
Можно сказать, что идея пользовательских историй – подсказать заказчику (или автору концепции продукта, в случае коробочной разработки), как ему «правильно», лаконично и наиболее эффективно, подать его исходные требования.
Традиционно, после получения пользовательских историй от заказчика каждая история обсуждается с заказчиком, при необходимости детализируется, и на основе историй обязательно формируются уже конечные требование к системе. Полученные требования могут быть по- прежнему краткими, и не сильно детализированным, как и сами пользовательские истории, но эти требования обязательно должны быть четкими, однозначными, и что самое главное – проверяемыми (т.е. должны содержать критерии проверки).
В своей книге «User stories applied» (глава 1) Майк Кон замечает, что процесс разработки требований с помощью пользовательских историй подразумевает три аспекта:
В своей же практике я «извлекаю» из заказчика его первичные требования (пользовательские истории) итеративно:
Получив от заказчика список таких историй, я имею достаточно четкое видение о границах системы. На основе данного списка можно планировать общий объем работ, и – достаточно быстро сформировать конечный список требований на итерацию.
Был случай, когда заказчик по своей инициативе представил мне объемный документ, с так называемым техническим заданием на реализацию системы (комплексной информационной системы для его бизнеса).
Понять общую концепцию ожидаемой системы, а также ключевой набор ее функционала было достаточно трудно, читая этот документ. После того, как мною было предложено перечислить всех участников бизнеса, пользователей будущей системы, с тем, чтобы потом отдельно обсудить возможности каждого из них, и заказчик уже был готов к формированию списка таких участников, – заказчик сам заметил, что его исходное «ТЗ» не верно, и что мне не стоит его читать.
Впоследствии заказчик был благодарен за предложенный мною способ быстрого формирования требований к системе. Планировать итерации было легко, и мы не боялись погружаться в обсуждение деталей той или иной, отдельной истории.
Второй проект (автоматизация вендингового бизнеса) может служить примером, где заказчик самостоятельно формировал список историй, даже не догадываясь о том, что они так называются.
Как и в первом случае, заказчик подготовил документ, именуемый «ТЗ». Программисты читать этот документ не могли, и использовать его в качестве критериев для сдачи системы тоже было практически невозможно. Положительная сторона документа была в том, что документ был разбит на пункты, и в целом не был объемным. Не смотря на то, что понять каждый отдельный пункт было достаточно сложно, по каждому из них заказчик охотно рассказывал (или печатал в скайп) реальные истории из бизнеса – какие есть задачи в бизнесе, и как система поможет их решать, предоставляя ту или иную возможность.
К сожалению, реальные формулировки исходных требований и прилагаемых к ним историй не могу привести в виду конфиденциальности проекта, однако постараюсь предложить пример, как это выглядело, по сути.
Выглядело это примерно так.
Исходное требование:
- «Журнал А. Заносится номер машины и сумма. Кассир видит два поля. В первое поле заносит сумму. Система сравнивает значения и выдает сообщение о несоответствии, если такое имеется…».
Прилагаемая история:
- «Операторы обслуживают машины. Каждую машину обслуживает один оператор. Оператор берет у кассира деньги, чтобы заполнять монетники для выдачи сдачи. На каждом операторе числится сумма. Мы хотим контролировать операторов. Мы хотим, чтобы кассир заносил в систему, сколько он выдал денег оператору, а по отчетам смотреть, сколько денег осталось … и т.д.».
Из примера видно, что подобные формулировки от заказчика никак нельзя назвать конечными требованиями к системе. Формулировки нечетки, неоднозначны и неочевидны для восприятия.
Положительная сторона в следующем:
- уже упоминаются некоторые роли участников бизнеса (кассир, оператор, «мы»…);
-также упоминаются некоторые их задачи в бизнесе и цели по отношению к системе.
Приведенные формулировки есть не что иное, как Пользовательские Истории – исходные требования от заказчика. Таких пользовательских историй вполне достаточно, чтобы начать конструктивное обсуждение с заказчиком, и в результате сформировать список уже четких требований уровня «цели пользователя» к системе.
Из пользовательских историй у нас рождались требования следующего характера:
Такие требования умышленно абстрагированы от многих деталей и, что очевидно, еще не достаточны (без дополнительного пояснения, устного или письменного) для передачи программистам или тестировщикам.
3. Типичные ошибки при внедрении User Stories
В предыдущих разделах я постаралась показать, чем пользовательские истории являются, по сути. Также, постаралась объяснить, что шаблон, предложенный Майком Коном, «Как <пользователь>,я могу <действие>, для <цель>», не есть их неотъемлемым свойством.
К сожалению, многие команды, желающие перейти на гибкую разработку, и впервые предпринимающие попытки внедрения SCRUM, убеждены, что именно шаблон Майка Кона и есть суть пользовательских историй. Пытаясь «внедрить SCRUM целиком» (а значит внедрить абсолютно все его практики), команды начинают «применять» Пользовательские Истории везде, и как только могут.
Нередки случаи, когда под «шаблон» пользовательских историй начинают «загоняться» (перефразироваться) уже готовые однозначные требования к системе.
Хорошо, если «загоняются под шаблон» только требования уровня «цели пользователя». Тогда, например, вместо требования:
- «менеджер по закупкам может сформировать заказ на закупку»,
Получается:
- «Как менеджер по закупкам, я могу с помощью системы формировать заказы на закупки, это предостерегает меня от возможных ошибок при ручном формировании заказов, также избавляет от большого объема рутинной работы».
Хуже, когда под «шаблон» начинают «загоняться» требования уровня пользовательского интерфейса и/или его реализации. Вместо привычного описания экранных форм (словесного или с помощью прототипов), необходимых для реализации того или иного требования уровня «цели пользователя» появляется набор «историй» следующего характера:
- «Как пользователю мне нужно поле для выбора из четырёх и более значений, чтобы выбирать тип заказа».
- «Как архитектор интерфейса я должен иметь возможность автоматически создавать форму для ввода любого количества значений» и т.д.
Перефразирование требований к интерфейсу под стиль «пользовательских историй» не дает никакого выигрыша. Наоборот, требования становятся более громоздкими и неудобными для восприятия.
Если вы, тем не менее, решились на «перефразирование» всех требований под «шаблон», пожалуйста, не думайте, что этим вы следуете рекомендациям SCRUM ;).
4. Заключение
В качестве заключения подведу небольшие итоги всего вышесказанного.
Когда на одном из тренингов по SCRUM, посещенных мною, я впервые услышала о Пользовательских Историях, то была крайне удивлена:
- Я была удивлена тем, что практика Пользовательских Историй (User Stories) предлагается, как некое новшество.
- И я была удивлена тем, что метод, который я давно использую в своих проектах (а как же иначе), и который мы с инструктором изначально предлагали на специализированных тренингах для аналитиков, как, оказалось, именуется «практикой Пользовательских Историй» :).
Нет строго формата для формулирования пользовательских историй. Каждый имеет право выбрать для себя формат, который будет для него наиболее подходящим, и наиболее эффективным именно в данном проекте.
В свое время Майк Кон предложил шаблон написания пользовательских историй, который и до нынешних пор остается достаточно популярным: «Как пользователь с ролью такой-то я хочу в системе делать то-то».
Но опять-таки, «Формат – не догма», соглашусь с А. Кривицким (ведущим координатором украинского сообщества Agile-ukraine). У самого Майка Кона в его книге «User stories applied» практически все (возможно, все) примеры историй не соответствуют предложенному им же шаблону. Аналогично, пользовательские истории Хенрика Книберга в его книге «Скрам с передовой» сформулированы иначе (т.е. не по шаблону).
2. Зачем, и когда применяют Юзер-стори?
«Пользовательские истории не являются конечными требованиями к системе, и не предназначены быть полезными в конце итерации», – отмечает Майк Кон в своей книге «User stories applied».
Назначение пользовательских историй – как можно быстрее «выудить» (извлечь) из заказчика хоть какие-то фразы о ключевых бизнес-сервисах требуемого продукта. Заказчику предлагается в любой, наиболее удобной для него формулировке, ответить на простые вопросы: кто будет пользоваться системой, какие действия будет выполнять в системе, и как выполнение этих действий поможет ему при выполнении его ежедневных задач в бизнесе.
Можно сказать, что идея пользовательских историй – подсказать заказчику (или автору концепции продукта, в случае коробочной разработки), как ему «правильно», лаконично и наиболее эффективно, подать его исходные требования.
Традиционно, после получения пользовательских историй от заказчика каждая история обсуждается с заказчиком, при необходимости детализируется, и на основе историй обязательно формируются уже конечные требование к системе. Полученные требования могут быть по- прежнему краткими, и не сильно детализированным, как и сами пользовательские истории, но эти требования обязательно должны быть четкими, однозначными, и что самое главное – проверяемыми (т.е. должны содержать критерии проверки).
В своей книге «User stories applied» (глава 1) Майк Кон замечает, что процесс разработки требований с помощью пользовательских историй подразумевает три аспекта:
- Написание историй;
- Обсуждение историй (с целью выявления деталей и формирования четких требований);
- Документирование деталей и критериев проверки по каждой отдельной истории.
В своей же практике я «извлекаю» из заказчика его первичные требования (пользовательские истории) итеративно:
- Сначала я прошу заказчика перечислить всех участников бизнеса, которые предположительно будут пользоваться системой.
- Затем я прошу по каждому участнику перечислить задачи, которые участник сможет выполнить с помощью системы (цели пользователя).
- Формулировать прошу следующим образом: «Пользователь может сделать…то-то». Именно – «сделать», а не «делать»; например, «Менеджер по закупкам может сформировать и отправить заказ на закупку». Таким образом, однозначно видна цель действия (метод заимствован у А. Коберна из его рекомендаций по написанию вариантов использования).
- Зачастую, первые несколько историй мы с заказчиком формируем совместно; также привожу несколько примеров, чтобы заказчик лучше понял, что от него ожидается.
Получив от заказчика список таких историй, я имею достаточно четкое видение о границах системы. На основе данного списка можно планировать общий объем работ, и – достаточно быстро сформировать конечный список требований на итерацию.
Был случай, когда заказчик по своей инициативе представил мне объемный документ, с так называемым техническим заданием на реализацию системы (комплексной информационной системы для его бизнеса).
Понять общую концепцию ожидаемой системы, а также ключевой набор ее функционала было достаточно трудно, читая этот документ. После того, как мною было предложено перечислить всех участников бизнеса, пользователей будущей системы, с тем, чтобы потом отдельно обсудить возможности каждого из них, и заказчик уже был готов к формированию списка таких участников, – заказчик сам заметил, что его исходное «ТЗ» не верно, и что мне не стоит его читать.
Впоследствии заказчик был благодарен за предложенный мною способ быстрого формирования требований к системе. Планировать итерации было легко, и мы не боялись погружаться в обсуждение деталей той или иной, отдельной истории.
Второй проект (автоматизация вендингового бизнеса) может служить примером, где заказчик самостоятельно формировал список историй, даже не догадываясь о том, что они так называются.
Как и в первом случае, заказчик подготовил документ, именуемый «ТЗ». Программисты читать этот документ не могли, и использовать его в качестве критериев для сдачи системы тоже было практически невозможно. Положительная сторона документа была в том, что документ был разбит на пункты, и в целом не был объемным. Не смотря на то, что понять каждый отдельный пункт было достаточно сложно, по каждому из них заказчик охотно рассказывал (или печатал в скайп) реальные истории из бизнеса – какие есть задачи в бизнесе, и как система поможет их решать, предоставляя ту или иную возможность.
К сожалению, реальные формулировки исходных требований и прилагаемых к ним историй не могу привести в виду конфиденциальности проекта, однако постараюсь предложить пример, как это выглядело, по сути.
Выглядело это примерно так.
Исходное требование:
- «Журнал А. Заносится номер машины и сумма. Кассир видит два поля. В первое поле заносит сумму. Система сравнивает значения и выдает сообщение о несоответствии, если такое имеется…».
Прилагаемая история:
- «Операторы обслуживают машины. Каждую машину обслуживает один оператор. Оператор берет у кассира деньги, чтобы заполнять монетники для выдачи сдачи. На каждом операторе числится сумма. Мы хотим контролировать операторов. Мы хотим, чтобы кассир заносил в систему, сколько он выдал денег оператору, а по отчетам смотреть, сколько денег осталось … и т.д.».
Из примера видно, что подобные формулировки от заказчика никак нельзя назвать конечными требованиями к системе. Формулировки нечетки, неоднозначны и неочевидны для восприятия.
Положительная сторона в следующем:
- уже упоминаются некоторые роли участников бизнеса (кассир, оператор, «мы»…);
-также упоминаются некоторые их задачи в бизнесе и цели по отношению к системе.
Приведенные формулировки есть не что иное, как Пользовательские Истории – исходные требования от заказчика. Таких пользовательских историй вполне достаточно, чтобы начать конструктивное обсуждение с заказчиком, и в результате сформировать список уже четких требований уровня «цели пользователя» к системе.
Из пользовательских историй у нас рождались требования следующего характера:
- Кассир может зафиксировать сумму, выданную оператору;
- Оператор может посмотреть график посещения машин;
- Руководитель может просмотреть отчет по оператору, где отражена «сумма на операторе», где видны фактические посещения машин операторами, где видны несоответствия фактических посещений и запланированных, и т.д.
Такие требования умышленно абстрагированы от многих деталей и, что очевидно, еще не достаточны (без дополнительного пояснения, устного или письменного) для передачи программистам или тестировщикам.
3. Типичные ошибки при внедрении User Stories
В предыдущих разделах я постаралась показать, чем пользовательские истории являются, по сути. Также, постаралась объяснить, что шаблон, предложенный Майком Коном, «Как <пользователь>,я могу <действие>, для <цель>», не есть их неотъемлемым свойством.
К сожалению, многие команды, желающие перейти на гибкую разработку, и впервые предпринимающие попытки внедрения SCRUM, убеждены, что именно шаблон Майка Кона и есть суть пользовательских историй. Пытаясь «внедрить SCRUM целиком» (а значит внедрить абсолютно все его практики), команды начинают «применять» Пользовательские Истории везде, и как только могут.
Нередки случаи, когда под «шаблон» пользовательских историй начинают «загоняться» (перефразироваться) уже готовые однозначные требования к системе.
Хорошо, если «загоняются под шаблон» только требования уровня «цели пользователя». Тогда, например, вместо требования:
- «менеджер по закупкам может сформировать заказ на закупку»,
Получается:
- «Как менеджер по закупкам, я могу с помощью системы формировать заказы на закупки, это предостерегает меня от возможных ошибок при ручном формировании заказов, также избавляет от большого объема рутинной работы».
Хуже, когда под «шаблон» начинают «загоняться» требования уровня пользовательского интерфейса и/или его реализации. Вместо привычного описания экранных форм (словесного или с помощью прототипов), необходимых для реализации того или иного требования уровня «цели пользователя» появляется набор «историй» следующего характера:
- «Как пользователю мне нужно поле для выбора из четырёх и более значений, чтобы выбирать тип заказа».
- «Как архитектор интерфейса я должен иметь возможность автоматически создавать форму для ввода любого количества значений» и т.д.
Перефразирование требований к интерфейсу под стиль «пользовательских историй» не дает никакого выигрыша. Наоборот, требования становятся более громоздкими и неудобными для восприятия.
Если вы, тем не менее, решились на «перефразирование» всех требований под «шаблон», пожалуйста, не думайте, что этим вы следуете рекомендациям SCRUM ;).
4. Заключение
В качестве заключения подведу небольшие итоги всего вышесказанного.
- Пользовательские Истории – это исходные требования от заказчика о целях пользователей в общем виде. Каждая Пользовательская История – это повод к обсуждению с заказчиком.
- Пользовательские Истории ни в коем случае не являются конечными требованиями к системе. Ошибкой считать, что Пользовательские Истории должны «как есть» помещаться в «баклог». На основе пользовательских историй обязательно должны быть сформированы четкие требования к системе (зачастую, варианты использования).
- Нет цели – сформулировать требование по «шаблону» Пользовательской Истории. Если известны конкретные требования к системе, то перефразировать их под «шаблон» не имеет смысла. Шаблон, предложенный Майком Коном, не является неотъемлемым свойством Пользовательских Историй, а есть лишь подсказка к сути их содержания.
- Основное отличие Пользовательских Историй от Вариантов Использования заключается в том, что Истории являются исходными требованиями, а Варианты Использования – конечными.
- Пользовательские Истории, как правило, пишутся в более свободном формате, чем Варианты Использования. Глядя на пользовательские истории, зачастую нельзя однозначно определить критерии их проверки. Пользовательские Истории, в основном, являются только идеями требований; в то время как Варианты Использования есть полноценные требования к системе.
- Название каждого Варианта Использования (ВИ) представляет собой краткую формулировку одной из целей пользователя и есть законным требованием к системе уровня «цели пользователя». Детализация же ВИ (его описание) может быть представлена как в виде пошаговых сценариев, так и в виде общего текста.
- При сборе требований к коробочному продукту (где заказчиком являемся мы же) эффективно сразу начинать с перечисления Вариантов Использования, без предварительного написания Пользовательских Историй.
***
Основное преимущество Пользовательских Историй заключается в следующем:- Пользовательские Истории формулируются самим заказчиком и тем самым служат законным источником к их обсуждению и разработке конечных требований;
- Они всегда коротки и не содержат деталей реализации – тем самым не дают возможности заказчику создать большие объемы непонятных и нереализуемых требований;
- Пользовательские Истории сфокусированы на целях и бизнес-задачах пользователей – это помогает быстро получить полный список ключевых требований к системе, а также и не создать неиспользуемый функционал.
- Имея перед собой законченный набор историй, мы можем быть почти уверены, что реализуя его, создадим требуемую систему – Пользовательские Истории очерчивают границы системы.
***
Когда на одном из тренингов по SCRUM, посещенных мною, я впервые услышала о Пользовательских Историях, то была крайне удивлена:
- Я была удивлена тем, что практика Пользовательских Историй (User Stories) предлагается, как некое новшество.
- И я была удивлена тем, что метод, который я давно использую в своих проектах (а как же иначе), и который мы с инструктором изначально предлагали на специализированных тренингах для аналитиков, как, оказалось, именуется «практикой Пользовательских Историй» :).
Комментариев нет:
Отправить комментарий