Burada nispeten küçük yeni bir yazılım geliştirme projesinin kapsamını belirleme ve tahmin etme sürecindeyim. Müşterinin önerdiği kullanıcı hikayelerini inceledim ve görevin nasıl yerine getirileceğine dair bir tahmin ve bazı kısa notlar ile her birine karşı görevler yerleştirdim. Kabul kriterleri vardır. Herkes dünya ile iyi olmalı.
Planladığım işe baktığımda eksik bir şey olduğunu fark ettim. İşlevselliği civatalayabileceğimiz şeylerin ayarlanmasında ilk harcama olacak. Belirli bir kullanıcı hikayesine değil, tüm kullanıcı hikayelerine ait olan şeyler.
Örneğin, bu uygulamanın bir kısmı XML ayrıştıran bir hizmettir. Kullanıcının bakış açısından, XML içeriğine bağlı olarak farklı şeylerin yapılması gereken belirli hikayeler vardır. Aslında bir XML ayrıştırıcısı yazmak - bir dosyayı arayan, okuyan ve içeriklerle ne yapacağına karar vermeden önce ilgili verileri çeken bitler - tüm bu hikayelerin bir parçasıdır. Bir yükleyici vb. İle bir Windows hizmetine sarmak gibi. Bir kullanıcı ile doğrudan ilgisi olmayan geliştirici merkezli bir görevdir.
Bu özel uygulamadan bir başka ilgili örnek, bu uygulamanın işlevleri için yararlı olan kötü eski kod bloğunu almak ve yeniden yazmaktır. Yine, bunun kullanıcı için hemen bir sonucu yoktur, ancak gerekli çalışmadır. Bu çalışmanın planlanması ve yürütülmesi kullanıcı öykülerine odaklanan bir proje planında nerede yaşıyor?
İnsanların "Bir geliştirici olarak ... istiyorum ..." kullanıcı hikayeleri yazarak bunu çözdüklerini gördüm ama başka bir yerde tartışıldığı gibi bu bir kullanıcı hikayesi değil . Bu bir geliştirici.
TFS gibi katı yönetim çerçevelerini kullanarak proje planlamada bana (ve diğerlerine) yardımcı olmak için buna somut bir cevap arıyorum. Bunlar , bir Scrum ekibi planlama toplantısında altyapı görevlerini nasıl açıklar? Bölümünde verilen yanıtlarda belirtilen "paydaş öyküleri" veya diğer belirsiz meta çözümler yapma işlevine sahip değildir.