Чому Scrum - це не про стендапи

“у нас скрам не такий як у книжці”, “та скрам - то коли багато мітингів”, “у нас є стендапи, тому у нас є скрам” та інші схожі фрази мені неодноразово доводилось почути як критику методології Scrum чи як аргумент, що вона не працює. Погано реалізований Scrum чи нерозуміння ідей цієї методології не робить її поганою.

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

Отже, Scrum це в першу чергу методологія. Саме методологія, бо вона чітко описує процес, артефакти, є чіткі рекомендації і можна конкретно сказати як запровадити Scrum для команди. Тому, порівняння Scrum vs Weterfall не є коректним, бо Waterfall це модель яка доволі абстрактно описує процес розробки продукту, а не процес роботи команди над цим продуктом. Про моделі SDLC я писав тут

Порівняння Scrum vs Agile також не є коректним, бо Agile це швидше філософія\підхід і також не описує як працювати команді. Більше про Agile я писав тут

Scrum foundation

Scrum базується на декількох подіях чи активностях. Це :

• Standup
• Planning
• Sprint Review чи Demo
• Retrospective

Standup

У багатьох сферах, де працюють команди кожного дня у них є коротке обговорення теперішнього стану справ. У скрамі це називається Standup або Daily Standup meeting(DSM). То чи можна сказати, що у них Scrum ? Скоріше, ні.

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

Як не потрібно проводити DSM:

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

Planning — центр скраму

Проблема, яку вирішує Scrum — планування. Якщо ми знаємо, що команда A за один спринт виконує Х роботи(юзер сторі, сторіпоінтів, годин), то за N спринтів ми виконаємо N*X роботи. Ну приблизно так. Звісно, потрібно враховувати всілякі ризики та потенційні проблеми. І, звісно ж, таке можна зробити, розуміючи к-сть роботи та маючи швидкість роботи конкретної команди.

Маючи такі дані, можна оцінювати та планувати складні проекти. На основні кожного спринта ми можемо вносити корективи як і у швидкість команди, так і у к-сть роботи. Тому, оцінка роботи(Estimate) — дуже критичний показник. І тому, не можна міняти об’єм робіт який планується на спринт під час спринта. Бо якщо хтось вкине нову задачу посеред спринта, весь план спринта може не бути досягнутим, і статистика по швидкості команди буде трохи не справжня. А об’єм робіт не зменшиться, а перенесеться на наступний спринт. Відповідно, важче планувати далеко.

Існує дві організації: Scrum Guide та Scrum Alliance. Вони організовують навчання та сертифікації у області Scrum. Їхнє бачення в основному однакове, але Scrum Alliance виділяє ще Backlog Refiment як окрему активність. Backlog Refiment це активність під час якої ми створюємо задачі, проводимо декомпозицію задач та можемо їх якось оцінювати. А вже під час планування обираємо які задачі у який спринт підуть.

У Scrum Guide ці активності об’єднані в один івент — Planning. Якоїсь кардинальної відмінності немає, але я більше підтримую підхід Scrum Aliance

Sprint Review

Кожен спринт повинен мати ціль або цілі. По завершенню спринта ми повинні продемонструвати нашому Product Owner-у, що ми досягли за цей спринт. Навіть якщо ваш спринт не завершується релізом на продакшин, проводити демо потрібно. Так ми досягаємо прозорості у нашій роботі та націлені на отримання результату. Інакше, не буде що показувати, а червоніти перед PO не хочеться.

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

Retrospective

Ціль ретроспективи — наголосити болючі місця під час спринта. Тут зворотній зв’язок покаже ті місця, які уповільнювали чи блокували членів команди. Що для вас є проблемою — для когось може не бути проблемою і він її не побачить.

Не варто думати, що підняття проблем на ретро — це “донос” на когось. Ваші проблеми не повинні бути персоналізованими. Потрібно розуміти, що ретро це не місце самоствердження, а місце для покращення процесу.

Але розповідати про проблеми на ретро недостатньо. Потрібно виносити якісь дії, котрі повинні бути виконані у наступних ітераціях. Ці дії варто закріпляти на членів команди. І наступне ретро починати з цього списку.

Навіть, якщо ви не використовуєте скрам, робити ретроспективу за певний період — це гарна ідея.

Summary

Хтось колись написав, що скрам — це не для серйозних проектів і всякі там “аерокосмічні та медичні проекти не можуть працювати по скраму”. І я вже роками подібне слухаю на співбесідах. Але якихось фактів чи прикладів з таких проектів ніхто ніколи не наводить. Такі висловлення переважно взято з неба. Звісно, існують проекти у подібних доменах, які не використовують скрам. Та і у інших доменах є такі проекти. Не важливо, скрам чи не скрам, але складний проект ви не можете просто “візьми та зроби”. Складний проект — це завжди ітеративний процес, де наступна ітерація бере результат попередньої і оновлює план згідно неї. І без оцього зворотнього зв’язку наш проект не може рухатись, бо на початку проекту не можливо запланувати та визначити всі деталі, та і часто наші гіпотези можуть бути хибними. Тому, зворотній зв’язок і підлаштування з новими даними — це важливо. А так як проекти мають якісь дедлайни чи часові плани — це можна і потрібно планувати за допомогою Scrum. Бо Scrum — це про планування.