Некоторое время назад я обнаружила интересный и полезный метод для простого и эффективного разделения пользовательских историй на более легковесные. Agile-тренер и соучредитель Scrum Alliance Mike Cohn отметил, что "почти каждая история может быть разделена с помощью одной из пяти техник". Он обобщает эти пять техник под аббревиатурой "SPIDR".
Во-первых, существует два типа пользовательских историй, которые принципиально отличаются друг от друга:
Пользовательские истории, которые чрезвычайно велики изначально и не могут быть разделены, но встречаются крайне редко.
Составные истории пользователя, которые содержат множество более мелких и поэтому могут быть разделены.
Разделение составных пользовательских историй
Согласно принципу INVEST, требованием к пользовательской истории является то, что она должна быть "достаточно мала" или иметь правильный размер. Пользовательская история должна быть настолько небольшой, чтобы 6-10 из них можно было сделать за один спринт. Конечно, это также зависит от скорости работы команды разработчиков. Чтобы практически достичь этой цели, большая история также должна быть разделена соответствующим образом.
В настоящее время существует несколько техник и инструментов, использующихся для разбивки таких пользовательских историй. Например, Richard Lawrence представляет развернутый постер, который проводит зрителя через процесс, помогающий разделить пользовательские истории. Однако далее я хотела бы познакомить вас с простым и быстрым методом SPIDR от Mike Cohn. Он обобщает пять приемов, с помощью которых можно разделить почти каждую большую пользовательскую историю.
Спайки
Спайк — это термин, используемый в agile-разработке программного обеспечения. Спайки — это небольшие, прототипные реализации функциональности, которые обычно используются для оценки и обоснованности новых технологий.
Этот метод предполагает проведение исследований и накопление знаний. Его следует использовать, если другие методы SPIDR не дали положительных результатов. С помощью таких вновь приобретенных знаний некоторые истории можно лучше понять и, возможно, легче разделить. Однако этот метод является относительно абстрактным, и поэтому его труднее применять, чем остальные.
Пути
Если в пользовательской истории есть несколько возможных альтернативных путей, то одним из вариантов является создание отдельных пользовательских историй по некоторым из этих путей. Нет абсолютной необходимости писать историю для каждого отдельного пути, достаточно того, где это имеет смысл. Например, возьмем историю пользователя, в которой он хочет иметь возможность оплачивать покупки в интернет-магазине. Сейчас есть два возможных пути: оплата с помощью кредитной карты или с помощью Paypal. Теоретически оплату кредитной картой можно разделить еще на несколько частей, но нужно взвесить, имеет ли смысл для каждого типа кредитной карты иметь свою собственную историю. Однако главная задача — оплата покупок — хорошо делится на две упомянутые альтернативы. Таким образом, вновь созданные истории меньше и легче поддаются оценке.
Интерфейс
Интерфейсами в данном контексте могут быть, например, различные устройства или типы устройств, такие как смартфоны на базе iOS или Android. Пользовательские истории также могут быть разделены с учетом этого разнообразия. Давайте придерживаться примера с различными операционными системами: в проекте, например, могут быть истории пользователя, которые относятся исключительно к использованию устройств на базе Android, или другие, которые сосредоточены на веб-браузерах. Чтобы не делать их слишком большими и всеобъемлющими, спросите себя, какие устройства или интерфейсы вам хотелось бы разрабатывать. Возможно, первый результат разработки должен относиться только к устройствам iOS, поскольку целевая аудитория здесь, вероятно, больше.
Данные
Другая техника разделения пользовательских историй может быть использована, когда исходные истории относятся только к поддиапазону релевантных данных. Возьмем пример веб-сайта, предназначенного для привлечения туристов в определенный город. Если это город, известный своими музеями, например, то в первую историю можно включить информацию о различных музеях в этом месте. Последующий рассказ может быть посвящен различным туристическим маршрутам по городу, а другой — активному отдыху на природе.
Правила
Правила ведения бизнеса или технологические стандарты могут стать еще одним разделяющим фактором. Возьмем пример с онлайн-покупкой билетов в кино. Часто существуют ограничения, основанные, например, на бизнес-требованиях соответствующего кинотеатра, такие как ограничение на покупку билетов через интернет — не более пяти билетов на один адрес электронной почты.
В этой истории можно было бы представить, что команда разработчиков опустит это ограничение, позволив каждому посетителю купить столько билетов, сколько он пожелает. Затем ограничение может быть добавлено на втором этапе итерации. Инкрементальная реализация, подобная этой, означает, что первоначальные истории не реализуются сразу полностью, а выполняются за несколько небольших шагов. Иногда имеет смысл пренебречь техническими спецификациями или бизнес-правилами, если таким образом можно быстрее достичь презентабельного результата, удовлетворяющего пользователя или клиента. Пропущенные истории могут быть добавлены позже.
Небольшие пользовательские истории — более легкая реализация
Разделение пользовательских историй происходит не всегда легко: многие новички склонны оставлять свои истории слишком полными и большими. Но когда дело доходит до уточнений с командой разработчиков и, в конечном счете, до их реализации, вскоре выясняется, что истории должны быть гораздо меньше. В своей предыдущей статье в блоге о написании (хороших) пользовательских историй я утверждала, что история должна быть "поддающейся оценке" и "небольшой". Это станет наиболее вероятным, если вы знаете, как разделить большую историю на части. И точно так же, как и в случае с написанием пользовательских историй, практика способствует совершенствованию.
Хотите узнать, что еще делает историю пользователя хорошей? Вы можете прочитать об этом в моем блоге: "Что такое (хорошие) пользовательские истории?"
Фредерик Брукс сказал, что самая сложная часть построения систем ПО – решить точно, что же создавать: «Никакая другая часть не даст более трудные для исправления ошибки».
Приглашаем на открытый урок, на котором рассмотрим основные приемы проверки требований, научимся исправлять ошибки анализа и проектирования до реализации. Рассмотрим:
проверку выделения объектов и действий над ними по CRUD и даже по CRUD(LSHAX);
магический кристалл требований и проверки с его помощью;
стандарт разработки требований ISO 29148 и его практическое применение;
и еще несколько полезных проверок.
Регистрация для всех желающих — по ссылке.