Kanban: Bir Yalın Pratiği

Kanban’ı, değer akışlarını daha etkili ve verimli işleyecek şekilde optimize etmeye yarayan, yalın prensipleri benimseyen bir çerçeve (framework) olarak tanımlayabiliriz. Bir proje yönetim veya yazılım geliştirme yaşam döngüsü metodolojisi değil. ‘Değer’ dediğimiz bağlama göre değişiklik gösterebilir. Bir yazılım projesinde yazılım işlevi, üretim sektöründeyse somut parçalar bizim için değere karşılık gelebilir. Zaten Kanban’ın çıkış noktası da aslında üretim sektörü, kökenleri Toyota Üretim Sistemi’ne kadar dayanıyor. İş akışının olduğu herhangi bir yerde, bunu optimize etmek için Kanban’dan faydalanılabilir. Sağlıktan pazarlamaya, finanstan yazılıma geniş bir kullanım alanı olduğunu söylemek mümkün.

Yazılım dünyasında her iş kendine özgü farklılıkları barındırır. Kişiler, yapılan projeler, kurumların dinamikleri, paydaşları bağlamdan bağlama farklılık gösterir. Bu nedenle yazılım için ‘one size fits all’ yaklaşımıyla katı süreçler tanımlamak işe yaramaz. Scrum gibi Kanban da farklı işlerde uygulanış biçiminde değişiklik gösterir. İkisini de çerçeve olarak adlandırmanın sebebi budur. Yazılım projelerinde hepimiz Jira gibi araçların da yardımıyla iş ögelerinin akışlarını yönetmeye çalışıyoruz. Bu akışın başlangıcında bir iş talebi ve sonunda da bu işin teslimatı söz konusu. Kanban’ın amacı bu akışın kaynak verimliliği ve etkinliğini gözetmek, daha iyi performans için iyileştirme gereken noktalara odaklanmak. Bunu sağlamak için 3 temel pratiği bulunuyor:

• İş akışını tanımlamak ve herkese açık biçimde görselleştirmek,
• İş akışındaki talepleri aktif olarak yönetmek,
• İş akışını iyileştirmek.

Pratiklerde de gördüğümüz gibi Kanban’ın odağında akış var. Akışı potansiyel bir değerin sistem içindeki hareketi olarak da düşünebiliriz. Yazılım özelinde düşünecek olursak, bir kullanıcı hikayesi, iyileştirme veya gereksinim değişikliği talebi bizim için birer değerdir. Nihai hedef bu akışı iyileştirmek. Bunun anlamı ise çıktıyı maksimize etmek değil, kaynakları da göz önünde bulundurarak kimseye kaldırabileceğinden fazla iş yüklemeden daha dengeli bir akış oluşturmak.

Pull vs. Push

Tipik iş akışlarında talep genelde sonraki aşamaya doğrudan aktarılır (push). Kanban ise bundan farklı olarak pull sistemiyle çalışıyor. Yani ilgili aşamada kapasite uygunsa talep alınıyor. Burada amaç aşırı yüklenmeleri engellemek ve dar boğazları görerek buna çözüm bulmak. Örneğin tipik bir kullanıcı hikayesinin kodlanmasının sonrasında test aşamasına geçmek istiyoruz. Kullanıcı hikayesini bu durumda doğrudan test aşamasına alamıyoruz, test aşamasında kapasite uygunsa talep bu aşamaya çekilebiliyor. Test aşamasında boş slot olduğunda bir önceki aşamaya bununla ilgili bir sinyal gönderiyor. Bunun için WIP (Work in Progress) Limitlerini kullanıyoruz. Yani her bir aşamanın aynı anda devam edebilecek iş kapasiteleri belirleniyor. Yani test aşamasında WIP limitimiz 10 ise ve hali hazırda devam eden 10 iş varsa, test aşamasında yeni talep çekilemiyor. WIP limitler Kanban’ın olmazsa olmazı. Bir timebox’ın olmaması, conitinuous flow şeklinde çalışılması Kanban Sistemi için yeterli değil.

DoW(Definition of Workflow)

Kanban Sistemi oluşturulurken ilk aşamada iş akışını tanımlamak gerekiyor. Burada ilk cevaplanması gereken soru: İş akışımızdaki talep tipleri neler? Bunlar kullanıcı hikayeleri, iyileştirme talepleri, gereksinim değişiklikleri, hatalar gibi talepler olabilir. Sonraki aşamada bu taleplerin her birinin akış içindeki aşamalarını belirlemek gerekiyor. Farklı iş talep türleri için farklı akışlar oluşturulabilir. Örnek bir iş akışı aşağıda. Yazılım projelerinde çalışanlar için oldukça tanıdık bir akış.

Şekil 1: Örnek İş Akışı

Product Backlog’a aynı Scrum’da olduğu gibi Kanban’da da ihtiyaç duyuyoruz. Önceliklendirilmiş bir talep listesinin elimizde bulunması lazım. Bunun için Product Owner rolünün Kanban’da da olması tavsiye ediliyor. Product Owner rolüne İş Analisti rolündeki kişiler destek verebilir. Backlog’daki talebi gerçekleştirebilmek için işin detaylarının analiz edilerek alt parçalara bölünmesi lazım (Detaylandır). Sonraki aşamalar ise standart yazılım geliştirme döngüsü aşamaları (Gerçekleştir — Doğrula — Teslim Et). Burada WIP (Work in Progress) olarak tanımlayabileceğimiz aşamalar ise Detaylandır, Gerçekleştir ve Doğrula aşamaları. Diğer 2 aşama işin başlangıç ve bitiş aşamaları. İş akış(lar)ı tanımlandıktan sonra doğal olarak bunun tüm ekibe görünür duruma getirilmesi gerekiyor. Agile ve Lean’de high touch — low tech ürünler teşvik edildiğinden duvarda büyük bir poster üzerinde post-it kağıtlar kullanılabilir. Jira vb. araçlardan da beraberinde faydalanılabilir.

İş Akışının Yönetilmesi

İş akışı tanımlandıktan sonra aşamaları takip edebilmek için aşamada devam eden ve aşamayı tamamlamış işlerin de ayrımını yapmamız gerekiyor. Bunun için ilgili akış aşamalarında aşağıdaki gibi 2 ayrı kolon daha ekliyoruz:

Şekil 2: WIP ve Done

Bu ayrımı yaparak sonraki aşamada kapasite uygun olduğu takdirde hangi taleplerin çekilebileceğini belirtmiş oluyoruz (Kodlama Tamamlandı, Test aşamasına hazır gibi). Böylece aşama içinde 2 ayrı durumumuz oluyor. Bunun için de Definition of Done(DoD) yani tamamlanma kriterlerini belirlemeye ihtiyacımız var. Aynı zamanda Pull Kriteri olarak da adlandırabiliriz. Örneğin yukarıdaki 3 aşama için tamamlanma kriterlerimiz aşağıdaki gibi olabilir. Bu kriterleri sağlamayan talepler bir sonraki aşamaya geçemezler. Bu da ürünün kalitesini garanti altına almaya ve reworkü azaltmaya yöneliktir.

• Detaylandır(Analiz Et): Backlog’daki öge, spesifikasyonu kodlamaya hazır detayda olmalı ve en fazla 5 iş gününde tamamlanabilecek alt görevlere bölünmelidir.
• Gerçekleştir(Kodla): Kod yazılmış, tüm birim testleri geçmiş, commit işlemleri tamamlanarak başarılı bir build alınmış ve entegrasyon testleri de başarıyla geçmiştir.
• Doğrula(Test): Son kullanıcı testleri başarıyla tamamlanmış ve spesifikasyonlarda belirtilen kriterlerin karşılandığı doğrulanmıştır. Bulunan tüm hatalar giderilmiştir.

Gelelim Kanban’ın en ilginç prensibi olan WIP Limitlerine. Kanban’da limitler nasıl çalışıyor?

• Bir kişi aynı anda sadece ve sadece bir iş üzerinde çalışır.
• Bir kişi elindeki işi tamamlamadan yeni bir iş almaz.
• Her bir aşamada yer alabilecek en fazla iş sayısı WIP limitlerle belirlenir. Bunlara sıkı sıkıya bağlı kalınır ve WIP limitine erişildiyse, yeni bir talep çekilmez.
• Bu yolla ekip verimliliği ve performansı artırılır, dar boğazlar daha kolay tespit edilir(kümülatif akış diyagramları ve kanban board yardımıyla) ve teslim süreleri(lead time) kısaltılır.

Birden fazla işi paralel yürütmeye çalıştığımızda verimimizin düştüğüne çoğu zaman şahit olmuşuzdur. Yukarıdaki prensiplerle daha sürdürülebilir bir akış hedeflenir. Günlük olarak Kanban Board’u veya kümülatif akış diyagramları gibi araçlar üzerinden gözlem yapılır. Scrum’da günlük toplantılarda Sprint ilerleyişi ve problemler gündemde olurken, Kanban’da günlük toplantılarda görsel araçlar üzerinde darboğazlar, bloke işler tespit edilir ve çözüm üretilmeye çalışılır.

Örneğin; 6 kişilik bir ekibin bir zaman diliminde aşağıdaki aşamalarda çalıştığını varsayalım.

Şekil 3: Darboğazların Tespiti

Yukarıdaki örnekte işin nerede biriktiğini görüyoruz? Gerçekleştirmesi tamamlanmış işler Doğrula aşamasına geçmek için bekliyorlar. Sayıları da artıyor görünüyor.

• Doğrula aşamasında WIP limitine erişilmediyse yani kapasite uygunsa bu işler Doğrula aşamasına aktarılabilir.
• WIP limitine erişildiyse, eldeki iş(ler)in bitmesi beklenebilir.
• Buna rağmen Kodlama aşamasında Done durumdaki işler artıyorsa, burada kaynakla ilgili çözülmesi gereken hususlar olma ihtimali yüksektir. Kodlama’nın ritmi iyi göründüğü için, Doğrula aşamasına buradan bir miktar kaynak aktarımı yapılabilir.

WIP limitler yardımıyla darboğazlar ve bloke işler görünür kılınıyor. Aynı zamanda ekibin genel verimliliği de odaklı çalışmaları sağlanarak artırılıyor.