Как разбить рабочий процесс бизнес-процесса на истории пользователей
Владельцы Продукта предъявляют особые требования к тому, как Продукт должен включать пользователей в сложный рабочий процесс бизнес-процесса (одобрения, а что нет). Самый простой способ документировать требование в форме диаграммы процесса / блок-схемы.
Однако в Scrum рекомендуется, чтобы требования были представлены в форме пользовательских историй. Каков наилучший способ приблизиться к этому?
Вариант 1 Имейте общие пользовательские истории, которые охватывают рабочий процесс, и прикрепите диаграмму потоковой диаграммы как вспомогательный документ. Например, как автор, я хочу иметь возможность отправить мою статью на утверждение, чтобы она была опубликована.
Плюсы- людям легче понять и переварить - вместо того, чтобы читать 10-20 пользовательских историй.
Минусы это становится эпическим
Вариант 2 Разбейте сложную блок-схему на собственные пользовательские истории. Например, как автор, я хочу иметь возможность представить свою статью. Как редактор, я хотел бы получать уведомления, когда статья была отправлена, чтобы я мог ее просмотреть. Как редактор, я должен одобрить статью. Как редактор, я хотел бы иметь возможность запросить дополнительную информацию...
Плюсы чистого Scrum. легко расставить приоритеты / оценить / спланировать
Минусы Как вы можете видеть, даже короткий рабочий процесс бизнес-процесса легко превратится во множество пользовательских историй.
7 ответов
Я согласен с pma_. Делай то, что имеет смысл. В этом случае у вас есть несколько прекрасно выглядящих пользовательских историй.
"Как редактор, я хотел бы получать уведомления, когда статья была отправлена, чтобы я мог ее просмотреть".
Если у вас есть тонна этих, то, возможно, они слишком малы. Все они будут 1-2 часа. Это, наверное, не очень хорошая вещь. В этом случае попробуйте сгруппировать их. Возможно "Как редактор, я хочу иметь возможность управлять статьями". Это будет включать несколько из тех, которые у вас уже есть.
Имейте в виду цели пользовательских историй...
- Отслеживание элементов на графике выгорания
- Поставить полностью функциональную работу (не бесполезную часть работы)
- Есть оценочные части
Если вы можете достичь этих целей, у вас все хорошо. Если нет, попробуйте еще раз.
О, и последнее: сохраняйте блок-схему, не выбрасывайте ее в пользу историй. Но дополните рассказы этим.
Я склоняюсь к ранним возможностям / эпикам с основной функциональностью добавления конечного пользователя / заинтересованного лица, например, в вашем примере, чтобы "опубликовать статью, чтобы подписчики могли получать последние новости". Затем, когда функция будет приближаться к реализации, я буду разбивать ее на истории размера реализации, если это необходимо.
Большинство нетривиальных бизнес-процессов выигрывают от разделения во время внедрения, чтобы их можно было постоянно развертывать и проверять, чтобы получать ранние отзывы от заинтересованных сторон. Большим недостатком единой реализации большого взрыва является поздняя проверка. Я думаю, что ранняя обратная связь перевешивает возросшее административное бремя обработки нескольких историй.
Совет о том, как разделить эпос на истории: у Лассе Коскела есть отличная статья о том, как разделить истории по-разному.
Если этот бизнес-процесс похож на большинство бизнес-процессов, каждый из этих шагов будет иметь значительное количество правил. Эти правила должны соответствовать критериям приемлемости для этих историй и, в идеале, автоматизированным тестам, чтобы доказать, что код работает как задумано. Из-за большого количества критериев приемлемости я бы склонялся ко второму варианту.
В настоящее время мы создаем систему управления контентом на основе бизнес-процессов. Мы разделяем наши процессы на истории согласно вашему второму варианту.
Но, конечно, мы держим блок-схему под рукой. Фактически, мы распечатываем это и прикрепляем это к стене. Мы даже сохраняем каждую старую версию, поэтому у нас на стене прикреплен собственный бумажный контроль версий (в дополнение к использованию git для электронной версии;-))
Для меня все проворство заключается в использовании здравого смысла. В этом случае у вас идеальный дизайн, поэтому просто реализуйте его и не ищите ненужных вещей.
Рабочие процессы представляют собой интересную запись для написания пользовательских историй и эпопей, но пользовательские истории не соответствуют рабочим процессам, а соответствуют бизнес-возможностям. Таким образом, вы включаете в этот вопрос какое-то ошибочное мышление с самого начала. Рабочие процессы - хороший инструмент для разговора, но они будут жить независимо от рабочего процесса, поскольку они касаются функциональности, а не времени. Сроки живет в бизнес-правилах. На этом примечании бизнес-правила не являются критериями принятия, они представляют собой связь между критериями принятия, которые могут быть продемонстрированы владельцем продукта, и тестовыми примерами. Опять же, критерии принятия - это особенности, а не поведение. Поведение живет в деловых правилах. Например, у меня может быть "История пользователя" для банкомата с надписью "Как пользователь, я могу проверить баланс своего счета". И Критерии приемки могут быть такими: "Если меня переутомят, я получу предупреждение". Правила того, что представляет собой избыточный проект (у меня на счете было 1000 долларов, и я внес свой платежный чек на 2500 долларов, но это не прояснится до получения ипотечного платежа в 1500 долларов и т. Д.), Не являются критериями приемлемости. Это бизнес-правила, выполнение которых приводит к очевидным действиям Критериев приемки. Обратите внимание, что эта пользовательская история может быть захвачена с помощью анализа рабочих процессов, но может существовать во многих рабочих процессах (или вообще без них).
Однако в Scrum рекомендуется, чтобы требования были представлены в форме пользовательских историй. Каков наилучший способ приблизиться к этому?
Два варианта, которые вы упомянули, на самом деле не являются вариантами, это последовательные этапы, ИМХО. Во время гибкого сбора требований или планирования продукта первым шагом является создание историй EPIC. После того, как у вас есть эти эпосы, вам нужно разбить их на более мелкие куски.
Без EPIC вы, скорее всего, столкнетесь с проблемой создания случайных историй, не понимая смысла принадлежности истории. Вы можете создать иерархию в пользовательских историях. Не понимая этого, все просто случайно, следовательно, становится сложнее обернуть голову или управлять историями как ПО.
Конечно, это гораздо больше, чем то, что я упомянул в предыдущем абзаце. Вот почему, вероятно, вам нужен опытный Scrum Coach или много прилежного чтения / реализации по гибкому планированию и написанию пользовательских историй.
Надеюсь, это имеет смысл. Я бы посоветовал прочитать Agile Estimating and Planning Майка Кона для тех, кто даже отдаленно думает взять на себя роль ПО. Удачи!