Agile'ın 20. yılı: Başarısız bir isyan
(simplethread.com)<p>- Agile Manifesto'nun (Çevik Bildirge) yayımlanmasının üzerinden 20 yıl geçti ve bugün ortada iki açık gerçek var:<br />
1. Agile adı konusunda zafer kazanıldı. Hiç kimse non-Agile olarak anılmak istemiyor.<br />
2. Ancak Agile'ın uygulanışı, kurucularının devrimci fikirlerinin oldukça gerisinde kaldı.<br />
- "Herkes Agile yaptığını söylüyor ama gerçekten çevik olan neredeyse kimse yok." Peki neden böyle oldu?<br />
<br />
[ Whence The Manifesto : Bildirge nasıl başladı ]<br />
- 2001 Şubat'ında 17 kişilik bir yazılım uzmanı grubu Utah'taki bir kayak tesisinde buluştu.<br />
- Birkaç gün süren tartışmaların ardından birlikte "Agile Software Development Manifesto"'yu kaleme aldılar.<br />
<br />
- Buradaki önemli nokta, onların birer "practitioner" yani uygulayıcı olmalarıydı. PM, CTO ya da VP Eng değillerdi. Geliştirici, programcı, bilim insanı ve mühendistiler. O dönemde de hâlâ kod yazıyor, paydaşlarla iş birliği yaparak sorun çözüyorlardı. Bu gerçekten önemli.<br />
- Bir başka nokta da Agile Manifesto'nun boşluktan doğmamış olması. Bu kişilerin çoğunun ya geliştirdiği ya da yaygınlaştırdığı kendi metodolojileri zaten vardı.<br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Pragmatic Programming <br />
<br />
- Gruptaki herkesin ciddi bir yazılım geliştirme geçmişi vardı ve o dönemde piyasaya hakim olan belge odaklı ağır yazılım geliştirme süreçlerine alternatif arıyorlardı.<br />
- Bildirgenin özü, dört değerin açıklanmasıdır.<br />
<br />
"Bizler yazılım geliştirerek ve başkalarının geliştirmesine yardımcı olarak, yazılım geliştirmenin daha iyi yollarını keşfediyoruz. Bu çalışma sayesinde şunlara değer vermeye başladık:<br />
- süreçler ve araçlardan (processes and tools) çok bireylere ve etkileşimlere (Individuals and interactions)<br />
- kapsamlı dokümantasyondan (comprehensive documentation) çok çalışan yazılıma (Working software)<br />
- sözleşme pazarlığından (contract negotiation) çok müşteriyle iş birliğine (Customer collaboration)<br />
- bir planı takip etmekten (following a plan) çok değişime yanıt vermeye (Responding to change)<br />
Değer veriyoruz. Yani soldakilerin de değeri var, ancak sağdakilere daha fazla değer veriyoruz."<br />
<br />
[ A New Hope : Yeni bir umut ]<br />
- 2021'in bakış açısından modern yazılım geliştirme pratiklerini doğal kabul etmek kolay, ancak 2001'de bu fikirler son derece radikaldi.<br />
- Tüm gereksinimleri toplamadan ve tüm özellikleri değerlendirmeden yazılım geliştirmeye mi başlayacaksınız? Delilik!<br />
- Unutulmaya yüz tutmuş önemli bir nokta, Agile'ın ilk döneminde açıkça ve mücadeleci biçimde anti-management olmasıydı.<br />
<br />
- Örneğin Scrum'un ortak yaratıcılarından Ken Schwaber, tüm proje yöneticilerinin ortadan kaldırılması gerektiğini savunuyordu; sadece projeden PM'i çıkarmayı değil, sektörün kendisinde bu mesleğin kaldırılmasını öneriyordu.<br />
<br />
"Proje yöneticisi rolünün karmaşık ve yaratıcı işlerde verimsiz olduğunu keşfettik.<br />
Proje planı olarak somutlaşan proje yöneticisinin düşüncesi,<br />
sorunu en iyi biçimde çözmek için herkesin zekâsını bir araya getirmek yerine,<br />
herkesin yaratıcılığını ve zekâsını planda yazanlarla sınırlar."<br />
<br />
- Scrum master'ın neredeyse hiç yetkisi yoktu ve konularda oy hakkı da bulunmuyordu. Onlar servant leader idi; takımı koruyor ve engelleri kaldırıyorlardı ama takımı yönetmiyorlardı.<br />
→ servant leader: Ekibine hizmet etme yaklaşımıyla onların büyüme ve gelişimine destek olan, lider ile ekip arasında güven oluşturarak organizasyon hedeflerine ekip üyelerinin kendiliğinden katkı vermesini sağlayan lider<br />
- XP'de de başlangıçta benzer şekilde çalışan Tracker ve Coach rolleri vardı.<br />
<br />
- Crystal ve Hexagonal Architecture'ın yaratıcısı Alistair Cockburn yakın tarihli bir tweet flood'unda şöyle diyordu:<br />
"Scrum düşmanca bir bölgede olağanüstü bir anlaşma sağladı:<br />
- Yönetim yılda 12 kez, her sprintten sonra istediği gibi yön değiştirebiliyordu.<br />
- Takım, ağır düşünme ve çalışma için kesintisiz ve yön değişikliği olmadan tamamen sakin geçen bir ay kazanıyordu.<br />
- Takım, yönetimin müdahalesi olmadan, Bid'de (öncelik belirlemek için) bir ay içinde neyi yapıp neyi yapamayacağını ilan edebiliyordu.<br />
- Hiçbir yönetim bundan daha iyi bir anlaşma yapmadı.<br />
- Hiçbir geliştirme takımı da bundan daha iyi bir anlaşma yapmadı.<br />
"<br />
(Çevirmenin notu: Bu tweet flood'u aslında "Scrum takımının sprint'e alınan tüm maddeleri %100 bitirmesi gerektiği fikri nereden çıktı? Bu saçma." sorusuna verilen yanıttan başlıyor. Orijinal flood'un tamamına bakmanızı öneririm.)<br />
<br />
- 15 yılı aşkın süredir Agile ekiplerde çalışan sertifikalı bir Scrum master olarak ve bu alanda pek çok popüler kitap okumuş biri olarak, Scrum fikrini bu kadar net ve özlü anlatan bir açıklama görmemiştim.<br />
- Scrum, düşmanca ortamlarda çalışmak üzere tasarlanmıştı. Düşünmeye ve keşfetmeye zaman ihtiyacı olan geliştiricilerle baskıcı yöneticiler arasında yapılmış bir anlaşmaydı.<br />
<br />
[ The Empire Strikes Back : İmparatorluk geri dönüyor ]<br />
- Bir bakıma Agile tabandan gelen bir emek hareketiydi. Uygulayıcılardan başlayıp yönetime kadar yükseldi. Bu nasıl başarılı oldu?<br />
- Kısmen, geliştiricilerin sayısının artması ve iş dünyasına kattıkları değerin yükselmesi sayesinde.<br />
- Asıl büyük neden ise geleneksel waterfall geliştirme yaklaşımının iyi çalışmamasıydı.<br />
- Yazılım daha karmaşık hâle geldikçe, iş dünyasının hızı arttıkça ve kullanıcı beklentileri yükseldikçe her şeyi en baştan planlamak imkânsızlaştı.<br />
- İteratif geliştirmeyi kabul etmek mantıklıydı ama her şeyi önceden planlamaya alışmış yöneticiler için biraz korkutucuydu.<br />
<br />
- 2000'lerin ortalarında yöneticiler bunu tam anlamıyla benimsememişti.<br />
- Sonra şu düşünce ortaya çıktı: "Mühendislerin durmadan anlattığı bu çılgın fikri bir deneyelim. Zaten mevcut deadline'ı tutturamıyoruz; daha ne kadar kötü olabilir ki?"<br />
- Ama şaşırtıcı biçimde işe yaramaya başladı. Takımlar ilk başta biraz çekingen ve yavaştı, fakat zamanla hangi kalıpların kendi ekiplerinde işe yaradığını öğrenince hız kazandılar.<br />
- Birkaç sprint sonra çalışan yazılımın, iş birliğinin, inceleme ve uyarlamaya zaman ayırmanın ve bunları diğer her şeyin önüne koymanın gücünü görmeye başladılar.<br />
<br />
- Yaklaşık 5 yıl içinde Agile, duyulmuş ama herkesin aşina olmadığı bir yöntem olmaktan çıktı.<br />
- 2005'te Agile ve TDD gerçek bir farklılaştırıcıydı.<br />
- 2010'da modern yazılım ekiplerinin neredeyse hepsi bir şekilde Agile yapıyordu.<br />
- En azından danışmanlık sektöründe bu bir balon gibiydi. Büyük şirketler ise her zamanki gibi daha yavaş ilerliyordu.<br />
<br />
"Başardık! Kazandık! Hadi hep birlikte kutlayalım."<br />
Hikâye burada bitiyor; tarayıcı sekmesini kapatabilirsiniz.<br />
<br />
"Winning was easy, young man. Governing’s harder."<br />
"Kazanmak kolaydı, delikanlı. Yönetmek daha zordur."<br />
→ Hamilton müzikalindeki George Washington<br />
<br />
- Ne yazık ki, birçok devrimde olduğu gibi Agile'ın tarihi de kurucuların hayal ettiği şekilde ilerlemedi.<br />
→ "Bireyler ve etkileşimler"i önceliklendirmek anlatması zor bir kavram çıktı. Süreç ve araç satmak çok daha kolaydı.<br />
(Çevirmenin notu: Buradaki sell sözcüğü satıştan çok, başkalarına benimsetmek anlamında kullanılıyor.)<br />
→ "Çalışan yazılım" üretmenin, gerçekçi olmayan planlar ve bol dokümantasyondan daha zor olduğu ortaya çıktı.<br />
→ "Müşteriyle iş birliği" güven ve kırılganlık (vulnerability) gerektiriyor ama iş dünyasında bu her zaman bulunmuyor.<br />
→ "Değişime yanıt vermek" ise çoğu zaman uzun vadeli plan yapıp kontrol etmek zorunda olan yönetim karşısında geri planda kaldı.<br />
<br />
"Agile doğru uygulanmadığında çoğu zaman kaos gibi hissettirdiği ortaya çıktı."<br />
<br />
- Ancak bu dört değerin yanlış olduğu anlamına gelmiyor.<br />
- Bu sadece, bunların iyi işlemesi için biraz emek gerektiği ve yazılımın doğası gereği dağınık ve kaotik olduğunu kabul etme cesaretine ihtiyaç olduğu anlamına geliyor.<br />
- Sürekli öğrenip uyum sağlayıp iyileştirip yayınlamaya devam ederseniz, sonunda waterfall'dan çok daha iyi; çok daha dürüst, gerçekçi ve üretken bir yere ulaşabileceğinizi anlamak ve buna inanmak gerekir.<br />
<br />
"Çevik hareket anti-methodology değildir.<br />
Hatta birçoğumuz 'metodoloji' kelimesine duyulan güvenin yeniden kazanılmasını istiyoruz. Dengenin yeniden kurulmasını istiyoruz.<br />
Modellemeden yanayız ama bu, diyagramları şirket deposunda tozlanmaya bırakmak için değil.<br />
Dokümantasyondan yanayız ama bu, bakım görmeyen ve neredeyse hiç kullanılmayan yüzlerce sayfalık kitaplar anlamına gelmiyor.<br />
Planlar yaparız ama çalkantılı ortamlarda planların sınırlarını da kabul ederiz.<br />
XP, Scrum ya da diğer çevik metodolojilerin savunucularını 'hacker' diye damgalayanlar, 'metodoloji' ve 'hacker' terimlerinin asıl tanımlarını bilmiyor demektir."<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- İşte önemli noktalar bunlar. Hâlâ plan yapıyoruz, hâlâ doküman üretiyoruz ve Agile konusunda disiplinli olmak zorundayız. Mesele denge meselesi.<br />
- Ancak organizasyonunuz Agile dönüşümünde zorlanıyor ve kaosa sürükleniyorsa, biri size sertifikalar, süreçler ve araçlar gibi cankurtaran botları uzattığında oraya atlamanız çok kolay oluyor.<br />
- Yönetim, "self-organizing teams" kavramını süreç ve araçlardan çok daha az anlıyor.<br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One'ın dönüşü ]<br />
- Burada üç perdelik yapım biraz bozuluyor. Çünkü Agile adını taşımadan geri dönen cesur bir isyan göremiyoruz.<br />
(Çevirmenin notu: Star Wars film adlarına gönderme yaparak, Agile dışında başka bir şeyin ortaya çıkmadığı söyleniyor.)<br />
<br />
- Araç satıcıları, süreç danışmanları ve uzmanlar sık sık asla yerine getiremeyecekleri vaatlerde bulunuyor.<br />
- SAFe (Scale Agile Framework for Enterprise), Scaled Scrum ve kurumsal kullanıma yönelik diğer Agile versiyonlarını geliştirmemizin sebebi de bu.<br />
- Bu framework'ler kötü niyetle yaratılmış değil ve muhtemelen doğru bağlamlarda belli ölçüde değer de sunuyorlar.<br />
- Ama ben bunlara Agile demezdim.<br />
- Bireyler ve etkileşimler üzerine kurulu bir metodolojiyi ölçeklendirmeye çalıştığınızda kaçınılmaz olarak sorunlar ortaya çıkıyor ve metodolojinin özgün değerleri zarar görüyor.<br />
<br />
- Agile Manifesto imzacısı ve XP'nin ortak yaratıcılarından Ron Jeffries'in 2018'de yazdığı ünlü bir yazıdan:<br />
<br />
"Geliştiriciler Agile'ı bırakmalı.<br />
'Agile' fikirleri doğru uygulanmadığında, geliştiricilere daha fazla müdahale edilmesine, onlara çalışmak için daha az zaman verilmesine, daha yüksek baskı kurulmasına ve 'daha hızlı ilerlemelerinin' istenmesine yol açıyor. Bu geliştiriciler için iyi değil, nihayetinde şirket için de iyi değil. Çünkü 'Agile' doğru yapılmadığında, gerçekte başarılabilecek olandan çok daha fazla hata ve daha yavaş ilerleme ortaya çıkıyor. Üstelik iyi geliştiriciler çoğu zaman böyle şirketleri terk ediyor ve sonuçta bu şirketler, 'Agile'ı benimsemeden öncekinden bile daha verimsiz hâle geliyor."<br />
<br />
- Bir diğer imzacı ve Pragmatic Programming'in ortak yaratıcılarından Dave Thomas'ın 2014'te yazdığı ünlü yazıdan:<br />
<br />
"Agile öldü. (Yaşasın agility.)<br />
'Agile' kelimesi fiilen anlamını yitirecek kadar saptırıldı ve çevik topluluk da büyük ölçüde danışmanların ve satıcıların hizmet ve ürün sattığı bir yere dönüştü. Bildirge yaygınlaştıkça Agile sözcüğü, desteklenecek bir fikri, faturalandırılacak zamanı ya da satılacak ürünü olan her şeyi kendine çeken bir mıknatıs hâline geldi; bir pazarlama terimi oldu.<br />
<br />
Bu yüzden artık 'Agile' kelimesini emekliye ayırma zamanının geldiğini düşünüyorum."<br />
<br />
[ Retro : Geçmişe dönüş ]<br />
- En üzücü olan şey, genç geliştiricilerin Agile'ı küçümsenen bir şey, yöneticilerin gerçekçi olmayan vaatler çıkarmak için kullandığı bir araç ve geliştiricileri aşırı çalışmaya iten bir mekanizma olarak görmeleri.<br />
- Onların bildiği tek Agile, kendilerine dayatılan bir kontrol mekanizması; memnuniyetle benimsenecek bir güçlendirme aracı değil.<br />
- Yine de umarım tarihin ve orijinal vizyonun tartışılması, bundan sonra nasıl ilerlememiz gerektiğini hatırlamamıza yardımcı olur.<br />
<br />
- Buna rağmen iyi haber şu ki Agile Manifesto'nun ilkeleri, 20 yıl önce olduğu kadar bugün de akıllıca ve yerinde. Jeffries ya da Thomas gibi sözde mürtetler de hâlâ böyle düşünüyor.<br />
<br />
- Yukarıda anılan yazıda Jeffries şöyle diyor:<br />
"Ancak Manifesto for Agile Software Development'ın değerleri ve ilkeleri, bildiğim en iyi yazılım geliştirme yaklaşımını hâlâ sunuyor ve uzun, çeşitli deneyimlerime dayanarak, daha büyük organizasyonlarda hangi metodolojiyi kullanırsam kullanayım bu değerleri ve ilkeleri takip edeceğim."<br />
<br />
- Ben de bu görüşe katılıyorum.<br />
- Bugün Agile hakkında konuşmak artık havalı ya da çekici bir şey değil. Agile sıkıcılaştı.<br />
"Hepiniz Agile yapıyorsunuz, değil mi?"<br />
- Şimdi son 20 yıla dönüp kendimize birkaç soru sormak için mükemmel bir zaman:<br />
→ Neler doğru gitti?<br />
→ Neler yanlış gitti?<br />
→ Bir dahaki sefer neyi farklı yapmak isteriz?<br />
- Önümüzdeki birkaç ay boyunca orijinal 12 Agile ilkesine yeniden dönmeyi, bunların ilk anlamını bağlamına oturtmayı ve bugünkü yazılım geliştirme ortamındaki değerini değerlendirmeyi planlıyorum.<br />
<br />
"Umarım kurucu ilkeleri inceleyerek geçmişten ders çıkarabilir ve Dave Thomas'ın dediği gibi 'Agile'dan vazgeçsek bile 'Agility'yi koruyabiliriz."</p>
3 yorum