Dokümantasyon bir Kullanıcı Hikayesi midir? [kapalı]

Son birkaç sprint için üzerinde çalıştığımız bir ürün için bazı kullanıcı belgeleri yapmamız gerekiyor. Şimdi bir sonraki sprint'te yeni bir projeye başlıyoruz ve PO daha önce üretilen ürünün belgelerini bu sprint için bir Kullanıcı hikayesi yapıyor.

Sadece bu yaklaşım hakkındaki düşüncelerinizi merak ediyorum. Şahsen, herhangi bir kod üretmediği için belgelerin Scrum'da bir Kullanıcı Hikayesi olduğunu kabul etmiyorum.

EDIT: Düşünceleriniz için teşekkürler çocuklar. Bir sprint çalışan yazılımın bir artışını uygulamak olduğunu kafamın arkasında buldum, ancak görüşleriniz benim bakış açımı değiştirdi. Tüm cevaplarınız için teşekkür ederim.

"X kullanıcısı olarak, X'in nasıl çalıştığını bilmem gerekiyor" bana yasal bir kullanıcı hikayesi gibi geliyor. Bu yazılı belgelere veya çevrimiçi yardıma neden olabilir.

Mesele sadece kod değil, kullanıcıların gereksinimlerini de karşılamaktadır.

İdeal olarak, dokümantasyon her kullanıcı hikayesinin bir parçasıdır ve asla oluşmaz. Ancak, gerçek dünyada, bu genellikle olmaz. Bu durumda, belirli bir eksik belgeyi yakalamak için bir kullanıcı hikayesi oluşturmalısınız.

Haklısın, herhangi bir kod üretmiyor. Ancak bir kullanıcı gereksinimini karşılar ve diğer kullanıcı gereksinimlerine göre önceliklendirilmelidir.

Eğer bu hiç yapılmadığı anlamına gelirse, bu ve bu işlevsellik üzerinde çalışıldığı için muhtemelen bu belgelere çok fazla ihtiyacınız yoktu.

Gereksinim, teknik veya proje belgeleri ile ilgili ise pdr'nin belge değerlendirmesine katılıyorum. İdeal olarak sprint çalışmasına dahil edilmelidir.

Ürün dokümantasyonu Çok farklı olduğunu hissediyorum çünkü gerçek bir kullanıcı teslim talep ve doğrudan kullanıcıya değer sağlar. Bu Ürün Belgeleri esasen olduğunu elbette anlaşılmalıdır değil Teknik Görev ama Fonksiyonel Görev ve ya proje üzerinde teknik bir kaynak için uygun bir aktivite olabilir de olmayabilir de.

Bunun bir kullanıcı hikayesi olması gerektiğini düşünüyorum, ancak iş gereksinimlerini, kullanıcı perspektifini ve iyi teknik yazma becerilerini sağlam bir şekilde anlayan bir proje kaynağına bu görevlerin verilmesi gerektiğini düşünüyorum. İdeal olarak bu, eğer varsa, bir iş analisti veya belki de gereksinimleri, kullanıcı hikayelerini ve iyi teknik yazma becerilerini sağlam bir şekilde anlayan daha yüksek dereceli bir QA test cihazı olacaktır. Bu aynı zamanda bir geliştirici olabilir, ancak geliştiriciler tarafından yazılan ürün belgeleri, yüksek kalitede veya yararlı olma eğilimindedir, çünkü geliştiriciler genellikle teknik ayrıntılara çok yakındır.

Organizasyonumuzda, sürekli entegrasyon sistemimizi korumak ve geliştirmekle görevli takım ekibi, Scrum'u işlerini yönetmelerine yardımcı olmak için kullanıyor. Kod yazmıyorlar ama yine de Scrum'ı uyguluyorlar.

Sorunuzu özel olarak cevaplamak için, ekibin belgelerin "Bitti Tanımı" nın bir parçası olup olmadığını düşünmesini isterim.

Ekip, dokümantasyonun "tamamlanma tanımı" nın bir parçası olduğunu düşünürse, ek bir hikayeye gerek yoktur ve dokümantasyon yazılı ve doğrulanmadıkça hikaye kabul edilemez.

Ekip, belgelerin "tamamlanma tanımı" nın bir parçası olmadığını düşünürse, Ürün Sahibinin çalışmalarını yönetebilmesi için ayrı bir hikaye oluştururdum.