Scrum'da “teknik kullanıcı hikayelerine” izin veriliyor mu?

Scrum'da teknik kullanıcı hikayelerine izin veriliyor mu? Öyleyse, Scrum'da teknik kullanıcı hikayeleri yazmak için standart şablon nedir? Aynı mı As a <user> I want to do <task> so that I can <goal>??

Bazı bloglarda bir geliştirici-kullanıcı-olmayan bir hikaye olarak okudum, ama aynı zamanda Scrum'ın bunları zorunlu kılmadığını da okudum. Onlar paylaştı kaç blog var kullanıcı olarak sistemi ile kullanıcı hikayeleri , onun gibi as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Standart hangisi?

Örneğin, aşağıdaki gibi kullanıcı hikayeleri vardır:

Bir gözden geçiren olarak, diğer kullanıcıların görebilmesi ve beğenebilmesi için herhangi bir otelin / yemeğin fotoğraflarını yüklemek istiyorum

Kullanıcı olarak görünümümü daha iyi açıklayabilmem için fotoğraf yorumları eklemek istiyorum

Şimdi her iki kullanıcı hikayesi için de büyük bir teknik öğe var - Görüntüyü kaydetme ve alma

Peki, aşağıdaki açıklama ile "Görüntü saklama ve alma mekanizması" başlıklı teknik bir hikaye ekleyebilir miyim?

Bir geliştirici olarak, kullanıcıların istedikleri yerde resim ekleyebilmesi / görüntüleyebilmesi için resimleri depolamak ve almak için bir mekanizma geliştirmek istiyorum

Teknik hikayelere izin verilir, ancak onlardan olabildiğince kaçınmaya çalışmanızı tavsiye ederim.

Örneğin, görüntüleri kaydetme ve alma hikayeniz iki normal kullanıcı hikayesi olarak kolayca yazılabilir

1. İnceleyen olarak, yüklenen fotoğraflarımın kalıcı olarak depolanmasını istiyorum, böylece diğer kullanıcılar istedikleri zaman görüntüleyebilir.
   (Bunun, orijinal yükleme öykünüzde, yükleme işleminden sonra görüntünün kalıcı olarak depolanmayacağını varsaydığını unutmayın. Bu garip görünmesine rağmen, bunları yönetilebilir hale getirmek için hikayeleri bölmenin geçerli bir yoludur.)
2. Bir kullanıcı olarak, yüklenen resimleri şu anda benim için uygun olan izlemek istiyorum.
   (Bu, saklanan görüntülerin daha sonra alınabileceğini gösterir.)

Teknik öyküler, kuruluş için önemli olan ancak kullanıcılara doğrudan bir özellik / işlev olarak görünmeyen işler için ayrılmalıdır. Örneğin, daha büyük sayı veya istekleri işlemek için yük dengeleme eklemek.

Özel örneğiniz göz önüne alındığında, bir geliştirici neden görüntüleri eklemek veya görüntülemek istemiyorsa kullanıcıların resimleri gerektiği yerde ekleyebilmesi / görüntüleyebilmesi için görüntüleri depolamak ve almak için bir mekanizma geliştirmek istemek olabilir mi?

Yani, sorunuz iyi bir soru olsa da, örnek değil. Bu bir kullanıcı özelliğidir ve bir kullanıcı hikayesi olmalıdır. Ve eğer kullanıcı gerçekten bu işlevselliğe ihtiyaç duymuyorsa, geliştirici bunu yapmak istememelidir.

Teknik bir hikaye daha fazla "Bir geliştirici olarak, veri arşivleme modüllerindeki çoğaltmayı azaltmak istiyorum, böylece 6 yerde her değişiklik yapmak zorunda değilim."

Bunların sprint'e dahil edilip edilmeyeceği sorusu zor bir sorudur ve müşteriniz olarak kimi düşündüğünüze bağlıdır. Son kullanıcı mı yoksa sizi çalıştıran iş mi yoksa sizi çalıştıran iş mi?

Danışmanlık şirketlerinde çalışan kişiler, birçok endüstri görüşü yönlendirmesi ile yapılır. Bu açıdan, geliştirici hikayelerinin kötü olduğu argümanını görebiliyorum. Onlar, günlük olarak yaptığınız işin bir parçası olmalı, bunun için ödeme yapan şirket tarafından görülemez. Bu şirketler içgüdüsel olarak faturaları çok yüksek çalıştırmanın işinizin kurumasını sağladığını bilirler, bu nedenle her geliştirici yalnızca geliştirme sürenizi iyileştiren veya hatasız yazılım bırakma yeteneğinizi geliştiren bir teknik geliştirme ilkesi üzerinde çalışır.

Deneyimim daha çok şirket içi ekipler üzerinde çalışmak ve doğrudan ücretlerimi ödeyen şirkete yazılım sağlamak. Bu şirketlerin çoğunda, işletme ile işletmenin teknik kanadı arasında bir güven engeli vardır. Hepsinde, azalan maliyetlerin her geçen gün artan gelir olduğu farklı bir zihniyet vardır.

Bu ortamlarda, önemli geliştirici hikayeleri tanımlamak iyi olabilir. Görünürlüğü artırır, güven yaratır ve geliştiricileri ve yönetimi bu tür görevlerin işletmeye olan değeri hakkında düşünmeye ve buna göre öncelik vermeye teşvik eder.

Sonuçta, denemenizi öneririm. Ve eğer değer sunmuyorsa, yapmayı bırakın.

Ama içgüdüm, bu gelişmenin işletmeye olan değerini düşünürseniz, bunu bir geliştirici hikayesi yapmaya bile çalışamayacağınızı söylüyor. Ya son kullanıcı için iyi ya da değil. Değilse, o zaman işletmenin değeri yoktur.

Bu iyi bir soru. Resmi bir cevabım yok ama çalıştığım yerde teknik kullanıcı hikayeleri ekliyor ve onlara teknik borç veriyoruz. İzin verilmeselerdi, işimi sadece kayıt altına alıp işletmeye iletmek için onları eklemenin başka bir yolunu bulurdum. Aynı şekilde, bu belgeye sahip olmak bize gelecekteki projeler için neyin gerekli olduğunu hatırlatır.

Örnek olarak, teknik hikayeler eklememize izin verilmiyorsa, yeni bir uygulamadaki bağlantıyı kesme, bir sprint başladıktan sonra bir hafta boyunca veritabanı modelleri oluşturup veri modelleyicimin onaylamasını bekleyeceğim. onları modelleyici ile yineleyin ve bittiğinde komut dosyalarını dba'ya gönderin ve db nesnelerini oluşturmalarını bekleyin. Bu arada, yeni bir kod projesi, bazı temel ORM işlevselliği ve kaynak kontrol düzenimi oluşturacağım ve her şey söylendiğinde ve bittiğinde bir boş açılış sayfası oluşturmak ve dağıtmak için zamanım olacak.

Gün geçtikçe bu devam ediyor, eğer bilgiyi kaydetmezsem, iş aslında ekibimizin proje üzerinde çalışmadığımızı tartışıyor. Hikayelerde bu öğelere sahip olmak, çalışmamızı kontrol edebileceğimiz, çalışmayı belgelediğimiz ve ilerleme kaydettiğimiz işletmeye iletişim kurabileceğimiz anlamına gelir.

Bunu yapmak için daha iyi bir uygulama varsa, tamamen kulaklarım.

Kişisel hislerim, takımların scrum'un izin verdiği şeylere çok fazla asılmaması ve takım için neyin işe yaradığı konusunda daha fazla endişelenmemesi gerektiğidir. Scrum'ın kötü bir üne kavuşmasının nedenlerinden biri, uygulayıcıların çevik proje yönetiminin arkasındaki fikirlere karşı olan süreç odaklı hale gelebilmeleridir .

Şimdi sabun kutumdan çıkacağım, ancak aşağıdakilerin gerçekten 'scrum' olup olmadığını soruyorsanız, lütfen yukarıdakileri tekrar okuyun.

Kullanıcı öykülerinin tanımladığı 'özellikleri' ve teknik ekibin bu özellikleri desteklemek için sunması gereken 'çıktıları' ayırmak önemlidir. Bu durumda resimleri kaydetmeniz ve almanız gerekir (teknik ekip olarak) uygulamanız gereken teknik bir çıktıdır. Hemen hemen her hikayenin bazı teknik çıktılara ihtiyacı olacaktır.

Bunun önemli olmasının nedeni, bir teknik çıktısının (tek başına) kullanıcı açısından değer üreten bir şey olmamasıdır. Teknik çıktıları kullanıcı hikayeleri olarak izlemeye başlarsanız, teknik çıktıyı iş değeri üretme muamelesi tuzağına kolayca düşebilirsiniz. Suların bu şekilde çamurlanması, iş hedeflerini (yani paraya mal olanları) destekleyen işleri gerçek iş hedefleriyle (yani para kazandıran şeylerle) karıştıracaktır.

Yukarıdaki yanıtların tümü Scrum çerçevesi için yetkili kaynak belgesine referansta bulunmaz: Scrum Kılavuzu .

Ürün İş Listesi, gelecek sürümlerde üründe yapılacak değişiklikleri oluşturan tüm özellikleri, işlevleri, gereksinimleri, geliştirmeleri ve düzeltmeleri listeler.

Odak değer üretmeye odaklanmalıdır. Bazen bu değer altyapıyı yükseltme gibi teknik çalışmalardan gelir. Bu öğeleri hariç tutma!

Kullanıcı hikayesi terimi Scrum Rehberinde asla görünmez çünkü

içinde çeşitli süreçleri ve teknikleri kullanabileceğiniz bir çerçevedir.

Kullanıcı öyküsünü kullanmak PBI'ları kaydetmek için olası bir tekniktir. Her ne kadar "a olarak istiyorum, öyle olsun" biçimini görmek yaygın olsa da, orijinal amacına ters düşebilir . Bu sıkıntılı format Agile 2017'de de ele alındı .

Dikey dilimlemeyi anlamak ve kullanmak , Ürün İş Listesi kalemlerinin (PBI) boyutunu azaltmak için yardımcı olacaktır. Bu tek dilimleme düşünün tasarrufu ve Al içine öğeyi tasarrufu ve geri öğe s .