В рамках данной статьи хотелось бы поделиться личным опытом применения User Stories и рассказать об обогащении формата User Story — техникой 5 Whys, нацеленной на более глубокую проработку “цепочки создания ценности”.
UserStory — что это и как она выглядит…
Это легковесный формат требований, применяемый при итеративной разработке программных продуктов (гибкие методологии разработки программного обеспечения Scrum, XP), отражающий только требуемую бизнес-ценность, без намека на реализацию.
Как <Actor>, я хочу иметь возможность <Action>, чтобы <Reason>.
Примеры:
- Как медсестра, я хочу иметь возможность задокументировать результаты осмотра пациента, чтобы в результате был создан юридически-сильный документ, а результаты осмотра были доступны врачу для изучения.
- Как менеджер, я хочу найти карточку клиента, чтобы задокументировать результаты последней состоявшейся встречи.
Чем хороша User Story…
- легка для восприятия как программистом так и пользователем;
- может формулироваться непосредственно пользователем или заинтересованной стороной на их привычном языке;
- не учитывает реализацию, а отражает только требуемую бизнес-ценность;
- формат, отвечает разработчику сразу на три вопроса:
- для кого он делает инструмент — Actor?
- что ожидают от этого инструмента — Action?
- зачем будет использоваться этот инструмент — Reason?
Что необходимо для создания хорошейUserStory
Опыт использования показал, что для создания точных и содержательных User Stories необходимо проделать весь “стек” аналитической работы, т.е. применение легковесного формата не отменяет усилий аналитика по глубокому выяснению, описанию и анализу — пользователей, процессов, цепочек создания ценностей…
Следовательно, после того как выяснены Actors, написаны Scenarios, разработаны Use Cases, нарисованы диаграммы процессов, выяснены цепочки создания ценностей, можно взяться за создание содержательных, лаконичных и легковесных требований в формате User Stories, которыми вы будете оперировать при разработке решений.
Как можно расширить UserStory чтобы сделать ее более содержательной…
Хорошим заделом для разработки оптимального решения, по моему мнению, является — знание наиболее полной “цепочки создания ценности”.
Для того чтобы не вдаваться в подробности в данной статье об использовании техники 5 Whys, хотел бы дать ссылку на мой недавний труд — “5 Whys — как лекарство от Muda”, в котором эта техника рассмотрена на примерах.
В связи с выше изложенным, совмещение формата User Story и техники 5 Whys, для детализации “цепочки создания ценности” — позволяет наполнить разрабатываемые User Stories еще большим смыслом и дать возможность для разработки более продуманных и оптимальных решений.
Как использовать формат UserStory& 5 Whys…
Как <Actor>, я хочу иметь возможность <Action>,
- чтобы <Reason>
- чтобы <Reason>
- чтобы <Reason>
- чтобы <Reason>
- чтобы <Reason>
Примеры:
Как менеджер, я хочу найти карточку клиента,
- чтобы задокументировать результаты последней состоявшейся встречи
- чтобы результаты встречи были доступны и другим менеджерам работающим с этим клиентом в рамках нашей компании
- чтобы эти менеджеры могли изучить прогресс по работе с клиентом
- чтобы подготовиться к беседе с этим клиентом
- чтобы провести следующую встречу эффективно
Заключение
В заключении хотелось бы расставить акценты на ключевых мыслях, выраженных в данной статье.
Во-первых: не стоит воспринимать User Stories как замену всем остальным инструментам бизнес-анализа, а наоборот — считать его завершающей стадией по подготовке требований, т.к. этот формат позволит лаконично и содержательно отразить именно бизнес-требование и этим требованием можно будет пользоваться при разработке решений.
Во-вторых: применение техники 5 Whys в рамках User Story, позволит более четко проработать и отразить “цепочку создания ценности”, что в свою очередь обезопасит вас от выполнения задач “цели которых вам не известны”, а более полное представление о “цепочке создания ценности” — может натолкнуть на разработку оптимальных решений для пользователей.
Информация об авторе:
(Аналитик, Командный Менеджер)
- WaveAccess (г. Санкт-Петербург)
- Choice Hospital-Systems (Las Vegas)
Метод 5 Whys придуман выявления глубинных причин возникновения проблемы, а не для того, чтобы описывать «цепочки создания ценности».
То, что причины проблемы и «цепочка ценности» похожи, потому что их описание строится на основе причинно-следственных отношений, еще не повод применять 5 Whys для описания «цепочки ценности». Автор ошибается: «цепочки ценности» могут быть гораздо длиннее, чем пять. Кроме того, ценность может формироваться и куда более сложными структурами, чем цепочка, т.е., последовательность.
Уважаемый AndrewK, если вы прочитали статью на которую ведет ссылка — «5 Whys как лекарство от Muda», то вы должны были заметить, что автор не претендует на ввод своего личного «определения для техники 5Whys», а всего лишь — предлагает, применение этого инструмента для Бизнес Анализа (нестандартное применение). Так же никто не ограничивает применение этой техники цифрой «5″, но в большинстве случаев этого достаточно (так же как и для выявления ключевой проблемы, не всегда нужно «5 почему», все зависит от «качества» ответов получаемых при каждом вопросе «почему»).
Не очень понятно про «…ценность может формироваться и куда более сложными структурами, чем цепочка…» — хорошо бы увидеть пример?
Применение техники 5Whys, не ограничивает вас в «ветвлении — цепочек создания ценности/цепочек выявления ключевой проблемы», следовательно вы можете применять эту технику даже если на вопрос «почему/зачем» — вы имеете более одного ответа, просто для каждого ответа будет строиться отдельная «ветвь» (эти рассуждения, так же приведены в статье «5 Whys как лекарство от Muda»).
Благодарю за ваши комментарии и буду рад, если мои пояснения удовлетворят вас и других читателей!
Для моделирования причинно-следственных отношений существует достаточно много различных методов. Вот несколько:
- диаграммы Ишикавы, известные также как fish-back diagrams
- деревья текущей реальности в Теории Ограничений
- Root-Conflict Analysis Plus
Обращаю особое внимание на то, что все эти методы предназначены для выявления причин проблем. Метод 5Why — это наиболее простой в этом ряду. Посмотрите, хотя бы, правила проверки правильности модели, которые есть в других методах и нет в методе 5Why.
Иногда следует пользоваться простыми методами, если этих методов достаточно для достижения поставленных целей (решения задач).
Но не в этом случае, когда вы предлагаете использовать метод 5Why для описания модели формирования ценности.
Во-первых, помимо «цепочек создания ценности» или Value Chain к типовым моделям, точнее, конфигурациям создания ценности, относятся также Value Shop и Value Network. Посмотреть можно хотя бы здесь: http://www.ctoupdate.com/ctoupdate-65-20070626ValueChainsNetworksandShops.html
Во-вторых, линейная структура метода 5Why (а ветвление не предусмотрено самим методом), никак не позволяет отразить более сложные конфигурации создания ценности. Более того, даже древовидная структура fish-back diagram не всегда позволяет отражать некоторые структуры формирования ценности.
Ну, и в-третьих, ваши замечания по-поводу того, что можно не только 5, или можно не только последовательность, означают, что вы предлагаете изменить метод. Но ваши идеи изменить метод приводят к его усложнению, следовательно, вы ухудшаете главное преимущество метода 5Why — его простоту (я бы даже сказал, святую простоту). А что при этом улучшается? Ничего. Тогда в чем смысл вашей идеи?
Добрый вечер, AndrewK.
Во-первых, я хотел бы поблагодарить вас за конструктивную беседу и предложить вам начать делиться «своими знаниями» в более развернутом виде — например написать пару статей.
Во-вторых, хотел бы проявить немного «педантичности» и внести правки и уточнения в написанные вами строки, для тех читателей, которые захотят найти описание этих методик:
- Диаграмма Исикавы, а сам метод называется fishbone diagrams;
- Теория ограничений (Элия М. Голдратт);
Теперь попробую пояснить свою точку зрения и ответить на ваш вопрос.
Не могу согласиться с вашими строками «… Обращаю особое внимание на то, что все эти методы предназначены для выявления причин проблем. Метод 5Why — это наиболее простой в этом ряду…», так как метод «5 Whys» — предназначен для выявления корневой проблемы, а не на «выявление причин проблем». Хотя в свою очередь — метод fishbone diagrams — направлен именно на выявление причин возникновения уже сформулированной проблемы.
Но если честно, я не хотел бы глубоко вдаваться в это, так как цели статьи были немножко иными (как мне кажется, мы ушли в сторону «зациклившись» на одной фразе — «цепочка создания ценности» и на прямых назначениях методов). Теорию ограничений — даже не хочется затрагивать, так как перед ней стоят совершенно иные задачи — чем те «которым посвящена статья» =)
Первичная цель статьи — поделиться опытом «успешного» совмещения User Stories (как формата для формулировки требований) и техники «5 Whys» (в данном контексте — техника для выявления «цепочки создания ценности»). Слово «успешного», я применил не на пустом месте. Данный подход — прекрасно работает в проекте в котором я участвую. На мой взгляд, эти две «вещи» прекрасно совмещаются и позволяют создавать «легковесные требования с упором на цепочку создания ценности, без намека на реализацию» — только бизнес ценность. Легковесность требований — позволяет разработчику (к которому приходит требование), не тратить много усилий на то чтобы удержать в своей голове «функциональную спецификацию», позволяет всегда концентрироваться на ключевых вещах: для кого — что необходимо — зачем.
P.S. Более глубоко — его помещает в контекст аналитик — разъясняя предметную область (например на этапе планирования итерации).
Вы бы могли попробовать в следующей статье предложить использование метода fishbone diagrams или деревьев текущей реальности или еще каких либо методов для достижения похожих целей (вместо техники «5 Whys»), я с удовольствием почитаю ее!!!
Вторичная цель статьи — это получить несколько конструктивных комментариев к статье, чтобы получить информацию о других взглядах и подходах. В достижении этой цели, вы прекрасно мне помогли, за что я вам и благодарен. Собираюсь изучить данные вами ссылки: Root-Conflict Analysis Plus, Value Chain, Value Shop и Value Network.
Что же касается, рассуждений на тему «…Но ваши идеи изменить метод приводят к его усложнению, следовательно, вы ухудшаете главное преимущество метода 5Why — его простоту (я бы даже сказал, святую простоту)…«.
У меня нет никаких оснований полагать что я хоть сколько усложняю технику, так как она все так же легка в восприятии (но хочу заметить, сложна в применении — так как поиск качественного ответа это достаточно сложная задача — те кто на практике применял этот метод, поймут о чем я говорю). Хоть я и ответил на эти строки, считаю — что рассуждения о «простоте», достаточно неблагодарное занятие — простота для разных людей — разная!
Резюме: … в чем смысл моей идеи? …
Смысл моей идеи — совместить формат легковесного требования User Story и технику 5 Whys (поданную под другим «углом»), для создания легковесных требований с более детальной проработкой «цепочки создания ценности», которое в свою очередь будет вести разработчика на этапе проектирования и реализации, и позволит принять более оптимальное решения опираясь на «требуемую» ценность для пользователя.
Мне кажется что мои комментарии — уже в два раза больше (по объему) — чем сама статья =)
Привет, Михаил,
я представляю старую школу (old school), и в наше время диаграммы Исикавы назывались диаграммы Ишикавы, а fishbone была известна как fish-back («рыбий хвост»).
Теорию ограничений лучше изучать по книге Уильяма Детмера «Теория ограничений Голдратта», в которой расписаны различные аналитические техники. В статье в Wiki эти техники даже не упоминаются.
С моим подходом вы можете ознакомиться здесь: http://analyst.by/tag/triz
Чуть позже я подробнее отвечу вам по-поводу моего видения содержания User Story.
Как раз из комментариев (не из статьи) мы узнали, что подход опробован и действительно работает. Это уже говорит о том, что обсуждение не зря велось. В целом было интересно узнать о таком варианте совмещения техник. Да и Вы, как оказалось, нашли для себя новые области для изучения благодаря Андрею.
Михаил, спасибо за статью. Будем ждать следующую.
Применял пользовательские истории на 7 проектах: на 5 в качестве скрам-мастера, обучая менеджеров обязанностям PO, и на 2, являясь непосредственно владельцем продукта.
Прикинул, как может мне помочь метод 5 почему при работе с ними, и понял, что никак.
Во-первых, если Вы читали «User Stories Applied» Майка Кона (или Рона Джефриса, на которого тот ссылается), то, наверняка, помните, что сама концепция историй строится на 3 принципах: Card, Conversation, Confirmation. Занести историю на карточку (Card) можно и на первой встрече с заказчиком, если он действительно знает, чего хочет. Я остался очень доволен предметностью бесед, после того, как стал с самого начала встречи писать эпики (epics), доводя их в итоге до историй, на обратной стороне которых делал важные пометки.
Во-вторых, обсуждения с командой разработки (Conversation) могут проходить дальше как с участием самого заказчика, так и лично со мной. Во втором случае у меня на руках уже есть бизнес-модель (business model) и карта эффектов (impact map). Их вполне достаточно для объяснения всех действительно важных причинно-следственных связей.
В-третьих, на основании всех бесед я пишу главу Руководства пользователя и согласовываю её с заказчиком. Это лучший тестовый сценарий, какой можно только себе представить для приёмочного тестирования (Confirmation).
Ни на одном из перечисленных этапов метод 5 почему не может играть ключевой роли, а может быть использован лишь в качестве вспомогательного инструмента.
Не могли бы Вы привести конкретные примеры использования описанной Вами техники? Возможно, тогда мне станет понятнее, где и как именно её можно применить.
Добрый день, Вадим!
Извиняюсь за «перекидывание стрелок», могу ли я попросить написать парочку User Stories из вашего последнего проекта, мне просто хочется посмотреть хоть раз на «профессионально написанные истории»? (Параллельно — обещаю ответить на ваши вопросы)
Здравствуйте, Михаил
Да, конечно. Более того, я готов показать даже карту эффекта :-) Вот она, собственно: https://dl.dropbox.com/u/3442793/Google%20Drive/Proj/IM/121010-IM-Effectmap-1.1.png
Соответственно, истории (формируются в effectcup.сom автоматически):
3.1 Как Начальник Инспекции труда РМ, я хочу просмотреть экранные отчёты, чтобы ознакомиться со статистическими данными Инспекции.
3.2 Как Начальник Инспекции труда РМ, я хочу вывести печатные отчёты, чтобы ознакомиться со статистическими данными Инспекции.
3.3 Как Начальник Инспекции труда РМ, я хочу задать основные направления деятельности, чтобы составить Программу деятельности Инспекции на год.
3.4 Как Начальник Инспекции труда РМ, я хочу выдать территориальному инспектору Распоряжение о расследовании, чтобы инициировать расследование несчастного случая.
3.5 Как Глава территориальной инспекции, я хочу просмотреть экранные отчёты, чтобы ознакомиться со статистическими данными своего отделения.
3.6 Как Глава территориальной инспекции, я хочу вывести печатные отчёты, чтобы ознакомиться со статистическими данными своего отделения.
3.7 Как Глава территориальной инспекции, я хочу составить список предприятий для контроля, чтобы составить Квартальный план отделения.
3.8 Как Глава территориальной инспекции, я хочу выбрать предприятия для контроля из Квартального плана, чтобы составить Месячный план отделения.
3.9 Как Глава территориальной инспекции, я хочу выдать территориальному инспектору Распоряжение на проверку, чтобы инициировать проверку предприятия.
3.10 Как Территориальный инспектор, я хочу сформировать Акт проверки, чтобы провести проверку предприятия.
3.11 Как Территориальный инспектор, я хочу сформировать Акт(ы) о правонарушении в случае обнаружения нарушений, чтобы провести проверку предприятия.
3.12 Как Территориальный инспектор, я хочу сформировать Предписание о приостановке деятельности в случае нарушений, представляющих угрозу для жизни и здоровья сотрудников, чтобы провести проверку предприятия.
3.13 Как Территориальный инспектор, я хочу сформировать Дело о расследовании, чтобы провести расследование несчастного случая на производстве.
3.14 Как Территориальный инспектор, я хочу сформировать Акт несчастного случая, чтобы провести расследование несчастного случая на производстве.
На карточки для скрам-доски (висит сейчас перед глазами :-) в качестве манифестаций историй нанесены более краткие формулировки: Программа деятельности (со следующими значениями: проект — IM (Inspectia muncii (рум.) — Инспекция труда), важность — 30, сложность — 14, исполнители — K, N, V (первые буквы имени разработчиков); значения разнесены по углам карточки в специальных выемках), Квартальный план (IM, 27, 10, K) и т. д.
Обозначение проекта нужно для того, чтобы различать карточки между собой — сейчас на доске есть истории сразу по 3-м проектам. С недавнего времени для различения стали использовать также цвет карточки (просто я нашёл в биротике на 3-м этаже разноцветные бумажки ))
Важность и сложность, думаю, комментировать не имеет смысла, это классика (у Книберга описано).
Исполнители вписывают себя сами, когда берут задачи, связанные с историей. Бывает полезно в случаях, когда историй много, человека по каким-то причинам нет и он не может сказать, что это его история.
Спринт начали в этот понедельник и три истории уже близки к завершению, чему я донельзя рад )
Единственный существенный недостаток, который я сейчас вижу, это то, что мы ещё не пришли с руководством Инспекции к измеримым метрикам бизнес-цели. Я пока предварительно указал, что совокупное число нарушений и несчастных случаев должно два года подряд снижаться, хотя, конечно, это не очень хорошая метрика, ввиду того, что она зависит от множества факторов вне рамок проекта. Зато это отличная цель для самой Инспекции ))
В общем, буду рад конструктивной критике ;-)
Ой, простите, не ту версию карты дал. Вот последняя: https://dl.dropbox.com/u/3442793/Google%20Drive/Proj/IM/121016-IM-Effectmap-2.0.png :-)
Добрый вечер, Вадим!
Изучил данный вами материал, «честно» постарался осознать предметную область, но для «достаточного» понимания мне не хватило данных. Не смотря на это я взял на себя смелость «поиграться» над одним из ваших требований, результаты ниже:
Попробую поэксперементировать прямо в рамках вашего проекта, буду предполагать т.к. не всю необходиму информацию, для построения User Stories с применением 5Whys, удалось “выудить” из ваших данных.
Предположения:
Если предположить, что в рамках территориального отделения — работает несколько инспекторов под руководством одного главы отделения.
Если предположить, что одному инспектору в рамках месяца может быть поручено проверить несколько предприятий (не одно предприятие в месяц).
Если предположить, что в месячный план — это всего лишь список предприятий для проведения плановой проверки и обращений на проведение проверки предприятия, причем организованный определенным образом (например приоритезован, т.е. задан определенный порядок проведения проверок — не могу знать по каким правилам, работая в вашем проекте я бы постарался выяснить).
То для территориального инспектора, одну из User Story я бы сформулировал следующим образом:
Как Территориальный Инспектор, я хочу иметь возможность просмотреть список предприятий на которых мне поручено провести проверку или список заявок на проведение проверок
чтобы выбрать предприятие/заявку на котором я на данный момент провожу проверку
чтобы для выбранного предприятия/заявки составить “Акт проверки”
чтобы для выбранного предприятия/заявки составить “Акт о правонарушении”, если обнаружено
чтобы на основании этого акта соствить “Предписание о приостановке деятельности”, если правонарушение относится к разряду “злостных”
чтобы на основании предписания, деятельность предприятия было приостановлено до разбирательства и устранения причин правонарушения
чтобы “Акт о правонарушении” был учтен при расчете статистики правонарушений по территории за которое отвечает территориальное отделение
чтобы на основании этой статистики Галва Территориального Отделения мог судить о сокращении числа правонарушений по территории
Допустим так =)
Данных в этой User Story должно быть достаточно чтобы продумать и разработать один из инструментов для территориального инспектора, который будет использоваться инспектором для документирования результатов проверок, и даже чуть больше (затронут и вопрос пострения статистического отчета для Главы Отделения).
Если ход моих мыслей — покажется интересен, я готов потратить еще время и предложить еще несколько вариантов, но для этого потребуется дополнительная информация. Если честно — мне это интересно!
ой, все мое форматирование комментария куда-то пропало… Очень жаль — без форматирования будет трудно читать…
Вот тогда документ с отформатированными результатами: https://docs.google.com/document/d/1fVgjZKcA63XnI6__eER-koCMN75HnOklvO9wQqmTIGs/edit
Если по не получится по той ссылке, то можно попробовать по этой: https://docs.google.com/document/d/1fVgjZKcA63XnI6__eER-koCMN75HnOklvO9wQqmTIGs/view
Михаил, я уверен, что Вы помните 10-ый принцип Манифеста: «Простота — искусство минимизации лишней работы — крайне необходима». Так вот, если честно, мне показалось, что добавление техники 5W в данном конкретном случае нивелировало простоту, которая есть в карте эффекта.
Мы проводили планирование спринта в этот понедельник и я представлял команде поочерёдно органиграмму, схемы процессов, карту эффекта и карту историй. В какой-то момент ребята настолько осознали весь процесс, что мои комментарии оказывались лишними. И это всегда нужно иметь в виду. Команда состоит из мотивированных профессионалов, которые ничуть не уступают ни в воображении, ни в системном мышлении самому аналитику.
Задача PO, на мой взгляд, сводится к выявлению и представлению тех самых «первопричин», которые ищет 5W. Сами причинно-следственные связи, как правило, очевидны и не требуют дополнительного описания и документирования. Таким образом, 5W уместно применять при работе с заказчиком, но завязывать им конечные истории, как мне кажется, не особенно продуктивно. Impact map служит достаточным наглядным пособием, чтобы справляться с этой задачей.
Впрочем, я вполне могу ошибаться, поэтому, если Вы не против, приглашу в нашу беседу Артёма Сердюка, который о картах эффекта знает гораздо больше моего (собственно он их для меня и открыл :-) Возможно, ему удасться расставить точки над i (и написать ещё один интересный блогопост )))
Тем не менее, я готов поэкспериментировать, но, с Вашего позволения, после окончания REQ Labs (через неделю). Надеюсь, мы никуда не торопимся ;-)
В общем, выяснилось, что насчёт Impact map я не прав. Она для этих целей малоприменима. Ваша же техника, как предположил Артрём, основана на пострении фрагмента дерева текущей/будущей реальности, соответствующего истории.
Проблемы техники:
1. Чем длиннее причинно-следственная цепочка, тем выше вероятность наличия в ней ошибок.
2. Потратив много времени на построение деревьев, аналитик становится их слугой, потому что очень сложно признаться себе, что сделал где-то ошибку, которая сводит на нет пользу всего дерева.
Совет от Артёма:
Если Вы хотите построить дерево реальности, лучше это делать по Голдратту, а не «в оправдание» историй.
И вот набор презентаций на тему:
1. TOC Root-Cause anaylsis: http://www.slideshare.net/ek_artem/toc-rootcause-anaylsis
2. Agile и проблемы: http://www.slideshare.net/ek_artem/agile-1156848
P. S. Сам их с большим интересом буду смотреть ))
Добрый день, Вадим.
Свой комментарий я напишу — ниже, так как заметил что «чем больше вложенных комментариев, тем уже столбец в котором этот комментарий отображается», а хочется развернуто ответить!
Оффтоп: Как подписаться на обновления в комментариях? Уведомление о комментарии Михаила почему-то не пришло :-(
И всё-таки было бы крайне неплохо сделать комментарий доступным для редактирования хотя бы в течение минуты-двух. А то, вот, опечатался, ошибся, а никак не поправить ((
Замечания учтем. Спасибо, Вадим
Да, и возможность одобрения комментария была бы весьма кстати ))
Мне кажется, что полезно иметь возможность «пред-просмотра комментария» и возможность «удаления своего комментария»!
Ну и форматирование комментария — полезная штука, но почему-то не работает на этапе отображения комментария (только на этапе создания комментария — работает).
Можем создать отдельную тему на форуме для обсуждения статьи, если хотите.
Думаю, нет нужды!
Хорошо когда можно почитать прямо после статьи все «выкладки», а не перескакивать в отдельную ветку на форме.
Добрый день, Вадим.
Спорить с Вами на тему «простоты», которую уже изрядно «потрепали», я не готов. Считаю это неблагодарным делом. Поэтому давайте простоту оставим на совести наших проектов и фидбэков от пользователей =)
Хотел заметить, что моя «маленькая и лаконичная» статья позволила — самовыразиться и даже дать саморекламу уже четырем бизнес-аналитикам из сообщества. Надеюсь вы чувствуете благодарность к этой статье =)
Теперь отвечу на ваш последний комментарий, постараюсь быть конструктивным…
Планирование спринта, рассказ аналитика и презентация целого ряда информации в виде - органиграмм, схем процессов, карты эффекта и карты историй — это бесспорно хорошо! Риторический вопрос, в чьих головах и когда созревают «решения» которые будут воплощены в архитектуре и интерфейсах?
И теперь спросите их — размазанная по четырем местам информация, влитая в голову за 2-4 часа планирования спринта, позволит сосредоточиться на главном и разработать оптимальную реализацию для поставленной задачи? Или может позволить усвоить все «виртуально обрисованный причинно-следственные связи»?
В общем, к чему это я…
Почти так-же как и вы, я готов «похвастаться» проведениями планирующих спринтов, развернутым рассказам о процессах, пользователях, документах и цепочках создания ценности. Но так-же я готов признать что такие планирующие сессии достаточно утомительны и генерация идей происходит не во время этих сессий, а до или после. Процесс поиска оптимального решения очень «размазан» и нельзя оставлять разработчиков без «выжимки» ключевой для учета информации на протяжении всего этого времени, чтобы они каждый раз не открывали ваши схемы процессов, карты эффектов и т.д. (какими бы профессионалами они небыли), а имея в голове тот «сухой остаток» после аналитической сессии и имели перед глазами самодостаточную «шпаргалку».
В моей практике, User Story с применением 5Whys — позволяет создавать именно ту шпаргалку, которая самодостаточна, структурирована и позволяет всегда вернуться к ключевой информации, которая используется при разработке оптимального решения.
(и никаких деревьев Голдратта тут нет, а просто связанная с задачей (действием) цепочка создания ценности)
Честно скажу, у меня нет нужды навязывать эту статью, я поделился одним из своих инструментов. Все кому он покажется полезен, так же как и мне — смогут им воспользоваться.
Ну а все кому нужно рассказать о себе — могут писать комментарии об их благополучных командах! Все кому хочется самовыразиться — могут писать о «несогласии» с автором! А я буду с удовольствием на них отвечать!!!
Все равно, главным показателем Вашей успешности и успешности Ваших подходов — будет успешность ваших проектов: довольные пользователи, довольные инвесторы, слаженная команда и т.д. Поэтому если вы всего этого можете достичь без User Stories & 5Whys (в чем я нисколько не сомневаюсь) — то и прекрасно.
Кстати, интересно, а кто как описывает Acceptance Ciriteria в User Story? Чего я только не встречал, некоторые вставляли ссылку на спеку, кто-то писал тест кейсы.