Agile'ın 12 Prensibi: Geliştirici Gözüyle Tek Tek

Sürüm notu: Bu yazı agilemanifesto.org'daki "Principles behind the Agile Manifesto" sayfasını (2001) esas alır; prensipleri alıntılamak yerine kendi anlatımımızla özetliyoruz.

Önce Tahmin Et

Bookstore ekibinin son iki haftası şöyle geçti: Product Owner Sprint Planning'e gelemedi, ekip işleri kendi tahminiyle seçti. Bir geliştirici 2.400 satırlık bir pull request açtı ve review dört gün sürdü. Sprint'in ortasında müşteri bir değişiklik istedi ve "sprint kilitli" cevabını aldı. Son iki gün ekip gece yarısına kadar çalıştı, testlerin bir kısmı "sonra yazılacak" notuyla atlandı. Retrospective, iş yetişmediği için iptal edildi.

Tahmin et: bu iki haftada Agile Manifesto'nun 12 prensibinden kaçı çiğnendi? Üç mü, beş mi, daha fazlası mı? Sayarken bir şeye dikkat et: çiğnenen prensiplerin çoğu birbirine bağlı ve biri çiğnenince diğerleri de zincirleme düşüyor.

Prensipler Neden Var?

Manifesto'nun dört değeri neye öncelik verileceğini söylüyor; ikinci sayfadaki 12 prensip ise bu önceliklerin günlük işte neye benzediğini anlatıyor. Değerler soyut, prensipler daha somut ama yine de birer pratik değil. "Sık teslim et" bir prensip; iki haftalık sprint ya da günlük deploy onu uygulamanın yollarından biri.

12 prensibi tek tek ezberlemek yerine temalara ayırmak, hem hatırlamayı hem de birbirleriyle bağlarını görmeyi kolaylaştırıyor. Aşağıdaki tabloda prensipleri altı temada topladık ve her birini bir geliştiricinin günlük pratiğine bağladık:

Teslim ve Geri Bildirim: Prensip 1, 3 ve 7

Birinci prensip en yüksek önceliği değerli yazılımın erken ve sürekli teslimiyle müşteriyi memnun etmeye verir. Üçüncü prensip çalışan yazılımın birkaç haftadan birkaç aya uzanan aralıklarla, kısa olanı tercih ederek teslim edilmesini ister. Yedinci prensip de ilerlemenin asıl ölçüsünün çalışan yazılım olduğunu söyler.

2001'de "birkaç hafta" iddialı bir hedefti; bugün birçok web ekibi günde birkaç kez deploy ediyor. Ama prensip bir sayı değil, bir yön veriyor: kısa olanı tercih et. Geliştiricinin bu yöndeki en güçlü aracı küçük pull request. 2.400 satırlık bir PR dört gün review bekler, review eden kişi de ancak yüzeysel bakabilir. Aynı iş 150-300 satırlık beş PR'a bölünürse her biri aynı gün merge edilebilir ve hatalar daha küçükken bulunur. Bitmemiş bir feature'ı küçük parçalar hâlinde merge etmenin yolu feature flag: kod production'a gider ama kullanıcıya kapalı kalır.

Yedinci prensip, sprint review'da "yüzde 80 bitti" cümlesinin neden anlamsız olduğunu da açıklar. Çalışan yazılımda yüzde 80 yoktur; ya kullanıcı iade talebini oluşturabiliyor ya da oluşturamıyor.

Değişime Açıklık: Prensip 2

İkinci prensip, geliştirmenin geç aşamalarında bile değişen requirements'ı memnuniyetle karşılamayı ve değişimi müşterinin rekabet avantajı için kullanmayı söyler. Bu, "sprint kilitli" cevabının neden sorunlu olduğunu gösteriyor. Scrum'da sprint içinde Sprint Goal korunur, ama Product Backlog her zaman değişebilir ve sprint'in kapsamı Product Owner ile Developers arasında yeniden konuşulabilir. Bu mekaniğin ayrıntısı Scrum serisinin Sprint Planning yazısında.

Geliştirici açısından bu prensibin asıl anlamı teknik: değişikliği memnuniyetle karşılamak, ancak değişiklik ucuzsa mümkün. Testi olmayan, her şeyin her şeye bağlı olduğu bir kod tabanında geç gelen her değişiklik bir risk ve doğal olarak ekip direnir. Değişime açıklık bir tutumdan önce bir kod kalitesi meselesi; bu yüzden 2. prensip 9. prensibe bağlı.

İş Birliği ve İletişim: Prensip 4, 5 ve 6

Dördüncü prensip iş tarafından insanlarla geliştiricilerin proje boyunca her gün birlikte çalışmasını ister. Beşinci prensip projeleri motive bireyler etrafında kurmayı, onlara ihtiyaç duydukları ortamı ve desteği verip işi yapacaklarına güvenmeyi söyler. Altıncı prensip, ekibe ve ekip içinde bilgi aktarmanın en verimli ve etkili yolunun yüz yüze konuşma olduğunu söyler.

Bookstore örneğinde Product Owner'ın Sprint Planning'e gelmemesi tek bir toplantının kaçması değil, dördüncü prensibin kopması. Ekip neyin değerli olduğunu tahmin ederek iş seçiyor ve tahmin yanlışsa iki hafta yanlış işe gidiyor. Altıncı prensibin bugünkü okuması da önemli: 2001'de "yüz yüze" aynı odada olmak demekti. Uzaktan çalışan bir ekip için karşılığı senkron konuşma: bir video görüşmesi ya da ekran paylaşımı. Prensibin asıl karşı çıktığı şey uzaktan çalışma değil, her şeyin belge ve uzun yazışma zincirleriyle aktarılması.

Sürdürülebilir Hız: Prensip 8

Sekizinci prensip, Agile süreçlerin sürdürülebilir geliştirmeyi desteklediğini ve sponsorların, geliştiricilerin ve kullanıcıların sabit bir hızı süresiz olarak koruyabilmesi gerektiğini söyler. "Süresiz" kelimesi kilit nokta: iki haftalık bir sprint'te gece yarısına kadar çalışmak, o sprint'i kurtarabilir ama bir sonraki sprint'i yorgun bir ekiple başlatır.

Bu prensip en sık çiğnenen ve en az ölçülen prensip. Ekipler velocity'yi, burndown'u ölçer ama fazla mesaiyi ölçmez. Bookstore ekibi bunu basit bir göstergeyle görünür yaptı: mesai saatleri dışında atılan commit sayısı ve hafta sonu deploy sayısı, her retrospective'de bir satır olarak paylaşılıyor. Sayı tek başına bir şey kanıtlamaz, ama artmaya başladığında konuşmayı başlatır. XP'nin (Extreme Programming) "sustainable pace" pratiği bu prensibin mühendislik tarafı; serinin üçüncü yazısında ona döneceğiz.

Teknik Mükemmellik ve Sadelik: Prensip 9 ve 10

Dokuzuncu prensip, teknik mükemmelliğe ve iyi tasarıma sürekli dikkatin çevikliği artırdığını söyler. Onuncu prensip sadeliği, yapılmayan iş miktarını en üst düzeye çıkarma sanatı olarak tanımlar ve onu vazgeçilmez sayar.

Dokuzuncu prensip, Agile'ın bir proje yönetimi yaklaşımı olmadığının en açık kanıtı. Test atlamak, refactoring'i ertelemek ve CI kırmızıyken merge etmek kısa vadede hız kazandırır gibi görünür; ama her biri bir sonraki değişikliği pahalılaştırır ve ikinci prensibi, değişime açıklığı, imkânsız hâle getirir.

Onuncu prensip, XP'deki YAGNI ilkesinin manifestodaki karşılığı. Bookstore'da bir geliştiricinin yalnız CSV (Comma-Separated Values) dışa aktarımı istenmişken "ileride PDF ve Excel de gerekir" diyerek genel bir export framework'ü yazdığını düşün. İki hafta harcanır, ortaya çıkan soyutlama yalnız tek bir kullanımla test edilmiştir ve PDF gerçekten istendiğinde çoğu zaman yanlış soyutlama olduğu anlaşılır. Yapılmayan iş, hem bugün harcanmayan zamandır hem de yarın bakımı yapılmayacak koddur.

Self-Organizing Ekip ve Yansıma: Prensip 11 ve 12

On birinci prensip en iyi mimarilerin, requirements'ın ve tasarımların self-organizing ekiplerden çıktığını söyler. On ikinci prensip, ekibin düzenli aralıklarla nasıl daha etkili olabileceğini düşünüp davranışını buna göre ayarlamasını ister.

Self-organizing, ekibin işi kendi aralarında nasıl yapacağına kendisinin karar vermesi demek; Scrum Guide 2020 aynı fikri "self-managing" kelimesiyle anlatıyor. Bu, mimari kararların rastgele çıkacağı anlamına gelmiyor; kararları işi yapanların vermesi anlamına geliyor. Mimari tarafındaki karşılığı Mimariye Giriş serisinin "Conway's Law: Ekip Yapısı Mimariyi Nasıl Şekillendirir?" yazısında.

On ikinci prensip, Bookstore ekibinin iptal ettiği retrospective'in neden en son iptal edilmesi gereken toplantı olduğunu açıklıyor. Ekip tam da işlerin yetişmediği bir sprint'te neden yetişmediğini konuşmalı. Retrospective'in kendisi ve etkili bir retrospective'in nasıl yönetileceği Scrum serisinin "Sprint Review ve Sprint Retrospective" yazısında.

Üretimde Dikkat

Prensipleri bir checklist'e çevirip her sprint işaretlemek, onları bir ritüele dönüştürür. Daha işe yarayan yol, her retrospective'de bir prensibi seçip "bu sprint'te bu prensibe en çok nerede ters düştük?" diye sormak. On iki sprint'te bütün prensipler bir kez masaya gelir.

Prensipler arasındaki bağlara bak. Bookstore'un iki haftasında asıl kök, 4. prensibin kopmasıydı: Product Owner olmadan seçilen işler büyüdü, büyük işler büyük PR'lara dönüştü (3 ve 7), büyük PR'lar review'da sıkıştı, sıkışan iş fazla mesaiye (8) ve atlanan testlere (9) yol açtı, yetişmeyen iş de retrospective'i (12) iptal ettirdi. Belirtileri tek tek düzeltmeye çalışmak yerine zincirin başını bul.

Ölçebildiğini ölç: PR büyüklüğü ve review süresi (1, 3), sprint içinde değişen item sayısı (2), mesai dışı commit'ler (8), CI'ın kırmızı kaldığı süre (9) ve retrospective aksiyonlarının kaçının gerçekten uygulandığı (12).

Sık Düşülen Tuzaklar

"Sürdürülebilir hız" prensibini hiç ölçmemek en sinsi tuzak. Fazla mesai bir kez "istisna" olarak başlar, üç sprint sonra normal kapasite gibi planlanır ve ekibin velocity'si aslında yorgunlukla şişirilmiş olur.

İkincisi, prensipleri birbirinden bağımsız okumak. Değişime açıklık (2) teknik mükemmellik (9) olmadan, sık teslim (3) küçük işler olmadan, self-organizing ekip (11) güven (5) olmadan çalışmaz.

Üçüncüsü, altıncı prensibi "uzaktan çalışma Agile değildir" diye okumak. Prensip kanaldan çok senkron konuşmanın değerini anlatıyor.

Dördüncüsü, sadeliği tasarımsızlıkla karıştırmak. Yapılmayan işi en üst düzeye çıkarmak, gereken tasarımı yapmamak değil, istenmeyen esnekliği şimdiden inşa etmemek demek.

Küçük Bir Deneme

★☆☆ Yazının başındaki iki haftayı tekrar oku ve çiğnenen her prensibin numarasını yaz. Sonra hangi ihlalin diğerlerine yol açtığını oklarla çiz.

★★☆ Ekibinin son on pull request'inin satır sayısını ve açılıştan merge'e kadar geçen süreyi bir tabloya yaz. Büyüklük ile bekleme süresi arasında bir ilişki görüyor musun?

★★★ Bir sonraki retrospective için 8. prensibe odaklanan bir oturum tasarla: hangi veriyi getirirsin, hangi soruyu sorarsın ve ekip fazla mesainin kök sebebini bulursa aksiyonun takibini nasıl yaparsın?

Prensip 9, teknik mükemmelliğin çeviklik için şart olduğunu söylüyor ama nasıl yapılacağını söylemiyor. Bir sonraki yazıda bu sorunun en olgun cevabına, Kent Beck'in Extreme Programming'ine bakıyoruz: test-first, pair programming, continuous integration ve küçük release'ler.