Agile Manifesto: 2001'de Snowbird'de Ne Oldu, 4 Değer Gerçekte Ne Diyor?
Agile Manifesto'nun dört değeri bir yasak listesi değil, bir öncelik listesidir: manifesto sağdaki maddelerde (süreç, doküman, sözleşme, plan) de değer olduğunu açıkça söyler. Şubat 2001'de Snowbird'de 17 kişinin neye tepki olarak bir araya geldiğini, her değerin bir geliştirici için ne anlama geldiğini ve OpenAPI, ADR ve README gibi dokümanların neden hâlâ gerekli olduğunu Bookstore ekibi üzerinden anlatıyoruz.
Sürüm notu: Bu yazı Şubat 2001'de yazılan Manifesto for Agile Software Development'ın agilemanifesto.org'daki metnini ve Jim Highsmith'in aynı sitedeki tarihçe yazısını esas alır; manifestoyu alıntılamak yerine kendi anlatımımızı kullanıyoruz.
Önce Tahmin Et
Bookstore ekibinde yeni bir geliştirici, ödeme modülündeki bir hatayı düzeltmek için kodu açıyor ve hiçbir açıklama bulamıyor: README boş, API'nin (Application Programming Interface) dokümanı yok, neden asenkron bir yapı seçildiğini anlatan bir kayıt yok. Soruyor, cevap şu: "Biz Agile'ız, doküman yazmıyoruz. Manifesto'da öyle diyor."
Tahmin et: Agile Manifesto'da dokümanla ilgili tam olarak ne yazıyor? "Doküman yazmayın" mı, "doküman gereksizdir" mi, yoksa başka bir şey mi? Ve manifestonun dört değerinin hemen altındaki tek cümle neden manifestonun en önemli cümlesi olabilir?
Snowbird, Şubat 2001
11-13 Şubat 2001'de, Utah'taki Wasatch dağlarında bulunan Snowbird kayak merkezinde 17 kişi bir araya geldi. Hepsi ağır, belge odaklı yazılım süreçlerine alternatif arayan yöntemlerin temsilcileriydi: XP (Extreme Programming), Scrum, DSDM (Dynamic Systems Development Method), ASD (Adaptive Software Development), Crystal, FDD (Feature-Driven Development) ve Pragmatic Programming. İmzacılar Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland ve Dave Thomas.
Bu yöntemler 2000 yılı civarında yazılan makalelerde "light" ya da "lightweight" diye anılıyordu. Highsmith'in tarihçesine göre katılımcılar bu etiketten hoşlanmıyordu, Alistair Cockburn da açıkça itiraz etti. Toplantıda "Agile" kelimesi seçildi, grup kendine Agile Alliance adını verdi ve ortaya bugün Agile Manifesto diye bildiğimiz kısa metin çıktı.
Neye tepki olarak doğduğu, SDLC (Software Development Life Cycle) serisinde gördüğümüz tarihçede saklı. 1980'lerden itibaren sözleşmeler ve kurumsal standartlarla yerleşen sıralı süreçler, her aşamanın sonunda kapsamlı belgeler ve onaylar istiyordu. Bu süreçlerde ilerleme, çalışan yazılımla değil, tamamlanan belgelerle ölçülüyordu. Manifesto'yu yazanların ortak noktası aynı yöntemi savunmaları değil, bu ölçüm biçiminin yanlış olduğunda anlaşmalarıydı.
Dört Değerin Yapısı
Manifesto dört değer çiftinden oluşur. Her çiftte solda bir şey, sağda başka bir şey var ve aradaki ilişki "over", yani "-e tercih ederiz" ilişkisi. Dört değerin hemen altında, manifestonun en sık atlanan cümlesi gelir. Bu cümle, sağdaki maddelerde de değer olduğunu ama soldakilere daha çok değer verdiklerini söyler.
Bu cümle olmadan manifesto bir yasak listesi gibi okunur: süreç yok, araç yok, doküman yok, sözleşme yok, plan yok. Bu cümleyle birlikte ise bir öncelik listesine dönüşür: ikisi çatıştığında hangisini seçeceğini söyler. Bir ekibin Agile olup olmadığını anlamanın iyi bir yolu, bu çatışma anlarında ne seçtiğine bakmaktır.
Individuals and Interactions, Processes and Tools'un Önünde
Birinci değer, insanları ve aralarındaki etkileşimi, süreçlerin ve araçların önüne koyar. Bookstore ekibinde bunun en somut sınavı şu: bir pull request iki gündür review bekliyor, çünkü süreç iki onay istiyor ve ikinci onaylayan kişi izinde. Süreç kuralı bozulmasın diye iş beklesin mi, yoksa yazan kişi ile review eden kişi on beş dakika yan yana oturup kodu birlikte mi geçsin?
Değer, süreci kaldır demiyor. İki onay kuralının bir sebebi var ve o sebep geçerli. Değerin söylediği, süreç insanların konuşmasının yerine geçtiğinde bir şeylerin ters gittiği. Jira'da yorum zinciriyle üç gün süren bir tartışma, beş dakikalık bir görüşmeyle bitebiliyorsa, araç amaca hizmet etmiyor demektir.
Working Software, Comprehensive Documentation'ın Önünde
İkinci değer, çalışan yazılımı kapsamlı dokümantasyonun önüne koyar. Dikkat: "dokümantasyonun" değil, "kapsamlı dokümantasyonun". Bu değerin yanlış okunması, yazının başındaki boş README'nin sebebi.
Bookstore ekibinde hangi doküman hâlâ gerekli? Ödeme API'sinin OpenAPI dokümanı gerekli, çünkü mobil ekip ve iş ortakları onu kullanıyor ve koddan otomatik üretildiği için kodla birlikte güncel kalıyor. Asenkron ödeme kararını anlatan bir ADR (Architecture Decision Record) gerekli, çünkü "neden?" sorusunun cevabı koddan okunamaz. Projeyi ilk kez açan kişinin uygulamayı nasıl çalıştıracağını anlatan bir README gerekli. Bunların hepsi kısa, hedefli ve okunuyor.
Gereksiz olan ise kimsenin okumadığı 80 sayfalık tasarım dokümanı: projenin başında yazılmış, ilk sprint'ten sonra koddan uzaklaşmış ve artık yanlış bilgi veren bir belge. Böyle bir belge sıfır dokümandan daha kötüdür, çünkü okuyanı yanıltır. Değerin özü şu soruda: bu doküman çalışan yazılımı mı destekliyor, yoksa onun yerine mi geçiyor?
Customer Collaboration, Contract Negotiation'ın Önünde
Üçüncü değer, müşteriyle iş birliğini sözleşme pazarlığının önüne koyar. Sözleşme hâlâ var; özellikle ekip ile müşteri farklı şirketlerse olmak zorunda. Ama sözleşme, iş birliğinin yerine geçtiğinde her soru bir pazarlığa dönüşür: "Bu değişiklik kapsam içinde mi?"
Bookstore'un kurumsal bir müşterisi için geliştirilen toplu sipariş ekranını düşün. Sprint review'da müşteri ekranı görüyor ve sipariş satırlarını Excel'den yapıştırabilmek istiyor. Sözleşmede bu yok. Sözleşme odaklı cevap bir değişiklik talebi ve fiyat teklifi. İş birliği odaklı cevap, bu yeni isteği backlog'a almak ve karşılığında daha az değerli bir başka item'ı çıkarmayı müşteriyle birlikte konuşmak. İkinci cevap ancak sözleşme buna izin verecek biçimde yazıldıysa mümkün; sabit fiyatlı sözleşmede bunun nasıl yapılacağı serinin beşinci yazısının konusu.
Responding to Change, Following a Plan'ın Önünde
Dördüncü değer, değişime cevap vermeyi bir planı izlemenin önüne koyar. Bu değer en çok "Agile'da plan yoktur" diye yanlış okunur. Manifesto'yu yazanların çoğu planlamaya çok önem veren yöntemlerden geliyordu; XP'nin planning game'i, Scrum'ın Sprint Planning'i bunun örnekleri.
Fark planın rolünde. Plan, değişime ne kadar uzak olduğunu ölçtüğün bir sözleşme değil, bugünkü en iyi tahminin. Bookstore ekibinin çeyreklik planında kütüphanelere yönelik bir raporlama feature'ı var. Sprint'in ikinci haftasında kargo firması teslim event'lerinin formatını değiştireceğini duyuruyor ve iki hafta sonra eski format çalışmayacak. Planı izlemek, raporlama feature'ını bitirmek demek; değişime cevap vermek, planı güncelleyip format değişikliğine öncelik vermek demek. İkincisi planı çöpe atmak değil, planı yeniden yapmaktır.
Üretimde Dikkat
Değerleri bir karar aracına çevir. Bookstore ekibi bir tartışma kilitlendiğinde şu soruyu soruyor: "Burada solda olanı mı seçiyoruz, sağda olanı mı, ve neden?" Bazen cevap sağdaki olur: regüle bir ödeme entegrasyonunda kapsamlı doküman bir zorunluluktur. Önemli olan seçimin bilinçli olması.
Dokümantasyon için bir test uygula: bir belge son üç ayda kimse tarafından açılmadıysa ya da kodla çelişiyorsa, ya güncelle ya da sil. Belgeleri koda yakın tut; OpenAPI dokümanını koddan üret, ADR'ları repo'da tut, README'yi pull request review'ının bir parçası yap. Architecture Decision'lar serisinin "ADR Yazmak" yazısı bu konuda iyi bir başlangıç.
Değerleri ölçemezsin ama belirtilerini görebilirsin: review bekleyen PR'ların (pull request) süresi, müşteriyle son konuşmadan bu yana geçen gün sayısı, plan dışı ama değerli bir işe "hayır" demek zorunda kalınan durumlar.
Sık Düşülen Tuzaklar
Değerleri "soldaki var, sağdaki yok" diye okumak en yaygın tuzak. Sağdaki maddeler yasaklanmadı; manifesto açıkça onlarda da değer olduğunu söylüyor.
İkincisi, manifestoyu bir süreç sanmak. Manifesto ne yapacağını değil, neye öncelik vereceğini söyler. Sprint, stand-up ya da board bir değer değil, bir pratiktir; bu ayrımı serinin dördüncü yazısında yanlış bilinenlerle birlikte açacağız.
Üçüncüsü, değerleri slogan olarak duvara asıp kararlarda hiç kullanmamak. Duvardaki manifesto ile sprint planındaki gerçeklik arasındaki mesafe, ekibin ne kadar Agile olduğunun dürüst ölçüsü.
Dördüncüsü, "müşteriyle iş birliği" değerini, müşteri ne isterse yapmak diye okumak. İş birliği iki yönlüdür; ekip de müşteriye maliyeti, riski ve alternatifleri açıkça söyler.
Küçük Bir Deneme
★☆☆ agilemanifesto.org'u aç ve manifestonun tamamını oku; yalnız birkaç dakika sürer. Dört değerin altındaki cümleyi kendi cümlelerinle yaz.
★★☆ Ekibinin repo'sundaki dokümanları listele. Her biri için şu soruyu cevapla: çalışan yazılımı destekliyor mu, yoksa onun yerine mi geçiyor? Güncel olmayan bir belge bulursan güncelle ya da sil.
★★★ Son sprint'te ekibinin verdiği üç kararı seç ve her birini dört değer çiftinden biriyle eşleştir. Hangisinde sağdaki maddeyi seçtiniz, ve bu bilinçli bir seçim miydi?
Dört değer neye öncelik verileceğini söylüyor ama nasıl uygulanacağını söylemiyor. Bir sonraki yazıda manifestonun ikinci sayfasına, 12 prensibe geçiyoruz ve her birini bir geliştiricinin günlük pratiğine, küçük PR'lara, feature flag'lere ve CI (Continuous Integration) pratiğine bağlıyoruz.