Sadece bir butondu. Her şey hep böyle başlar.
Bir paydaş (stakeholder) basit bir CSV export istedi. Ama sonra Pazarlama bunun aynı zamanda bir PDF oluşturup oluşturamayacağını merak etti. Satış, PDF'in gerçek zamanlı grafikler içerip içeremeyeceğini sordu. Sprint bitmeden önce, 'basit buton' özel bir mikroservis, bir message queue ve üçüncü parti bir grafik kütüphanesi gerektirir hale gelmişti.
Bu bölüm aslında ne hakkında
Bu bölüm, tüm proje katillerinin en sessizi ve en ölümcülü olan Scope Creep (Kapsam Genişlemesi) hakkındadır. Kapsam kayması kötü niyetle olmaz; coşkuyla olur. Her yeni gereksinim tek başına küçük görünür, ancak bir araya geldiklerinde mimariyi ezen bir yerçekimi kuyusu oluştururlar.
Teknik Çıkarım
Eklediğiniz her feature, test matrisini ve bakım yükünü katlanarak artırır. Kapsamı genişletirken zaman çizelgesini (timeline) veya bütçeyi genişletmezseniz, etkiyi sönümlemek için geriye kalan tek değişken kod kalitesi olur.
Gerçek Takımlarda Nasıl Görünür?
Bunu, altı aydır sprint'ten sprint'e devredilen 'zombi epic'lerde görürsünüz. Ekip sürekli 'neredeyse bitmiş' durumdadır, ancak her demo paydaşlardan 'sadece küçük bir ince ayar daha' gelmesiyle sonuçlanır.
Takımların dikkat etmesi gerekenler
Orijinal gereksinimin—kullanıcının aslında ihtiyaç duyduğu şeyin—ekibin 'olsa iyi olur' edge case'lerini inşa etmekle meşgul olması nedeniyle nasıl aylarca ertelendiğine dikkat edin. Teslimat (delivery) bir feature'dır. Yayına alınmış (shipped) bir CSV export'u, yayına alınmamış yapay zeka destekli bir analitik paketinden sonsuz derecede daha değerlidir.
Teknik Çıkarım
Kontrolsüz kapsam genişlemesi, mimari karmaşıklığı katlanarak artırır ve teknik borcu garantiler.
Gerçek Takımlarda Nasıl Görünür?
Bu durum, product manager'ların ve mühendislerin katı bir Bitti Tanımı (Definition of Done) belirleyememesi ve 'elimiz değmişken' eklemelerinin sprint'i gasp etmesine izin vermesiyle ortaya çıkar.
Sıkça Sorulan Sorular
Bu bölümdeki teknik ders nedir?
Ders, her yeni gereksinimin sistemik karmaşıklık eklediğidir ve 'küçük' UI değişiklikleri genellikle büyük backend mimarisi değişiklikleri gerektirir.
Bu problem neden production'da ortaya çıkar?
Çünkü bir toplantıda 'evet' demek, production'da bir veritabanı şemasını refactor etmekten daha kolaydır.
Mühendislik ekipleri bu pattern'dan nasıl kaçınabilir?
Katı bir MVP'yi (Minimum Viable Product) zorunlu kılın, backlog'u acımasızca önceliklendirin ve sprint ortasındaki herhangi bir eklemenin eşit boyuttaki başka bir maddeyle değiştirilmesini şart koşun.