Одного разу була scrum-команда, моя scrum-команда. Я виконую ролі бізнес-аналітика та Scrum-майстра, ролі, пов’язані з оцінкою, плануванням, відстеженням швидкості, і все починалося як команда, де оцінки робилися у вигляді “людиноднів”, оцінювання і планування займали години у всієї команди.
З часом ми помітили деякі проблеми з цим підходом до оцінки. Під час кожного мітингу дискусії тривали нескінченно, розробники починали перевіряти код і намагалися дати оцінку якомога точніше. Дискусії також виникли через різницю в досвіді: більш досвідчені розробники оцінюють менше днів, а недосвідчені розробники просто погоджуються на оцінку, просто тому, що вона менша. Ми також заздалегідь призначали завдання на основі знань, тому ми переконалися, що їх виконує більш відповідний розробник.
Що це означало? Ми підтримували “вузькі місця”, якщо досвідчений розробник певного напрямку був відсутнім на зустрічі, то ця тема залишалася підвішеною. Загальний рівень команди не підвищувався, і справжнього прогресу команди не було видно.
Ми говорили про зміну оцінки з переходом на story points та про те, що це означатиме, але це здавалося абстрактним і суперечило течії організації.
Можливість
З останньою реорганізацією з’явилася нова течія, свобода та незалежність команд, справжня самокерованість. Це була перерва, на яку ми чекали, і разом із треннінгом зі скраму я знайшла правильний момент для презентації та впровадження цієї ідеї в команду.
Як ми це зробили? Було виконано кілька простих кроків:
- Презентація теорії – яка концепція лежить в основі відносної оцінки
- Цікава вправа визначення розміру тварин відносно людини
- Справжня вправа визначення історій, релевантних для нашої команди
- Почали застосовувати це на практиці в нашому процесі scrum і почали відстежувати швидкість
- Порахували переваги
- Поділилися з іншими
До теми: Customer journey з погляду бізнес-аналітика. Як зацікавити клієнта
Які переваги ми побачили одразу та пізніше?
Негайними перевагами були швидші оцінки, відсутність більше 3-годинних сеансів для підготовки 3 історій, знання почали поширюватися серед команди, і всі розробники почали відчувати себе більш впевнено в оцінюванні та підбиранні історій за межами основного домену.
Поступово ми досягли стабільної швидкості на впевненому рівні зобов’язань, підвищуючи нашу передбачуваність для майбутніх спринтів. Планування також виконується швидше, оскільки команда просто вибирає перші історії, які відповідають відповідному об’єму (velocity), з пріоритетного резерву.
Невимовною перевагою є зміцнення команди, яке згодом було відображено в ретроспективі: гнучкіший процес є чистішим, більш зрілим, більше довіри між членами команди та менше страху перед оцінкою порівняно з фактом.
Ми поділилися нашим прогресом з іншими командами нашої організації та з нетерпінням чекаємо нових і нових щасливих команд. Якщо ви боретеся з цією темою, нижче наведено деякі теоретичні аспекти, які можуть допомогти.
Story points залежать від часу, розміру, ризику, невизначеності, залежностей і складності
- Story points відносні
- Самі одиниці (юніти) не мають ніякого значення
- Легше порівнювати, ніж оцінювати
Відносне оцінювання — це прийняття рішень на основі фактів: фактичний обсяг роботи, як його сприймає команда.
Якщо брати до уваги оцінювання “в днях”, кожен член команди розглядатиме день по-своєму, і не матиме спільної точки відліку для єдності.
Метою оцінки в agile є не створення точного плану роботи до години. Команда повинна мати обґрунтоване уявлення про те, скільки елементів невиконаного продукту вони повинні прагнути завершити в майбутньому спринті.
Джефф Сазерленд, співавтор посібника Scrum: Story points це швидше, краще та дешевше, ніж години, і найефективніші команди повністю відмовляються від будь-яких погодинних оцінок, оскільки вважають це марнотратством, яке просто сповільнює їхню роботу.
Можливо також зацікавить Вебінар “Формування беклогу: декомпозиція, оцінювання та пріоритизація”
Fibonacci Estimation (Оцінка Фібоначчі)
Метод оцінки використовує послідовність Фібоначчі як початкову шкалу для порівняння елементів. У послідовності Фібоначчі кожне число є сумою двох попередніх чисел: 0, 1, 2, 3, 5, 8, 13, 21…
Цей експоненціально зростаючий масштаб навмисно створює буфер в оцінюванні, що дозволяє вносити зміни.
Planning Poker (Планувальний покер)
«Планувальний покер» — це вправа, яку виконують скрам-команди, щоб допомогти виміряти розмір переліку завдань (беклогу).
Першою необхідною умовою є вибір контрольної точки:
- Виберіть елемент середнього розміру, щодо якого розробники мають найкраще спільне розуміння
- Довільно призначте 3 або 5 story points, щоб створити стабільну точку відліку
Після того, як визначили опорні історії, виберіть першу історію для оцінки та запитайте: як оцінка цього завдання порівнюється з оцінкою оціненого і визначеного раніше завдання?
Кожен розробник тримає свої думки при собі, і тоді всі карти розкриваються одночасно. Візьміть середнє значення та рухайтеся далі або попросіть учасників пояснити граничні значення.
Можливі пастки
- Уникайте нормалізації оцінки та порівняння швидкості між різними командами
- Story Points тісно пов’язані до застосованих підходів для оцінки та людей, які виконують роботу
- Velocity — це не «інструмент покарання», це інструмент передбачення
- SM і PO не оцінюють, якщо SM не займається розробкою для команди Scrum
- Переоцінку Story Point під час бігу спринту робити не слід, оскільки це є частиною кінцевої швидкості спринту, навіть якщо це неточно. Це нормально, що кілька разів оцінки можуть бути неточними.
- Відображення Story Points у годинах додає невірну точність, коли ви починаєте працювати, пам’ятаючи про фіксовані результати.
- Використання проміжних очок історії, коли половина команди оцінює історію в 5 очок історії, а інша половина — у 8 очок історії
FAQ
- Як використовувати цей показник між кількома командами?
Бувають ситуації, коли кілька команд співпрацюють над одним продуктом. У цьому випадку між Командами будуть різні зв’язані історії, а це означає, що одна й та сама історія може бути різною для різних Команд. Коли історія передається від однієї команди до іншої, її розмір потрібно змінити. Технічний борг повинен мати власні зв’язані історії, які визначаються усіма розробниками разом. Немає правильного шляху, це лише метод проб і помилок, доки кожна команда не знайде спосіб, який їй підходить.
2. Перенесення (Carryovers)
Методологія Scrum передбачає переоцінку перенесених історій, щоб зусилля були розраховані правильно.
Наш поточний спосіб роботи, який залежить від циклів випусків і доступності тестового середовища, не дозволяє нам досягти DoD (Definition of Done) за один спринт, що спричиняє втрату балів, що спричиняє демотивацію.
Рішенням нашої команди було використання статусу «Готовий до тестування» для історій, зроблених, але не перевірених, оскільки їх не можна було розгорнути в тестовому середовищі, яке ми переносимо без повторної оцінки, але ми не додаємо повністю для визначення розміру наступного спринту на планувальному мітингу; Іншим рішенням може бути повне додавання завдання та висока змінна кількість балів, які реалізовуються за кожен спринт.
3. Як бути з бюджетними оцінками?
Власники продукту (Product Owner) використовують поняття ємності (capacity) і дні для бюджетування наступного обсягу робіт, а замовники, використовують оцінки днів для затвердження бюджету для запиту на зміни.
Можливий підхід щодо цього полягає в тому, щоб продовжувати робити високорівневі оцінки в днях для потреб бюджету, потім оцінити характеристики як у днях, так і в розмірі футболки (T-shirt size), а потім перейти до використання розміру футболки для функцій перед плануванням.
Пам’ятайте: розмір футболки завжди передбачає більше, ніж зусилля розробника; це також включатиме накладні витрати на обслуговування.
Автор: Irina Pirvan EPAM, Senior Business Analyst
Переклад з оригіналу здійснено 4 липня 2022 року