Pivotal Tracker kartım için bazı teknik borçları ele alan birkaç kullanıcı hikayesi ekledim. Bunları özellikler (hız seviyemi koruyarak) veya ev işleri / hatalar (hızımı düşürme) olarak mı düşünmeliyim? Birini ya da diğerini sürekli yapsam uzun vadede bir fark yaratmayacağını anlıyorum, ancak her teknik borç hikayesi eklediğimde kararı vermeliyim.

Bazı düşünceler:

• Aslında böcek değiller, hiçbir şey kırmıyorlar
• Kullanıcılar, onları etkilemeyen düşük düzeyli bir uygulama olduğu için hiçbir şey talep etmedi, ancak uzun vadeli gelişimi kolaylaştıracak
• Özellikleri kullanıcılara değer katan hikayeler olarak tanımlarsanız, a) kullanıcılar hiçbir doğrudan fayda görmeyecekleri gibi b) ancak b) yaparlar çünkü gelecekteki geliştirme / bakımı mümkün kılan , değer katan, şu an değil

İşi gerçekten yapıp yapmayacağımı veya ne zaman planlayacağımı kararlaştırmıyorum, sadece proje yönetimi aracımda teknik borç ne demem gerektiğini ve nedenini bilmem gerek.

Bu bir özellik.

As a [Developer], 
I want to [refactor the whizbang library] 
in order to [simplify maintenance and speed execution]

Diğer özellikler gibi tanımlanır ve zamanlanır ve izlenir.

Bu özelliğin uygulanması, planlanması için (müşteri veya sizin için) yeterince değerli değilse, bu farklı bir sorundur.

(Geri ödeme) teknik borç bir özellik değildir , çünkü müşteri bu konuda karar almaya yetkili değildir . En önemlisi, müşteri ne zaman bittiğine karar veremez ve ek olarak müşteri faydaları açıklamak için tamamen size bağımlıdır. Teknik borç olduğu yargınızdır ve bunu nasıl düzelteceğinize ve ne zaman bitirdiğinize karar vermek size bağlıdır. Teknik borç, müşterilerin yazılım algısını değil (gelecekteki) hızınızı etkiliyor. Borç olmasaydı daha üretken olurdun. Ve şimdiye kadar ölçtüğünüz hız yanlış, çünkü kodu formda tutmak için daha fazla zaman harcamalıydınız.

Bunu müşterinizle paylaşmanız gerektiğini düşünüyorum, ancak bu onların kontrolünde bir şey değil. Şöyle bir şey söyleyebilirsiniz: 'Şimdiye kadar düzeltmemiz gereken birkaç kısayol kullanıyoruz. Bu, önümüzdeki birkaç yinelemede hızımızın biraz düşeceği anlamına geliyor, ancak bu, uzun vadede sürdürülebilir yazılımımız olduğundan emin olmak için. '

Müşterinin özelliğiyle ilgili sürekli çalışma, mükemmel tasarımı bulmak için bir tür akademik egzersiz yapmak yerine, müşteri için yazılımı geliştirmeye odaklanmanıza yardımcı olacaktır (bu bazen kişisel olarak mücadele ettiğim bir şeydir).

IMHO teknik borcu ortadan kaldırmak için bir görev kesinlikle bir özellik değildir. Bu "hata" departmanına kürekle olabilir, ama yine kullanıcılar tarafından gözlemlenebilir davranış değişikliklerine yol açmaz gibi, terimlerin tanımını uzatmak olacaktır.

Ben buna sadece bakım görevi derdim. Herhangi bir geliştirme projesinde, dev / test ortamının kurulması, test verilerinin birleştirilmesi, SCM'de şubelerin birleştirilmesi vb. Gibi pek çok görev vardır. Bunların hiçbiri doğrudan kullanıcılar tarafından gözlemlenemez, ancak düzenli olarak yapılmaması gelişmenin artmasına neden olur. maliyetler ve uzun vadede hata oranı.

Bunları ayrı görevler olarak ele almanız gerekmeyebilir (çok büyük olmadıkları ve / veya şu anda yeni özellikleri uygulama baskınız yoksa). Genellikle yeni bir özelliğin ne zaman yeniden düzenleme / yazma birimi testleri vb. Gerektirdiğini belirlemek ve bunları yeni özelliğin geliştirilmesinin bir parçası olarak ele almak daha iyi olabilir. Bu hem yönetime hem de son kullanıcılara açıklamak daha kolay olabilir (eğer zamanınızı ne harcadığınızı bilmek istiyorlarsa). Güncelleme: Ayrıca, geliştiricilerin de yeniden düzenleme değerine odaklanmalarına yardımcı olur. Yeniden düzenleme uğruna yeniden düzenlemeye taşınmak kolaydır, bu nedenle müşterinin bakış açısından belirli bir yeniden düzenlemenin getirdiği katma değere odaklanmak IMHO yararlıdır.

Ben buna bir derdim improvement.

Hata değil çünkü hiçbir şey bozuk değil.

Ne de bir özellik, çünkü yeniden düzenleme müşterinizin bir isteği olmayacaktır. (çünkü işe yarıyor!).

Çoğu izleme sistemi improvementvarsayılan olarak bir sorun türünü destekler , aksi takdirde türleri yine de değiştirebilirsiniz.