Епосите са мъртви. Ето какво трябва да направим вместо това.

Какво вече не е обявено за мъртво? Test Driven Development е погребан преди години. Все пак продължава да се разпространява. Разбира се, Agile също е мъртъв. Но дори традиционните компании влизат в контакт със Scrum. Мъртвите продължават да живеят, но декларирането на нещо за мъртво винаги е добре за бързо заглавие. В този смисъл станете свидетели как унищожавам епосите като пъргава практика.

Какво представляват епосите?

Терминът е неясен. Това има предимства. Епосите са повече за комуникация, отколкото за спецификация. Неясността ги прави универсални. Но съществува риск от недоразумения. Придържам се към определението на Майк Кон:

Епичът Scrum е голяма потребителска история. (Източник)

Използвам термина така: Епопеята е история, която е твърде голяма, за да бъде приложена в спринт на Scrum. По този начин елементите в горната част на Backlog на продукта не са епоси, а малки истории. Надолу в изоставането обикновено ще намерите епопеи. С течение на времето епосите се „нарязват“ на истории, които могат да бъдат изтеглени в спринт.

На това преподавах години наред в моите курсове за обучение. Изглежда общият консенсус. Интуитивен на пръв поглед. Тук съм, за да обясня защо не е практично.

3 непрактични начина за справяне с епосите

Досега попаднах на три начина, по които компаниите се справят с епосите. Нито един от тях не е практичен. Нека им се обадим:

Разтваряне

1. Разтваряне

звена

2. Връзки

Дървета

3. Дървета

1. Разтваряне

Принципът на разтварянето е прост. Епикът е напълно разбит на неговите компоненти, отделните малки истории.

Например епичен „Книжен полет“ на онлайн портал за полети може да бъде разбит на отделните стъпки на процеса. Така „Вход“, „Търсене на полет“ и т.н. Всяка стъпка на процеса се превръща в история. Екипът оценява историята. Докато той е твърде голям, екипът продължава да го реже. След като всички истории са достатъчно малки, за да се поберат в спринтове, екипът изтрива епоса и започва разработка за историите.

Досадата на завършеността ме притеснява. Разтварянето предполага, че дадена тема може да бъде завършена с предварително определен обхват.
Но ако промените в историите са възможни по време на развитието, не можете да определите всички истории предварително.

Ръководството за Scrum казва:

Блогът на продуктите никога не е пълен. […] Изискванията никога не спират да се променят.

Ако трябва да предоставите фиксиран обхват, спрете да се преструвате. Забравете за епосите и предварително опишете подробните изисквания. Просто не претендирайте, че сте пъргави.

2. Връзки

Ако не разтворите епосите си напълно, има смисъл да използвате връзки. Епосите остават, надолу в изоставането. Свързвате нови малки истории с епосите, от които произлизат.

Рискът е, че с течение на времето количеството на епосите се увеличава. Закъснението става подуто. Той съдържа епоси, от които вече не се нуждаете. Заинтересованата страна вече не е в компанията. Или темата вече не е актуална.

Разбира се, можете да почиствате закъснението от време на време. Считам това за работа без добавена стойност. И можете да го избегнете, както ще опиша по-нататък.

3. Дървета

Друг начин е изобразяването на епосите и историите като дърво:

Изобразяване на епосите като дърво

Групирате малките истории по епос. Не е лоша идея. Но това, което губите, е подредения списък на изоставането. Как тогава определяте реда за изпълнение?

Разбира се, можете да използвате цифров инструмент, който поддържа и двата изгледа. Рискът: инвестирате твърде много време и усилия в инструментите. Какви са гледките? Какви са атрибутите? Какъв е основният модел на данните? Интересни въпроси. Но при пъргав подход те не трябва да имат висок приоритет.

В обобщение, идеята за групиране е добра. Но това да отнеме време.

Алтернативата на епосите

Отдавна съществува алтернатива. Той дори е споменат в същата публикация в блога на Майк Кон, която свързах по-горе.

Говоря по теми.

Една тема може да се мисли като допълнителен атрибут на историите. Обикновено няколко истории споделят една и съща тема. Историята „Полет за търсене“ може да има темата „Резервационен полет“. Фрагмент от изоставането може да изглежда така:

Потребителски истории с тема

Темите не се управляват като отделни резервни елементи. Това елиминира работата по почистване, разгледана в главата за връзки. Това е добре.

Но това, което губите, е процесът на постепенно усъвършенстване от големите епоси до историите, които могат да бъдат реализирани в спринт. Това е лошо.

За щастие има практики, които правят възможно това усъвършенстване извън изоставането. Един от начините за идентифициране на теми е диаграма на случаите на използване:

Хубавото на подобни диаграми е, че те показват „Голяма картина“ поради високото ниво на абстракция и графичното представяне. За това изоставането е неподходящо.

По-късно имената на случаите на употреба се превръщат в теми в изоставането. Но как да стигнете от случаите на употреба до историите? За това, Картографирането на историята е подходящо:

Най-горните два реда на примерната карта показват случаите на използване „Резервация на полета“ и „Управление на профила“ и основния им поток. Под отделните стъпки екипът окачва алтернативите: други процеси, грешки и т.н. Тези жълти бележки се наричат ​​потребителски задачи.

В Backlog Refinement екипът извлича историите от потребителските задачи. Заглавието на историята може да служи като задача. Екипът добавя подробности като критерии за приемане към историите.

Последствията

Прилагането на този алтернативен подход има последствия. Например, Backlog на продукта ще съдържа истории само за следващите 1–2 спринта. Така че може би 10–20 истории.

Всички дейности като по-нататъшно приоритизиране, оценка и изработване на критериите за приемане се извършват само с тези истории. Както казва десетият пъргав принцип:

Простотата - изкуството да се увеличи максимално количеството незавършена работа - е от съществено значение.

Ако ръководството иска да има представа за напредъка на развитието, това е възможно на три нива:

  • Използвайте диаграми или теми на темата осигуряват дългосрочната перспектива за управление. За 1 година или дори след това. Но: те не са подходящи за уточняване на подробности.
  • Картите на историята са основа за планиране на изданията. Заинтересованите страни на изданието създават историята с членове на екипа. (Поради новите открития, обхватът може да се промени по време на разработването.)
  • Тези, които искат да имат задълбочена представа и да повлияят на детайлите по време на разработката, участват в Sprint Review и Backlog Refinement.

Само на малка надморска височина виждаме детайлите. А продуктовото изоставане всъщност е като списък за пазаруване. Бихте ли написали какво искате да купите след година?

Не на последно място, но не на последно място, смъртта на епосите предвещава умирането на консуматорството. Ако искате нещо, трябва да се съгласите с екипа и да работите в тясно сътрудничество.

Post mortem

В дискусията с колеги те изтъкнаха, че дори след разпускане на епос могат да се добавят малки истории. Това е правилно и за мен е приемливо решение. Това, което се губи в този случай, обаче, е „Голяма картина“, която показах в диаграмата за използване.

В крайна сметка, пригодността на даден продукт за потребителите определя неговия успех. Не как е направено. Това се отнася за всички практики за развитие, включително епосите.
Може би сте измислили разумен начин да се справите с епосите? Тогава ме уведомете в коментарите.

Научете как ефективно да управлявате продукта си, като посетите моя онлайн курс. Тази статия е публикувана за първи път в блога HOOD на немски език.