Scrum срещу Kanban: кое да избере вашият екип?
Scrum работи с фиксирани спринтове и определени роли. Kanban е непрекъснат поток с WIP лимити. Ето как да изберете и кога да ги комбинирате.
Scrum и Kanban са двата най-разпространени начина за организиране на Agile работа. Решават един и същ проблем — доставка на стойност на малки части — но правят много различни залози: как да е устроен екипът, как да тече работата и откъде да идва натискът за подобрение.
Накратко: Scrum работи с фиксирани спринтове, определени роли и цел на спринта. Kanban работи като непрекъснат поток, регулиран с изрични work-in-progress лимити. Нито един не е универсално по-добър. Изборът зависи от характера на работата.
Какво дава Scrum
Scrum, описан в 13-страничния Scrum Guide, задава три роли (Product Owner, Scrum Master, разработчици), пет събития (спринт, планиране, дейли, преглед, ретроспектива) и три артефакта (Product Backlog, Sprint Backlog, инкремент). Всеки спринт има цел, която разработчиците поемат и Product Owner защитава.
Спринтът е клапанът на натиска. На всеки една до четири седмици екипът спира, инспектира инкремента със заинтересованите страни и решава какво да прави следващо. Този ритъм прави Scrum структуриран и подходящ за работа, която се реже на свързани парчета с такава дължина.
Какво дава Kanban
Kanban идва от лийн производството и е адаптиран за интелектуалния труд от Дейвид Дж. Андерсън. Няма спринтове, няма задължителни роли, няма задължителни церемонии. Kanban задава три неща: визуализиран работен поток, изрични WIP лимити на всяка колона и ритъм на прегледи, който екипът дефинира сам.
WIP лимитът е клапанът на натиска. Когато колона е пълна, нова работа не влиза, докато нещо не излезе. Това кара екипа да довършва работата, а не да започва нова, и извежда наяве тесните места. Kanban е оптимален за работа, която пристига непредсказуемо или не се реже чисто на спринтове.
Разликите, които наистина имат значение
- Ритъм: Scrum използва фиксирани спринтове. Kanban е непрекъснат.
- Роли: Scrum задава три подотчетности. Kanban не задава нито една.
- Ангажимент: Scrum ангажира цел на спринта. Kanban ангажира клас обслужване (например целево време на цикъла).
- Промяна: спринтът е защитен от промени по средата. Kanban приема нова работа по всяко време, стига WIP лимитите да се спазват.
- Метрики: Scrum разчита на burndown и velocity. Kanban на cycle time, throughput и cumulative flow.
- Ретроспектива: Scrum я прави всеки спринт. Kanban на ритъм, който екипът дефинира.
Кога Scrum е по-подходящ
Изберете Scrum, когато работата може да се планира на парчета от една до четири седмици и заинтересованите страни могат да чакат толкова между точки на решение. Подхожда на продуктовата разработка, където целта се променя на всеки няколко седмици според последния инкремент. Подхожда на екипи, които се нуждаят от структура на роли, за да държат Product Owner и Scrum Master честни.
Scrum също така е по-лесен за преподаване. Рамката е малка, събитията са именовани, има публични сертификации (PSM, PSPO, PSD от Scrum.org или CSM, CSPO от Scrum Alliance).
Кога Kanban е по-подходящ
Изберете Kanban, когато работата пристига непредсказуемо и не може да се групира в спринтове. Support екипи, операции, реакция на инциденти и маркетинг заявки са класически примери. Kanban е правилният избор и когато екипът вече има стабилни роли и ясен процес, а целта е да се подобри потокът, вместо да се въвежда цяла рамка.
Kanban е по-малко предписателен и затова по-малко защитен. Без реално спазвани WIP лимити Kanban се превръща в 'дъска със стикери'. Дисциплината трябва да идва от екипа, не от рамката.
Scrumban и хибриди
Много зрели екипи стигат до нещо по средата. Scrumban запазва ритъма и събитията на Scrum, но добавя WIP лимити и издърпване на работа в рамките на спринта. Често така изглежда Scrum екипът, когато вече има дисциплина да не бута задачи в Sprint Backlog, а да ги издърпва.
Как да решите за една среща
Отговорете на три въпроса. Първо: можете ли да планирате смислена работа на парчета от една до четири седмици? Ако да, Scrum е на масата. Второ: работата идва по график, който контролирате, или когато дойде? Ако второто — Kanban. Трето: имате ли Product Owner, който може да каже 'не' на промени по средата на спринта? Ако не, Scrum няма да защити нищо, а Kanban няма да загуби нищо.
Каквото и да изберете, рамката е само скелето. Уменията се раждат от повторения. Симулаторът на Scrumling ви поставя в моментите, които и двете рамки оставят на преценка.