Agile’a Veda Ederken
(lewiscampbell.tech)- Yazılım sektörüne uzun süre yön veren Agile metodolojisinin, gerçekte belirsiz ilkelerden ve zaten çözülmüş sorunların yeniden paketlenmesinden ibaret olduğuna dair eleştirel bir yeniden değerlendirme
- Waterfall ile kurulan karşıtlığın büyük ölçüde bir yanılsama olduğu; iteratif geliştirme ve müşteri katılımı gibi temel kavramların zaten 1970’lerdeki araştırmalarda ortaya konduğu
- Agile’ın her zaman yalnızca Waterfall modelinin karşıtı olarak tanımlandığı, oysa Waterfall modelinin sınırlarının daha 1970’lerde yaygın biçimde bilindiği
- Son dönemde büyük dil modellerinin (LLM) ortaya çıkmasıyla birlikte, Spec-Driven Development yeniden önem kazanıyor ve doküman merkezli geliştirme yükselişe geçiyor
- Agile’ın “kapsamlı dokümantasyondan çok çalışan yazılım” sloganı, artık “kapsamlı dokümantasyon çalışan yazılım üretir” anlayışına dönüşüyor
- Agile’ın geride bıraktığı belirsizliğin ötesine geçip, açık ilkeler ve mühendislik temelli yaklaşıma geri dönme zamanı gelmiş durumda
> RIP Agile, we hardly knew ye.
> And I mean that literally - because no one was ever clear on what it was.
> Agile, huzur içinde yat. Seni aslında hiç doğru düzgün tanımadık.
> Bunu kelimenin tam anlamıyla söylüyorum; çünkü onun tam olarak ne olduğu konusunda kimsenin kafası hiçbir zaman net değildi.
Agile’ın kimlik sorunu
- Agile, yazılım sektörünün tamamına yayılmış dev bir akımdı; ancak gerçekte anlamı netleşmeden yaygınlaşmış bir kavramdı
- Ne zaman soru işaretleri ortaya çıksa, tekrar tekrar “bu gerçek Agile değil” yanıtı verildi
- Agile Manifestosu’nu (2001) gerçekten okuyunca, somut yönlendirmelerin neredeyse hiç olmadığı; “müşteriyle iş birliği sözleşme pazarlığından daha önemlidir” gibi muğlak vecizelerden oluştuğu görülüyor
- “Geliştirmenin ileri aşamalarında bile gereksinim değişikliğini memnuniyetle karşılayın” gibi ilkeler ticari açıdan gerçekçi değil
- “Gerçek Agile (True Agile)” iddiası altında, pratikte yaşanan sorunların manifesto ile ilgisiz olduğu söylenerek kaçınıldı
- Agile endüstrisi Agile’ı düzgün uygulamıyor ve manifestonun kendisi de anlam bakımından yetersizse, Agile’ın gerçekte ne olduğu sorusu ortaya çıkıyor
“Yazılımın üzerinde Waterfall hayaleti dolaşıyor”
- Agile her zaman kendisini olmadığı şeyle (Waterfall) tanımladı; Agile yapmıyorsanız Waterfall yapıyorsunuz, Waterfall da çalışmaz şeklinde bir mantık kurdu
- Oysa Waterfall’ın çalışmadığı gerçeği 1970’ten beri zaten biliniyordu ve Winston W. Royce bunun nedenini açık biçimde açıklamıştı
- Royce, alternatif olarak program tasarımıyla başlamayı, gereksinimleri netleştirmek için yazılım prototipi oluşturmayı, müşteriyi resmî, derinlikli ve sürekli biçimde sürece katmayı önerdi
- Sonradan Agile’ın yeniliği diye sunulan tüm bunlar, gerçekte Ay’a inişten sonraki yıl olan 1970’te zaten yazılmıştı
- Dipnot 1: Apollo Guidance Computer programcıları, story point olmadan ve “teknik mükemmelliğe sürekli dikkat çevikliği artırır” ilkesini bile bilmeden böyle bir başarıyı nasıl elde etti?
1976 tarihli Bell-Thayer makalesi ve iteratif geliştirmenin tarihi
- Bell ve Thayer’ın 1976 tarihli makalesi, “Waterfall” terimini ilk kez kullanan metin olarak anılıyor; ancak bu terimin kendisi bile yapılmaması gereken şeye örnek olarak kullanıldı
- Söz konusu makalenin ampirik araştırma sonucu şuydu: gereksinimlerdeki kusurlar, yazılım geliştirme sürecinde tasarımla gereksinimleri karşılamaya çalışırken ancak fark ediliyordu
- İteratif geliştirme yeni bir şey değildi; Agile’dan onlarca yıl önce de sürekli olarak olgunlaştırılmıştı
- Manifesto sektörü özgürleştirmeden önce bile Waterfall son teknoloji bir yaklaşım değildi ve gereksinimler ile spesifikasyonların etkinliğinden ciddi biçimde şüphe eden kimse yoktu
Spec-Driven Development’ın yükselişi ve Agile sonrası
- Büyük dil modellerinin (LLM) yaygınlaşmasıyla, programcıların yeniden spesifikasyon (specification) yazdığı bir eğilim güçleniyor
- LLM’ler muğlak girdilere karşı kırılgan olduğundan, problemi açık biçimde tanımlamak doğru kod üretimini destekleyen temel yöntem hâline geliyor
- Agile “kapsamlı dokümantasyondan çok çalışan yazılımı” vurguladıysa, Spec-Driven Development buna karşılık “kapsamlı dokümantasyon çalışan yazılım üretir” önermesini öne sürüyor
- Royce daha 1970’te, “dokümantasyon, spesifikasyon ve tasarım, kod yazılıncaya kadar aynı kavramdır; doküman kötüyse tasarım da kötüdür” diye işaret etmişti
- Doküman yoksa tasarım da yoktur noktasını özellikle vurguladı
- 1970 ve 1976’daki çalışmalara dönüp bakıldığında, 2001 tarihli Agile Manifestosu’nun yeni bir içgörü sunmadığı görülüyor
- Agile, muğlak tanımlar ve ticari paketleme ile mevcut mühendislik yaklaşımının yerini aldı; ama somut bir ilerleme sağlayamadı
- O mühendislerin makaleleri çok daha açık bir anlam taşıyordu
- Yazılım geliştirmenin değişmeye ve evrilmeye devam ettiği bugün, Agile’ı tarihe uğurlayıp yeni bir bakış açısına geçme zamanı gelmiş durumda
- Geçmişin ciddi mühendislerinin bıraktığı açık ilkeler ve mühendislik düşüncesine geri dönmek gerekiyor
21 yorum
Neden metodolojilere kutsal metin muamelesi yapıldığını anlamıyorum. Bence asıl yazar da sadece yönü farklıydı; dogmatiklik açısından aynı derecede sorunluydu.
Sonuç bana biraz fazla iddialı geliyor. Sorun ticarileşme ya da aşırı biçimselleşme olabilir ama sprint veya backlog gibi araçlar işe yaramaz hâle gelmiş değil. Yatay ve hedef odaklı bir toplantı kültürünün yerleşmesine de yardımcı oldular. SDD’nin önem kazandığı doğru, ama o spesifikasyonu da yapay zeka ile işbirliği içinde hızla yazabildiğimiz için bu hâlâ çevik. Sadece iki haftalık sprintler birkaç saate kadar kısaldı; iteratif olarak törpüleme yapmanın özü ise aynı kalmış gibi görünüyor.
Katılıyorum
Dikey karar alma yapısını yıkmak ve kısa döngülerle tekrarlı iyileştirme bile, bize büyük bir mesaj bırakıyor (elbette proje yönetimi teknikleri/araçları da aynı şekilde).
'Agile'ın kendisinin yeni bir içgörü sunamadığı ve Agile'ı savunan herkesin körü körüne Agile fanatiği olarak çarpıtıldığı' sonucunun fazla sert olduğunu düşünüyorum
Katılıyorum. Agile hâlâ geçerli. Sanki sahada hiç bulunmamış insanların havaya konuşması gibi görünüyor.
Ne kadar saçma bir yazı. Asıl mesele, spec.'in kendisini çevik şekilde yazmak... Çeviklik, müşteri gereksinimlerine hızla değişip uyum sağlamaktır.
Çeviklik hakkındaki bu tür yanlış anlamalar ve yüzeysel hayaller yüzünden, ister çeviklik olsun ister geliştirme kültürü, her şey yanlış bir yöne gidiyor.
specin kendisini çevik şekilde yazmak tam olarak ne demek?speci kabaca yazarız.speci müşterinin söylediği gibi yazarız.speci hızlıca değiştirebilmek için araçların gücünden yararlanıp bakımını yaparız.speci çevik şekilde yazarız.Asıl meselenin, o yazının da özünde söylediği gibi, çevikliğin ne olduğunun bilinmemesi olduğunu düşünüyorum. Çevik için böyle özellikleri var, şöyle böyle yapılmalı diye çok konuşuldu ama bunun gerçekten çevik metodolojiyle geliştirilmiş bir üründür diye örnek gösteren bir yazı şimdiye kadar görmedim. Manifestoya bakınca da pek net gelmemişti. Bir kez gösterebilir misiniz?
Kent Beck’in Extreme Programming’i, Jeff Sutherland’ın Scrum’u vb. çoğu çevik yöntem kitabında temelde yer alan içerik budur. User story’lere de bakabilirsiniz. Çoğu insan, çevikliğin temelinin müşteri gereksinimlerine hızlı uyum sağlamak için kısa sprintler ve demolar olduğunu pek bilmiyor.
3 ve 4. madde. Spesifikasyonu detaylı yazmanın sonu gelmez; bunun sonsuz bir derinliği var. Önemli olan, organizasyona uygun bir seviyenin bulunmasıdır. Başarılı hizmetlerin nasıl geliştirildiğine dair tarihe baktığınızda, vakaların %99'unda spesifikasyonu kusursuz yazmaya fazla enerji harcamamanın başlı başına önemli bir unsur olduğunu görüyoruz. Yani buna saplanıp kalmamak gerekiyor. Summoners War, Dungeon & Fighter, Zigbang, Lineage gibi şeylerin nasıl yapıldığına bakınca bunu anlayabilirsiniz.
Waterfall döngüsü bir günde tamamlansaydı?
Son zamanlarda bu tür durumları daha sık görüyorum.
Ne yazık ki en sık gördüğüm şeylerden biri gibi görünüyor...
Türkiye'de çevik, geliştiricilere takvim baskısı uygulamak için kullanılan bir şeyden ne fazlası ne de eksiği.
Bazı ölçütlere göre herkes çevik zaten. Şimdiki kadar hızlı dağıtım yapıp geri bildirim aldığımız bir dönem olmuş muydu, emin değilim.
Kısa döngülü dağıtımlar dışında Agile’dan geriye ne kaldığını bilmiyorum.
Backlog ve sprint de daha önce zaten başka biçimlerde vardı; müşteriyle iletişim ise gerçekte çoğu zaman duruma uymuyor. Sonuçta bence Agile’dan ziyade DevOps iyileştirmeleri geliştirmede çok daha fazla ilerleme sağladı.
Bu yazının kendisi bile çevik değil!
Kod okumak zorunda kalınmayacak değil; bu açıdan bakınca kodun dokümandan daha önemli olduğu sözü geçerli gibi görünüyor ve talimat niteliğindeki dokümanı uygulamanın yürütücüsü olan LLM’in okuması gerektiği için bu açıdan da katılıyorum. Bu nedenle sonuç olarak ikisinin de aynı anda önemli olduğu düşünülebilir.
Şu anda LLM tabanlı ürünlerdeki sorun, operasyon aşamasında biriken teknik borçtur. Sürdürülebilir işletim için geliştiricinin koda müdahil olması gerekir; bunun için de en azından şimdilik kodun dokümanın yerini alabilecek durumda olması gerektiğini düşünüyorum.
Karşı argümanı temkinli biçimde iletmek gerekirse, bence kod dokümantasyonun yerini tutamaz. Programlama dilleri hâlâ doğal dilin zengin ifade gücüne ve aktarım kabiliyetine sahip değil; pratikte de o kadar kodun tamamını ne zaman okuyacağız ki?
Dokümantasyonun yerini alabilecek bir koda sahip olmak bir umut ve temenni, ama çıkılamayacak bir Babil Kulesi gibi.
Açıkçası OOAD üzerine ciddi şekilde çalışmak bana daha iyi görünüyor.
Tersine, doğal dilin kodun yerini almasının da zor olduğunu düşünüyorum. Doğal dil, koda kıyasla hızlı olduğu kadar fazlasıyla soyut. Hesaplama için sonuçta ayrıntıların doldurulması gerekiyor, ancak doğal dilin bu rolü üstlenmesi pek mümkün görünmüyor.
Yazılım geliştirirken sorun olan şey soyutluk değil, belirsizliktir. Doğal dil doğası gereği belirsizdir. Hatta çok anlamlıdır da. Bu yüzden doğal dille kod yazma girişimleri pek iyi sonuç vermiyor olabilir. Durum böyleyken, doğal dilin kodun yerini alması ise akla bile gelecek bir şey değil.
Evet, belirttiğiniz görüşe katılıyorum.
Kodla ikame edilemeyecek kısımlar olduğu kesin.
Bu anlamda biraz farklı açıklamak gerekirse, anlatmak istediğim şey okunabilirliği yüksek kodun belge üretme ihtiyacını azaltacak şekilde yazılmasıydı.
Yazılım uzun soluklu hale geldikçe biriken belgeler de geliştiriciye bilişsel yük getiriyor. Asıl mesele, kod ile belge arasında gidip gelme işini azaltmak.
Tamamen yalnızca kod bırakmanın mümkün olduğunu düşünmüyorum.
Bunun bağlama ve içinde bulunulan duruma göre değişebileceğini düşünüyorum.
Yorumunuz için teşekkür ederim.
Hacker News görüşleri
Agile sayesinde ilginç bir olgu gördüm
Başarısız olunca, bu durum “yeterince uygulanmadı” diye yorumlanan bir yapıya dönüşüyor
Aynı örüntüyü bulut, mikroservisler, kemer sıkma politikaları gibi alanlarda da gördüm — başarısızlığın nedeni her zaman yetersiz uygulama oluyor, yaklaşımın kendisinin asla yanlış olamayacağına dair bir inanç işliyor
Bir takım Agile'ı denediğinde iyi gitmezse, hemen “o zaten gerçek Agile değildi” savunması ortaya çıkıyor. Sonuçta Agile başarısız olamayan bir kavram haline geliyor
Agile Manifesto yalnızca değerler ve ilkelerden söz eder. Sorun, bunu zorla bir sürece dönüştürmeye çalışan organizasyon kültürüdür
Başarısızlıkta insanı içine dönmeye iten bu yapı illa kötü değil. Dış etkenleri suçlamak yerine öz değerlendirme teşvik ettiği için bazı yönleriyle sağlıklı bir sistem de olabilir
Müşteriye verilmiş bir yol haritası ile esnek tepki verebilmek birbiriyle zor bağdaşıyor. Gerçekte olan, plan odaklı organizasyonların Agile taklidi yapması
Başarısızlık olunca sonuç “daha fazla ajan kullanmalıydık” noktasına varıyor. Tıpkı “token asla yeterli olmaz” şakası gibi geliyor
Agile'ın formelleşmesinden korkar oldum
40 kişilik bir ekibi başarıyla yönettim ama gerçek Agile aslında sadece dört cümleye indirgenebilir — insanlar, çalışan yazılım, müşteriyle iş birliği, değişime tepki
Sorun, “büyük harfli Agile”ın zamanla esnek olmayan bir sürece dönüşmüş olması
İnsan sayısı arttıkça hedefleri hizalamak zorlaşıyor ve sonunda kontrol ile prosedür ihtiyacı doğuyor
Hatta ticket oluşturma yetkisinin bile sınırlandığı yerler gördüm; esneklikle uzaktan yakından ilgisi yoktu
Dokümantasyon eksik olursa bakım imkansız hale gelir ve iş sonunda YOLO geliştirmeye kayar
Çalıştığım büyük şirketlerdeki Agile tamamen yalandı
Bir iş arkadaşım, “Bir sonraki sprintin işini önceden yaparsan her zaman zamanında bitirmiş olursun” demişti.
Yani Agile, gerçek işten çok metrik üretim sistemi olarak işliyordu
Yöneticiler sadece sayıların artmasına bakıp memnun oluyor, ürün ise istatistiğin yan ürünü haline geliyordu
Agile Manifesto orijinal metnine yeniden bakmaya değer
Üzerinde uzlaşılmış tek nokta o. Agile'dan önceki Waterfall'ın ne kadar korkunç olduğunu hatırlamak gerekiyor
Sabit takvimleri ve teslimatları dayatan dönemi bitiren araç oydu
Çünkü ekipler kendi kendine çalışırsa bunun kendi konumlarını tehdit ettiğini düşünüyorlar
Kent Beck'in “Extreme Programming”de dediği gibi, Agile hayali bir her şeye kadirlik anlayışının zorbalığından kaçınma girişimiydi
Eski Waterfall yaklaşımı tasarım aşamasında her şeyi öngörmeye çalışıyor, öğrenmeyi ve geri bildirimi yok sayıyordu
Ama zamanla Agile'ın ritüelleri ve biçimleri özünün önüne geçti
Ben hâlâ Agentic programming fikrini seviyorum ama sonuçta asıl önemli olan bağlamı birbirine bağlayan insanın rolü
Asıl makale kafa karıştırıcıydı
Agile'ın yeni bir şey üretmediğini söyledikten sonra, LLM kod yazınca Agile'ın öldüğünü iddia ediyor
Oysa Agile'ın özü, eksik spesifikasyonları kabul etmek ve yinelemeli biçimde iyileştirmek
Bu ilke hâlâ geçerli
Agile bunun sadece bir varyasyonu; sorun kötü uygulamaların çok olmasıydı
İyi ürünler sonuçta spesifikasyon → öğrenme → düzeltme döngüsünden çıkar
Backlog Grooming, Sprint Review gibi süreçler ise tam tersine değişimi bastırıyor
Spec tabanlı geliştirme uzun ömürlü olmayacak gibi geliyor
Hâlâ çalışan yazılım üretip yinelemek daha hızlı — yani sonuçta Agile'a geri dönüş
Spesifikasyon kalitesi arttı ve inceleme yapmak kod incelemekten daha kolay hale geldi
GitHub bağlantısı
Manifestoda Daily Standup ya da Agile Coach gibi ifadeler yok
Özünde söylenen şey “programcıları mikro düzeyde yönetmeyin”
Yani mesaj şu: motive olmuş bireylere uygun ortamı ve güveni sağlayın
Kent Beck, Martin Fowler ve diğer kurucular başlangıçta esnek yönergeler amaçlamıştı
Ama zamanla bu anlayış ticari bir modele dönüştü, körü körüne takip edenler çoğaldı ve karmaşa büyüdü
Başarı ya da başarısızlık eninde sonunda insanların yetkinliğine ve tutumuna bağlı
Sprint uzunluğu da duruma göre ayarlanmalı ve spesifikasyon yoksa ekip bunu kendisi üretmeli
Yapay zeka çağında da, Agile'ı akıllıca kullanan insanlar olduğu sürece hâlâ geçerli
“Spec yazmak” ile tam olarak ne kastedildiğini merak ettim
Üzerinde çalıştığım tüm Agile projelerde tasarım belgeleri vardı ve ticket'lar o belgelerden türetilirdi
Belgesiz, sadece ticket tabanlı geliştirme cehennem gibi olurdu
Herkes onları kendi işine geldiği gibi yorumluyor
Ticket merkezli yaklaşım aslında daha saf bir Agile anlayışına yakın
Sahte Agile'da ise PO ya da PM'in yazdığı belgeler hakikatmiş gibi davranılır
Sizin anlattığınız yöntem, benim kastettiğim ‘spesifikasyon yazımı’ fikrine en çok yaklaşan şey