1960’lı yıllar. MIT (Massachusetts Institute of Technology) profesörü Edward Lorenz, yavaş çalışan ve aşırı ısınan devasa bilgisayarının işini kolaylaştırmak için hava hareketlerini modellediği programını baştan başlatmak yerine kestirme bir yol tercih ediyor. Başlangıç koşullarını, programının daha önce hesaplamış olduğu dizilerdeki sayıları girerek yeniden oluşturuyor ve programını ortalardan bir yerden başlatıyor. Bilgisayarın gürültüsünden kaçıp bir kahve içmek için odadan ayrılıyor ve bir saat sonra geldiğinde makinenin ürettiği değerler karşısında çok şaşırıyor. Aynı başlangıç koşulları ile çalışan aynı programın, daha önce ürettiği grafiklerden çok farklı sonuçlar ürettiğini görüyor. Başlangıçta hantal makinesinin arızalandığını düşünse de, daha sonra elle girdiği ve doğruluğundan emin olduğu başlangıç değerlerini, virgülden sonra altı basamaklı orijinal değerler yerine, zamandan kazanmak için, virgülden sonra üç basamaklı girdiğini hatırlıyor.
Lorenz’in önemsemediği binde birlik farkın ortaya çıkardığı tahmin edilemez sonuçlar, başlangıç koşullarından ufak bir sapmanın nihai sonuç üzerindeki devasa etkisini gösteriyordu. Bugün bu etkiyi “kelebek etkisi” olarak biliyoruz. Ne kadar gelişmiş teknolojiler kullansak da uzun vadeli hava tahminlerinin tutarlılığından şüphe duyuyoruz.[1]
Yazılım geliştirme projelerini gerçekleştirdiğimiz ortam da, hava koşullarını oluşturan atmosfer olaylarının geliştiği ortamla benzerlik gösteriyor. Çok fazla değişken var. Bu değişkenler arasında doğrusal bir ilişki yok. Dolayısıyla sebep sonuç ilişkilerini tanımlamak çok güç. Benzer sebepler farklı sonuçlar üretebiliyor.
Böyle bir ortamda, çoğu zaman iyi tanımlanmamış başlangıç koşulları ile çok iyi tanımlandığını düşündüğümüz hedeflere ulaşmaya çalışıyoruz. Üstelik ikisini birbirine bağlayan plandan da taviz vermeden. Sonuçta ya plan ya da elde ettiğimiz sonuçlar çöp oluyor.
İşte bu noktada ampirik süreç yönetiminin gözleme ve adaptasyona dayalı temel prensipleri imdadımıza yetişiyor. Bu tıpkı dünyanın her yerini ve atmosferi, aralıksız bir şekilde sensörlerle donatıp hava hareketlerindeki en ufak değişiklikleri anında algılayarak, tahminleme modelimizi yeni veriye uyarlamak gibi bir şey.
Çevik yaklaşımlarla, yazılım geliştirme projelerinde yapmaya çalıştığımız şey de bu:
Uygun başlangıç koşullarını oluşturmak: Proje faaliyetlerine dedike ve son karar verici bir ürün sahibi, ampirik süreç yönetimini bilen ve uygulayan bir scrum master, kendi kendi kendine organize olan bir geliştirme ekibi, yeterince detaylandırılmış ve önceliklendirilmiş bir ürün özellik listesi, geliştirme ekibinin bir arada çalışabileceği bir ortam...
Aldığımız aksiyonların başlangıç koşullarına etkisini gözlemleyerek ulaşılan yeni durumu algılamak: Günlük scrum toplantıları ve iş yıkım şeması ile sprint hedefine göre mevcut durumu algılamak, sprint değerlendirme toplantısı ile nihai ürüne giden yol haritasını görmek, sürekli entegrasyon ile yazılan kodun her an çalışır vaziyette olduğundan emin olmak, test güdümlü geliştirme ile uygulamanın fonksiyonelliğini ve tasarım kalitesini birlikte sağlamak...
Hedeflenen duruma bizi taşıyacak adımları yeni duruma sürekli uyarlamak ve gerekli aksiyonları almak: Günlük scrum toplantılarında sprint hedefinin önündeki engelleri belirlemek ve bu engelleri ortadan kaldırmak, sprint planlama toplantısı ile hedeflenen yeni durumu belirlemek ve gerekiyorsa yol haritasını revize etmek, ürün özellik listesini gözden geçirmek ve gerekli düzenlemeleri yapmak (backlog refinement/grooming), sprint retrospektif toplantısı ile üretim yöntemimizi sürekli geliştirmek...
Bu döngüyü her faaliyetimizde periyodik olarak tekrarlayarak gözlem ve adaptasyonu tüm sürece hakim kılmak: Pair programming ile her an, TDD ile her saat, sürekli entegrasyon ile günde birkaç kez, günlük scrum toplantıları her gün, sprint değerlendirme-planlama-retrospektif toplantıları ile birkaç haftada bir, sürüm değerlendirme-planlama toplantıları ile birkaç ayda bir...
Sürekli gözlem ve adaptasyon, yazılım geliştirmenin karmaşıklık ortamındaki küçük sapmaların, “kelebek etkisi” ile büyük felaketlere yol açmasını önlüyor.
[1] Kaos/ James Gleick