Стендапи в стилі Kanban

Stand-up meeting, Daily Scrum Meeting або просто планерки стали звичною практикою IT. Я описував різні нюанси стендапів ще 5 років тому у статті Stand-up meeting: найкращі та найгірші практики. Здавалося б, техніка проведення стендапів уже розглянута з усіх боків. Що у планерці може бути складного? Але нещодавно наша компанія почала практикувати дещо інший підхід, за допомогою якого ми прискорили вихід завдань у реліз.

Все почалося, коли влітку 2014 року в Москві ми з Асхатом йшли на тренінг і він звернув мою увагу на різницю між стендапами у Scrum та Kanban. До цього я не надавав особливого значення таким нюансам. У нас в компанії для частини проектів використовується Kanban, але стиль стендапів залишився від Scrum'а.

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

Різниця у стендапах між Scrum та Kanban

Якщо ви новачок в Scrum, то спочатку рекомендую прочитати про Daily Scrum.

Далі йтиметься про Kanban. Якщо ви не використовували його, рекомендую спочатку прочитати безкоштовну книгу Priming Kanban.

Взагалі стендап не є частиною практик Канбан. У Канбан особливо і практик немає, є лише кілька основних принципів. Стендап можна вважати одним із способів реалізації принципуimprove continuously.

Разом отримуємо, що Scrum meeting іде навколо людей, які розповідають про завдання, а Канбан meeting іде навколо завдань. Якщо говорити іншою мовою, то в Scrum маємо зв'язокПрограміст 1* User Story, а в Kanban зв'язокUser Story 1* Програміст.

Опис процесу

Як можна помітити, вKanban, на відміну від Scrum, обов'язково потрібна дошка із візуалізацією ситуації на проекті. Т.к. ви обговорюєте не конкретні дії людей, а поточне положення задач та їх потік, дуже важливо бачити, де ці завдання знаходяться. Саме тому стендапи в стилі Kanban називають Story-focused stand-up або Work Items Attend.

Крім того, можна ставити 3 питання (а можна не ставити, це ж Kanban), як це робиться в Scrum, але ці питання виникатимуть навколо завдань, а не навколо членів команди:

Що заважає руху завдання?
Як завдання рухається потоком?
Що можна покращити?

Результати переходу

Детальніше про Cumulative flow diagram рекомендую подивитися в презентації Explaining Cumulative Flow Diagrams

Причини зависання завдань

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

Велика кількість заблокованих завдань.Наприклад, завдання дійшло до передостанньої стадії і чекає на підтвердження від Product Owner'а (PO) на заливку. У цьому PO може бути зайнятий, змінив фокус інші завдання. Виходить, що завдання висить в одному кроці від релізу, в неї вже вклали багато робочого часу і залишається зробити невелике зусилля. Якщо ми робимо стендапи в стилі Scrum, такі завдання не мають кому тягнути в реліз, тому що цим завданням ніхто вже давно не займається. Коли ми робимо стендап у стилі Kanban, такі завдання відразу стають помітними, крім того, кожен стендап ми до них повертаємося, т.к. йдемо праворуч наліво.
Пріоритет у завдань змінюється.Завдання доходять до останніх стадій, раптомстають не дуже важливими, команда переходить на нові завдання. Виходить, що PO змінив пріоритети та не дав завершити роботу. Спочатку всі мирилися з таким станом речей, тому що під час стендапів у стилі Scrum відбувається обговорення завдань, над якими команда працює зараз. Все, що було раніше не так цікаво.
Робота заповнює час, відпущений на нее.. Якщо ітерація триває 3 тижні, то всі завдання висітимуть десь на дошці до завершення ітерації. Навіть якщо якесь завдання може бути зроблено раніше, то вона може не дійти до останньої стадії. У Scrum немає мети зменшити Lead Time, тоді навіщо релізувати завдання до закінчення ітерації? Kanban підштовхує завдання у реліз, а стендапи у стилі Kanban цьому сприяють.
Багато роботи != багато результату.На Scrum meeting команда може обговорити як багато було зроблено вчора. Але чи ударна робота означає, що команда дала багато бізнес-результату? Можливо після ударної роботи утворилося багато пляшкових шийок? Важливим є потік завдань та його потрібно конролювати.

Висновок

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