Agile ve Gerçek Dünya: Sabit Fiyatlı Sözleşme, Deadline ve Mimari Kararlar

Sürüm notu: Bu yazı Agile Manifesto ve 12 prensibi (2001), DSDM'in (Dynamic Systems Development Method) MoSCoW önceliklendirme rehberini (Agile Business Consortium), Jeff Sutherland'in "Money for Nothing, Change for Free" sözleşme önerisini ve SAFe'in (Scaled Agile Framework) architectural runway tanımını esas alır; sözleşme maddeleri hukuki tavsiye değildir.

Önce Tahmin Et

Bookstore'un yazılım ekibi, kurumsal bir müşteri için B2B (business-to-business) sipariş portalı geliştirecek. Müşterinin satın alma birimi sabit fiyat, sabit kapsam ve üç aylık bir teslim tarihi istiyor. Müşterinin ürün ekibi ise "Agile çalışalım, her iki haftada bir demo görelim, ihtiyaç değişirse kapsamı güncelleyelim" diyor. İki talep aynı sözleşmede.

Tahmin et: bu sözleşme Agile çalışmayı imkânsız mı kılıyor? Yoksa sabit fiyatın içinde değişebilecek bir şey var mı? Ve üç ayın sonunda değişmeyecek olan tarih, kapsamı mı, kaliteyi mi, ekibin sağlığını mı yiyecek?

Proje Üçgenini Ters Çevirmek

Geleneksel proje yönetiminde kapsam sabitlenir; zaman ve maliyet bu kapsamdan tahminle türetilir. Tahmin tutmazsa, üçgenin bir köşesi esner: ya tarih kayar, ya bütçe artar, ya da en sinsi olanı, kalite sessizce düşer. Agile yaklaşım üçgeni ters çevirir: zaman ve ekip, dolayısıyla maliyet, sabitlenir; değişken olan kapsamdır. DSDM bu fikri sabit zaman ve kaynak, esnek feature'lar olarak merkezine koyan ilk yöntemlerden biri.

Bu tersine çevirmenin dayanağı manifestonun ikinci ve dördüncü değeri: önden yazılmış bir kapsam, ne istendiğine dair bugünkü en iyi tahminden ibaret. Kapsamı sabitlemek, bu tahmini bir taahhüde çevirmek demek. Zamanı sabitleyip kapsamı değişken tutmak ise "bu sürede, bu ekiple, en değerli olanı yapacağız" taahhüdü. İkinci taahhüt hem daha dürüst, hem de tutulabilir.

Elbette kapsamın tamamen serbest olduğu bir sözleşme müşteri için kabul edilemez olabilir. Pratikte aranan şey, kapsamın ne kadarının sabit ve ne kadarının esnek olduğunu baştan konuşmak.

Sabit Fiyatlı Sözleşmede Agile Çalışmak

Jeff Sutherland'in "Money for Nothing, Change for Free" adıyla bilinen önerisi, sabit fiyatlı bir sözleşmeye iki madde ekler. İlki, "change for free": müşteri henüz başlanmamış bir item'ı, aynı büyüklükte başka bir item'la ücretsiz olarak değiştirebilir; toplam iş miktarı değişmediği sürece. İkincisi, "money for nothing": müşteri, yeterli değeri aldığına karar verirse herhangi bir sprint sonunda sözleşmeyi erken bitirebilir; bu durumda kalan bedelin üzerinde anlaşılmış bir kısmını öder. Sutherland bu fikri 2008'de Agile konferansında anlattı ve 2014 tarihli "Scrum" kitabında bir bölüm olarak işledi. Önerinin bir de şartı var: müşteri sürece, yani Product Backlog önceliklendirmesine ve review'lara aktif olarak katılmazsa sözleşme zaman ve malzeme modeline döner.

Bookstore'un B2B portalı sözleşmesine bu fikri uyarlayalım. Kapsam, büyüklükleri ekiple birlikte tahmin edilmiş bir Product Backlog olarak eke girer. Müşteri her sprint review'dan sonra başlanmamış item'ları eşdeğer büyüklükte yenileriyle değiştirebilir. Excel'den sipariş yapıştırma isteği sprint review'da ortaya çıktığında, bir değişiklik talebi ve fiyat pazarlığı yerine, aynı büyüklükteki "çoklu teslim adresi" item'ının çıkarılması konuşulur. Altıncı sprint'te müşteri portalın ihtiyacını karşıladığına karar verirse, kalan iki sprint'in bedelinin anlaşılan kısmını ödeyerek projeyi kapatabilir.

Bu maddeler her müşteriye uymaz ve hukuki metni bir avukatla birlikte yazmak gerekir. Önemli olan fikir şu: sabit fiyat, sabit kapsam anlamına gelmek zorunda değil. Fiyat ve süre sabit kalırken kapsamın içi değişebilir.

Deadline'ı Olan Ekip: Must Have Listesini Gerçekten Küçük Tutmak

Bazı tarihler pazarlık konusu değildir. Bookstore'un en büyük kampanya dönemi Kasım sonu; yeni indirim kodu altyapısı o tarihte production'da olmalı, bir hafta sonrası işe yaramaz. Sabit tarih karşısında Agile'ın cevabı yine kapsam: tarihte mutlaka olması gereken en küçük dilimi bul ve önce onu bitir.

DSDM'den gelen MoSCoW yöntemi bu dilimlemenin dilini verir: Must have, Should have, Could have ve Won't have this time. Yöntemin en çok atlanan kuralı Must have'lerin büyüklüğü. Agile Business Consortium'un DSDM rehberi, ekibin teslim edebileceğinden emin olacağı bir seviyede kalmak için Must have eforunun genellikle toplam eforun yüzde 60'ını geçmemesini önerir. Geri kalanı, Should ve Could, aslında bir güvenlik payıdır: işler ters giderse ilk onlar düşer.

Bookstore'un kampanya planında Must have listesi şunlardan oluşuyor: checkout'ta tek bir indirim kodunun uygulanması, kodun kullanım limitinin kontrolü ve indirimin faturaya doğru yansıması. Should have: kampanya sayfasında kalan süre göstergesi. Could have: aynı siparişte birden fazla kodun birleştirilmesi. Won't have this time: kişiye özel kod üretimi. İlk iki sprint'te Must have'lerin hepsi production'a, feature flag'in arkasına çıkıyor; kalan zaman Should ve Could'a gidiyor. Kasım'ın üçüncü haftasında bir ödeme sağlayıcısı sorunu iki günlük ek iş çıkardığında, düşen şey birleştirilmiş kodlar oluyor, kampanya değil. Önceliklendirme yöntemlerinin karşılaştırması Product Management'a Giriş serisinin önceliklendirme framework'lerini anlatan yazısında.

Mimari Kararlar: Architecture Runway ve Ne Zaman Karar Vermeli?

Agile ekiplerin en çok zorlandığı soru şu: mimari kararları ne zaman vermeli? Bir uçta, her şeyi baştan tasarlayan BDUF (Big Design Up Front) var; diğer uçta, her kararı son ana bırakıp kendini köşeye sıkıştıran bir ekip. Mary ve Tom Poppendieck'in "Lean Software Development" (2003) kitabıyla yaygınlaşan last responsible moment fikri, kararı, vermemenin maliyeti vermenin maliyetini aşmadan hemen önceye kadar ertelemeyi önerir. Bu fikrin pratikte işe yaraması için iki tür kararı ayırmak gerekir.

Geri alınması ucuz kararlar ertelenebilir: bir endpoint'in response formatı, bir cache süresi, bir class'ın adı. Geri alınması pahalı kararlar ise erken düşünülmelidir. Bookstore'un B2B portalı için bunlar belli: veritabanı motoru ve şema stratejisi, kimlik doğrulama ve yetkilendirme yaklaşımı (müşterinin kendi kimlik sağlayıcısıyla mı, Bookstore'un hesap sistemiyle mi?) ve multi-tenancy modeli (her kurumsal müşteri ayrı veritabanında mı, aynı tablolarda bir TenantId kolonu ile mi?). Bu üçünü üçüncü sprint'te değiştirmek, portalın büyük kısmını yeniden yazmak demek.

SAFe bu dengeyi architectural runway kavramıyla anlatır: yakın vadedeki feature'ları minimum yeniden tasarım ve gecikmeyle geliştirmek için gereken mevcut kod, bileşenler ve teknik altyapı. Uçak benzetmesi açık: runway yetersizse feature'lar kalkamaz, gereğinden uzunsa yatırılan emek hiç kullanılmaz. Bookstore ekibi bunun için her sprint'in kapasitesinin bir kısmını, yaklaşan feature'ların ihtiyaç duyacağı altyapıya ayırıyor ve bu işi backlog'da ayrı bir item tipiyle görünür tutuyor.

Erken verilen pahalı kararlar kısa ve okunur biçimde belgelenmeli. Bir ADR (Architecture Decision Record), kararın bağlamını, seçeneklerini ve sonuçlarını bir iki sayfada kaydeder; "neden multi-tenancy için tek veritabanı seçtik?" sorusunun cevabı ekip değişse de kalır. ADR yazmanın ayrıntısı Architecture Decision'lar serisinin "ADR Yazmak" yazısında, trade-off analizi aynı serinin "Trade-off Analizi" yazısında.

Agile Ne Zaman Gerçekten Zor?

Dürüst olmak gerekirse, Agile'ın faydasını sınırlayan durumlar var. Requirements yasal olarak dondurulmuşsa, örneğin bir ihale şartnamesinde her alan tek tek tarif edilmişse ve değişiklik ihaleyi yeniden açmayı gerektiriyorsa, kapsamı esnek tutmanın hukuki bir yolu olmayabilir. Geri bildirim alınamayan bir ortamda, örneğin son kullanıcıya teslimattan önce hiç erişilemeyen bir sistemde, kısa döngülerin asıl getirisi olan gerçek kullanıcı tepkisi gelmez.

Bu durumlarda bile Agile'ın bir kısmı işe yarar: kısa iterasyonlar, sürekli entegrasyon, otomatik testler ve ekip içi yansıma, kapsam sabit olsa da riski erken görmeyi sağlar. Hangi modelin ne zaman seçileceği SDLC (Software Development Life Cycle) serisinin son yazısında karar faktörleriyle ele alındı.

Üretimde Dikkat

Sözleşme imzalanmadan önce, sabit ve esnek olanı yazıya dök: hangi tarih sabit, hangi bütçe sabit, kapsamın hangi kısmı Must have, değişiklik nasıl yapılacak. Bu konuşma sözleşmeden sonra yapılırsa, her değişiklik bir pazarlığa dönüşür.

Must have listesinin büyüklüğünü her sprint yeniden ölç. Listeye sessizce eklenen her item, güvenlik payını yer ve deadline'a doğru ekip fazla mesaiye itilir; manifestonun sekizinci prensibi, sürdürülebilir hız, en çok böyle çiğnenir.

Mimari kararları ilk iki sprint'te listele ve her biri için "geri almak ne kadar pahalı?" sorusunu cevapla. Pahalı olanları erken ve belgelenmiş olarak ver; ucuz olanları bilinçli olarak ertele.

Sık Düşülen Tuzaklar

Sabit tarih, sabit kapsam ve sabit ekibi aynı anda kabul etmek en yaygın tuzak. Üçü birden sabitse, esneyen tek şey kalite olur: testler atlanır, teknik borç birikir ve teslimden sonraki bakım aşaması pahalılaşır.

İkincisi, her şeyi Must have yapmak. Must have'leri toplam eforun yüzde 90'ı olan bir plan, MoSCoW kullanıyor gibi görünür ama aslında sabit kapsamlı bir plandır.

Üçüncüsü, "Agile'da mimari kendiliğinden ortaya çıkar" diyerek geri alınması pahalı kararları ertelemek. Emergent design ucuz kararlar için çalışır; multi-tenancy modeli emerge etmez, ya bilinçli seçilir ya da kazara.

Dördüncüsü, sözleşmeye Agile maddeler koyup müşteriyi sürece katmamak. Change for free, müşteri review'lara gelip öncelik vermedikçe işlemez.

Küçük Bir Deneme

★☆☆ Ekibinin üzerinde çalıştığı işte zaman, maliyet ve kapsamdan hangisi gerçekten sabit, hangisi esnek? Üçü de sabitse, bugün esneyen şey ne?

★★☆ Bir sonraki release'in backlog'unu MoSCoW ile etiketle ve Must have'lerin toplam eforun yüzde kaçı olduğunu hesapla. Yüzde 60'ın üzerindeyse hangi item'ları Should'a indirirsin?

★★★ Projendeki geri alınması en pahalı üç kararı listele. Her biri için kısa bir ADR yaz: bağlam, seçenekler, karar ve sonuçlar. Bu kararlardan biri henüz verilmediyse, last responsible moment ne zaman?

Agile'ın gerçek dünyayla sürtünmesini gördük. Serinin son yazısında 2001'den bugüne Agile'ın nasıl evrildiğine bakıyoruz: Heart of Agile, Modern Agile, Agile Fluency Model ve büyük organizasyonlarda Agile'ı ölçeklendirme tartışması.