SPIDR - пять простых приемов создания идеально разделенной пользовательской истории
Katharina Lattenkamp - специалист и тренер по Agile Некоторое время назад я обнаружила интересный и полезный метод простого и эффективного разделения пользовательских историй на более мелкие.
Тренер по Agile и соучредитель Scrum Alliance Майк Кон отметил, что «почти каждую историю можно разделить с помощью одной из пяти техник». Он определяет эти пять методов аббревиатурой «SPIDR».
Отметим, что есть два типа пользовательских историй, которые принципиально отличаются друг от друга:
• Пользовательские истории, которые чрезвычайно велики сами по себе и не могут быть разделены. Но встречаются они крайне редко.
• Составные пользовательские истории, которые содержат множество небольших историй и, следовательно, могут быть разделены.
Разделение составных пользовательских историй
Согласно принципу INVEST (Agile), пользовательская история должна быть «достаточно маленькой» или иметь определённый размер. Пользовательская история должна быть достаточно маленькой, чтобы за один спринт можно было выполнить 6–10 таких историй. Конечно, это также зависит от скорости работы команды разработчиков. Чтобы достичь этой цели в принципе, большая история должна быть соответственно разделена на более мелкие.
Я хотела бы познакомить вас с простым и быстрым методом SPIDR от Майка Кона, который привожу ниже. Он отображает пять приемов, с помощью которых можно разделить почти любую большую пользовательскую историю.
Тренер по Agile и соучредитель Scrum Alliance Майк Кон отметил, что «почти каждую историю можно разделить с помощью одной из пяти техник». Он определяет эти пять методов аббревиатурой «SPIDR».
Отметим, что есть два типа пользовательских историй, которые принципиально отличаются друг от друга:
• Пользовательские истории, которые чрезвычайно велики сами по себе и не могут быть разделены. Но встречаются они крайне редко.
• Составные пользовательские истории, которые содержат множество небольших историй и, следовательно, могут быть разделены.
Разделение составных пользовательских историй
Согласно принципу INVEST (Agile), пользовательская история должна быть «достаточно маленькой» или иметь определённый размер. Пользовательская история должна быть достаточно маленькой, чтобы за один спринт можно было выполнить 6–10 таких историй. Конечно, это также зависит от скорости работы команды разработчиков. Чтобы достичь этой цели в принципе, большая история должна быть соответственно разделена на более мелкие.
Я хотела бы познакомить вас с простым и быстрым методом SPIDR от Майка Кона, который привожу ниже. Он отображает пять приемов, с помощью которых можно разделить почти любую большую пользовательскую историю.
SPIDR = Шипы, Пути, Интерфейсы, Данные, Правила.
Шипы
Шипы - это термин, используемый в гибкой разработке программного обеспечения. Шипы - это небольшие прототипы реализации функциональных возможностей, которые обычно используются для оценки и возможности применения новых технологий.
Этот метод включает в себя исследования и накопление знаний. Его следует использовать, если другие методы SPIDR не сработали. С помощью таких новоприобретённых знаний некоторые пользовательские истории можно будет проще понять и, возможно, и легче разделить. Однако этот метод является относительно абстрактным, и поэтому его труднее применять, чем остальные методы.
Пути
Если в пользовательской истории есть несколько возможных альтернативных путей, одним из вариантов является создание отдельных пользовательских историй на основе некоторых из них. Не
обязательно писать историю для каждого отдельного пути, лишь там, где это имеет смысл. Например, возьмем пользовательскую историю, в которой пользователь хочет иметь возможность оплачивать покупки в интернет-магазине. Сегодня есть два возможных пути: оплата кредитной картой или оплата через PayPal. Теоретически оплату кредитной картой можно разделить на дополнительные этапы, но вам необходимо взвесить, имеет ли смысл для каждого типа кредитной карты иметь свою собственную историю. Однако основная задача оплаты покупок делится на два альтернативных подхода. Таким образом, вновь созданные истории меньше и их легче оценивать.
Интерфейс
Интерфейсами в этом контексте могут быть, например, разные устройства или типы устройств, такие как смартфоны на базе iOS или Android. Пользовательские истории можно также разделить по этому признаку. Давайте придерживаться примера различных операционных систем: в проекте, например, могут быть пользовательские истории, которые относятся исключительно к использованию устройств Android, или другие, которые ориентированы на веб-браузеры. Чтобы не делать истории слишком большими и универсальными, вы должны спросить себя, какие устройства или интерфейсы вы хотите разработать. Возможно, первый результат разработки должен относиться только к устройствам iOS из-за, вероятно, большей целевой группы.
Данные
Другой метод разделения пользовательских историй можно использовать, когда исходные истории относятся только к одному разделу общих данных. Возьмем, к примеру, сайт, предназначенный для привлечения туристов в конкретный город. Например, если это город известен своими музеями, первый рассказ может включать информацию о различных музеях в этом районе. Следующий рассказ может включать в себя различные туристические туры по городу, а также еще один рассказ о мероприятиях на свежем воздухе.
Правила
Ещё одним фактором разделения могут быть бизнес-правила или технологические стандарты. Возьмем, к примеру, онлайн покупку билетов в кино. Часто существуют ограничения, основанные, например, на бизнес-требованиях соответствующего кинотеатра, таких как ограничение на покупку в Интернете максимум пяти билетов на один адрес электронной почты.
В этой истории можно было бы предположить, что команда разработчиков опускает такое ограничение, позволяя каждому посетителю покупать столько билетов, сколько они пожелают. Затем ограничение можно было бы добавить на втором этапе итерации. Такая инкрементальная добавка означает, что начальные истории реализуются не сразу полностью, а в несколько более мелких этапов. Иногда имеет смысл пренебречь техническими спецификациями или бизнес-правилами, если так можно быстрее достичь презентабельного результата, удовлетворяющего пользователя или клиента. Пропущенные истории можно будет добавить позже.
Маленькие пользовательские истории – более простая реализация
Разделение пользовательских историй задача не всегда легкая. Многие новички склонны формулировать свои истории так подробно, что они становятся слишком большими. Но когда дело доходит до взаимодействия с командой разработчиков и, в конечном итоге, до реализации историй, становится очевидным, что пользовательские истории должны быть гораздо более мелкими. Достигнуть этого несложно, если вы знаете, как разделить большую историю. И точно так же, как и в написании пользовательских историй, практика помогает достичь совершенства.
Шипы
Шипы - это термин, используемый в гибкой разработке программного обеспечения. Шипы - это небольшие прототипы реализации функциональных возможностей, которые обычно используются для оценки и возможности применения новых технологий.
Этот метод включает в себя исследования и накопление знаний. Его следует использовать, если другие методы SPIDR не сработали. С помощью таких новоприобретённых знаний некоторые пользовательские истории можно будет проще понять и, возможно, и легче разделить. Однако этот метод является относительно абстрактным, и поэтому его труднее применять, чем остальные методы.
Пути
Если в пользовательской истории есть несколько возможных альтернативных путей, одним из вариантов является создание отдельных пользовательских историй на основе некоторых из них. Не
обязательно писать историю для каждого отдельного пути, лишь там, где это имеет смысл. Например, возьмем пользовательскую историю, в которой пользователь хочет иметь возможность оплачивать покупки в интернет-магазине. Сегодня есть два возможных пути: оплата кредитной картой или оплата через PayPal. Теоретически оплату кредитной картой можно разделить на дополнительные этапы, но вам необходимо взвесить, имеет ли смысл для каждого типа кредитной карты иметь свою собственную историю. Однако основная задача оплаты покупок делится на два альтернативных подхода. Таким образом, вновь созданные истории меньше и их легче оценивать.
Интерфейс
Интерфейсами в этом контексте могут быть, например, разные устройства или типы устройств, такие как смартфоны на базе iOS или Android. Пользовательские истории можно также разделить по этому признаку. Давайте придерживаться примера различных операционных систем: в проекте, например, могут быть пользовательские истории, которые относятся исключительно к использованию устройств Android, или другие, которые ориентированы на веб-браузеры. Чтобы не делать истории слишком большими и универсальными, вы должны спросить себя, какие устройства или интерфейсы вы хотите разработать. Возможно, первый результат разработки должен относиться только к устройствам iOS из-за, вероятно, большей целевой группы.
Данные
Другой метод разделения пользовательских историй можно использовать, когда исходные истории относятся только к одному разделу общих данных. Возьмем, к примеру, сайт, предназначенный для привлечения туристов в конкретный город. Например, если это город известен своими музеями, первый рассказ может включать информацию о различных музеях в этом районе. Следующий рассказ может включать в себя различные туристические туры по городу, а также еще один рассказ о мероприятиях на свежем воздухе.
Правила
Ещё одним фактором разделения могут быть бизнес-правила или технологические стандарты. Возьмем, к примеру, онлайн покупку билетов в кино. Часто существуют ограничения, основанные, например, на бизнес-требованиях соответствующего кинотеатра, таких как ограничение на покупку в Интернете максимум пяти билетов на один адрес электронной почты.
В этой истории можно было бы предположить, что команда разработчиков опускает такое ограничение, позволяя каждому посетителю покупать столько билетов, сколько они пожелают. Затем ограничение можно было бы добавить на втором этапе итерации. Такая инкрементальная добавка означает, что начальные истории реализуются не сразу полностью, а в несколько более мелких этапов. Иногда имеет смысл пренебречь техническими спецификациями или бизнес-правилами, если так можно быстрее достичь презентабельного результата, удовлетворяющего пользователя или клиента. Пропущенные истории можно будет добавить позже.
Маленькие пользовательские истории – более простая реализация
Разделение пользовательских историй задача не всегда легкая. Многие новички склонны формулировать свои истории так подробно, что они становятся слишком большими. Но когда дело доходит до взаимодействия с командой разработчиков и, в конечном итоге, до реализации историй, становится очевидным, что пользовательские истории должны быть гораздо более мелкими. Достигнуть этого несложно, если вы знаете, как разделить большую историю. И точно так же, как и в написании пользовательских историй, практика помогает достичь совершенства.
