Yazılım değişiklik talebi, “şuraya bir alan ekleyelim” mesajından daha fazla bilgi taşımalıdır. İhtiyaç, beklenen değer ve etkilenen akış görünür olduğunda ekip doğru çözümü ve önceliği tartışabilir.
Talep formunun asgari alanları
- Mevcut durum ve yaşanan sorun
- Etkilenen kullanıcılar ile sıklık
- Beklenen iş sonucu
- Örnek kayıt veya belge
- İstenen tarih ve gerekçesi
- Talep sahibi ile karar sahibi
Çözüm önerisi yazılabilir; fakat problem açıklamasının yerini almamalıdır.
Etki analizi
Arayüz, veri modeli, yetki, rapor, entegrasyon, veri geçişi, test, eğitim ve işletim etkisi incelenir. Benzer mevcut işlev veya planlı sürümle birleştirme fırsatı aranır. Teknik risk ve tahmin, iş değerinden ayrı sunulur.
Öncelik ve karar
Gelir etkisi, kullanıcı sayısı, risk azaltma, zorunluluk, sıklık ve efor birlikte değerlendirilir. “En yüksek sesli talep” otomatik olarak ilk sıraya geçmez. Onay, erteleme veya ret gerekçesi talep sahibine görünür olmalıdır.
Teslim zinciri
Onaylanan talep kabul kriterine dönüşür, hedef sürüme alınır, test edilir ve yayın notunda belirtilir. Sonuçta beklenen fayda gerçekleşti mi izlenir. Kullanılmayan değişikliklerin nedenleri sonraki öncelik kararını besler.
Talep portföyünü temizleyin
Uzun süredir bekleyen her talebi güncel ihtiyaç, kullanıcı sayısı ve benzer yeni işlev açısından yeniden doğrulayın. Talep sahibi ayrılmış veya süreç değişmişse kayıt otomatik sonsuza kadar açık kalmamalıdır. Birbiriyle ilişkili talepleri tek sonuç altında gruplayın; çelişen taleplerde karar sahibini çağırın. Teslim edilen değişikliğin kullanımını ölçmek, sonraki taleplerde beyan edilen değer ile gerçekleşen değeri karşılaştırmaya yardım eder.