Incremental, Iterative ve Spiral Modeller: Riski Erken Görmek

Sürüm notu: Bu yazı Barry Boehm'in 1988 tarihli Spiral model makalesini (IEEE Computer, cilt 21, sayı 5), Alistair Cockburn'ün 2008 tarihli "Using Both Incremental and Iterative Development" yazısını ve Jeff Patton'ın aynı yılki incremental/iterative karşılaştırmasını esas alır.

Önce Tahmin Et

Bookstore ekibi yeni checkout akışını üç iterasyonda, ikişer haftada çıkaracak. Kapsam belli: ödeme, kargo ve iade. İki plan masada. A planı: ilk iterasyonda ödemeyi eksiksiz bitir, ikincide kargoyu, üçüncüde iadeyi. B planı: ilk iterasyonda üçünün de kaba bir sürümünü yap, sonraki iki iterasyonda hepsini olgunlaştır.

Hangi plan riski daha erken gösterir? Hangisi ilk iterasyonun sonunda müşteriye gerçekten kullanılabilir bir şey verir? İkisinin cevabı farklı plana çıkıyorsa, belki doğru soru "hangisi?" değil, "ikisini nasıl birleştiririm?" sorusudur.

Incremental ve Iterative Aynı Şey Değil

İki kelime günlük konuşmada birbirinin yerine kullanılıyor, ama farklı stratejileri anlatıyorlar. Alistair Cockburn'ün ayrımı en net olanı: incremental geliştirme bir staging ve scheduling stratejisidir; sistemin farklı parçaları farklı zamanlarda geliştirilir ve hazır oldukça bütüne eklenir. Iterative geliştirme ise bir rework scheduling stratejisidir; bir parçayı gözden geçirip iyileştirmek için baştan zaman ayrılır.

Jeff Patton aynı farkı bir resim benzetmesiyle anlatır. Incremental çalışan bir ressam tabloyu parça parça bitirir: önce sol üst köşe eksiksiz, sonra yanındaki parça. Bu, sayılarla boyama kitabına benzer; her alanın ve rengin önceden bilinmesi gerekir, yani ilk seferde doğru yapmak zorundasın. Iterative çalışan ressam ise önce bütün tablonun kaba bir eskizini yapar, sonra alt boyamayı, sonra ayrıntıları. Her turda bütüne bakar ve değiştirir. Patton'ın uyarısı da önemli: ekiplerin çoğu "iterative" dediği hâlde iterasyon yapmayı planlamaz, yani bir şeyi yeniden işlemek için zaman ayırmaz.

A planı saf incremental. İlk iterasyonun sonunda ödeme gerçekten çalışır, ama kargo ve iadeye dair hiçbir bilgi yoktur; ödeme tasarımının kargoyla çelişip çelişmediğini altıncı haftada öğrenirsin. B planı saf iterative. Üç parçanın birbirine nasıl bağlandığını ilk iki haftada görürsün, ama ilk iterasyonun sonunda müşteriye verilebilecek hiçbir parça tam değildir. Cockburn'ün önerisi ikisini birlikte kullanmak: her iterasyonda hem yeni bir parça eklemek hem de öncekileri yeniden işlemek.

Walking Skeleton: Bookstore Checkout'u Nereden Başlar?

İkisini birleştirmenin pratik yolu walking skeleton. Terim Cockburn'e ait: sistemin uçtan uca küçük bir işlevi yerine getiren, mümkün olan en ince uygulaması. Bütün mimari katmanlardan geçer, ama her katmanda yalnız gerektiği kadar kod vardır.

Bookstore checkout'unda ilk iterasyonun ilk haftası şuna gider: Angular'da tek bir "Siparişi tamamla" butonu, bu butonun çağırdığı ASP.NET Core 10 endpoint'i, EF (Entity Framework) Core ile Order tablosuna yazılan tek bir kayıt ve bunların hepsinin CI (Continuous Integration) pipeline'ından geçip staging'e deploy edilmesi. Ödeme yok, kargo yok, iade yok. Ama artık her katmanın birbirine bağlandığı, build'in ve deploy'un çalıştığı biliniyor. Deploy yetkisi eksikse, veritabanı migration'ı staging'de çalışmıyorsa, bunlar ilk hafta görünür.

Sonraki iterasyonlar iskelete dilim ekler: ikinci iterasyonda ödeme sağlayıcısıyla gerçek bir test ödemesi, üçüncüde kargo ücreti hesabı ve teslim event'i, dördüncüde iade. Bu incremental kısım. Her iterasyonda bir önceki dilimin de yeniden ele alınması iterative kısım: ödeme dilimi ilk hâlinde yalnız tek bir kart tipini destekliyordu, kargo dilimi eklenirken ödeme tutarına kargo ücretini dahil etmek için yeniden işlendi. Bu yeniden işleme bir hata değil, plandaki bir adım.

Spiral Model: Turu Riskin Belirlediği Döngü

Barry Boehm 1988'de IEEE Computer'da yayımlanan makalesinde iterative fikri bir adım öteye taşıdı: döngünün kaç kez döneceğini ve her turda ne yapılacağını belgeler ya da kod değil, risk belirlesin. Boehm bunu belge odaklı ve kod odaklı süreçlere karşı risk odaklı bir yaklaşım olarak sundu.

Spiralin her turu dört işten geçer. Önce o turun hedefleri, seçenekleri ve kısıtları belirlenir. Sonra seçenekler değerlendirilir ve en büyük riskler belirlenip çözülür; bunun için prototip, simülasyon ya da benchmark kullanılır. Ardından bir sonraki seviyenin ürünü geliştirilir ve doğrulanır. En son bir sonraki tur planlanır ve paydaşlar devam edip etmeme kararını verir. Spiralin dışa doğru büyümesi birikmiş maliyeti gösterir: her tur daha pahalıdır, bu yüzden riskin erken turlarda, ucuzken çözülmesi gerekir.

Bookstore checkout'una uygulandığında ilk turun sorusu şudur: bu projede en çok neyin ters gitme ihtimali var ve ters giderse en pahalı ne olur? Cevap ödeme sağlayıcısı entegrasyonuysa, ilk tur bir ekran tasarımına değil, sağlayıcının test ortamında 3-D Secure (kart sahibinin ek doğrulaması) akışını deneyen küçük bir prototipe gider. Risk azaldıkça turlar ürünün daha olgun sürümlerine döner. Spiral bu yüzden bir "model" olmaktan çok, hangi modeli ne kadar kullanacağını riske göre seçmeni sağlayan bir çerçeve; Boehm makalede doğru risk profilinde spiralin Waterfall'a benzeyen bir yola da dönüşebileceğini anlatır.

Prototyping ve RAD

Spiral'in risk çözme aracı olan prototip iki farklı amaçla yapılır ve ikisini karıştırmak pahalıdır. Throwaway prototype, bir soruyu cevaplamak için yazılır ve cevap alınınca atılır: "Ödeme sağlayıcısının webhook'u gerçekten 30 saniye içinde geliyor mu?" sorusunu cevaplayan bir console uygulaması gibi. Evolutionary prototype ise ürüne dönüşmek üzere yazılır ve baştan production kalitesinde test, hata yönetimi ve gözlemlenebilirlikle büyütülür. Walking skeleton ikinci türe yakın bir örnek.

1990'ların başında James Martin'in RAD (Rapid Application Development) yaklaşımı prototiplemeyi merkeze aldı: kullanıcıyla yoğun atölyeler, zaman kutusuna sığdırılmış kısa geliştirme döngüleri ve hızlı ekran üretim araçları. RAD'ın bıraktığı en kalıcı fikir, zamanı sabitleyip kapsamı değişken tutan timebox'tır; bu fikir Agile yöntemlerin sprint ve iterasyonlarında da yaşıyor.

RUP: Dört Faz ve İçlerindeki İterasyonlar

1990'ların sonunda Rational Software'in RUP (Rational Unified Process) süreci, iterative geliştirmeyi kurumsal ölçekte paketledi. RUP projeyi dört faza böler: Inception (iş gerekçesi ve kapsam netleşir), Elaboration (mimari riskler çözülür ve çalışan bir mimari iskelet ortaya çıkar), Construction (feature'ların büyük kısmı iterasyonlar halinde geliştirilir) ve Transition (ürün kullanıcıya geçirilir, beta ve eğitim). Her faz kendi içinde bir ya da daha çok iterasyondan oluşur ve her iterasyonda requirements, tasarım, implementation ve test birlikte yapılır; yalnız ağırlıkları fazdan faza değişir.

RUP'un Elaboration fazı, walking skeleton fikrinin süreç dilindeki karşılığı: mimariyi riskli kısımlarıyla birlikte erkenden çalıştırmak. RUP'un sık eleştirilen yanı, kapsamlı bir süreç kataloğu olmasıydı; birçok kurum katalogdaki her şeyi uygulamaya çalıştı ve ağır bir süreçle karşılaştı. Fazların ve risk odaklı iterasyonların arkasındaki fikir ise hâlâ geçerli.

Üretimde Dikkat

Bir iterasyonun gerçekten iterasyon olup olmadığını anlamanın en iyi ölçüsü sonundaki üründür. İterasyon sonunda entegre edilmiş, test edilmiş ve en azından staging ortamına deploy edilmiş bir increment yoksa, o iki hafta bir planlama birimidir, bir geri bildirim döngüsü değil. Bookstore ekibi her iterasyonun son gününde checkout'u staging'de, gerçek ödeme sağlayıcısının test ortamıyla, bir kişinin baştan sona denemesini kural yaptı.

Tamamlanmamış dilimleri production'a taşımanın güvenli yolu feature flag. Ödeme dilimi production'a deploy edilir ama yalnız iç kullanıcılara açılır; böylece deploy ile release ayrılır. Bu tekniğin ayrıntısı CI/CD Temelleri serisinde ve Scrum serisinin teknik pratikler yazısında.

Yeniden işlemeyi planla. Her iterasyonun kapasitesinin bir kısmını önceki dilimlerin iyileştirmesine ayırmayan bir ekip, iterative değil, sadece incremental çalışıyordur. Patton'ın önerisi basit: beklediğin her revizyon için backlog'a ayrı bir item yaz.

Sık Düşülen Tuzaklar

İterasyon adı altında mini-Waterfall en yaygın tuzak. İki haftalık iterasyonun ilk üç günü analiz, sonraki beş günü kodlama, son iki günü test ise, Waterfall'ın bütün sorunları sadece küçülmüş hâliyle yaşanır: test son günlerde sıkışır ve bulunan hata bir sonraki iterasyona kalır. Scrum serisinin anti-pattern yazısı bu durumu "mini-Waterfall sprint" adıyla ele alıyor.

İkincisi, prototipin production koduna dönüşmesi. Throwaway olarak yazılmış bir prototip demoda çok iyi görünür ve birisi "zaten çalışıyor, bunu kullanalım" der. Test'i, hata yönetimi, loglaması olmayan kod böylece ürünün temeline girer. Prototipi yazarken türünü baştan ilan et ve throwaway olanı ayrı bir repo'da tut.

Üçüncüsü, entegrasyonsuz incremental. Dilimler ayrı ayrı geliştirilip en sonda birleştiriliyorsa, ekip Waterfall'ın geç entegrasyon riskini dilimlere bölmüş, ama ortadan kaldırmamıştır.

Dördüncüsü, Spiral'i her turda ağır bir risk analizi belgesi üretme zorunluluğu gibi uygulamak. Risk analizi bir sorunun cevabıdır, bir belge şablonu değil.

Küçük Bir Deneme

★☆☆ Ekibinin son iki haftasını incele: yapılan işin ne kadarı yeni bir dilim eklemekti, ne kadarı mevcut bir dilimi yeniden işlemekti? İkinci oran sıfırsa, gerçekten iterative çalışıyor musunuz?

★★☆ Üzerinde çalıştığın sistem için bir walking skeleton tarif et: hangi katmanlardan geçer, ilk hafta neyi kanıtlar, hangi riskleri ortaya çıkarır?

★★★ Önündeki projenin en büyük üç riskini yaz ve her biri için Spiral'in ilk turunda yapılabilecek, en fazla iki gün süren bir prototip tasarla. Prototiplerden hangisi throwaway, hangisi evolutionary olmalı?

Royce'tan Spiral'e kadar gördüğümüz her model aynı soruya farklı cevap veriyor: geri bildirim ne kadar sürede gelir? Bir sonraki yazıda bu sürenin aylardan saatlere nasıl indiğini, Agile Manifesto'yu ve DevOps'u ortaya çıkaran koşulları ve bu kısalmanın nasıl ölçüldüğünü anlatıyoruz.