Лекция «User Story и Use Case: требования для команды»

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

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 40 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Четырнадцать тем о ремесле записи требований — о трёх формах, в которые его укладывают, и о границах каждой. Начало — цена вопроса по данным PMI 2014 с честным разбором того, что там измерено: 47% это доля уже провалившихся проектов, где причиной названы требования, 37% — доля организаций, назвавших это главной причиной, 5,1% бюджета — 51 млн долларов на каждый потраченный миллиард, и всё это опрос самоотчётов, а не аудит. Дальше хронология от проекта C3 Кента Бека до исследования 2016 года с тремя ошибками авторства, которые ходят по интернету, и с единственным выводом, ради которого она нужна: шаблон придумали, чтобы люди задавали вопросы. Формула трёх C Джеффриса, шаблон Connextra с разбором спора о части «чтобы» и вариантом Криса Мэттса, где ценность идёт первой, и три способа сломать шаблон по Рэйчел Дэйвис. Критерии приёмки: канва Дано — Когда — Тогда Норта и Мэттса, вопрос «а это не анализ ли?» 2004 года, и отдельная тема о том, когда чек-лист уместнее сценария — обе формы легитимны. Качество написанного: INVEST Билла Уэйка с конфликтом критериев между собой и его же пересмотром small в пользу сквозной истории, и измерение Лукассена и коллег — 1023 истории из 18 компаний, 13 критериев рамки QUS, из которых машина проверяет три: наличие роли и действия, атомарность, отсутствие лишнего. Декомпозиция: уровни Кокбёрна с тестом «может ли актор уйти довольным», расширения сценария, срезы Use-Case 2.0, пять разрезов SPIDR с правилом выбора и карта историй Паттона с хребтом, рёбрами и ходячим скелетом. Финал — границы: в Scrum Guide термина user story нет вовсе, определение готовности легко превращается в фазовые ворота, нефункциональные требования в форму истории не лезут, ГОСТ 34.602-2020 применяется добровольно по 162-ФЗ, а ISO/IEC/IEEE 29148:2018 отделяет качество набора требований от качества отдельного требования.

Границей ответственности. Там разбирают выбор подхода: манифест, обязанности, события, артефакты, поток, критерии выбора между гибким подходом и каскадом; история пользователя упоминается как артефакт бэклога. Здесь методология уже выбрана, и разбирается ремесло записи: как устроен шаблон Connextra и почему спорят о его третьей части, чем сценарий Дано — Когда — Тогда отличается от чек-листа критериев, что именно ломается в историях по измерениям на выборке из 1023 штук, какими пятью разрезами режут крупное и что делать с требованиями, которые в форму истории не укладываются. Пересечение ровно одно — акроним INVEST, и здесь он дан с тем, чего в обзорной теме нет: с конфликтом критериев между собой, с разницей между «маленькой» и «сквозной» историей и с пересмотром терминологии самим Биллом Уэйком.

Нет, и лекция специально защищает вас от этого обвинения. В Scrum Guide словосочетания user story нет ни разу: гайд говорит про элемент бэклога продукта и перечисляет его атрибуты — описание, порядок, оценка и ценность, — а форму записи намеренно не определяет. Элементы могут быть выражены историями, сценариями использования или любым другим подходом, который полезен команде. Симметричное утверждение тоже неверно: «команда пишет технически, значит делает Agile неправильно» — такое же передёргивание. Практический критерий один и он не про формат: понятно ли из записи, кто заинтересован, что должно получиться и как проверить, что готово. Если технические формулировки на это отвечают — они работают. Если нет, три формы из лекции дают готовые способы починить каждую из трёх дыр.