Пользовательские истории всегда можно разбить на более мелкие, более полезные части. Позвольте мне рассказать вам, как.
Зачем разделять?
Обязательно сначала прочтите Часть I:
Когда разделяться?
Должна ли пользовательская история всегда быть разделена? Мое эмпирическое правило — всегда разделять; не потому, что он большой, а из-за всех выгод от расщепления, которые сильно превышают их накладные расходы. Например, небольшие истории могут быть доставлены независимо друг от друга, но при этом приносить пользу пользователям и обучать команду.
Когда вы разделитесь? Слишком раннее разделение расточительно. Вы не хотите тратить много времени на подготовку историй, которые тем временем могут измениться или быть отброшены. Лучше разойтись в последний ответственный момент — когда вы только собираетесь приступить к делу. Кроме того, убедитесь, что создание пользовательских историй дешево; воздержитесь от добавления подробностей, так как история пользователя — это исключительно напоминание о проблеме пользователя (подробные описания — это антипаттерн).
📝 Продукт — это постоянное открытие. Чем дальше в бэклоге, тем менее определенной должна быть история. Разделение и детализации следует отложить до последнего ответственного момента, иначе вы создаете лишнее.
В двух словах, разделяйте столько, сколько сможете (пока есть потенциальная доставляемая ценность), как можно позже.
Думайте вертикально
Почему организация вещей вокруг задач плоха? Техническое/горизонтальное задание:
- поощряет универсальные перепроектированные решения;
- требует координации между командами, что включает в себя ожидание и передачу (разновидность отходов);
- требует пометки функций;
- не представляет ценности для пользователя, пока все части не будут готовы и интегрированы;
- продвигает незавершенные вещи в кодовой базе, базе данных, инфраструктуре, …;
- составляет балог, полный технических историй (то есть задач), понятных только разработчикам (что затрудняет отслеживание ценности, стоящей за ними).
Задачи даже нельзя называть историями. Реальные пользовательские истории (вертикальные) помогают нам быть ориентированными на пользователя, поскольку они о целях пользователя, а не о технических задачах. Таким образом, задача состоит в том, как разделить работу по вертикали, сохраняя при этом ценность для пользователя, пусть даже крошечную. Кроме того, вы хотите стремиться к историям, которые не зависят друг от друга.
Точно так же, как гамбургер представляет собой комбинацию различных ингредиентов, влияющих на общий вкус и впечатления от блюда, функции программного обеспечения состоят из различных технических компонентов, влияющих на общее впечатление пользователя. Вы бы не стали есть гамбургер по ингредиентам; Точно так же вы хотите разделить работу по вертикали таким образом, чтобы приносить пользу пользователю с каждой итерацией.
Любой полезный способ разделения историй должен каким-то образом разбивать техническую сложность, чтобы ее можно было доставлять итеративно. Но прямое нападение на эту сложность часто оказывается не самым эффективным способом разделения истории. Вместо того, чтобы нарезать технические результаты и затем искать полезные фрагменты ценности, попробуйте начать с противоположного направления: нарежьте ценность и ищите полезные технические фрагменты. Один из полезных способов сделать это — запросить несколько примеров того, как предполагаемый результат будет полезен, а затем выбрать те, которые зависят только от небольшой части общего решения. Извлеките каждый из этих примеров в отдельную пользовательскую историю. Пятьдесят быстрых идей по улучшению ваших пользовательских историй
Разделение по вертикали работает лучше, только если у вас есть автономные и междисциплинарные команды, состоящие из людей, которые вместе обладают необходимыми навыками и полномочиями для обеспечения ценности для пользователей.
Начните с выводов
Начинать с конца (цели) — самый полезный способ сосредоточиться на реальной проблеме и избежать слишком раннего решения. В этом контексте конец — это набор выходов. Каждый результат соответствует положительному влиянию на жизнь пользователей. Вклады — это средство для достижения цели. Выходы — это причины, по которым создаются продукты.
👥 ▶ inputs ▶ -system-
◀ outputs ◀
Разделяйте не по входным данным, а по выходным, которые соответствуют целям пользователей. Дать пользователям возможность достичь своих целей — ваша цель. Сосредоточьтесь на том, чего хотят достичь пользователи, и на том, какое поведение вы хотите изменить к лучшему. Позже вы захотите разделить эти выходные данные системы на более мелкие истории; это ваше отставание.
Крис Мэттс популяризировал идею о том, что ценность ИТ-системы в основном заключается в результатах, которые она производит, а входные данные — это просто средства для достижения цели. Вместо того, чтобы думать о рабочих процессах линейно, сначала подумайте о результатах. Вместо того, чтобы думать об экране входа в систему, подумайте об отчетах. Вместо того, чтобы нарезать будущую систему на входы, нарежьте ее на выходы, а затем наращивайте способность постепенно производить эти выходы. […] Результаты гораздо легче нарезать, чем входные данные, потому что они позволяют пользователям достичь чего-то конкретного, и люди могут вести плодотворные обсуждения по ним. Пятьдесят быстрых идей по улучшению ваших пользовательских историй
Отделите обсуждение вопросов что от вопросов как. Не говорите о том, как/решение, прежде чем начать историю. Вместо этого сосредоточьтесь на том, почему/проблеме. Воздержитесь от обсуждения экранов и баз данных слишком рано. Решение должно происходить только тогда, когда команда начинает реальную работу над историями. Это включает в себя дизайн интерфейса, архитектуру, разработку программного обеспечения, реализацию и тестирование…
Личный прием, который я использую при написании пользовательских историй, — это думать о мире без компьютеров и смартфонов. Используя ручку и бумагу, пользователи все равно хотели бы достичь своих целей. Эти цели — то, что должны кодировать пользовательские истории.
Нарезка проблемы (домена)
Я никогда не начинаю с создания лучшей или самой полной реализации истории. Я начинаю с наименьшей возможной вещи, которая выполняет важную работу, а затем получаю обратную связь. Если они говорят это здорово, мне конец. Если они говорят это хорошо, но…, они говорят мне, что строить дальше. Зачем тратить время на добавление наворотов, которые никому не нужны? Работайте понемногу, получайте отзывы, улучшайте только по мере необходимости. (Аллен Холуб)
Небольшие истории представляют мышление MVP, применяемое в более детальном масштабе. Особенности начинаются с их минимальной версии. Например, поля ввода и кнопки отправки может быть достаточно, чтобы сделать кого-то счастливее.
Я приведу несколько примеров вертикального разделения, надеясь, что вы сможете обобщить и адаптировать их к своим потребностям. Естественно, некоторые из этих идей могут потребовать ограниченного доступа пользователей (например, пометка функций, авторизация на основе ролей, сокрытие под URL-адресом), но это проблема, не зависящая от разделения.
- Поддержка только одного типа чего-либо (например, отчета, кредита, поставщика SSO) — в идеале, наиболее ценного или того, который может прояснить предположение или предоставить больше знаний;
- Предоставление разумных значений по умолчанию (например, отсутствие фильтров таблиц, пользователь не может фильтровать по чему-либо или применяется фильтр по умолчанию; то же самое можно сказать и о сортировке);
- Поддержка только счастливого сценария (пограничные случаи могут появиться позже в виде новых пользовательских историй, если предположение будет доказано);
- Реализация только ответвления/вариации рабочего процесса (грубо говоря, каждое if — это история пользователя);
- Сужение клиентского сегмента (например, поддержка только технически подкованных пользователей, поддержка только одного языка);
- Версия функциональности «без препятствий» (например, без входа в систему, без списания денег);
- Сбор минимально возможных данных (например, сбор только имени пользователя в форме).
Давайте посмотрим на несколько примеров такого разделения истории:
⦿ Authors can publish articles in their blogs: ◦ publish plain text articles ◦ publish HTML articles ◦ with a thumbnail ⦿ Buyers can chat with sellers: ◦ send/receive basic text messages ◦ receive messages in real-time ◦ see if messages were read ⦿ Users can browse their movements: ◦ view the latest movements sorted by date desc. ◦ browse through movements (e.g. pagination) ◦ filter movements by type ◦ sort movements by title ◦ search movements
Нарезка раствора (технология)
Что касается технологий/решений, мы должны стремиться быть бережливыми и экономными. Вам не нужен набор микросервисов для начала (возможно, никогда), система мониторинга, ведение журнала, несколько сред развертывания, автоматическое резервное копирование базы данных и многие другие технические артефакты. Таким образом, вы держите чрезмерную инженерию под контролем, особенно если вы находитесь на этапе начальной загрузки. Поскольку никто не угадывает, чего хотят пользователи, не позволяя им попробовать что-то, вероятно, вы будете часто менять направление. Это становится намного проще, если вы держите обязательства на низком уровне.
- Готовые решения, которые вы можете заменить позже (например, войти в систему с помощью Google, использовать стороннего поставщика платежей);
- Примитивная версия архитектуры — достаточно хорошая архитектура (например, упрощенная версия чистой архитектуры);
- Ограниченный графический дизайн (например, небрендированный или примитивный визуальный дизайн);
- Предоставление базовой полезности перед удобством использования (например, без перетаскивания, без автоматических обновлений, примитивные элементы управления пользовательского интерфейса);
- Использование существующей развернутой технологии (например, используйте PostgreSQL, если он уже используется, даже если ElasticSearch имеет больше смысла);
- Минимально жизнеспособная технология (например, использование текстовых файлов или баз данных в оперативной памяти, рендеринг на стороне сервера, а не API+SPA);
- Ограниченная емкость (например, поддержка до 20 одновременных пользователей, позволяющая загружать файлы размером не более 100 КБ);
- Жестко закодированные данные (например, жестко запрограммированные конфигурации, список валют в коде, а не в таблицах базы данных).
В двух словах: статичное вместо динамического, конкретное вместо универсального, полезное вместо красивого, работающее вместо удобного, ограниченное вместо масштабируемого, значения по умолчанию вместо настраиваемого… Вот пример технического варианта, который может помочь в прогрессивной доставке, сохраняя при этом ценность:
⦿ Admins need to schedule content ◦ by manually typing a date and time ◦ by selecting a date from a pop-up calendar
В этом примере мы говорим об элементах управления пользовательского интерфейса, поэтому мы говорим о технических решениях. Тем не менее, мы по-прежнему решаем проблему пользователей, добавляя ценность за счет лучшего UX. Мы могли бы назвать это рефакторингом вертикального среза. Тем не менее, с таким типом нарезки наши истории рискуют оказаться техническими, что противоречит моему совету избегать технических историй. Для этого в ходе рефакторинга вы можете добавить технические детали в описание, оставив названия историй прежними, так как каждая из них будет выполняться в разное время.
