Doğru SDLC Modelini Seçmek: Proje, Ekip ve Risk Profiline Göre Karar

Sürüm notu: Bu yazı Dave Snowden ve Mary Boone'un 2007 tarihli "A Leader's Framework for Decision Making" makalesinde tanıtılan Cynefin çerçevesini (alan adlarının bugünkü hâliyle) ve Barry Boehm ile Richard Turner'ın 2003 tarihli "Balancing Agility and Discipline" kitabını esas alır.

Önce Tahmin Et

Bookstore'un önünde üç proje var. Birincisi, bir bankanın taksitli ödeme altyapısına entegrasyon: bankanın dokümanı 140 sayfa, denetim ekibi her değişikliğin kaydını istiyor, canlıya geçiş tarihi bankanın takviminde sabit. İkincisi, kütüphanelere yönelik yeni bir abonelik ürünü: kimin, hangi feature için para ödeyeceğini kimse bilmiyor. Üçüncüsü, finans ekibi için aylık satış raporları: ne istendiği belli, kullanıcılar aynı katta oturuyor.

Her proje için bir model seç: Waterfall, V-Model, iterative/Spiral, Agile ile continuous delivery ya da bir karışım. Sonra kendine sor: seçimini hangi bilgiye dayandırdın? Ekibin alışkanlığına mı, yoksa projenin özelliklerine mi?

Model Bir Araçtır, Kimlik Değil

Serinin önceki yazılarında her modelin geri bildirim döngüsüne farklı bir cevap verdiğini gördük. Bu yazının iddiası basit: model, projenin risk profiline göre seçilen bir araçtır. "Biz Scrum şirketiyiz" ya da "biz kurumsal olduğumuz için V-Model kullanırız" gibi cümleler, aracı kimliğe çevirir ve projenin kendisini sorudan çıkarır.

Barry Boehm ve Richard Turner, 2003 tarihli "Balancing Agility and Discipline" kitabında bu soruyu sistemli hâle getirdi. Plan odaklı ve Agile yaklaşımların her birinin bir "home ground"u, yani en iyi çalıştığı bir ortamı olduğunu savundular ve projeyi beş faktörle değerlendirmeyi önerdiler: ekip büyüklüğü, hatanın kritikliği, requirements'ın değişkenliği, ekipteki deneyim düzeyi ve kurum kültürünün kaosa mı düzene mi yakın olduğu. Aşağıdaki faktörler bu fikrin bugünkü bir web ekibine uyarlanmış hâli.

Karar Faktörleri

Requirements belirsizliği ilk ve en güçlü faktör. Ne istendiği biliniyorsa ve bilgi zamanla değişmiyorsa, önden plan yapmak ucuzdur. Ne istendiği ancak kullanıcı ürünü görünce anlaşılacaksa, önden plan bir tahminden ibarettir ve kısa döngüler gerekir.

Regülasyon ve denetim ikinci faktör. Denetçi her requirement'ın bir testle eşleştiğini, her değişikliğin onaylandığını görmek istiyorsa, bu izlenebilirlik modelin bir parçası olmalı. Bu, Agile'ı dışlamaz; ama V-Model'in traceability disiplinini zorunlu kılar.

Sözleşme tipi üçüncüsü. Sabit fiyat ve sabit kapsamlı bir sözleşme, değişikliği resmî bir talebe bağlar; zaman ve malzeme (time and materials) sözleşmesi ise kapsamın iterasyonlarla değişmesine izin verir. Agile çalışmanın sözleşmeyle nasıl bağdaştırılacağı Agile Mindset serisinin konusu.

Deploy maliyeti dördüncüsü. Bir web uygulaması günde onlarca kez deploy edilebilir. Bir mobil uygulama mağaza incelemesinden geçer ve kullanıcının güncellemesine bağlıdır. Bir cihazın firmware'i sahada güncellenemeyebilir. Deploy maliyeti yükseldikçe, her release'in önünde daha fazla doğrulama gerekir.

Ekip dağılımı ve geri bildirime erişim son ikisi. Kullanıcılara her hafta ulaşamayan bir ekip, kısa döngülerin asıl faydasını, yani gerçek kullanıcı geri bildirimini alamaz. Farklı saat dilimlerine dağılmış ve farklı şirketlerden oluşan bir ekip de yazılı arayüzlere ve sözleşmelere daha çok ihtiyaç duyar.

Cynefin: Problemin Türünü Tanımak

Faktörleri tartmanın kısa yolu, problemin türünü sormak. Dave Snowden'ın geliştirdiği Cynefin (Galce bir kelime; kabaca "yaşanılan yer") çerçevesi, durumları neden-sonuç ilişkisinin ne zaman ve nasıl bilinebildiğine göre ayırır. Alanların bugünkü adları clear, complicated, complex ve chaotic; ortada da hangi alanda olduğunun bilinmediği confusion durumu var.

Clear alanda neden-sonuç herkes için açık; doğru cevap bir prosedürle bulunur: algıla, sınıflandır, uygula. Complicated alanda neden-sonuç vardır ama görmek için uzmanlık ve analiz gerekir; birden fazla iyi cevap olabilir: algıla, analiz et, uygula. Complex alanda neden-sonuç ancak geriye dönüp bakınca anlaşılır; önden analiz cevabı vermez, küçük ve güvenli deneylerle yolu bulursun: dene, algıla, uygula. Chaotic alanda neden-sonuç görülemez; önce durumu stabilize etmek için harekete geçersin: harekete geç, algıla, uygula.

SDLC (Software Development Life Cycle) modellerine çevirince tablo netleşiyor. Complicated bir problem, yani bankanın dokümante ettiği bir protokolü uygulamak, analizle çözülebilir; önden plan ve V-Model'in disiplini burada işe yarar. Complex bir problem, yani kütüphanelerin hangi feature için para ödeyeceğini bulmak, analizle çözülemez; kısa iterasyonlar, sık release ve ölçüm gerekir. Chaotic bir durum, yani production'da yanan bir sistem, model değil incident yönetimi ister. Clear bir iş, yani her ay aynı formatta bir rapor, bir prosedüre ve otomasyona dönüşmelidir.

Snowden'ın sık vurguladığı hatalardan biri, complex bir problemi complicated sanıp ona uzman analiziyle cevap aramak. "Doğru requirements dokümanını yazarsak ürün başarılı olur" düşüncesi tam olarak bu hata.

Karar Tablosu

Faktörleri ve modelleri yan yana koyan kaba bir tablo, ekip içi tartışmayı başlatmak için iyi bir araç. Tablo bir algoritma değil; bir hücrenin seni hangi soruyu sormaya ittiğine bak:

Üç Senaryo ve Hibritlerin Dürüst Tarifi

Banka entegrasyonu: protokol dokümante edilmiş, denetim ağır, canlıya geçiş tarihi bankanın elinde. Bu complicated bir problem. Uygun model V-Model'in traceability'si ile birlikte iterasyonlar. Requirements bankanın dokümanından çıkarılır ve her biri bir acceptance test'e bağlanır; ama geliştirme tek geçişte değil, bankanın test ortamına her iki haftada bir bağlanan iterasyonlarla yapılır. Serinin üçüncü yazısındaki trait'li testler, denetçiye her iterasyonda güncel bir eşleşme tablosu verir. Bu hibritin dürüst tarifi şu: dış çerçeve plan odaklı, iç çalışma iterative. Plan değişmeyecek bir tarihe göre kurulur; değişen yalnız işin iç sırası.

Kütüphane abonelik ürünü: kimin neye para ödeyeceği bilinmiyor. Bu complex bir problem. Uygun model kısa sprint'ler, sık release ve feature flag'lerle ölçülen deneyler. Burada uzun bir requirements dokümanı yazmak, yanlış ürünü verimli biçimde inşa etmenin yolu olur. Hangi deneyin önce yapılacağı ve sonuçların nasıl ölçüleceği Product Management'a Giriş serisinin konusu; günlük çalışma biçimi ise Scrum ve Kanban serilerinde.

Finans raporları: ne istendiği belli, kullanıcılar yakında, risk düşük. Bu çoğunlukla clear, kenarlarında biraz complicated bir iş. Ağır bir süreç gereksiz; Kanban gibi akış odaklı, hafif bir yöntem yeter. Raporların ilk sürümü finans ekibiyle birlikte birkaç gün içinde çıkar ve gerisi bakım akışına girer.

Üç senaryonun ortak noktası, hiçbirinin saf bir model kullanmaması. Gerçek dünyada çoğu ekip hibrit çalışır ve bunda bir sorun yok. Sorun, hibritin bilinçsiz olması: water-scrum-fall gibi, bir modelin dili ile başka bir modelin gerçekliğinin karışması. Bilinçli bir hibritte ekip hangi kısmın neden plan odaklı, hangi kısmın neden iterative olduğunu tek cümleyle söyleyebilir.

Üretimde Dikkat

Model seçimini proje başında bir kez yazıya dök: hangi faktörler, hangi alan, hangi model ve neden. Bunu bir ADR (Architecture Decision Record) gibi kısa tut. Proje ilerledikçe faktörler değişebilir; complex başlayan bir ürün, pazarı oturdukça complicated bir bakım işine dönüşür ve hafif bir süreç yeterli hâle gelir. Kayıt, bu değişimi fark etmeni sağlar.

Modeli seçip pratikleri seçmemek, kâğıt üzerinde kalan bir karardır. "Agile" seçen bir ekip continuous integration'ı, otomatik testi ve küçük PR'ları (pull request) da seçmiş olmalı; "V-Model" seçen bir ekip de requirements ile test arasındaki eşleşmeyi gerçekten tutmalı. Model, pratiklerin toplamı kadar gerçektir.

Aynı kurumda farklı ekiplerin farklı modeller kullanması normal. Bunu standartlaştırmaya çalışmak yerine, ekipler arasındaki arayüzü standartlaştır: release takvimi, API (Application Programming Interface) sözleşmeleri ve ortak metric'ler.

Sık Düşülen Tuzaklar

Her projeye aynı modeli dayatmak en yaygın tuzak. Kurum genelinde tek bir süreç, yönetimi kolaylaştırır ama projelerin yarısını kendine uymayan bir modelle çalışmaya zorlar.

İkincisi, complex bir problemi complicated sanmak. Yeni bir ürün için altı ay requirements analizi yapmak, analizin cevap veremeyeceği bir soruya analizle cevap aramaktır.

Üçüncüsü, hibriti bir mazeret olarak kullanmak. "Biz hibritiz" cümlesi, hangi parçanın neden öyle olduğu söylenemiyorsa, çoğu zaman eski sürecin yeni adıdır.

Dördüncüsü, kararı bir kez verip unutmak. Projenin risk profili değişir; model de değişebilmelidir.

Küçük Bir Deneme

★☆☆ Üzerinde çalıştığın projeyi karar tablosundaki altı faktörle değerlendir. Bugün kullandığınız model, tablonun gösterdiği sütuna uyuyor mu?

★★☆ Ekibinin önündeki üç işi Cynefin alanlarına yerleştir. Complex bir işe complicated gibi davrandığınız bir örnek bulabiliyor musun?

★★★ Ekibin için bir "model seçimi" kaydı yaz: faktörler, alan, seçilen model, seçilen pratikler ve bu kararın hangi koşulda yeniden gözden geçirileceği. Kaydı bir ekip arkadaşına okut ve tek cümleyle neden bu modeli kullandığınızı söyleyip söyleyemediğine bak.

SDLC serisi burada bitiyor: aşamaları, modelleri ve seçimin nasıl yapılacağını gördük. Agile'ın neden bugün bu kadar yaygın olduğunu ve "Agile'ız" diyen bir ekipte neyin gerçekten Agile olduğunu anlamak için sıradaki seri Agile Mindset; ilk yazısı 2001'de Snowbird'de yazılan manifestonun dört değerine bakıyor.