Agile Requirements Model

Обсуждаем управление требованиями к программному продукту в соотвествии с философией Agile, фреймфорками SAFE, LESS и их лучшими практиками.

На рисунке представлена обобщённая модель отношений между сущностями. Чёрные стрелочки обозначают именованное отношение, белые стрелочки - отношение "является подвидом" или "уточняет качества". Читать нужно в направлении стрелочки, например: User Story является подвидом Story; или: Feature расщепляется на 1 или более Story.

Epic - описание поведения разрабатываемого продукта, написанное бизнес-пользователями или записанное с их слов (не обязательно формальным языком, и не обязательно отвечающее критериям хороших требований).

Иногда наряду с Epic используется Topic (отсутствует на картинке)- область для группировки Feature или Story со схожим назначением (образующие функциональный кластер).

Backlog Item - элемент бэклога - отвечает на вопрос: что делаем?, асбтрагируясь от вопроса: как делаем?. На картинке - это все жёлтые прямоугольники.

Feature - формально записанное, точное, полное, непротиворечивое, тестируемое требование к поведению программного продукта (но не соответствует принципу INVEST, т.к. не выполняются условия Small, Estimatable, и потому не является Story).

Story должен быть реализован в рамках одной итерации (спринта). Переносить на следующую итерацию не рекомендуется (если Story нельзя реализовать в рамках одной итерации, то следует расщепить/нарезать на несколько мелких story). Все Story должны качественно соответствовать приципу IVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable).

User Story - имеет отношение к пользователю системы (внешнему stakeholder, не входящему в команду разработки и не являющемуся PO). Общепринятой формой записи является: As a <role> I can <activity> so that <business value>.

Technical Story - имеет отношение в первую очередь к внутренней архитектуре, системным требованиям, техническому долгу, и лишь косвенно относится к стейкхолдерам. Может формулировать требования к (микро)сервисам.

Issue Solving Story - баг, инцидент, проблемная ситуация.

Task - набор конкретных действий для достижения требования, описанного в Story, но, в отличие от Story, который отвечает на вопрос "что должно быть в результате?", Task отвечает на вопрос: "как достичь результата?". Story абстрагируется от пути достижения результата, а Task прямо его предписывает. Task не является элементом бэклога! Пример Task'а: "развернуть и настроить Kubernetes", "выучить API к новой библиотеке machine learning на Python".

Non-functional Requirements - существуют в виде явных или неявных ограничений, накладываемых ИТ-инфраструктурой, бизнес-средой и др. Нефункциональные требования накладываются на элементы backlog'а. Пример нефункционального требования: "необходимо обеспечивать отклик до 1 секунды при одновременной работе 1000 пользователей".

Acceptance Criteria (приёмочные критерии) - набор тестов для проверки реализации Feature или Story. Completeness Criteria (критерии завершённости) определяет завершение задачи, например: "программный код написан и отлажен; осуществлено развёртывание в тестовом контейнере".

Расщепление/нарезка (англ.: splitting, partitioning, slicing, dicing) - способ декомпозиции на мелкие Story. Расщепление - горизонтальная декомпозиция по разным шагам бизнес-процесса (на мелкие функции). Нарезка - вертикальная декомпозиция внутри одного шага бизнес-процесса (например, по ответственным модулям системы на front end/back end/database).

Iteration (Sprint) - ограниченная временем деятельность, результатом которой является увеличение полезности разрабатываемого программного продукта (product increment). В Scrum составляет от 1 недели до 1 месяца.

Для приоритезации Story может использоваться одна из многих техник. Применение Story в полной мере проявит себя, если вы используете инструмент автоматизации (Jira или др.) Обратите внимание, что все подтипы Backlog Item, включая Story, должны иметь возможность визуализироваться отдельно от Tasks, т.к. Task не является элементом бэклога. Это позволит проводить разработку, концентрируясь на требованиях стейкхолдеров и на достижении результата (а не на технических задачах и на процессе).

Взято отсюда (картинка не точна, т.к. Epic US на самом деле не соответствует критерию IVEST и не может считаться User Story; вверху - самые детальные и приоритетные Story):

Gherkin Feature - форма записи Feature на доменном языке Gherkin.

Обсудение темы в чате в Телеграм: @softer_ru или на встречах meetup.com/SOFTER