Практика застосування Burn Down Charts у контексті SAFe та Scrum

У цій статті я планую розповісти, як на своїй практиці ми застосовуємо діаграму згоряння (Burn Down Chart) у процесі роботи за методологією SAFe

Почну, мабуть, із найцікавішого. А саме з того, що використання цієї діаграми в SAFe не повинно мати жодної специфіки щодо використання цієї діаграми в SCRUM. Чи повинно?

SAFe у нас відрізняється наявністю такої ролі, як RTE, на відміну від SCRUM, де її немає. Burn Down Chart - це інструмент відстеження обсягу робіт у спринті, і він потрібен насамперед для SCRUM-команди, а не для когось ззовні, чи не так?

Таким чином, все ж перейду до того, як ми використовуємо Burn Down Chart, незважаючи ні на що, і, перебуваючи по-прежньому всередині фреймворку SAFe.

Я перебуваю в ролі Scrum Master і намагаюся висвітлювати цю діаграму щодня для всієї Dev Team. Засіб, який я використовую - це командний чат, згадка всієї команди через "@", скриншот поточного стану діаграми. Згадка всієї команди - це досить тонкий інструмент, і важливо використовувати його якомога рідше (адже ми, Скрам Майстри, повинні допомагати команді працювати в комфорті та з мінімально можливою розфокусованістю, чи не так?)

У підсумку команда щодня бачить поточний стан спринту і здатна відстежити такі події

• Поява незапланованої роботи
• Довге зависання задач у незавершеному статусі
• Надмірне закладання ризиків
• Розуміння - чи в правильному темпі йде робота

Далі я спробую розкрити кожну з цих подій і навести приклади зі своєї практики.

Поява незапланованої роботи

На цій діаграмі дуже добре видно, як з'являється нова робота (у другий вівторок двотижневого спринту).

Випадок із практики: "Розробник, як член scrum-команди, що поділяє принципи agile, класно взаємодіє з Product-ом напряму. Product каже йому, що ось це треба запилити швиденько, ти ж сам розумієш, тут швидко і ризики мінімальні.

Розробник класний, він знає все про agile і про важливість доставки бізнес-цінності, іде закидає на дошку історію з беклогу, оцінена вона командою в 6 sp.

Решта команди (крім розробника і Product-а) помічає це на ранковому апдейті діаграми. На стендапі команда ухвалює рішення, як бути з цією ситуацією. Найімовірніше, історія викидається зі спринту, Product-у і Розробнику команда дає зрозуміти, що так робити не можна, продакт може поставити цю історію в наступний спринт за потреби.

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

Тут важливо розуміти, що сценарій міг піти по-різному залежно від рівня команди. У крутих командах Власник продукту навряд чи так зробив би, а якби й зробив, то аргументував не тим, що «це можна швиденько запилити», а тим, що «я оцінюю в 55% ймовірність того, що якщо це запилити зараз, то може збільшити наш прибуток на 20% наступного місяця» або ще якоюсь вимірюваною метрикою.

Довге зависання задач у незавершеному статусі

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

• Погана декомпозиція задач

  Дуже часто початківці команди говорять про неможливість декомпозиції. У них все згорає в останній день, робота не розпаралелюється тощо. Звісно, з цим необхідно працювати Скрам Майстру і пояснювати цінність декомпозиції команді.

• Не оптимально сформульований DOD

  DOD (Definition of Done) - опис критеріїв готовності User Story в спринті. Іноді їх взагалі немає або вони описані дуже абстрактно. Це цілком може бути проблемою, яку, звісно, повинен допомогти вирішити Скрам Майстер

Надмірне закладання ризиків

У цьому випадку ми бачимо ситуацію, коли команда перезаклала ризики.

Можливо, якась історія була переоцінена. Можливо, це більш системна проблема і необхідно збільшувати обсяг роботи при плануванні спринту. У будь-якому випадку, ця ситуація не коректна. Адже бізнес планував що будуть реалізовані саме задачі спринту і саме до кінця спринту. Залежно від того як були сплановані залежності, тут найімовірніше доведеться проводити зустрічі для коригування очікувань.

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

Розуміння - чи в правильному темпі йде робота

Тут я хотів би звернути увагу на графічно невдалі способи відображення Burn Down Chart

У верхній частині зображення наведено приклад не найвдалішої графічної реалізації з двох причин, які я викладу нижче.

• Не помітно потрапляння нових SP в спринт

  Тут, на верхній діаграмі, практично не помітно, що додалася незапланована робота. На нижній це більш наочно.

• Не коректно відображається відносний залишок робіт

  Згідно з верхньою діаграмою залишилося працювати ще 3 дні. За фактом їх 2, в вихідний, можливо, хтось планує відпочити.

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