Yazılım Projesinde Değişiklik Talebi Nasıl Yönetilir?

Değişiklik talebi, kapsam belirlendikten sonra gelen her yeni istek için açılan kayıttır ve amacı isteği reddetmek değil, bedelini görünür kılmaktır. Yazılım projelerinde gecikmenin en yaygın sebebi kötü tahmin değil, kayda geçmeden büyüyen kapsamdır: tek tek küçük görünen istekler toplandığında takvim kayar ve kimse nerede kaydığını gösteremez.

Kapsam belgesinin nasıl hazırlandığını yazılım projesinde kapsam belgesi ve fiyatlama, bakım döneminde nelerin kapsandığını ise yazılım bakım ve destek kapsamı yazısında ele aldık. Bu yazı ikisinin arasındaki boşluğu dolduruyor.

Talep nasıl kaydedilir?

Birinci kural: sözlü istek bir talep değildir. Toplantıda söylenen, telefonda geçen ya da mesajda kalan bir istek kayda geçmediği sürece ne planlanabilir ne de ölçülebilir. Kayıt tek bir yerde tutulmalı ve her talepte şunlar bulunmalı:

• İsteyen kişi ve tarih.
• İstenen davranış: ekranda ne olacak, hangi veri değişecek.
• Gerekçe: hangi iş sorununu çözüyor.
• Aciliyet ve kimin işini durdurduğu.
• Kapsam içi mi dışı mı değerlendirmesi.
• Etki tahmini ve verilen karar.

Üçüncü madde en çok atlanan ve en çok işe yarayan alan. Gerekçesi yazılı bir talep çoğu zaman daha basit bir çözümle karşılanabilir; gerekçesiz talep ise istendiği biçimde yapılır ve sonradan kullanılmaz. Taleplerin önemli bir bölümü gerekçe yazıldığı anda kendiliğinden küçülür.

Kapsam içi mi kapsam dışı mı?

Bu ayrım tartışmanın çıktığı yer olduğu için önceden yazılı bir ölçüte bağlanmalı. İşleyen ölçüt şu: kapsam belgesinde tanımlanmış bir davranışın eksik ya da hatalı çalışması kapsam içidir; belgede olmayan yeni bir davranış kapsam dışıdır. Ölçüt sezgiye bırakıldığında her talep bir pazarlık konusu olur.

Son satır bilinçli olarak belirsiz: resmî bir zorunluluk geldiğinde kapsam tartışması işi geciktirir. Bu tür talepler için projede baştan bir pay bırakmak, her seferinde yeniden pazarlık yapmaktan iyidir.

Etki nasıl ölçülür?

Etki yalnızca süre değildir. Bir talebin dört ayrı etkisi olur ve dördünü birlikte yazmak kararı kolaylaştırır: geliştirme süresi, test yükü, veri etkisi (mevcut kayıtlarda değişiklik gerekiyor mu) ve bağımlılık (hangi işler bu yüzden bekler).

Veri etkisi en çok hafife alınan kalem. Bir alanın zorunlu hâle gelmesi, mevcut kayıtların o alanı boş taşıdığı anlamına gelir; geçmiş kayıtların doldurulması çoğu zaman geliştirmeden uzun sürer. Benzer şekilde bir alanın anlamının değişmesi, o alanı kullanan raporların hepsini etkiler. Ölçütün değişince raporun neden tutmadığını rapor sayıları neden tutmaz yazısında anlatmıştık.

Etkiyi kimin tahmin ettiği de sonucu değiştirir. Tahmini işi yapacak kişinin vermesi, hem daha gerçekçi olur hem de sonradan itiraz üretmez. Tahminin tek bir sayı değil bir aralık olarak verilmesi ise belirsizliği görünür kılar: iki ile beş gün arası denen bir iş, kesin olarak üç gün denen bir işten daha dürüst planlanır. Aralığın üst ucu gerçekleştiğinde kimse şaşırmaz.

Kuyruk nasıl sıraya dizilir?

Onaylanan talepler bir kuyruğa girer ve kuyruğun sırası tek bir kişi tarafından belirlenmeli. Birden fazla kişi sıra değiştirebiliyorsa, en son konuşan kazanır ve ekip her hafta başka bir işe başlar. Sıra kararında işe yarayan üç ölçüt: kaç kişinin işini durdurduğu, ertelendiğinde maliyetinin artıp artmadığı ve başka bir işin önünü açıp açmadığı.

Kuyruğun görünür olması da en az sırası kadar önemli. Talebi açan kişi kaydın hangi sırada olduğunu görebiliyorsa, durumu sormak için kimseyi aramaz. Görünmeyen kuyruk, aynı talebin farklı kanallardan tekrar tekrar iletilmesine yol açar.

Reddedilen taleplerin de kuyrukta kalması gerekir. Kapatılan bir talep silindiğinde aynı istek birkaç ay sonra yeniden gelir ve ilk kararın gerekçesi hatırlanmaz. Gerekçesiyle kapatılmış bir kayıt, ikinci gelişte tartışmayı baştan açmaz; koşullar değiştiyse bu kez neyin değiştiği yazılır ve karar yenilenir.

Devreye alma ile ilişkisi

Onaylanan her talep hemen canlıya çıkmaz. Küçük düzeltmeler toplu olarak, davranış değiştiren talepler ise duyurusu yapılmış bir sürümle çıkar; çünkü kullanıcı ekranın bir sabah habersiz değişmesini hata sanar. Sürüm notunun hangi talepleri içerdiği yazılı olduğunda, hem talep sahibi hem kullanıcı ne değiştiğini bilir.

Devreye almanın ve geri dönüşün nasıl planlandığını yazılım devreye alma ve geri dönüş planı yazısında ele aldık; değişiklik talebi kuyruğu o planın girdisidir.

Kısa kontrol listesi

• Sözlü istek yok; her talep tek bir yerde kayıtlı.
• Her talepte gerekçe alanı dolu.
• Kapsam içi ve dışı ayrımı önceden yazılı bir ölçüte bağlı.
• Etki dört kalemde ölçülüyor: süre, test, veri, bağımlılık.
• Kuyruk sırasını tek kişi belirliyor ve kuyruk görünür.
• Davranış değiştiren talepler duyurulmuş sürümle çıkıyor.
• Sürüm notu hangi talepleri içerdiğini söylüyor.

Özet olarak değişiklik talebi yönetimi bir bürokrasi değil, kapsamın nerede büyüdüğünü gösteren bir ölçüm aracıdır. KAV Yazılım projelerinde talepler kayıtlı bir kuyrukta tutuluyor ve her talebin etkisi karar verilmeden önce yazılıyor.