Vaka dosyası
Karar vermeden önce kanıtı ayır.
Dört görünüm aynı durumu farklı açıdan açar. Bir görünüm seçmek ilerleme kaydı oluşturmaz.
Görev
Bu durumda neyi değerlendireceksin?
Senaryo sonunda kullanıcı,
- 01
Technical Debt'i eski veya sevmediği kodun genel etiketi yapmadan gelecekteki değişiklik ve bakım etkisi üzerinden konuşabilmelidir.
- 02
Feature işi ile borç giderimini;
- 03
ürün hedefi, gecikme maliyeti, gözlenen tekrar iş, risk, bağımlılık, çözüm maliyeti ve belirsizlik birlikte görünürken değerlendirebilmelidir.
- 04
Ayrıca borç kaydını refinement ile karar verilebilir hâle getirmeyi ve takip Ownership'ini açık bırakmamayı değerlendirebilmelidir.
Rol ve ekip
- Rolün
- Bir ödeme ürünü ekibinde ilk ayındaki junior geliştiricisin. Günlük ekip eşgüdümünde tekrar eden bir değişiklik maliyetini fark ettin ve ayrıntılı değerlendirme için Backlog/Refinement görüşmesine katılıyorsun.
- Ekip ve ürün bağlamı
- Ekip Product Backlog ve refinement terimlerini Scrum anlamında kullanıyor. Aşağıdaki item şeması, puanlar, roller ve karar akışı bu temsili ekibe aittir; Scrum'ın Technical Debt için zorunlu kıldığı bir şablon değildir.
Metafor, pratik ve metodoloji sınırı
Cunningham'ın özgün borç metaforu, erken çalışan yazılım ile sonradan konsolide edilmeyen yapının gelecekteki değişiklik maliyeti arasındaki gerilimi anlatır. Bu tek proje deneyim raporu, bütün eski veya dağınık kodu otomatik Technical Debt yapmaz ve evrensel bir geri ödeme sırası vermez.
Fowler'ın prudent/reckless ile deliberate/inadvertent ayrımı, borcun hangi bağlamda oluştuğunu konuşmaya yarayan bir practitioner düşünme çerçevesidir; hakemli standart veya zorunlu sınıflandırma değildir. SEI kaynakları borcu görünür kılma, yeniden çalışma etkisini değerlendirme ve bağlama özgü trade-off'ları yönetme pratiğini destekler; tek ve genellenebilir bir borç metriği olmadığını da açıklar.
Scrum Guide bu senaryoda yalnız Product Backlog'un ordered ve emergent olması, refinement'ın item'ları daha küçük ve kesin hâle getiren sürekli bir faaliyet olması, Developers'ın sizing sorumluluğu ve Product Owner'ın etkili Backlog yönetimi accountability'si için kullanılır. Rehber, Technical Debt'i Feature'dan önce veya sonra sıralayan evrensel bir kural tanımlamaz.
Kanıt sınırı
- Bildiğin
- Yaklaşan mobil cüzdan Feature'ı aynı ödeme yönlendirme alanını değiştirecek. Son iki temsili değişiklikte aynı doğrulama kuralı üç yerde düzenlenmiş ve bir eksik yol release öncesi testte yakalanmış. Borç adayının sınırı ile giderim süresi henüz doğrulanmadı.
- Kasıtlı olarak eksik bırakılan
- Yeni Feature'ın üç yolu da değiştirip değiştirmeyeceği, iş ortağı takviminin esnekliği, mevcut testlerin güveni, konsolidasyonun tüm edge case'leri koruyup korumayacağı ve daha geniş refactor'ın gerçek maliyeti başlangıçta bilinmiyor.
Temsili kayıt
Temsili Backlog/Refinement notu ve ekip konuşması — özgün ve kurgusaldır; gerçek bir şirket kaydı, toplantı tutanağı veya alıntı değildir. Bütün sayılar yalnız bu senaryonun karar bağlamını kurar.
Product Goal: Ödeme tamamlama oranını artırırken başarısız ödeme davranışını öngörülebilir tutmak.
FEAT-91 — Mobil cüzdan ödeme seçeneği
- Beklenen katkı: Kampanya öncesi desteklenen ödeme seçeneklerini artırmak
- Hedef tarih: 12 gün sonra başlayan temsili iş ortağı kampanyası
- Bağımlılık: Ödeme yönlendirme ve doğrulama kuralları
- Bilinen belirsizlik: Feature'ın üç mevcut yolu da değiştirip
değiştirmeyeceği teyit edilmedi
DEBT-34 — Yönlendirme doğrulamasının üç yerde tekrarlanması
- Gözlenen sinyal: Son iki temsili kural değişikliğinde üç uygulama noktası
ayrı düzenlendi; bir yol release öncesi testte eksik bulundu
- Bugünkü etki: Değişiklik incelemesi ve test kapsamı üç yol için tekrarlanıyor
- Gelecek etki hipotezi: Aynı alandaki yeni değişiklikler yeniden çalışma ve
tutarsız davranış riskini artırabilir
- Giderim adayı: Ortak doğrulama sınırı oluşturmak ve üç yol için davranış
testleri eklemek
- İlk tahmin: 2–4 gün; edge case incelemesi yapılmadan güvenilir değil
- Scope dışı: Bütün ödeme modülünü yeniden yazmak
- Takip sorumlusu: Deniz — item görünürlüğü, eksik kararların takibi ve
yeniden değerlendirme çağrısı; bütün uygulamayı tek başına yapma veya bütün sonuçların suçu değil
- Yeniden değerlendirme tetikleyicisi: FEAT-91 geliştirmesi başlamadan önce
- Açık sorular: FEAT-91 hangi yolları değiştiriyor? Mevcut davranış testleri
konsolidasyon için yeterli mi? İş ortağı tarihi ne kadar esnek?
Temsili ekip konuşması
Junior: “Eski olduğu için değil, aynı kuralı her değişiklikte üç yerde takip ettiğimiz ve bir yolu kaçırdığımız için bunu borç adayı olarak açtım.”
Product Owner: “Feature değeri ve tarih görünür; borcun aynı Feature'a etkisi ile giderim belirsizliğini netleştirirsek order kararını güncelleyebilirim.”
Developer: “Önce hangi yolların gerçekten değişeceğini ve ortak sınırın davranışı koruyacağını doğrulayalım; 2–4 gün şu an aralık, taahhüt değil.”
Bu not Technical Debt'in kesin parasal değerini hesaplamaz. Gözlenen etkiyi, gelecek etki hipotezini, belirsizliği, olası giderimi ve takip sorumluluğunu aynı yüzeyde görünür kılar.
Bölüm 1 / 4
Temsili Backlog/Refinement notu ve ekip konuşması — özgün ve kurgusaldır; gerçek bir şirket kaydı, toplantı tutanağı veya alıntı değildir. Bütün sayılar yalnız bu senaryonun karar bağlamını kurar.
Product Goal: Ödeme tamamlama oranını artırırken başarısız ödeme davranışını öngörülebilir tutmak.
FEAT-91 — Mobil cüzdan ödeme seçeneği
- Beklenen katkı: Kampanya öncesi desteklenen ödeme seçeneklerini artırmak
- Hedef tarih: 12 gün sonra başlayan temsili iş ortağı kampanyası
- Bağımlılık: Ödeme yönlendirme ve doğrulama kuralları
- Bilinen belirsizlik: Feature'ın üç mevcut yolu da değiştirip
Bu not Technical Debt'in kesin parasal değerini hesaplamaz. Gözlenen etkiyi, gelecek etki hipotezini, belirsizliği, olası giderimi ve takip sorumluluğunu aynı yüzeyde görünür kılar.
Karar oynatıcısı
İlerlemen yükleniyor…