Agile ve Scrum

02-13 manifestoyu ve Scrum sözlüğünü tanıttı, 9. ders Agile'ı model tablosuna yerleştirdi. Bu ders işleyişi anlatır: on iki ilke, Scrum'ın üç sorumluluğu, beş olayı ve üç artefaktı — her birinin neden var olduğuyla; backlog'un nasıl yazılıp tahmin edildiği; Kanban'ın akış matematiği; XP'nin Scrum'a eklediği mühendislik pratikleri; ölçekleme ve en sık yapılan hatalar. İlan B "Agile/Scrum metodolojileri"ni ayrı madde olarak sayar; sözlüde "Scrum'ı anlatın" sorusu roller-olaylar-artefaktlar ezberi değil, "daily neden 15 dakika, velocity neden hedef değil, sprint ortasında kapsam neden değişmez" düzeyinde cevap bekler. Ders, 02-13'ün hibrit cümlesini kamu sözleşmesi gerçeğiyle kapatır.

01Ne öğreneceksin

02Manifesto: dört değer, on iki ilke

2001'in dört değeri 02-13'te: bireyler ve etkileşimler, çalışan yazılım, müşteriyle iş birliği, değişime yanıt — her biri "X'ten çok Y" kalıbıyla. Manifestonun asıl işletilebilir kısmı on iki ilkedir; ezber için dört gruba toplanabilir:

• Teslim: (1) en yüksek öncelik, değerli yazılımın erken ve sürekli teslimiyle müşteriyi memnun etmek; (3) çalışan yazılımı sık teslim etmek — haftalar, aylar değil; (7) ilerlemenin birincil ölçüsü çalışan yazılımdır.
• Değişim ve iş birliği: (2) geç aşamada bile değişen gereksinim hoş karşılanır; (4) iş tarafı ve geliştiriciler her gün birlikte çalışır; (6) en verimli iletişim yüz yüzedir.
• İnsan ve sürdürülebilirlik: (5) motive bireyler, ortam ve güven; (8) sürdürülebilir tempo — sonsuza kadar korunabilecek hız; (11) en iyi mimari ve tasarım öz-örgütlenen ekiplerden çıkar.
• Teknik mükemmellik ve sadelik: (9) teknik mükemmelliğe ve iyi tasarıma sürekli özen çevikliği artırır; (10) sadelik — yapılmayan işi en üst düzeye çıkarma sanatı; (12) düzenli aralıklarla ekip nasıl daha etkili olacağını düşünür ve ayarlar.

Kıdemli okuma: Agile bir yöntem değil, bir değerler ve ilkeler kümesidir; Scrum, XP, Kanban bu ilkeleri işleten çerçevelerdir. "Agile yapıyoruz" cümlesi tek başına hiçbir şey söylemez; "iki haftalık sprint, çalışan artım, retrospektifte çıkan üç eylem" söyler. Dokuzuncu ilke en çok atlanandır ve 06. bölümün konusudur: teknik pratik olmadan Agile, hızla çöp üreten bir süreçtir.

03Scrum çerçevesi

Scrum, ampirik süreç kontrolüne dayanır: karmaşık işte önceden plan yapmak yerine kısa döngülerde şeffaflık → denetim → uyarlama. Her olay bu üçlünün bir uygulamasıdır; bir olayı "gereksiz" bulup atan ekip, denetim ya da uyarlama fırsatını atmış olur. Beş değer (adanmışlık, odak, açıklık, saygı, cesaret) çerçevenin insan tarafıdır. Yapı üç sorumluluk, beş olay, üç artefakttır:

Üç artefakt, 2020 rehberiyle birer taahhüde bağlandı — artefakt "şey", taahhüt "ona karşı ölçülen hedef": Product Backlog ↔ Ürün Hedefi (uzun vadeli hedef; backlog yalnızca ona hizmet eden sıralı listedir), Sprint Backlog ↔ Sprint Hedefi (bu sprint'in tek cümlelik amacı; maddeler değişebilir, hedef değişmez), Increment ↔ Definition of Done (artım ancak DoD'yi karşılıyorsa vardır; karşılamıyorsa gösterilmez, backlog'a döner). Sprint'te birden fazla artım üretilebilir ve dağıtılabilir — "sprint sonu = dağıtım" zorunlu değildir, 7. dersin trunk-based ritmiyle her PR bir artım olabilir.

04Backlog: yazmak, tahmin etmek, izlemek

Kullanıcı hikâyesi backlog maddesinin yaygın biçimidir: "Aday olarak, başvuru durumumu görmek istiyorum, böylece kurumu aramak zorunda kalmam." Üç parça — kim, ne, neden — ve "neden" yine en önemlisidir: PO neden'i söyleyemiyorsa madde backlog'da değildir. Hikâye bir konuşma vaadidir, spesifikasyon değil; ayrıntı, 9. dersin Given/When/Then kabul kriteriyle hikâyeye iliştirilir. İyi hikâyenin ölçütü INVEST: bağımsız, müzakere edilebilir, değerli, tahmin edilebilir, küçük, test edilebilir. Hiyerarşi: epic (aylar) → feature → hikâye (sprint'e sığar) → görev (saatler; sprint backlog'un "nasıl" kısmı). Teknik borç ve mimari iş de backlog'a girer (15-11: kayıtlı borç), aksi hâlde hiç yapılmaz; iyi ekipler kapasitenin bir dilimini buna ayırır.

Refinement (backlog düzenleme) bir olay değil, sürekli etkinliktir: PO ve geliştiriciler yaklaşan maddeleri böler, netleştirir, tahmin eder — kapasitenin kabaca %10'u. Planlamaya giren madde DoR'yi (Definition of Ready: kabul kriteri var, tahmin var, bağımlılık yok) karşılamalı; hazır olmayan madde planlamayı analiz toplantısına çevirir.

Tahmin: story point. Saat değil, göreli büyüklük — belirsizlik, çaba ve risk birlikte; Fibonacci benzeri ölçek (1, 2, 3, 5, 8, 13) çünkü büyüdükçe belirsizlik büyür ve "13 mü 14 mü" tartışması anlamsızdır. Planning poker: herkes aynı anda kart açar, uçlar (en düşük ve en yüksek) gerekçesini anlatır, yeniden oylanır — amaç sayı değil, uçların ortaya çıkardığı gizli varsayımdır. Referans hikâye ile ölçek sabitlenir. Velocity = sprint başına tamamlanan (DoD'yi geçen) point toplamı; birkaç sprint ortalaması, sonraki sprint'e ne kadar çekileceğinin ölçüsüdür. Üç kural: ekibe özgüdür, ekipler arası kıyaslanamaz (ölçekler farklı); hedef değil tahmin aracıdır — hedef yapılırsa point enflasyonu başlar; ve yarım iş sayılmaz. Burndown (kalan point ↓ gün) sprint içindeki gidişi, burnup (tamamlanan ↑ ve toplam kapsam çizgisi) kapsam değişimini gösterir — burnup'ta kapsam çizgisi yukarı kayıyorsa ekip yavaş değil, iş büyüyordur.

DoD ekibin kalite sözleşmesidir ve yazılıdır; tipik: kod incelendi (8. ders), birim ve entegrasyon testleri yeşil, CI geçti, analizör temiz (15-10), kabul kriterleri doğrulandı, doküman ve changelog güncellendi (11. ders), UAT ortamına dağıtıldı, güvenlik kontrol listesi (14-09) işaretlendi. DoD sprint sonunda değil, her madde için uygulanır; "kod bitti, test sonra" DoD ihlalidir.

05Kanban: akış ve WIP limiti

Kanban sprint tanımaz; işi akış olarak yönetir. Pano sütunları iş akışının adımlarıdır (Bekliyor → Analiz → Geliştirme → İnceleme → Test → Bitti), tek kural her sütuna WIP limiti koymaktır: "İnceleme"de en fazla 3 madde. Limit dolunca yeni iş çekilemez; ekip yeni işe başlamak yerine tıkanan işi bitirmeye gider — "başlamayı bırak, bitirmeyi başlat". Bunun matematiği Little yasasıdır:

ortalama lead time = ortalama WIP / ortalama throughput
   12 açık madde, haftada 4 madde bitiyor  →  lead time ≈ 3 hafta
   WIP 6'ya indirilirse (aynı throughput)  →  lead time ≈ 1,5 hafta

Yani teslim süresini kısaltmanın en ucuz yolu daha hızlı çalışmak değil, daha az işi aynı anda açık tutmaktır; 8. dersin "PR'lar inceleme bekliyor" darboğazı tam bir WIP sorunudur. Metrikler: lead time (talepten teslime), cycle time (işe başlamadan teslime), throughput, ve kümülatif akış diyagramı (sütun başına iş sayısının zamana göre yığılı grafiği — bant genişleyen sütun darboğazdır). Hizmet sınıfları: acil (expedite) şeridi WIP limitini aşabilir ama tek maddelik; sabit tarihli; standart; müdahalesiz.

İkisi birbirini dışlamaz: Scrumban sprint ritmini korur, WIP limiti ve akış metriklerini ekler; bakım ekibi Kanban, ürün ekibi Scrum kullanabilir. 15-11'in bakım işi, tanımı gereği Kanban'a daha uygundur.

06XP: Scrum'ın söylemediği mühendislik

Scrum rehberi tek satır kod pratiği içermez; bilerek — süreç çerçevesidir. Manifestonun dokuzuncu ilkesini işleten çerçeve Extreme Programming'dir ve pratikleri bu müfredatın önceki hatlarında zaten öğrenildi: TDD (15-05), sürekli entegrasyon (3. ders, 7. ders, 18. hat), refactoring (4-14), eş programlama (8. dersin inceleme yükünü hafifletir), kolektif kod sahipliği (herkes her dosyaya dokunabilir — CODEOWNERS bunun "kim bakmalı" kısmıdır, "kim dokunabilir" kısmı değil), küçük sürümler, basit tasarım (YAGNI), kodlama standartları (15-10 makineye verildi), sürdürülebilir tempo, müşteri ekipte. Cümle: "Scrum süreç, XP mühendislik." İki haftada bir artım vaat eden ekip test otomasyonu ve CI olmadan bunu ancak birkaç sprint sürdürür; sonra her sprint'in sonu elle test haftasına döner ve "Agile bizde işlemedi" denir. İşlemeyen Agile değil, eksik bırakılan mühendislik katmanıdır.

07Ölçekleme ve yaygın hatalar

Tek Scrum Team on kişiyi geçmez; daha büyük iş birden fazla ekip ister ve ekipler arası bağımlılık sorunu doğar. Çözümler ölçekleme çerçeveleridir: Scrum of Scrums (ekip temsilcilerinin günlük eşitlemesi), Nexus (3-9 Scrum ekibi, tek backlog, entegrasyon ekibi), LeSS (tek PO, tek backlog, çok ekip; Scrum'ı büyütür), SAFe (portföy/program/ekip katmanları; büyük kurumlarda yaygın, ağırlığıyla eleştirilir). Kıdemli tavır: ölçeklemeden önce bağımlılığı azaltmak — ekipleri bileşene değil değer akışına göre kurmak (19. hattın servis sınırları burada örgüt sınırı olur; Conway yasası).

08Agile'ın kamu projesinde sınırı

02-13 ve 9. dersin hibrit cümlesini burada kapatalım. Kamu alımının doğal biçimi sabit kapsam + sabit fiyat + sabit süredir: şartname kapsamı, sözleşme bedeli ve teslim tarihini önceden bağlar. Agile'ın ikinci ilkesi ("geç aşamada bile değişen gereksinim hoş karşılanır") bununla doğrudan çelişir — üçü de sabitse değişime yer yoktur. Çözüm, üçlünün tamamını değil birini esnetmektir ve dört yerleşik yol vardır:

1. Zaman ve bütçe sabit, kapsam esnek. Şartname "olmazsa olmaz" çekirdeği (MoSCoW: must / should / could / won't) sabitler; should ve could maddeleri sprint'lerde değere göre sıralanır. Kabul, must'lar üzerinden yapılır.
2. Kilometre taşlı hibrit. Analiz ve tasarım onayı kapı, geliştirme sprint'lerle, her sprint review'una kurum temsilcisi katılır ve tutanak tutulur — şartnameye "iki haftalık sprint review toplantısı" maddesi yazılır. UAT kabulden aylar önce başlar (9. ders).
3. Çerçeve sözleşme / sprint bazlı alım. Belirli sprint ya da adam-gün kapasitesi satın alınır, içerik PO'nun backlog'uyla belirlenir; kamuda hizmet alımı olarak mümkündür, denetim kaygısıyla daha az tercih edilir.
4. İç ekip. Kurumun kendi geliştirici ekibi (iki ilanın ta kendisi) ihale kısıtından bağımsızdır; Scrum burada saf hâliyle uygulanabilir ve PO kurumun iş birimi olur — kamu Agile'ının en verimli biçimi.

Sınır dürüstçe söylenmeli: kabul komisyonu, garanti ve denetim mekanizmaları yazılı ve sabit kanıt ister; Agile'ın "kapsamlı dokümantasyondan çok çalışan yazılım" değeri kamu tesliminde "çalışan yazılım ve yeterli doküman" olarak okunur (11. ders). Sözlüde "kurumda Scrum uygular mısınız" sorusuna cevap: "İç ekipte evet, saf; ihaleli projede kilometre taşlı hibrit — ve şartnameyi baştan buna göre yazarım."

09Mini alıştırma — bir sprint, tek kişilik prova

10Kendini sına

Scrum'ın sorumlulukları, olayları ve artefaktları nelerdir? Her olayın zaman kutusu ve var olma nedeni nedir?

Temel: ampirik süreç kontrolü — şeffaflık, denetim, uyarlama; beş değer. Sorumluluklar: Product Owner (ürün hedefi ve backlog'un tek yetkili sahibi; komite değil; "hayır" diyebilir), Scrum Master (Scrum'ın işlemesi, engel kaldırma, koçluk; proje yöneticisi değil, görev dağıtmaz), Developers (her sprint'te DoD'yi karşılayan artım; çapraz işlevli, öz-yönetimli); toplam ≤10. Olaylar: Sprint (≤1 ay, sabit; kapsam sprint içinde sabit, yalnız PO iptal eder), Sprint Planlama (≤8 saat/aylık; neden-ne-nasıl; taahhüt hedefe, kapasiteye göre çekilir), Daily (15 dk; geliştiricilerin günü planlaması, rapor değil), Review (≤4 saat; artımı göstermek, geri bildirim, backlog uyarlamak; çalışma toplantısı), Retrospective (≤3 saat; süreç/araç/DoD iyileştirme; çıktısı sahipli eylem). Artefaktlar ve taahhütleri: Product Backlog ↔ Ürün Hedefi; Sprint Backlog ↔ Sprint Hedefi (maddeler değişebilir, hedef değişmez); Increment ↔ Definition of Done (DoD'yi karşılamayan artım yoktur, gösterilmez). Sprint içinde birden fazla artım dağıtılabilir; sprint sonu = dağıtım zorunlu değildir.

Kullanıcı hikâyesi nasıl yazılır; INVEST nedir? Story point neden saat değildir, velocity neden hedef olamaz? DoD ile DoR farkı nedir?

Hikâye: "X olarak, Y istiyorum, böylece Z" — kim, ne, neden; neden söylenemiyorsa madde backlog'da değildir; hikâye konuşma vaadidir, ayrıntı Given/When/Then kabul kriteriyle iliştirilir. INVEST: bağımsız, müzakere edilebilir, değerli, tahmin edilebilir, küçük, test edilebilir. Hiyerarşi epic → feature → hikâye → görev; teknik borç da backlog'a girer. Story point göreli büyüklüktür — belirsizlik, çaba ve risk birlikte; Fibonacci ölçeği çünkü büyüdükçe belirsizlik büyür; planning poker'ın amacı sayı değil, uç tahminlerin ortaya çıkardığı gizli varsayım; referans hikâyeyle ölçek sabitlenir. Velocity = sprint'te DoD'yi geçen point toplamı; ekibe özgüdür, ekipler arası kıyaslanamaz; tahmin aracıdır — hedef yapılırsa point enflasyonu başlar; yarım iş sayılmaz. Burndown sprint içi gidişi, burnup kapsam değişimini gösterir. DoD: ekibin yazılı kalite sözleşmesi (inceleme, testler, CI, analizör, kabul kriteri, doküman, UAT dağıtımı, güvenlik listesi) — her madde için, sprint sonunda değil. DoR: maddenin planlamaya girmeye hazır olma ölçütü (kabul kriteri, tahmin, bağımlılık yok); refinement sürekli etkinliktir, kapasitenin ~%10'u.

Kanban nasıl çalışır; WIP limiti ve Little yasası neyi söyler? Scrum ile Kanban ne zaman seçilir? XP'nin Scrum'a eklediği nedir?

Kanban sprint tanımaz, işi akış olarak yönetir: pano sütunları iş akışı adımları, her sütuna WIP limiti; limit dolunca yeni iş çekilmez, tıkanan iş bitirilir. Little yasası: lead time = WIP / throughput — 12 açık madde ve haftada 4 bitiş ile 3 hafta, WIP 6'ya inince 1,5 hafta; teslim süresini kısaltmanın en ucuz yolu daha az işi aynı anda açık tutmaktır (PR inceleme darboğazı bir WIP sorunudur). Metrikler: lead time, cycle time, throughput, kümülatif akış diyagramı (genişleyen bant = darboğaz); hizmet sınıfları (expedite tek maddelik). Scrum: sabit ritim, roller, sprint içi sabit kapsam, velocity — ürün geliştirme ve planlanabilir iş; Kanban: sürekli akış, rol dayatmaz, her an değişiklik, akış metrikleri — işletim, bakım, destek gibi kesintili iş; Scrumban ikisini birleştirir. XP, Scrum'ın bilerek boş bıraktığı mühendislik katmanıdır: TDD, sürekli entegrasyon, refactoring, eş programlama, kolektif sahiplik, küçük sürümler, basit tasarım, kodlama standartları, sürdürülebilir tempo, müşteri ekipte — "Scrum süreç, XP mühendislik"; test otomasyonu ve CI olmadan iki haftalık artım birkaç sprint sürer, sonra sprint sonu elle test haftasına döner.

Scrum uygulamasında en yaygın hatalar nelerdir? Agile, sabit kapsam-sabit fiyat kamu sözleşmesiyle nasıl bağdaştırılır?

Hatalar: mini şelale (sprint'ler analiz-tasarım-kod-test sırasına dönüşür; düzeltme dikey dilim), rapor daily'si (yöneticiye anlatım; daily geliştiricilerin planlamasıdır), velocity'nin hedef yapılması (point enflasyonu; performans için akış/DORA metrikleri), DoD'siz "bitti" (testsiz iş review'da gösterilmez), komite PO (tek yetkili), eylemsiz retro (1-3 sahipli eylem backlog'a), sprint ortasında kapsam (acil iş için sabit pay ya da Kanban şeridi; hedef korunur), zombi Scrum (olaylar yapılır, hiçbir şey değişmez, artım dağıtılmaz). Ölçekleme (Scrum of Scrums, Nexus, LeSS, SAFe) öncesinde bağımlılığı azaltmak: ekipleri değer akışına göre kurmak. Kamu sözleşmesi doğal olarak sabit kapsam + fiyat + süredir ve "değişen gereksinim hoş karşılanır" ilkesiyle çelişir; çözüm üçlüden birini esnetmek: (1) zaman ve bütçe sabit, kapsam esnek — MoSCoW ile must çekirdeği şartnamede, should/could sprint'lerde; (2) kilometre taşlı hibrit — analiz/tasarım onayı kapı, geliştirme sprint'lerle, şartnameye sprint review maddesi, erken UAT; (3) çerçeve sözleşme / sprint bazlı kapasite alımı; (4) iç ekip — ihale kısıtından bağımsız, saf Scrum, PO iş birimi. Sınır: kabul, garanti ve denetim yazılı kanıt ister; "çalışan yazılım ve yeterli doküman" olarak okunur.

11Sınav köşesi