Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Flow Metric'leri: WIP, Throughput, Work Item Age ve Cycle Time
Kanban Guide'ın dört zorunlu metric'i olan WIP, Throughput, Work Item Age ve Cycle Time'ı Bookstore ekibinin altı aylık board verisinden bir .NET 10 console uygulamasıyla hesaplıyoruz. Ortalama yerine percentile kullanmayı, cycle time scatterplot ve aging chart okumayı, Work Item Age'in neden en erken uyarı olduğunu ve Created tarihinden hesaplamanın p85'i 14 günden 79 güne nasıl çıkardığını görüyoruz.
WIP Limit ve Little's Law: Daha Az İşe Başlayıp Daha Çok Bitirmek
Throughput sabitken WIP'i artırmak cycle time'ı aynı oranda uzatır; Little's Law bunun aritmetiğidir. C# ile yazdığımız simülasyonda WIP 3'ten 10'a çıkınca ortalama cycle time 2,4 günden 7,9 güne çıkıyor, context switching eklenince throughput da düşüyor. Little's Law'un varsayımlarını, neden tahmin aracı olmadığını, ilk WIP limit'ini belirlemeyi ve kişi başına limit gibi tuzakları konuşuyoruz.
Definition of Workflow ve Board Tasarımı: İş Ne Zaman Başlar, Ne Zaman Biter?
Board'u Kanban yapan, arkasındaki Definition of Workflow'dur: work item tanımı, started/finished noktaları, state'ler, WIP kontrolü, explicit policy'ler ve SLE. Bookstore ekibinin board'unu bu altı parçayla kuruyor, queue ve active state'leri ayırıyor, Done'ı merge yerine production deploy'una bağlamanın cycle time'ı nasıl değiştirdiğini ve sık yapılan board tasarımı hatalarını konuşuyoruz.
Kanban Nedir? Toyota'dan Yazılıma ve Board'dan Fazlası
Kanban bir board değil, WIP'i sınırlayarak value akışını optimize eden bir stratejidir; board yalnız onu görünür kılar. Toyota'nın pull sisteminden Anderson'ın Microsoft ve Corbis deneyimine, Kanban Method ile The Kanban Guide 2025.5 arasındaki farka, Guide'ın üç pratiğine ve dört flow metric'ine Bookstore destek ekibinin board'u üzerinden bakıyoruz.
Scrum'ın Evrimi: 1986 HBR Makalesinden Scrum Guide 2020'ye ve 2025 Expansion Pack'e
Scrum'ın resmi tanımı Kasım 2026 itibarıyla hâlâ Scrum Guide 2020; 2025'te Sutherland, Jocham ve Coleman'ın yayımladığı Expansion Pack (son sürüm v2026.1) Schwaber'ın imzasını taşımayan, resmi Guide'ın yerine geçmeyen bir ek. Yazı 1986 HBR makalesindeki rugby yaklaşımından 1995 OOPSLA sunumuna, 2010–2017 revizyonlarına ve 2020'nin Product Goal, commitment ve self-managing değişikliklerine uzanan yolu anlatıyor.
Scrum Anti-Pattern'leri: Dark Scrum, Zombie Scrum ve Mini-Waterfall Sprint'ler
Scrum anti-pattern'lerinin ortak noktası, event ve artifact'lar yerindeyken empiricism'in çalışmamasıdır. Yazı Dark Scrum, Zombie Scrum, ScrumBut, Sprint 0, hardening sprint, mini-waterfall ve taşan Sprint'leri belirti, kök neden, Guide'daki karşılığı ve ilk adımla bir tabloda topluyor; çoğunun kökünde büyük item'lar ve zayıf bir Definition of Done olduğunu gösteriyor ve ekipler için 10 soruluk bir teşhis listesi veriyor.
Scrum'da Teknik Pratikler: Branching, CI, Feature Flag ve Teknik Borç
Scrum mühendislik pratiği dayatmaz, ama her Sprint Definition of Done'ı karşılayan bir Increment ancak kısa ömürlü branch'ler, CI ve feature flag'lerle sürdürülebilir. Gerçek koşuda Microsoft.FeatureManagement 4.8.0 ile flag kapalıyken iade endpoint'i 404, açıkken 201 döndü; aynı build iki ortamda farklı davrandı. Yazı flag'in Definition of Done'ı neden delmediğini, teknik borcu görünür kılmanın üç yolunu ve spike'ı anlatıyor.
Scrum'da Metrikler: Velocity, Burndown ve Sprint Goal Başarısı Neyi Gösterir, Neyi Göstermez?
Scrum Guide hiçbir metrik tanımlamaz; velocity, burndown ve Sprint Goal başarısı ekibin kendi forecast'i için faydalı ama değeri göstermez. Gerçek bir C# koşusunda kapsamı Sprint ortasında 3 item büyüyen bir Sprint'in burndown'u dördüncü günde başlangıçla aynı 12'de duruyor, burnup ise ilerlemeyi ve kapsam değişikliğini ayrı gösteriyor. Yazı velocity'nin ekipler arası karşılaştırılmasını ve Goodhart yasasını da ele alıyor.
Sprint Review ve Sprint Retrospective: Ürünü ve Süreci Inspect Etmek
Sprint Review bir demo değil, stakeholder'larla Increment'i inspect edip Product Backlog'u adapt eden bir çalışma oturumudur; Retrospective ise bireyleri, süreçleri, araçları ve Definition of Done'ı inspect edip ölçülebilir bir iyileştirmeyi Sprint Backlog'a koyar. Yazı Bookstore'un 90 dakikalık Review gündemini, retro formatlarını ve code review beklemesini 2,1 günden 0,6 güne indiren bir aksiyonu anlatıyor.
Increment ve Definition of Done: "Bitti" Ne Demek?
Definition of Done, Increment'in commitment'ıdır: onu karşılamayan item ne release edilebilir ne de Sprint Review'da gösterilebilir, Product Backlog'a döner. Yazı bir .NET ve Angular ekibi için somut bir Definition of Done yazıyor ve maddelerini bir GitHub Actions workflow'una çeviriyor: adımların yerel koşusunda zafiyetli transitive bir paket build'i NU1903 hatasıyla kırdı, commit edilmemiş OpenAPI dokümanı git diff'te exit code 1 verdi.
Daily Scrum: 15 Dakikalık Plan Toplantısı, Status Raporu Değil
Daily Scrum, Developers'ın Sprint Goal'e ilerlemeyi inspect edip Sprint Backlog'u adapt ettiği 15 dakikalık bir planlama event'idir; çıktısı rapor değil, ertesi gün için uygulanabilir bir plandır. Yazı 2020'de üç sorunun neden kalktığını, board'u sağdan sola yürüyen ve item yaşına bakan formatı, remote ve hibrit ekip pratiklerini ve yöneticiye rapor, problem çözme ve süre aşımı tuzaklarını Bookstore ekibiyle anlatıyor.
Sprint ve Sprint Planning: Why, What, How ve Sprint Goal
Sprint bir aydan kısa, sabit uzunlukta bir event'tir; Sprint Planning ise why, what ve how sorularıyla Sprint Goal'ü ve Sprint Backlog'u üretir. Developers seçilen item listesine değil Sprint Goal'e commit olur; liste bir forecast'tir. Yazı iyi ve kötü Sprint Goal örneklerini, iptal yetkisinin neden yalnız Product Owner'da olduğunu ve Bookstore ekibinin brüt kapasitenin yüzde 72'sine inen gerçek kapasite hesabını gösteriyor.