Закоулки мозга

Шаблоны разбиения историй (user stories) на более мелкие

Patterns for Splitting User Stories

Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

via Pocket http://ift.tt/IO5FVq

December 26, 2014 at 10:01AM

Общая проблема многих скрам-команд - слишком большие истории. Большие истории сложно понять, оценить и реализовать в срок. Маленькие истории чаще релизятся, дают быструю обратную связь по срокам релиза, по продукту в целом, по различным техническим и архитектурным вопросам.

Каков оптимальный размер истории?

Истории должны быть такого размера, чтобы в спринт входило от 4 до 10 историй. Нужно понимать, какая оценка (в стори-пойнтах) сигнализирует о необходимости разбиения историй, обычно это 8 или 13, но может быть и 5.

Шаблоны разбиения историй на более мелкие

Шаблон нужно выбрать такой, чтобы отсеять некритичную функциональность и разбить крупную историю на несколько примерно одинаковых по размеру мелких.

Шаблоны:

  1. Шаги процесса. Для каждой истории стоит определить рабочий процесс, возможно, каждый его шаг станет самостоятельной историей. Для идентификации процесса можно задать вопрос: “Если представить, что функциональность уже реализована, как именно ее используют?”. Наиболее важными шагами процесса обычно являются первые и последние. Иногда бывает, что все или большинство шагов в процессе важны, тогда можно рассмотреть вариант реализации очень тонкого среза всех шагов (см. следующий раздел), реализующего минимально полезный набор функций.
  2. Варианты бизнес-правил. Например, параметр “гибкие даты” можно разделить на “между x и y”, “выходные в декабре”, “за +/- x дней до y”. В “системе рекомендаций” можно выделить отдельные метрики. Общая идея этого подхода - дать пользователю добиться своей цели несмотря на минимальную юзабилити.
  3. Основное усилие. Иногда история содержит в себе несколько вариантов, реализация первого из которых займет много времени, а всех последующих - окажется тривиальной. Тогда нужно выделить историю “используя какой-либо один вариант” и историю “используя все остальные варианты”.
  4. Просто/сложно. Иногда история обрастает различными условиями. В этом случае нужно зафиксировать исходную историю, а все доп.условия оформить в виде отдельных историй.
  5. Вариации данных. Любые варианты (например, поддержка разных языков) должны оформляться в виде отдельных историй. Сюда же относятся разные фильтры - в этом случае стоит обращать внимание на разные типы фильтров, например “точное соответствие” или “попадание в диапазон”. Обращать внимание на общие слова, которые можно заменить несколькими конкретными примерами. Каждый из таких примеров может стать новой историей.
  6. Методы ввода данных. Иногда сложность возникает на уровне пользовательского интерфейса, поэтому реализация каждого его варианта должна оформляться в виде отдельных историй.
  7. Отложенная оптимизация. Варианты “заставить работать” и “заставить работать быстро” заслуживают двух разных историй.
  8. CRUD. Обычно пользовательские истории оперируют общими глаголами, вроде “управлять”. Реально это может быть разбито на: “создавать”, “получать”, “изменять”, “удалять”.
  9. Роли. В некоторых историях замаскированы несколько ролей / участников, например, пользователь и программист в истории “Логирование ошибок”. Следует обращать внимание на маркеры “и”, “а также” и т.п.
  10. Критерии приемки. Это такие проверяемые условия, позволяющие понять, действительно ли история реализована так, как предполагалось. Иногда история может подразумевать несколько независимых критериев приемки, тогда каждый из них можно выделить в историю поменьше.
  11. Неопределенность. Иногда никакие разговоры не помогут понять, как же нужно реализовать историю. Тогда необходимо выделить время на исследование БП и возможностей технологий. Оформить это в виде отдельной истории.

Техника разбиения задач

Можно воспользоваться простой техникой для определения минимально полезного сценария:

  1. Описать в виде последовательности шагов любой сценарий использования в рамках пользовательской истории с максимально подробными и конкретными деталями (номера счетов, суммы денег, даты и т.п.)
  2. Пройтись по каждому шагу сценария и определить, какие можно сделать предположения, чтобы устранить этот шаг. Если будут найдены такие варианты, которые делают сценарий проще в разработке, но сложнее в использовании, такие варианты необходимо использовать. Удобства для пользователя будут добавлены в последующих историях.
  3. Оформить все идеи по улучшению, возникшие в ходе работы, в виде новых пользовательских историй.

Источники и связи