Scrum vs Kanban

Scrum ve kanban her ikisi de çevik çerçevenin şemsiyesi altına girdiğinden, birçok insan onları karıştırır veya aynı şey olduğunu düşünür. Ancak, pek çok farklılıkları vardır. Scrum yazılım geliştirme ekiplerine daha özgüdür, kanban birçok takım tarafından kullanılır ve çevik bir ekibin iş akışının görsel bir sunumunu sağlamaya odaklanır. Farklılıklara geçmeden önce Scrum ve Kanban' ı tanımlamaya başlayalım.

1.0 Scrum Nedir?

Scrum, 1990' ların başından beri karmaşık ürünler üzerindeki çalışmaları yönetmek için kullanılan içinde çeşitli süreçleri ve teknikleri barındıran bir süreç çerçevesidir. Scrum, ürün yönetiminizi ve çalışma tekniklerinizi göreceli olarak etkilemektedir. Böylece ürünü, ekibi ve çalışma ortamı sürekli iyileştirebilirebilir.

Kompleks yazılım süreçlerinin yönetilmesi için genellikle kullanılır. Bunu yaparken bütünü parçalayan; tekrara dayalı bir yöntem izler. Düzenli geri bildirim ve planlamalarla hedefe ulaşmayı sağlar. Bu anlamda ihtiyaca yönelik ve esnek bir yapısı vardır. Müşteri ihtiyacına göre şekillendiği için müşterinin geri bildirimine göre yapılanmayı sağlar. İletişim ve takım çalışması çok önemlidir. 3 temel prensip üzerine kurulmuştur;

Şeffaflık; Projenin ilerleyişi, sorunlar, gelişmeler herkes tarafından görülebilir olmalıdır.

Denetleme; Projenin ilerleyişi düzenli olarak kontrol edilir.

Uyarlama; Proje yapılabilecek değişikliklere uyum sağlayabilmelidir.

İş listeleri Sprint başlığı altında küçük gruplara ayrılır. Yeni talepler ve değişiklikler Sprint iş listesi üzerinde yapılamaz. Devam eden Sprint'e yeni işler eklenemez. Büyük değişimlerde Sprint derhal durdurulur ve yeni bir Sprint planlanmaya başlanır.

1.1 Roller:

Bir Scrum ekibi üç rolden oluşur:

Product Owner (Ürün Sahibi): Geliştirme süreci boyunca soruları cevaplamak, tamamlanan işleri gözden geçirmek ve gereksinimleri önceliklendirmek için hazır bulunan proje paydaşlarının bir temsilcisidir.
Scrum Master (Proje Sorumlusu): Geliştirme ekibine liderlik eder, herkesin çalışmalarına odaklanır, ekipteki diğer kişilere Scrum hakkında bilgi verir ve tüm Scrum toplantılarına liderlik eder. Her şeyin yolunda gittiğinden ve herkesin Scrum kurallarına uyduğundan emin olarak ekibin şefi olarak çalışır.
Scrum Team (Geliştirme Takımı) : Ürün sahibi tarafından açıklanan ve önceliklendirilen işi yapmaktan sorumlu üç ila dokuz geliştiriciden oluşan bir gruptur.

1.2 Kavramlar:

Sprint (Koşu): Proje sprint denilen küçük kısımlara ayrılır. Scrum içerisindeki tüm aktiviteler sprint içerisinde gerçekleşir. Genellikle 1–2 haftalık süreçlerdir.

Sprint Backlog (Koşu Gereksinim Listesi) : Geliştirme takımı tarafından her bir gereksinim (product backlog item) öncelik sırasına göre sprint içerisine alınırlar. Bir sprint boyunca yapılacakların listesini oluşturur. İşlerin detaylı olarak zaman çizelgesi çıkarılır.

Product Backlog (Ürün Gereksinim Listesi) : Proje için gerekli olan gereksinimler listesidir. Proje sonunda “Ne üretilmek isteniyor?” sorusuna cevap aranır. Product owner tarafından müşteriden gereksinimler alınır, öncelik sırasına göre sıralanır. Ürün sahibi değişen ihtiyaçlara göre product backlog’a ekleme veya çıkarma yapabilir. Böylece değişim, projenin her aşamasında projeye kolayca entegre edilebilir.

Sprint Goal (Koşu Hedefi): Ürün gereksinim listesinin gerçekleştirilmesi için sprint içinde uygulanacak olan ve geliştirme ekibine ürünü niçin geliştirdikleri konusunda rehberlik sağlayan bir amaçtır. Koşu Hedefinin cevaplaması gereken temel soru “Niçin bu koşuyu gerçekleştiriyoruz” şeklindedir.

User Stories (Kullanıcı Hikayeleri ): Gereksinimler genellikle kullanıcı hikayeleri oluşturularak açıklanmaktadır. Kullanıcı Hikayeleri müşterinin anlatımı ile oluşturulan, ürün sahibinin ne istediğini, sonuçta görmek istediğini ifade eden ve ürün ile kullanıcının etkileşiminin basit bir açıklamasını içeren bir liste şeklindedir. Kullanıcı Hikayeleri projede yapılacak görevleri ifade etmez, bu yüzden proje sürecindeki kişilerin ne yapacağını belirten görevlerden oluşmamaktadır.

Scrum Board (Scrum Panosu) : Bir sprint içerisinde yapılacak olan maddeler burada yönetilir. Yapılacak olan tasklar “TO DO” bölümüne alınır. Takım üyesi bu işe başladığında “IN PROGRESS” bölümüne getirilir. Bir iş, test için hazırsa “TO VERIFY” durumuna getirilir. İş, kontrol edildikten sonra “DONE” bölümüne getirilir. Scrum toplantılarında bu maddeler durumlarına göre yerleri değiştirilir.

1.3. Toplantılar:

Sprint Planning (Koşu Planlama) : Product backlog ile belirtilen gereksinimler, bu toplantı ile geliştirme takımı tarafından küçük görevlere (task) ayrılır. Takımdaki her bir kişi kendi hızına göre bu görevleri kendilerine alır. Bu toplantıya ürün sahibi, geliştirme takımı ve scrum master katılır. Sprintler; her sprint sonunda ürün sahibine sunulmak üzere yazılım geliştirmeyi hedefleyecek şekilde belirlenir. 1–3 haftalık sprintler oluşturulur.

Daily Scrum (Günlük Scrum): Her gün aynı yerde aynı saatte ayak üstü yapılan 15 dakikalık toplantılardır. Üyeler davet edilmeyi beklemezler. Bu toplantı gelecek 24 saati planlamak üzere yapılır. Takımdaki her üye dün ne yaptım,bugün ne yapacağım, işimi engelleyen herhangi bir sorun var mı sorularına cevap verir. Bu sayede herhangi bir sorunu var ise scrum master bu problemi ortadan kaldırır. Takım üyelerinden bu probleme yardımcı olabilecek biri var ise toplantı sonunda iletişime geçebilirler. Daily scrum her ne koşulda olursa olsun yapılır. Takımdaki birinin geç kalması veya gelmemesi toplantıyı etkilemez. Sadece takımdaki büyük çoğunluk yok ise toplantı yapılmaz.

Sprint Review (Koşu Değerlendirme): Her sprint sonunda yapılır. Yapılan sprint gözden geçirilir, ortaya çıkan ürün değerlendirilir. Amaç yazılımın ürün sahibinin gereksinimlerine uygun olarak geliştirildiğinden emin olmaktır. Eğer bir hata var ise fark edilir ve düzeltilir.

Sprint Retrospective (Koşu Süreç Değerlendirme) : Sprint boyunca yapılan işlerin kalitesinin, doğruların ve yanlışların değerlendirildiği toplantıdır. Bu toplantı scrum takımının kendini geliştirebilmesi için bir fırsattır. “Neleri daha iyi yapabiliriz?”, “Nasıl daha iyi yapabiliriz?” sorularına cevap aranır. Bu aşamadan sonra bir sonraki sprint planning toplantısı gerçekleştirilerek hepsi tekrardan yaşanır.

1.4. Anahtar Metrikler:

Release Burndown: Sprint sonrası tüm ürün iş listesindeki kalan gereksinimleri geçen zaman ile birlikte gösteren grafiktir.

Burndown Chart: Yatay ekseninde sprintin günlerini, dikey ekseninde sprintte kalan işi gösteren grafiktir. Scrum’un temel ilkelerinden olan şeffaflığı sağlar ve günlük olarak güncellenir.

Hız: Takımın hızı hakkında fikir verir. Bir sprint'te tamamlanan iş miktarına bağlıdır. Doğru sonuçlar vermesi takımın aynı ekip üyeleri ile devam etmesi durumunda mümkündür. İşin niteliklerine bakmadan diğer takımların iş miktarları ile kıyaslanamaz.

Teknik Borç: Yazılımın kalitesiz bir şekilde geliştirilmesinden dolayı oluşan maliyettir. Fonksiyonel olarak bekleneni veren bir yazılım olmasına rağmen bir süre sonra yönetilemez hale gelebilir.

2.0 Kanban Nedir?

Kanban, daha verimli bir üretim süreci oluşturmak için orijinal olarak Toyota'da bir endüstri mühendisi olan Taiichi Ohno tarafından geliştirilmiş ve Toyota'nın ana üretim tesisinde uygulanmıştır. Daha sonra da David J. Anderson tarafından 2010 yılında Kanban: Teknoloji İşiniz için Başarılı Evrimsel Değişim adlı kitabında yazılım geliştirmeye uygulanmıştır. Kanban kelimenin tam anlamıyla görsel işaret veya kart olarak tercüme edilir. Kartlı fiziksel kanban panoları, herkesin görmesini sağlayan sistem aracılığıyla çalışma akışının görselleştirilmesini mümkün kılar ve teşvik eder. Bu büyük gösterim (görsel bilgi sunumu) çalışmanın tamamlabilmek için akış sağlaması gereken durumları temsil eden sütunlardan oluşur. En basit panolar üç sütuna sahip olabilir ( yapılacak, yapılıyor ve tamamlanmış), ancak bunu kullanacak olan ekibin ihtiyacına göre uyarlanabilir. Gelen işlerin kapsamı ve önceliği farklı oluyorsa ve iş listelerinde sürekli değişiklikler meydana geliyorsa, Scrum'a göre Kanban çok daha avantajlıdır.

Roller: Kanban'da önceden tanımlanmış belirli roller yoktur. Bütün seviyelerdeki kişileri liderliğe teşvik eder. Sistem baştan bir sorumlu atamak yerine zamanla liderliğin üstlenilmesine imkan verir.

Esneklik: Kanban' da iş akışı her an değişebilir. İş listelerine yenileri eklenebilir, mevcut kartlar önceliklendirmeye bağlı olarak toplu olarak yer değiştirebilir ya da kaldırılabilir. Her şey kanban da esnek olmak ile ilgilidir.

2.1 Anahtar Metrikler

Lead Time: Bir iş talep edildikten sonra teslim edilene kadar geçen süredir. Müşteriyi ilgilendiren bir değerdir. Kanban'daki temel amaçlardan biri Lead Time'i düşürmektir.

Cycle Time: Gelen işin yapılmaya başlanıp bitirildiği zamana kadar geçen süre. İşi yapan kişiyi ilgilendirir.

WIP (Work in Progress): Aynı anda bir sütunda bulunan iş sayısını sınırlandırır. Bu sayede iş sayı sınırının üzerinde yeni işlerin listeye eklenmesi engellenmiş olurak, verimsiz çalışmanın önüne geçilir. Teslim süreleri azalır, daha kaliteli işler çıkar, mult-tasking sorunlarının çıkması engellenir.

3.0 Scrum ve Kanban Arasındaki Farklılıklar

Yazılım geliştirme alanında, Scrum ve Kanban, agile bir yazılım yaklaşımının özel biçimleridir. Hem arkasındaki felsefede hem de pratik uygulama da pek çok farklılar göstermektedir.

SCRUM	KANBAN
Geliştirme belirlenen zaman limiti içinde başlar ve biter.	Geliştirme sürekli olarak devam eder. Limit belirlemek opsiyoneldir.
Planlama, süreç iyileştirmeleri ve teslim için farklı ritimlere sahip olabilir. Sprint planlama, sprint retrospektif ve teslim planlaması farklı zamanlarda yapılabilir.	Yaşanılan gelişmelere göre aksiyon alınır. Önceden belirlenmiş toplantılar ya da aktiviteler bulunmamaktadır.
Takım bir iterasyonda belirli miktarda işi bitireceğine dair termin verir.	Termin vermek opsiyoneldir.
Takımın hızı planlama ve süreç iyileştirme için temel metrik olarak kullanılır.	Lead Time, planlama ve süreç iyileştirme için temel metrik olarak kullanılır.
Geliştirme takımlarının çapraz fonksiyonel olması kuraldır.	Geliştirme takımlarının çapraz fonksiyonel olması opsiyoneldir. Uzmanlıkların ön planda olduğu takımlar kurulabilir.
İş maddeleri bir Sprint içinde tamamlanacak küçük parçalara bölünmelidir.	İş maddeleri büyüklükleri farklılık gösterebilir. Belirlenen alt ya da üst bir limit yoktur.
Burndown grafiklerin kullanılması tavsiye edilir.	Belirli tipte bir grafiğin kullanılması zorunlu değildir. İşi yapmaya yarayacak herhangi bir grafik kullanılabilir.
Geliştirilen iş sayısı dolaylı olarak kısıtlanır. Bir sprintte geliştirme takımının gerçekleştirebileceği iş miktarı belirlidir.	Geliştirilen iş sayısı direk olarak kısıtlanır. Bu kısıt koyulurken iş akış durumuna bakılır.
İşlerin büyüklükleri hakkında tahmin yapmak tavsiye edilir.	İşlerin büyüklüklerini tahmin etmek opsiyoneldir.
Devam eden bir Sprint’e yeni işler eklenemez.	Kapasite uygun olduğu sürece yeni işler eklenebilir.
Sprint iş listesi belirli bir takım tarafından sahiplenilmiştir.	Kanban panosu, birçok takım ya da kişi tarafından kullanılabilir.
Üç rol belirlenmiştir. Ürün Sahibi, Geliştirme Takımı, Scrum Master	Herhangi bir rol belirlenmemiştir.
Scrum panosu her sprint başında yeniden oluşturulur.	Kanban panosu kalıcıdır.
Önceliklendirilmiş bir iş listesi zorunludur.	Önceliklendirme zorunlu değildir.
İş geliştirilirken kısa aralıklarla ulaşılabilecek hedefler konulur. Böylece takım hedefe her ulaşmaya çalıştığında test yapabilir ve önceki testlerden çıkardığı sonuçlar ile gelecekteki testlerde daha iyi sonuçlar elde etmek için iyileştirmelerde bulunabilir. Amaç bir ritim yakalamak ve olabildiğince bu ritmi iyileştirerek ilerlemektir.	İşler bir akış mantığı içinde geliştirilir. Akışta bir dar boğaz tespit edildiğinde bu dar boğaza karşı aksiyon alınır ve tekrarlamaması için iyileştirmeler yapılır. Kısa vadelerde belirlenen hedefler yoktur. Geliştirme sürekli olarak devam eder. İş sürekli olarak akar. Amaç işin pürüzsüz bir şekilde sürekli olarak akışını sağlamaktır.