Пользовательские истории в разработку программного обеспечения пришли вместе с практиками экстремального программирования. На формирование подхода влияли две главные потребности.
- Понимать пользователя и бизнес, чтобы брать в работу только то, что принесёт пользу и выгоду.
- Осмысленно управлять потоком задач, идущих в разработку, чтобы производство не простаивало из-за трудностей понимания в первом пункте.
Для разрешения этих потребностей с историями бок о бок шли две практики: Three-C и INVEST.
Предписание Three-C
Практика «Трёх Си» предписывала фиксировать быстрое описание функциональности на небольшой карточке (Card), обсуждая её (Conversation) с заинтересованными лицами. По результату этого обсуждения записывались конкретные примеры-тесты или критерии приёмки, проверяя которые, можно было заключить, что функциональность соответствует ожиданиям всех заинтересованных лиц (Confirmation). Через беседу происходило движение от многозначного и по началу абстрактного описания функциональности к более конкретному, зафиксированного в примерах-тестах.
Спустя 18 лет, автор практики «Трёх Си» признался, что с ростом сложности задач и размера организаций, карточки в начале подолгу нет. В начале идёт множество долгих бесед. В результате бесед возникает набор подтверждающих и схватывающих историю тестов. Но мы уже не стартуем с записи истории сразу. Трудно. Хотя, на мой взгляд, эта трудность может быть преодолена с постепенным заполнением расширенных шаблонов, таких, например, каким является шаблон рабочей истории.
Набор критериев INVEST
Развитием первой стала практика с акронимом INVEST в названии. Она предписывает проверять и «гнуть» истории так, чтобы они соответствовали шести критериям.
- Независимость, Independent. История к моменту отправки её на реализацию должна быть самодостаточна, а не требовать для своего воплощения ещё несколько. Критерий следует из намерения добавлять в программный продукт только ценное, запрещая итерации с разработкой балласта, который ждёт окончания разработки другой части.
- Обсуждаемая, Negotiable + Negotiated.Важно, чтобы история была обсуждена, а кроме того, чтобы к её содержанию можно было в любой момент вернуться и обсудить его вновь, если позднее будет обнаружено, что прежние договорённости перестали удовлетворять ситуации. Таким образом, история рассматривается как возможность для коммуникации, а не готовый контракт на разработку конкретной функциональности. Так сохраняется гибкость в выборе решений.
- Ценная, Valuable or Vertical. Важно, чтобы история была ценна именно для пользователя. Информационные системы многоуровневы, и, как в многослойном торте, в них можно выделять различные архитектурные слои: физический с реальными железками, логический с назначением функций железкам, функциональный с выделением важных операций, визуальный соприкасающийся с пользователем. Принцип заставляет выделять истории «вертикально», затрагивая все необходимые архитектурные слои, а не резать согласно архитектурным и иным техническим соображениям.
- Оцениваемая, Estimable. Это один из критерием масштаба, он требует от истории обозримости и укладываемости в голову. История должна быть настолько прозрачной и просматриваемой, что её возможно оценить.
- Вместима в итерацию, Small. История должна вмещаться в минимальный цикл разработки: итерацию. Критерий необходимый для приоритезации историй как задач на разработку.
- Тестируема, Testable. Команда понимает историю настолько прозрачно, что может написать набор тестов на неё ещё до её реализации. Такими тестами решаются сразу две задачи: подтверждение понимания истории и дальнейшая приёмка готовой функциональности.
Паттерны декомпозиции Лоуренса
Ричард Лоуренс сформулировал в 2009 году шаблоны разделения пользовательских историй. На мой взгляд это не только и не столько паттерны разделения, сколько мыслительные операторы для пересмотра требований в формате историй на этапе их приёмки в работу. Это важно, потому что изначально истории могли фиксироваться с участием заинтересованных лиц, но без гнёта и требований потока разработки.
Истории декомпозируются и реструктуризируются командой в одной из плоскостей согласно предложенным шаблонам. В процессе этой реструктуризации принимаются решение о вариантах её реализации в ближайших циклах разработки. Это крайне полезные техники вариации решений историй для разработчиков и продуктовых управленцев. Незаменимы в работе по принципу ФФФ.
Перечислю шаблоны Лоуренса и опишу их своими словами.
- Шаги рабочего процесса. Часто критическими для выполнения задачи являются первые и последние шаги в цепочке. Дополнительные шаги внутри последовательности часто являются вспомогательными, например, обогощающими данными необходимый минимум, и их можно на время отложить.
- Вариации бизнес-правила или способа действия. Погружение в подробности часто выявляет несколько способов выполнить одно и то же действия. Например, в истории «гибкого выбора» дат для перелёта могут быть варианты: n дней между двумя датами, уикенд в декабре, ±n дней от двух дат.
- Место наибольшего усилия. Иногда связанные истории требуют общей инфраструктуры, без которой их не реализовать. Например, для обработки платежей по банковским картами разных платёжных систем, нужно будет сначала реализовать обвязку для процессинга карт.
- Простое/сложное. Классический вариант движения по линии грациозной деградации от сложного к простому. Задаём вопрос «Какой наиболее простой вариант реализации этой истории?»
- Вариации в структурах данных. Некоторые истории можно выделить и сделать вперёд на основе одной структуры данных, в то время как истории с другой структурой отложить.
- Подходы к вводу данных. Ещё один вариант простого/сложного, но применительно к интерфейсу ввода — неважно пользовательский он или машинный. Сначала можно взять упрощённый вариант, обеспечивающий базовую работоспособность, а после продвинутый и смузихлёбный.
- Временный отказ от производительности. Разбиение в линии «сделать это рабочим», «сделать это работающим быстро». Если можно отложить вопросы производительности, то возможно стоит это сделать.
- Операционный состав процедур. Часто за словами «организовать» или «управлять» скрывается целый набор операций. Например, к большинству цифровых сущностей применим паттерн CRUD: создание, чтение, обновление, удаление, но некоторое время можно пожить и без части операций.
- Слом неопределённости через исследование. Иногда разговоры о смысле истории блокируются высокой степенью неопределённости в затрагиваемом ею вопросе. В этих случаях выделяют жестко ограниченную во времени задачу на исследование вопроса. История разбивается на исследовательскую и реализационную части.
Общая рекомендация Лоуренса — не стараться разделять истории на архитектурные слои, а делать это, придерживаясь модели INVEST. Таковыми и являются паттерны автора.
Литература
- Bill Wake, INVEST in Good Stories, and SMART Tasks, Apr-Aug 2003
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, Aug 30, 2001
- Ron Jeffries, Three-C's Revisited, Mar 26, 2019
- Richard Lawrence, Patterns for Splitting User Stories, 28 Oct 2009