Scrum, kullanıcı öykülerinden ziyade Ürün İş Listesi'nde teknik özellikleri kullanabilir mi?

Halen çalıştığım şirkette Scrum projeleri yapmaya başladık. Yöneticileri şelaleden Scrum'a geçmeye ikna etmek o kadar da zor değildi. Platformumuzu sıfırdan yeniden oluşturduğumuz bir proje yapıyoruz. Bu nedenle (çoğu) işlevsellik bilinir ve çoğu geliştirme oldukça tekniktir.

Bunda kullanıcı hikayeleri yerine teknik görevlere sahip olmak haklı görülebilir. İş birikimimiz aşağıdaki gibi her türlü teknik göreve sahiptir:

• DB sınıfını MySQL'den PostgreSQL'e yeniden yazın.
• Sistem günlüğü tutma.
• Nesne önbelleğini yeniden yazın.

Stand-up sırasında ortaya çıkan şeyler arasında uzun "araştırma görevleri" isteniyor, ancak bunlar asla yapılmıyor. Ayrıca, takım üyeleri sprint ortasında planlanmamış görevlerin eklenmesi gerektiğini iddia ediyor.

Bir Scrum Master bununla nasıl başa çıkmalı? Bu tür bir proje için, Scrum gidilecek yol DEĞİL olabilir mi?

TL; DR

Scrum, kullanıcı öykülerinin kullanılmasını zorunlu kılmaz; bunlar sadece yararlı bir çevik uygulamadır. Ürün Sahibi, Ürün İş Listesi'ni oluşturmak için kullanıcı hikayeleri yerine teknik özellikleri kesinlikle kullanabilirken, diğer işlem sorunlarınızın çoğu etkili Scrum ve çevik uygulamaları benimsememekten kaynaklanır.

İşleminizle İlgili Çeşitli Sorunlar

Scrum'ınız aşağıdakiler de dahil olmak üzere çok çeşitli şekillerde kırılmış gibi görünüyor:

1. Spesifikasyonlarınızda açık bir bakış açısı veya değer teklifi yok.
2. Biriktirme listesi öğeleriniz Sprint Hedeflerine bağlı değildir.
3. İş Listesi Bakım işleminiz tamamen eksik ya da Ürün İş Listesi için hikaye ani artışları oluşturamıyor.
4. Sprint Planlama işleminiz Ürün İş Listesi öğelerini Sprint İş Listesi öğelerine yeterince ayrıştırmıyor.
5. Ekibiniz, Sprint Planlama tahminlerine biriken işler hakkındaki belirsizliği düzgün bir şekilde dahil etmiyor.
6. Ekibiniz zaman boksunun temellerine veya Sprint'in bütünlüğüne saygı duymuyor.

Scrum her proje için her zaman uygun olmasa da , bu durumda Scrum'ın çalışmadığını söylemek daha doğru olur çünkü takım gerçekten Scrum yapmaz. Kullanıcı hikayeleri hakkındaki sorunuz, ekibinizin karşılaştığı daha büyük süreç sorunlarının yalnızca küçük bir kısmıdır.

Agile Programcıları Neden Kullanıcı Öykülerini Kucaklıyor?

Teknik özellikler, gereksinimleri iletmek için temelde kırılmış bir yoldur. Bir bakış açısından bağlanmamış olan gereksinimler, geliştiriciler için herhangi bir yararlı rehberlik sağlamaz. Gönderilen örneklerinizi kullanarak:

• Nesne önbelleğini yeniden yazın. Neden? Amaç nedir? Kim para alıyor? Görev hakkında kimler açıklama yapabilir? Bu, işlevsel olmayan bir gereksinime bağlıysa, bu hangi proje hedefine hitap eder?
• Sistem günlüğü tutma. Neden? Günlükleri kim okuyacak? Günlüklerin hangi bilgileri içermesi gerekir? Günlük biçiminin veya günlük verilerinin yararlı olup olmadığını nasıl anlayacaksınız?

Bir geliştiricinin bakış açısından, bu tür sorulara cevap verememek, tam olarak tarif ettiğiniz süreç sorunlarına yol açar. Kullanıcı öyküleri bunu yapar: çok ihtiyaç duyulan bağlam sağlarlar ve belirli özellikler hakkında paydaşlarla veya son kullanıcılarla ek görüşmeler için yer tutucu görevi görürler.

Kullanıcı öykülerini kullanmamalısınız, çünkü bunun bir çerçeve gereksinimi olduğunu veya yaygın olarak kabul edilen bir çevik uygulama olduğu için. Bunun yerine, bunları etkili bir şekilde oluşturma ve kullanma üzerinde çalışmalısınız çünkü programlama görevlerini daha kolay ve programlama mesleğini daha eğlenceli hale getirir. Yaptığınız mil değişebilir, elbette.

Buradaki problemin Scrum olduğunu düşünmüyorum, problemin net bir şekilde tanımlanmış bir proje olmaması ve (bunu birçok kez yaşadım) net bir yön olmamasıdır.

Teknik görevlerinizin büyük olasılıkla büyük olasılıkla iyi olduğunu, ancak bir hikaye için ölçülebilir ve tanımlanabilir olduğunu düşünüyorum.

Scrum'da araştırma görevleri benim için büyük bir kırmızı bayrak çünkü çok az görünür fayda sağlıyorlar ve muazzam kapsam sürünmesi yaratabilirler. Bunları bir süratle sınırlamayı savunuyorum, eklenmemeli ve kesinlikle taahhüt edilen hedefler pahasına eklenmemelidir. Kararlaştırılmış bir sürat görevini tamamlamaları gerekiyorsa, o zaman bu bağımlılık planlamada net olmalıydı (aksi halde ne tahmin ediyorlardı?).

Deneyimlerime göre, çok sayıda "araştırma sivri" olan projeler, aslında çok fazla şey yapmayan ve iş değeri yaratmak yerine yeni parlak havalı şey hakkında bilgi edinmek için zaman harcamak isteyen geliştiriciler için bir kapaktır. Ekibinizin bunu yapmasını önermiyorum, ancak bir projenin net hedeflere ihtiyacı var ve eğer geliştiricilere "araştırma" özgürlüğü tanınırsa, bunu yapacak ve izin verdiğiniz sürece yapmaya devam edecekler.

Scrum, müşterinize teslim edilebilir bir ürün almanızın daha iyi olacağını söylüyor. Ancak buradaki nokta, teslim edilebilir ürünü ve müşteriyi belirtmemesi .

Başka bir deyişle, özel durumunuzda, teslim edilebilir ürününüzü kod iyileştirmeleri, platform değişiklikleri, yeniden yazma ve yeniden tasarımlar vb. Olarak tanımlayabilir ve teknik yöneticinizi müşteriniz olarak düşünebilirsiniz.

Bu benim için% 100 mantıklı. Ürünlerinizin kullanıcı hikayelerini anlatan bir biriktirme listesi oluşturursunuz ve kullanıcı kimdir? Teknik Müdür. Böylece öğeler gibi:

1. Teknik yönetici olarak, veritabanımın MySQL'den X'e değişmesini istiyorum, böylece ölçeklenebilirliği artırabilirim
2. Geliştirici olarak, daha verimli bir şekilde teşhis koyabilmek için kapsamlı bir günlük sistemi istiyorum

Ve müşterinize teslim ettiğiniz şey (teknik müdür) bir kayıt sistemidir.

Ancak, bahsettiğiniz Ar-Ge görevleriyle ilgili olarak Scrum'daki ani artışları okumanızı tavsiye ederim . Bunlar aslında, daha büyük tanıdık olmayan görevleri yerine getirmek için gereken süreyi belirlemenize yardımcı olan, zamana bağlı mini görevlerdir.

Scrum Master olarak, işin doğası gereği daha uzun sprintleri düşünmek isteyebilirsiniz. Bu size "araştırma" görevleri için biraz daha bir tampon verecektir. Ancak, görevlerin bir çeşit iş ürünü / koddaki kavram kanıtı ürettiğinden emin olmanız gerektiğini düşünüyorum. Bir programcının ne yapmasını bekliyorsunuz? Onlardan çalışmak için bir şeyler almalarını isteyin ve A: istediğimizi yapıp yapmadığını belirlemek için bu bilgileri kullanın B: daha iyi performans gösterir C: Daha fazla hızlanmak ve ne kadar süreceği hakkında herhangi bir fikir edinmeye başlamak ne kadar sürer bir şey yapmak.

Mevcut yeniden yazma hakkında düşündüğünüz kadar bilmediğinizi fark ederseniz, daha kısa sprint döngülerine gidebilirsiniz. Siz ilerledikçe onları ayarlamaktan korkmayın; çevik olmakla kastedilen budur. Araştırmanızdan sonra yeni teknolojiyi kullanmaya da karar verebilirsiniz. Bu, kontrolden çok uzaklaşmadan sprintleri kısaltmak için başka bir neden olabilir. Bir sprint ortasında yeni şeylerin işe yaramayacağını keşfedebilirsiniz. Sprint'i durdurun ve eski teknolojiyle ayarlayın. Daha sonra, geliştiricilerinizin eski ve yeni yöntemleri karşılaştırabilmeleri ve karşılaştırmaları gerekirdi.

Geliştiricilerinizin ihtiyaçlarını dengeliyorsunuz ve bu durumda uygulamayı yeniden yazıyorsunuz. Bu projenin daha sonra değil, daha kısa sürede tamamlanmasını isteyen ve "araştırma" ihtiyacını uzun vadeli bir mazeret olarak kabul etmeyecek Ürün Sahipleri olduğunu tahmin ediyorum.

Aşağıdaki stratejilerden bazıları yardımcı olabilir,

1. Evet, Teknik öykülerle bir biriktirme listesi oluşturabilirsiniz .

   Bir kullanıcı hikayesi gibi bu da son kullanıcıya getireceği faydalara odaklanarak Teknik Hikayeler olmalıdır. İşte yazmanız için bazı ipuçları. Bunlar, daha iyi bir arka uca geçmek istediğiniz gibi ürüne içsel değer getirecek hikayelerdir.

2. Soruşturma (Araştırma) Görevleri için Spike Kullanın

   Spike, geliştiricilerin, bir kullanıcı hikayesinde bilinmeyen bir şey, örneğin yeni bir teknoloji hakkında, bu kullanıcı hikayesini tahmin edebilecek kadar yeterince öğrenmelerini sağlayan bir deneydir. Spike zaman kutulu olmalıdır. Bu, öğrenmeye harcanacak maksimum süreyi tanımlar ve sivri uç için tahmini belirler.