Scrum'da, biriktirme listesini işlevsel bir biriktirme ve teknik biriktirme birikimine bölmeli ya da bölmemeli misiniz?

Scrum ekiplerimizde çoğunlukla işlevsel konular içeren ancak bazen teknik konular içeren bir biriktirme listesi kullanıyoruz. 1 biriktirme topluluğuna sahip olmanın avantajı, bir sonraki sprint için konuları seçmenin kolay hale gelmesidir, ancak bazı sorularım var:

• İlk olarak, bana göre, geliştiricilerin kendileri gibi saf teknik öğeler ekleyebilecekleri ayrı bir teknik biriktirmeye sahip olmak daha mantıklı görünüyor: bu yöntemde performansı artırabiliriz, bu sınıf bazı teknik belgelere sahip değildir, ... geliştiricilerin konularını biriktirmeye eklemek için her zaman ürün sahibi üzerinden geçmeleri gerekir, bu da ürün sahibi için ek, gereksiz bir iş gibi görünür.
• İkincisi, yalnızca saf işlevsel öğelere odaklanan bir ürün sahibiniz varsa, saf teknik öğeler (eksik teknik belgeler, aşınan ve yeniden düzenlenmesi gereken kod gibi, hata ayıklama sırasında her zaman sorun veren sınıflar, istikrarlı bir temel ve yeniden düzenlenmesi gerekir, ...) her zaman listenin sonunda yer alır çünkü "müşteriye doğrudan hizmet etmezler". Ayrı bir teknik birikim ve bu saf teknik ürünler için her sprintte ayrılan zaman sayesinde, uygulamaları işlevsel olarak geliştirebiliriz, aynı zamanda onları içeride sağlıklı tutabiliriz.

En iyi yaklaşım nedir? Bir iş listesi mi yoksa iki iş listesi mi?

Uzman değilim ama takım başına sadece bir birikmiş iş biriktirebileceğini söyleyebilirim. Ekibin hangi konuların acil olduğuna ve hangilerinin ertelenebileceğine karar vermesi gerekiyor. Sorunları ayrı yığın yığınlarına ayırırsanız, scrum'un kalbindeki temel düşünceye karşı gidersiniz, bu da bir sorun havuzu ve her sprint ekibinin en acil olarak çalıştığıdır. Takımları (alt bölümlere ayırırsanız), kendileriyle ilgili görev türlerini bölebilirsiniz, ancak temelde paralel çalışan takımlar kurarsınız. Aciliyet / zorunluluk bir sonraki sürat planlaması söz konusu olduğunda bir numaralı karar vericidir. Görevleri kategorilere ayırabilirsiniz, ancak bu karar sürecinize engel olmamalıdır.

Her ürün için bir iş listesi önerenlere sesimi eklemek istiyorum. Başka bir biriktirme listesi oluşturmak mantıklı bir yanıttır, ancak asıl sorundan kaçınmak gerekir: Ürün Sahibi neden teknik öğelere özellik öğelerine göre öncelik vermez? Etrafında çalışmak yerine bunu çözmeye odaklanmalısınız. Örneğin, şeylerin en altına inmeye çalışmak için 5 Whys tekniğini kullanabilirsiniz .

PO'nun teknik konulara öncelik vermemesinin birçok nedeni olabilir. Örneğin, teknik ekip, teknik borcu ele almamanın uzun vadeli maliyetini ($$$ olarak) açıklamıyor olabilir. Belki de tamamen başka bir şeydir. Bir iletişim sorununa bağlı olma şansı yüksektir ve uzun vadeli çözüm, üzerinde çalışmak ve çözmek - engeli ortadan kaldırmaktır.

Ayrıca, düşünmeniz gereken başka bir sorum daha var: Teknik borç neden ilk başta ortaya çıktı? İdeal olarak, yeniden düzenleme gibi işler fonksiyonel öyküler içinde gerçekleşmeli ve sürat içinde tamamlanmalıdır. Kendi başlarına fazladan hikayeler olmamalıdırlar, aksi takdirde potansiyel olarak gönderilebilir kodunuz yoktur.

Bahsettiğiniz şey genellikle 'teknik borç' olarak adlandırılır. Teknik borç işinin, kusurların yapabileceği şekilde scrum sürecine nasıl uyduğunu görmek bazen zor olabilir.

Teklif ettiğiniz şey, birikmiş işin 3'e bölünmesiyle ayrı bir 'kusur biriktirme listesi' olduğunu da önermeye benzer.

Şahsen, ürün biriktirme listesini bölmeyi hiç savunmam. Ürün birikmiş iş fikri, olağanüstü iş öğelerini temsil etmektir . Bu açıdan bakıldığında, bir özellik ile teknik borç kalemi arasındaki tek fark, gereksinimin müşteriden değil geliştirme ekibinden gelmesidir. Bu hala bir iş kalemidir ve diğer iş kalemlerine göre öncelik verilmesi de dahil olmak üzere hala yönetilmesi gerekmektedir. Bu, özellikle teknik borç kalemi test gerektiriyorsa geçerlidir, bu durumda normal bir özellikle aynı KG sürecinden geçmelidir.

Onno ile proje başına tek bir birikmiş iş olması gerektiğine katılıyorum. Aksi takdirde, ekip temel olarak ürün sahibine ait olan bazı kararları kendi elleriyle alır.

"Tamamen teknik" öğeler bile kullanıcılar (ve dolayısıyla ürün sahibi için) sprint biriktirme listesi için uygun olacak bazı pratik değerlere sahip olmalıdır. Bunların faydasını ürün sahibine açıklamak ve onu maliyeti haklı çıkaran katma değere ikna etmek sizin görevinizdir. Ve bu süreç sizi bu konularda düşünmeye ve projeye en az çabayla en fazla değeri getiren teknik değişiklikleri seçmeye zorlar.

Yukarıdaki tüm cevaplara katılıyorum. Ticari gerçekliğin sıcağında, PO teknik hikayelere göre fonksiyonel hikayelere öncelik vermeye devam edecektir. Genellikle takımın hayal kırıklığına uğraması. Ekip, kullanıcı değeri olmayan teknik hikayelerden kaçınmalıdır (hız bir sorun değilse optimizasyonu kimin umurunda?) Ve fonksiyonel hikayelerin ima ettiği diğer bazı teknik görevleri görmeyi öğrenmelidir. "Tamamın tanımı" da büyük bir rol oynamaktadır. Kalan işlevsel öyküler PO'nun öncelik sırasına göre biriktirmeye devam eder.

Örnek: Teknik dokümantasyon: Teknik dokümanların (varsa) mevcudiyeti, DOD'a ait olan tipik bir maddedir ve bu nedenle, güncellenmesi her işlevsel öykü ile YASAKTIR.

Örneğin, Yeniden düzenleme kodu: ürün geliştirmeye faydalı olduğunda yapılmalıdır. Daha önce değil (ekip ürünün hangi yönde evrimleşeceğini varsaymamalıdır) ve daha sonra teknik borca ​​dönüştüğünde değil. Tasarımın gözden geçirilmesi DoD'nin bir parçası olabilir.

MelR ile hemfikirim. 'Teknik' bir şey varsa, neden yaptığımıza bakmamız gerekir - hatta kısa ve uzun vadeli neden ve sonuç (kullanıcı için) nedir?

Ben sözde 'teknik görevler' bir iş değeri bir şekilde kolayca yazılabilir birçok birikmiş işler gördüm.

Teknik görevler genellikle büyük parçalanmış hikayelerin bir sonucudur, çünkü işleri parçalamanın daha kolay yolu olabilir. Ancak bu, gerçek katma değerin (veya geri bildirim fırsatlarının) daha yavaş tekrarlanmasına veya hatta sprintlerin başarısızlığına neden olabilir.

Patrick'in bahsettiği gibi "erozyona uğrayan ve yeniden düzenlenmesi gereken kod" ile ilgili olarak, sormamız gerektiğine inandığımız - bu kodun sistem işlevselliğinin hangi alanını etkilediğine inanıyorum? ve şimdi yeniden düzenleme yapmazsak kullanıcı üzerindeki uzun vadeli etkisi nedir?

Sonra, uzun vadeli teknik borcu azaltmak için "işleri bulduğumuzdan biraz daha iyi bırakma" konusu var ve bu daha geniş proje üzerinde çok fazla etkisi olmadan her sprint'teki küçük hikayelerin bir parçası olarak yapılabilir mi?

Nihayetinde, iki öncelikli birikime ihtiyacım olduğunu görmüyorum, bu, önceliklendirilmiş ihtiyaçları yavaşlatmak için bir fırsat yaratıyor - ancak teknik etkilerin kaygıları konusunda eğitim görmüş ve gerçek değeri tanımlama konusunda güçlü bir yeteneğe sahip bir ürün sahibine ihtiyaç var. hikayeleri dikey olarak parçalamak için - Adobe dikey dilimleme hakkında iyi bir açıklama sunar .

Hayır, asla teknik hikayeler yaratmamalısınız. Bu yaygın bir hatadır. Hikayelerinizin işletme gereksinimlerini yansıtması gerekir. Teknik şeyler asla gerçekten iş gereksiniminden değildir. Bu, scrum ustasının ve ekibin, amaca veya hikayeye ulaşmak için yapmaları gereken tüm teknik görevleri değerlendirmedeki rolüdür.

Hikayeniz, örneğin bir giriş ekranı oluşturmakla ilgiliyse, henüz oluşturulmamışsa da veritabanının oluşturulmasını dikkate almanız gerekir.

BT ekibinin kullanıcı olduğu PO'larla görevler oluşturma sorununu görmüyorum. Görev PO tarafından anlaşılabiliyorsa ve iş değeri açısından değerlendirilebiliyorsa, evet, bir tür teknik hikaye yaratmanın bir yolu var. Sadece sistemi kullan.