Definition of Workflow ve Board Tasarımı: İş Ne Zaman Başlar, Ne Zaman Biter?

Sürüm notu: Bu yazı The Kanban Guide'ın 2025.5 sürümünü (ProKanban.org, Mayıs 2025) esas alır.

Önce Tahmin Et

Bookstore ekibinde Fix VAT rounding on invoice PDF başlıklı bir bug kaydı var. Fatura PDF'indeki KDV (katma değer vergisi) kuruş yuvarlaması hatalı. Bir geliştirici işi pazartesi sabahı alıyor, salı akşamı PR'ını (pull request) açıyor, review çarşamba bitiyor, tester perşembe onaylıyor ve PR cuma öğleden sonra main branch'e merge ediliyor. Ekip production'a yalnız salı ve perşembe deploy ediyor; düzeltme bir sonraki salı müşteriye ulaşıyor.

Ekipten biri bu işin bir haftada bittiğini söylüyor, bir diğeri sekiz günde. İkisi de board'a bakarak konuşuyor. Hangisi haklı? Daha önemlisi: müşteri açısından hatanın düzeltildiği an hangisi, ve ekip "bitti" kelimesini hangi ana bağlarsa ölçtüğü cycle time gerçeği söyler?

Definition of Workflow: Guide'ın İstediği Altı Parça

Bir önceki yazıda board'un tek başına Kanban olmadığını, arkasında bir Definition of Workflow (DoW) olması gerektiğini söyledik. The Kanban Guide DoW'u ekibin işin sistemde nasıl aktığına dair ortak anlayışı olarak tarif eder ve en az şu altı parçayı ister: ekibin takip ettiği value biriminin, yani work item'ın tanımı; işin ne zaman başlamış ve ne zaman bitmiş sayılacağı; bu iki nokta arasında item'ın geçtiği state'ler; WIP'in (Work in Progress) nasıl kontrol edileceği; item'ların state'ler arasında nasıl hareket edeceğini söyleyen explicit policy'ler; ve bir SLE (Service Level Expectation).

Guide bu parçaların hangi sırayla kurulacağını önemsemez; önemli olan hepsinin yerinde olmasıdır. 2025.5 sürümünde SLE de bu listenin içine alındı, yani artık "sonra bakarız" denebilecek bir ek değil, DoW'un parçası. Bookstore ekibinin her parça için verdiği karar şöyle:

Work Item: Neyi Sayıyoruz?

İlk karar en kolay görüneni: board'daki bir kart neyi temsil ediyor? Bookstore ekibi bunu "tek başına production'a çıkabilen değişiklik" olarak tanımladı. Bu tanımın iki sonucu var. Birincisi, "Gift card desteği" gibi haftalar sürecek bir epic board'a tek kart olarak girmez; önce production'a ayrı ayrı çıkabilecek parçalara bölünür. İkincisi, "Unit test yaz" ya da "PR'ı review et" gibi bir item'ın parçası olan görevler ayrı kart değildir; onlar item'ın içinden geçtiği state'lerdir.

Bu neden önemli? Çünkü dört flow metric'in hepsi item sayar. Throughput "bu hafta kaç item bitti" sorusudur; bir haftada bitirilen üç epic ile otuz alt görev aynı birimle ölçülürse sayı hiçbir şey söylemez. Item'ların birebir aynı boyutta olması gerekmez, ama aşağı yukarı aynı türde olması gerekir. Boyut farkının tahmine etkisini 05. yazıda konuşacağız.

Started ve Finished: Çizgiyi Nereye Çekiyoruz?

Baştaki sorunun cevabı bu iki karara bağlı. Bookstore ekibi "started" noktasını, bir geliştiricinin item'ı Ready'den In Dev'e çektiği an olarak koydu. Ready kolonu ekibin "bunu yapacağız" dediği ama henüz kimsenin dokunmadığı işlerin listesi; bir item'ın orada beklemesi ekibin taahhüdünden önceki süre olduğu için cycle time'a girmiyor. Jira'da kaydın açıldığı an (created) ise hiç başlangıç değildir; bir bug kaydı başlanmadan önce aylarca backlog'da bekleyebilir. Bunun ölçümü nasıl bozduğunu 04. yazıda gerçek sayılarla göreceğiz.

"Finished" noktası daha tartışmalı. Merge anını bitiş saymak cazip, çünkü geliştiricinin işi orada bitmiş gibi hissedilir. Ama müşteri açısından KDV hatası, düzeltme production'a çıkana kadar düzelmemiştir. Bookstore ekibi bu yüzden finished noktasını production deploy'u ve ardından geçen smoke test olarak koydu. Bu kararla baştaki işin cycle time'ı pazartesiden bir sonraki salıya, yani bitiş - başlangıç + 1 konvansiyonuyla 9 gündür; merge'ü bitiş saysaydı 5 gün çıkacaktı. Aradaki 4 gün yok olmuyor; yalnız ölçümden çıkmış oluyor. Ekibin haftada iki kez deploy etmesinin bedeli tam olarak bu 4 gün ve ancak ölçülürse tartışılabilir.

Guide bu noktaların nereye konacağını söylemez; ekibin seçimine bırakır. Söylediği tek şey açık olmalarıdır. Burada kritik olan, çizgiyi değer müşteriye ulaştığında çekmek ve bir kere çektikten sonra her item için aynı çizgiyi kullanmak.

State'ler: Queue ile Active'i Ayırmak

Başlangıç ve bitiş arasındaki state'ler ekibin gerçek çalışma biçimini yansıtmalı. Bookstore ekibinin board'u şöyle:

Görseldeki board Ekim sonundaki hâli. Kolonların iki türü var. Active state'lerde biri item üzerinde iş yapıyor: In Dev'de kod yazılıyor, Code Review'da PR okunuyor, Test'te tester senaryoları deniyor. Queue state'lerde ise iş yalnız bekliyor: Ready'deki item birinin çekmesini, Ready to Deploy'daki item salı ya da perşembe deploy'unu bekliyor. Bu ayrımı board'da açıkça görmek önemli, çünkü bekleme süresi queue state'lerde birikir ve çoğu ekip bunu fark etmez. Cycle time'ın büyük kısmı çoğu zaman birinin çalıştığı süre değil, işin beklediği süredir.

Code Review kolonu ilginç bir örnek: içinde hem "review'u bekleyen" hem de "review'u yapılan" PR'lar var. Ekip başta bunu tek kolon olarak bıraktı. 06. yazıda Code Review'daki bekleme sorununu verisiyle konuşurken bu kolonu "Waiting for Review" ve "In Review" diye ikiye ayırmanın ne zaman mantıklı olduğunu tartışacağız. Kural basit: bir state'i ancak ölçmek istediğin bir bekleme ya da iş varsa ayrı kolon yap.

WIP Kontrolü: Sayı, Şerit ya da Başka Bir Biçim

Guide WIP'in açıkça kontrol edilmesini ister, ama 2025.5 sürümünde bunun biçimi konusunda daha esnektir: illa kolon başına bir sayı yazmak zorunlu değil. Kişi başına avatar sayısı, toplam limit, kolon grupları için ortak limit gibi biçimler de olur; şart, kontrolün board'da görünür olması ve istisnaların DoW'da yazılı olması.

Bookstore ekibi Mayıs'ta board'u kurduğunda kolon limit'i koymadı; yalnız started ile finished arasındaki toplam için 14 sınırı yazdı. Bu sayı keyfi değildi: Kanban'a geçmeden önceki eski board'da, 01. yazının başındaki o board'da, In Progress kolonunda ortalama 13–14 kart duruyordu; ekip bugünkü durumdan başlamayı seçti. Bu limit pratikte neredeyse hiç devreye girmedi ve Haziran–Ağustos arasında Code Review kolonunda iş birikti. Eylül'de ekip limit'leri sıkılaştırdı: In Dev 5, Code Review 3, Test 3 ve toplamda 12. Bu kararın gerekçesini 03. yazıda Little's Law ile, sonucunu 06. yazıda verisiyle göreceğiz.

Board'un altındaki pembe şerit expedite şeridi: "checkout'ta kartla ödeme çalışmıyor" gibi aynı gün çözülmesi gereken işler için. Bu şeridin kendi kuralı var ve o kural da DoW'un parçası.

Explicit Policy'ler: Kimin Kafasında Değil, Board'da

Policy, item'ın bir state'ten diğerine nasıl geçeceğini söyleyen kuraldır. "Açık" olması, yazılı ve herkesin görebileceği bir yerde durması demek. Bookstore ekibinin board açıklamasına yazdığı policy'ler:

• Pull: Kapasiten açıldığında önce sağdaki kolonlara bak; bitirmeye yakın bir işe yardım edebiliyorsan yeni iş çekme. Yeni iş çekeceksen Ready'nin en üstündekini al.
• Code Review: Bir PR Code Review'da en fazla 1 iş günü bekler; dolmuşsa en yaşlı PR'ı alan kişi o gün yeni iş başlatmaz.
• Test: Item Test'e ancak PR merge edilmiş ve CI (Continuous Integration) pipeline'ı yeşilse geçer.
• Blocked: Dış bir sebeple duran item'a blocked etiketi ve sebebi yazılır; blocked item kolonundan çıkmaz ve WIP'e sayılmaya devam eder.
• Expedite: Aynı anda en fazla 1 expedite item olur, toplam WIP'e dahildir; onu ilk boşalan kişi alır.
• Done: Değişiklik production'da, smoke test geçti ve ilgili destek kaydı müşteriye bildirildi.

Bu listede iki şey dikkat çekmeli. Birincisi, policy'ler davranış tarif ediyor; "hızlı çalış" gibi bir temenni yok. İkincisi, blocked item'ı ayrı bir "Blocked" kolonuna taşımak yerine bulunduğu kolonda etiketlemek bilinçli bir seçim: item hangi state'te takıldığını kaybetmesin ve WIP'ten düşmesin diye. Blocked item WIP'ten düşerse ekip onun yerine yeni bir iş başlatır ve board takılan işi gizlemeye başlar.

SLE: İlk Gün Tahmin, Sonra Veri

SLE, bir item'ın başlangıçtan bitişe ne kadar sürede gitmesinin beklendiğini bir süre ve bir olasılıkla söyler: "item'ların %85'i 14 gün içinde biter" gibi. Guide SLE'nin geçmiş cycle time verisinden hesaplanmasını ister, ama yeterli veri yokken makul bir tahminin kabul edilebilir olduğunu da söyler. Bookstore ekibi Mayıs'ta "%85 olasılıkla 10 gün" diye bir tahminle başladı. Altı aylık veriyle bu sayının 14 gün olduğu ortaya çıktı; nasıl hesaplandığını 04. ve 05. yazılarda göreceğiz.

SLE bir söz değil, bir beklenti. Ekip onu her sabah board'a bakarken kullanır: yaşı SLE'ye yaklaşan bir item, henüz bitmemiş olsa da dikkat ister. Guide'ın "item'ların gereksiz yere yaşlanmasını önlemek" pratiği tam olarak budur.

Üretimde Dikkat

DoW'u kâğıda yazmak yetmez, aracın da ona uyması gerekir. Jira'da her board kolonu bir ya da birkaç status'a bağlanır; "Code Review" kolonu "In Review" status'una bağlı değilse, geliştiriciler PR açtığında kart hiç hareket etmez ve state geçiş tarihleri yanlış kaydedilir. GitHub Projects'te de "Status" alanının değerleri board kolonlarıyla birebir eşleşmeli. Board'u kurduktan sonra birkaç kartı elle izleyip geçiş tarihlerinin doğru kaydedildiğini kontrol et.

İkinci nokta, DoW'u değiştirdiğinde ölçümün değişmesi. Finished noktasını merge'den deploy'a çektiğin gün cycle time'ın bir anda artar; bu, ekibin yavaşladığı anlamına gelmez. Böyle bir değişikliğin tarihini not et ve metric'leri karşılaştırırken o tarihin iki yanını ayrı oku.

Üçüncüsü, birden fazla DoW. 2025.5 sürümü bir ekibin ya da organizasyonun kaç DoW tutacağına alt ya da üst sınır koymaz; flow'u value'ya bağlamak gereken her yerde bir DoW kurulabilir. Bookstore'da ekip seviyesindeki board'un yanında, birkaç ekibin epic'lerini izleyen ikinci bir board, kendi started/finished noktaları ve kendi SLE'siyle ayrı bir DoW'dur. İkisinin item'larını aynı throughput sayısında toplamak, iki farklı birimi toplamaktır.

Sık Düşülen Tuzaklar

İlk tuzak her ara adımı kolon yapmak. QA (Quality Assurance) ve UAT (User Acceptance Testing) adımlarını, bekleme hâllerini ve release notlarını ayrı ayrı kolon yapınca "Unit Test", "Integration Test", "Code Review Bekliyor", "Code Review", "QA Bekliyor", "QA", "UAT", "Staging", "Release Notes" diye uzayan bir board çıkar; kimsenin okuyamadığı bir haritaya dönüşür ve her kolon için ayrı WIP limit'i yönetmek imkânsızlaşır. Kolon, ancak ekibin konuşmak istediği bir bekleme ya da iş içeriyorsa hak edilir.

İkinci tuzak belirsiz Done. Bir geliştirici merge'ü, tester test onayını, ürün sahibi production'ı "bitti" sayıyorsa ekip aynı board'a bakıp üç farklı cycle time konuşur. Done'ı tek cümleyle yaz ve board'un en sağ kolonuna o cümleyi koy.

Üçüncüsü "Blocked" kolonu. Takılan işi ayrı kolona taşımak onu görünür yapıyor gibi gelir, ama iki bilgiyi birden kaybettirir: item'ın hangi state'te takıldığı ve hâlâ bir WIP yeri işgal ettiği. Etiket ve sebep, kolondan daha çok şey anlatır.

Dördüncüsü Ready'yi WIP'e saymak ya da tersine, Ready to Deploy'u saymamak. Started ile finished arasındaki her şey WIP'tir; aradaki queue state'leri saymazsan, işin en çok beklediği yerleri ölçümün dışına atmış olursun.

Küçük Bir Deneme

★☆☆ Kendi board'undaki her kolonun yanına "queue" ya da "active" yaz. Kaç kolonun içinde ikisi birden var? Bunlardan hangisinde bekleme süresini merak ediyorsun?

★★☆ Ekibine "bir iş ne zaman bitmiş sayılır?" diye ayrı ayrı sor ve cevapları yan yana koy. Cevaplar farklıysa, son tamamlanan beş item için merge tarihini ve production deploy tarihini çıkar; aradaki gün farkının ortalaması kaç?

★★★ Ekibin için bu yazıdaki tabloya benzer bir DoW tablosu ve en fazla altı maddelik bir policy listesi yaz. Her policy'nin bir davranış tarif ettiğinden ve ölçülebildiğinden emin ol; "hızlı review" yerine "en fazla 1 iş günü" gibi.

Board hazır, ama WIP limit'inin neden işe yaradığını henüz göstermedik. Bir sonraki yazıda Little's Law'u ve aynı ekibin WIP'i 3'ten 10'a çıkardığında cycle time'ın nasıl büyüdüğünü C# ile yazdığımız küçük bir simülasyonla göreceğiz.