Scrum vs Kanban

Agile manifestonun sitesini açtığımızda karşımıza çıkan dört manifestodan ilki şudur.

“interactions and individuals over processes and tools”

(agilemanifesto.org)

Agile manifestonun 17 fikir babası, yapılandırılmış süreçleri ve buna bağlı çeşitli araçlardansa interaktif  iletişimi tercih ettiğini belirtir. İşin sonuca ulaşması için, düzenli toplantılar, süreç toollarında günlerce uğraşılarak çizilmiş labirent gibi süreçler, katı hiyerarşiler, …. yerine takımın iletişimi ve etkileşime dayalı hızlı aksiyon alması agile manifestonun ilk kuralıdır.  

Hal böyleyken katı agile metotlarından söz etmek agile ruhuna çok da uygun düşmeyebilir. Çünkü her metot kendi içinde kurallar, süreçler ve yapılandırılmış araçlar içerir haliyle. Ne var ki agile proje geliştiriyorum deyip manifesto kurallarını ezberleyip tekrarlayarak proje geliştirilmesi de mümkün olmayacağı için bazı yöntemler esas alınabilir.  İnsan doğası işte kuralsız yaşayamaz…

Neyse. gelelim  Scrum ve Kanban ilişkisine. Burada Scrum ve Kanban’ın (özellikle de scrum’un)  tekniklerini anlatmayacağız. Esas olarak, temel prensiplerini ve temel farklarını ortaya koymaya çalışacağız.

İkisi arasında çok temel 2 fark vardır.

Birinci Fark, scrum temel olarak sprint bazlı olarak ilerler. Bu yüzden kesikli teslimat söz konusudur. Kanban ise süreklidir. Proje başlangıcından sonuna kadar sürer.

İkinci Fark, Scrumda yapılacak işlerin boyutu her sprint öncesinde development takımı tarafından belirlenir. Kanbanda ise WIP limitine göre her adımdaki limite göre sürekli doldur boşalt yapılır. Hangi işin yapılacağı development tarafından belirlenmez.

WIP (Work In Progress) Limiti: Proje başlamadan önce iş akışının en yavaş noktasına göre belirlenir. Bu yöntem ilk Toyota’da ara stokları düşürmek için kullanılmıştır. Örneğin; Yazılım üretim hattında 3 temel akış bölgesi olsun. Önyüz yazılımı, servis yazılımı ve test.  Bu akışta servis yazılımı yapacak kişi çok yoğun ve servis işleri çoksa bu kişinin hızına göre servis yazılımı akış noktasına göre bu kişiye bir seferde en fazla kaç task verilecekse WIP bu olur.

Bu iki farkı aşağıdaki şekil üzerinde izah edecek olursak ;

A, B, C gibi harfler her bir taskı ifade eder. Product Backlog SME ile üzerinde mutabakata varılan “Task-Story-Epic” listesidir.

SCRUM KANBAN AKIŞ

Kanban’da Proje başladıktan sonra Product Baclog üzerinden iş akmaya başlar. Aşağıdaki kanban boardda  herhangi bir anda todo bölümünde ilk 3 LŞT taskları olsun. Bu adımda In Progress adımına gidecek 3 task bellidir. Bu tasklardan örnğin l taskı çekildikten sonra Product Backlog’tan sorumlu kişi kendi belirlediği Q taskını Todo adımına ekler. (WIP Limit 3 olduğu için o kolonu maksimum 3 yapabilir)  Hangi taskı ekleyeceğini SME ile yaptığı önceliklendirmeye göre belirler. Aynı şekilde Todo adımındaki 3 tasktan hangisini In Progres adımına çekeceğine takım üyeleri karar verir. Bu süreç tüm product backlog bitene kadar tekrar eder.

KANBAN BOARD

Dikkat edilirse Kanban Board üzerinden hiçbir adımda WIP’ten fazla task bulunmuyor ve tasklar bitene kadar board kolonları boş kalmıyor. Boş kaldığı durumda takımda ilgili adımdan iş alacak kişiler kilitlenir ve boş kalabilir.

Scrum akışına bakarsak,  her sprint öncesinde SME önceliğine göre takım kendi yapabileceği kadar task üzerinde uzlaşır. Sprint 3 için bakacak olursak takım O,S,Z,Ş,Q,L  tasklarını bitireceğini taahhüt etmiştir. Bu durumda takım sprint sonuna kadar bu 6 taskı teslim etmek zorundadır. Sprint başında bu 6 task aşağıdaki gibi boarda eklenir. Bu board üzerinde sadece bu 6 task hareket eder.

Sprint sonunda bu 6 task bitirilir. Sonraki Sprinte geçildiğinde tüm backlog taskları bitene kadar aynı şekilde sprintler devam eder.

SCRUM BOARD