Scrum ekibi üyelerinden birini veya scrum master'ını Ürün Sahibi olarak atamak iyi bir fikir mi?

Son zamanlarda müşterinin gezmekle meşgul olduğu bir projemiz vardı. Her zamanki scrum ekibi kurulduğu gibi, müşteri aktif olarak katılamayacağı için yönetim analistimizi Ürün sahibi olarak atamaya karar verdi. Analist, ihtiyaç analizi ve şartname taslağı hazırlamak için müşteri ile yakın bir şekilde çalışan kişiydi.

Müşteri ilk iki sürümü gözden geçirecek zamana sahip değil. Müşteri üçüncü sürümü görene kadar her şey yolunda gitti; bazı işlevlerden memnun değildi ve bunlar vardiyalı Ürün Sahibi (analistimiz) tarafından tanıtıldı.

Tasarım ekibinin tüm sayfaların mock-up'ını tamamlamasını beklememiz söylendi ve müşteri her birini kontrol edip çalışmaya devam etmeyi onayladı. Scrum ekibi var, ama sprint yok - neredeyse klasik şelale yöntemi gibi çalışmayı bitirdik.

Scrum ekip üyesini veya master'ı ürün sahibi olarak atamak iyi bir fikir mi? Müşteri / ürün sahibi katılımı olmadığında scrum'u takip etmemiz gerekiyor mu?

Sadece birkaç hafta önce Mike Cohn, scrum ustası ve ürün sahibi rollerini blogunda birleştirme hakkında yazdı. Ben ondan daha iyi koyabileceğimi sanmıyorum, ama onun yazının kısa özeti şudur:

• Bu kötü bir fikir
• SM ve PO çok farklı görevler yerine getirir (Cohn'un sözleriyle "yıldız görevleri" ve "koruyucu görevler")
• iki rolü birleştiren kişinin her iki rolde yer alan tüm görevler için uygun olması pek olası değildir
• ekip, en iyi olmadıkları görevleri ihmal ederek kombine SM / PO tarafından yaralanabilir.

Scrum ekibinin herhangi bir üyesini alıp onu Ürün Sahibine taşımakla ilgili yanlış bir şey olmadığını düşünüyorum. Ancak bunun bir promosyon veya dahili transfer gibi olduğunu fark etmelisiniz; takımda bir delik oluşturur ve deliğin doldurulması gerekir. Belki takım deliği doldurmak için "kendini yeniden düzenleyebilir"; belki de boş pozisyonu doldurmak için yeni bir çalışan tutması gerekir.

İşlemin bana iyi geliyor. Bunu ayrıntılı olarak tarif etmediniz, ancak en azından rollere saygı duyuluyor (bu önemlidir).

Ancak, sahip olduğum birkaç ayrıntıyla, ürün sahibi düzeyinde bazı sorunlar görebiliyorum.

Müşterinin ilerleme hakkında doğru şekilde bilgilendirilmesini sağlamalıdır. Görünüşe göre o müşteri ile dışarıdan "şelale" yapıyor ve seninle "scrum".

Sonuç : müşteri kral olduğu için şelale kazanır. Bu durumda bile müşterinin sorumluluğu varsa ...

Mevcut ekibiniz (Scrum Master dahil) sprint biriktirme işini dağıtmaya odaklanmalıdır. Ancak ürün sahibi (analist) biriktirme listesinde bulunanın müşterinin istediklerini yansıttığından emin olmalıdır. Ayrıca, iletişimin iyi olduğundan ve müşterinin katıldığından emin olmalıdır.

Olası çözüm : ürün sahibinizi (analist) bir Scrum Ürün Sahibi kursuna gönderin veya bu kitabı okumasını (ve anlamasını) sağlayın: Scrum ile Çevik Ürün Yönetimi .

Scrum, gerçek bir müşteriyle en iyi şekilde çalışır. Yinelemeli ürün tasarımına alışkın olmayan müşterilerle başa çıkmada birkaç gerçek zorluk vardır.

• Boş tabaka sendromu
• Korkmuş istemci sendromu

Boş bir levhaya sahip tasarım aşamaları, gökyüzünde çok hızlı bir şekilde pastaya girme eğilimindedir ve genellikle birkaç yan konuda büyük derinliğe ve gerekli çekirdek işlevsellik üzerinde yeterli derinliğe sahip değildir. Müşterinin tasarım toplantılarının başarılı bir şekilde ilerlemesi için ayrılması için gerçekten hasır bir erkeğe ihtiyacınız var. Bir kerede yalnızca bir veçheye odaklanarak müşterinizin yinelemeli tasarımı öğrenmesine yardımcı oluyorsunuz.

Korkmuş müşteriler (deneyimlerinizde olduğu gibi), çevik projelerin sürecin bir parçası olarak belirli (kontrollü) bir yeniden çalışmayı beklediğinin farkında değiller. Onların kavramada zorlandıkları şey, ürün geliştirme ilerledikçe daha az "Aman Tanrım" anları olacaktır. Daha da önemlisi, çoğu müşterinin zor zamanları olan kısım, "Aman tanrım" anlarının, inceleme / planlama döngüleri arasındaki kısa zaman nedeniyle düzeltmek için paçavra gerektirmediği.

Müşteri beklentilerini yönetmek çok zordur. Bu müşteri eğitimi, yatıştırma ve hatta "hayır" demeyi öğrenme iyi bir denge. Müşteri her zaman haftalık veya iki haftada bir gelemez. Bazen ayda sadece bir kez gelebilirler. Bu iyi. Onlara bir önceki ay endişelerini gidermek için ne yaptığınızı gösterdiğiniz ve bu ayın çalışmalarına odaklandığınız sürece, projeyi daha sorunsuz hale getirmek için uzun bir yol kat edecektir. Sonuç olarak, müşterinin yokluğunda bazı sorular için makul önerilerde bulunabilecek birisine sahipsiniz. Müşterinin ulaşmaya çalıştığı hedeflere aşina biri olması gerekir.

İdeal olarak, ürün sahibinin proje hakkında bir miktar yetki ve bilgi birikimi vardır. Aynı şey, müşteri daha sonra yeniden başlamanızı gerektiren daha sonraki bir aşamada yönetilmeyen bir alt düzey çalışan atadığında da olabilirdi.

Gönderiniz için teşekkürler. Eski olduğunu anlıyorum, ama bence harika bir dava açtın ve işte benim 0,02 dolarım:

Sorun 1: Analisti sizin durumunuzda PO olarak atamak , scrum çerçevesini ciddi şekilde kısa devre yapar. Neden? Çünkü sadece PO, ürüne aşinalıktan değil, teknolojiden değil, işten akan değer yargıları, YG değerlendirmeleri, önceliklendirme ve belirleyici seçimler yapabilir. Eminim sr. analist PO'yu taklit eden harika bir iş çıkardı, ama nihayetinde PO'nuzdan gelecek istekleri, değerleri ve seçimleri tahmin etmek zorunda kaldı. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . Analistinize danışandan POA verilmediği sürece (olası değil), sprint incelemesinde herhangi bir şeyi kabul edecek veya reddedecek konumda olmayacaklardır.

Bu yaklaşım muhtemelen işe yarayabilir mi? Evet, ancak müşteriniz dışarıdayken sorumlulukların tamamen aktarılması gerekir. Müşterinizin patronunun vekil üzerinde anlaşması ve hiçbir makul kararın geri alınmaması gerekir. Kulağa doğru geliyor mu? Muhtemelen müşterinizin organizasyonundan geçici bir PO almanız muhtemeldir (ki bu kesinlikle dezavantajı olmadan değildir!) Ama sr. analist geçici PO ile çalıştı, işten yanlış kararlar gelirdi, böylece ekibinizin rolleri temiz kalırdı.

Sorun 2: "Müşterinin incelemek için zamanı yok". Büyük sorun (ve son zamanlarda da karşılaştığım bir sorun). Ürünü kabul etmek için PO bulunmalıdır. Başka hiç kimse 'çeki imzalayamaz'. PO yokluğu, memnuniyetsizliğin daha sonra gerçekleşmesi, potansiyel olarak daha fazla yeniden çalışma ve güven kaybı anlamına gelir. Daha temelde, müşterinizin projenize aktif olarak katılmadığını hissediyorum: günlük standup için zaman yok, soruları cevaplamak için zaman yok, vb.

Sorun 3: "Tasarım ekibinin maketi bitirmesini beklememiz söylendi". Ve şimdi tamamen scrum kapalı. Maketi yapan insanlar çapraz fonksiyonel ekibinizin bir parçası olmalıdır. Bunun, scrum yönetim anlayışının eksikliği veya üçüncü sürümünüze şok tepki nedeniyle olup olmadığını anlayamıyorum.

Soru: Tüm bunlarda scrum ustanız neredeydi? SM, ele alınacak her iki engel / tehlike olan rol çatışması ve PO'nun katılım eksikliğinin normal olarak farkında olacaktır.