Епоси мертві. Ось що нам слід робити замість цього.

Що ще не оголошено померлим? Розроблений тест-драйв був похований багато років тому. Проте він продовжує поширюватися. Звичайно, Agile теж мертвий. Але навіть традиційні компанії контактують із Scrum. Мертві продовжують жити, але оголосити щось мертвим завжди добре для швидкого заголовка. У цьому сенсі засвідчіть, як я руйную епос як спритну практику.

Що таке епос?

Термін нечіткий. Це має переваги. Епос - це більше для спілкування, ніж для специфікації. Нечіткість робить їх універсальними. Але є ризик непорозумінь. Я дотримуюся визначення Майка Кона:

Епос Scrum - це велика історія користувача. (Джерело)

Я використовую такий термін так: Епос - це історія, яка занадто велика, щоб її можна було реалізувати в спринті Scrum. Елементи у верхній частині відставання товарів - це, таким чином, не епопеї, а маленькі історії. У відставанні ви, як правило, знайдете епопеї. З часом епопеї «нарізаються» на історії, які можна втягнути в спринт.

Це те, що я роками викладав на своїх навчальних курсах. Здається, це загальний консенсус. Інтуїтивно зрозумілий на перший погляд. Я тут, щоб пояснити, чому це не практично.

3 непрактичні способи боротьби з епосами

Поки що я зіткнувся з трьома способами, якими компанії займаються епосами. Жоден з них не є практичним. Назвемо їх:

Розчинення

Посилання

Дерева

1. Розпуск

Принцип розчинення простий. Епопея повністю розбита на її складові, окремі маленькі історії.

Наприклад, епічний «Книжковий рейс» інтернет-порталу польотів можна розбити на окремі етапи процесу. Тож “Увійти”, “Шукати рейс” тощо. Кожен крок процесу стає історією. Команда оцінює історію. Поки він занадто великий, команда продовжує його розрізати. Як тільки всі історії досить маленькі, щоб вміститися в спринт, команда видаляє епопею і починає розробку історій.

Мене турбує основна ідея повноти. Розпуск передбачає, що тема може бути завершена заздалегідь визначеним обсягом.

Але якщо під час розробки можливі зміни в історіях, ви не можете визначити всі історії заздалегідь.

Посібник Scrum каже:

Відставання товару ніколи не буває повним. […] Вимоги ніколи не перестають змінюватися.

Якщо вам доведеться поставити фіксований приціл, припиніть прикидатися. Забудьте про епопеї та заздалегідь опишіть докладні вимоги. Тільки не претендуй на спритність тоді.

2. Посилання

Якщо ви не розчиняєте свої епоси повністю, має сенс використовувати посилання. Епопеї залишаються у відставанні. Ви пов’язуєте нові маленькі історії з епосами, з яких вони походять.

Ризик полягає в тому, що з часом кількість билин збільшується. Відставання стає роздутим. Він містить епопеї, які вам більше не потрібні. Зацікавленої особи більше немає в компанії. Або тема вже не актуальна.

Звичайно, час від часу ви можете прибирати відставання. Я вважаю це роботою, що не додає вартості. І цього можна уникнути, як я опишу пізніше.

3. Дерева

Інший спосіб - зображення епосів та історій як дерева:

Ви згрупуєте маленькі історії за епосом. Непогана ідея. Але те, що ви втрачаєте, - це упорядкований список відставань. Як тоді ви визначаєте порядок реалізації?

Звичайно, ви можете використовувати цифровий інструмент, який підтримує обидва види. Ризик: ви вкладаєте занадто багато часу та сил в інструменти. Які погляди? Які атрибути? Що є базовою моделлю даних? Цікаві питання. Але при спритному підході вони не повинні мати високого пріоритету.

Таким чином, ідея групування хороша. Але робити це трудомістко.

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

Альтернатива давно існує. Це навіть згадується в тому самому дописі блогу Майка Кон, на який я посилався вище.

Я говорю про теми .

Тема може розглядатися як додатковий атрибут історій. Зазвичай декілька історій мають однакову тему. Історія “Пошуковий політ” може мати тему “Книжковий політ”. Фрагмент із відставання може виглядати так:

Темами не керують як окремими елементами відставання. Це виключає роботу з очищення, обговорену в розділі Посилання. Добре.

Але те, що ви втрачаєте, - це процес поступового вдосконалення від великих епосів до історій, які можна реалізувати в спринті. Це погано.

На щастя, існують практики, які дозволяють зробити це вдосконалення поза відставанням. Одним із способів ідентифікації тем є схема використання:

Приємним у таких діаграмах є те, що вони показують «велику картину» завдяки високому рівню абстракції та графічному зображенню. Для цього відставання непридатне.

Назви випадків використання згодом стають темами у відставанні. Але як ви переходите від випадків використання до історій? Для цього ідеально підходить "Складання історії" Джеффа Паттона:

Два верхні рядки прикладу карти показують варіанти використання "Політ забронювати" та "Керувати профілем" та їх основний потік. На окремих етапах команда розглядає альтернативи: інші процеси, помилки тощо. Ці жовті нотатки називаються завданнями користувача.

У програмі уточнення відставання команда виводить історії із завдань користувача. Завдання може служити заголовком оповідання. Команда додає до історій такі деталі, як критерії прийняття.

Наслідки

Застосування цього альтернативного підходу має наслідки. Наприклад, відставання товару міститиме лише історії для наступних 1-2 спринтів. Тож, можливо, 10–20 історій.

Всі види діяльності, такі як подальше встановлення пріоритетів, оцінка та розробка критеріїв прийняття, відбуваються лише з цими матеріалами. Як говорить 10-й спритний принцип:

Простота - мистецтво максимізувати обсяг незавершеної роботи - має важливе значення.

Якщо керівництво хоче мати уявлення про хід розвитку, це можливо на трьох рівнях:

  • Діаграми або теми використання дають довгострокову перспективу управління. На 1 рік, а то й пізніше. Але: вони не підходять для уточнення деталей.
  • Карти сюжетів складають основу для планування випуску. Зацікавлені сторони, зацікавлені у випуску, створюють карту історії разом із членами команди. (Через нові висновки область застосування може змінюватися під час розробки.)
  • Ті, хто хоче глибоко зрозуміти та вплинути на деталі під час розробки, беруть участь у Sprint Review та уточненні відставання .

Лише на невеликій висоті ми бачимо деталі. А відставання товару в основному схоже на список покупок. Чи не записали б ви, що хочете придбати за рік?

І останнє, але не менш важливе, смерть епосів віщує вмирання споживацтва. Якщо ти чогось хочеш, ти повинен домовитись з командою і тісно співпрацювати.

Посмертний випадок

В дискусії з колегами вони вказали, що навіть після розпаду епосу можна додати невеличкі історії. Це правильно, і для мене це прийнятне рішення. Однак у цьому випадку втрачено «велику картину», яку я показав на схемі використання.

Зрештою, придатність продукту для користувачів визначає його успіх. Не те, як це було зроблено. Це стосується всіх практик розробки, включаючи епос.

Можливо, ви придумали розумний спосіб боротьби з епосами?

Дізнайтеся, як ефективно управляти відставанням товарів, відвідавши мій онлайн-курс. Ця стаття вперше була опублікована в блозі HOOD німецькою мовою.