Bir ürün sahibinin scrum'da bir kullanıcı hikayesi yazması gerektiğini biliyorum.

Bir kullanıcı hikayesi, son kullanıcı için bir özelliği açıklamaktadır.

Ancak, neyin teknik olarak geliştirilmesi gerektiğini ve nasıl uygulanması gerektiğini açıklayan

ve scrum ile ilgili bu bilgiler nerede saklanıyor?

Bu beni gerçekten ilgilendirir!

Geliştirici hikayeyi uygulamaya başladığında şirketimizde büyük bir bilgi eksikliği görüyorum ama nasıl uygulanacağını bilmiyorlar!

Örneğin, eski bir COM API ile uğraşmak zorunda kalıyorlar ve bununla nasıl başa çıkacakları konusunda bir fikirleri yok ya da teknik olarak WPF / WEB veya başka bir şekilde yetenekli değiller.

Scrum, kullanıcıların kullanıcı hikayesiyle başlamasına nasıl yardımcı olur?

Burada çevik olmayan düşmanı. Uygulama ayrıntılarının belirlenmesi ve yapılması gereken görevlerin belirlenmesi, kullanıcı hikayelerini sprint için gerçek görevlere / gereksinimlere dönüştürecek olan sprint planlama toplantısında gerçekleşir. Birçok çevik sürecin başarısızlığı, sprint planlama toplantısının aslında büyük ölçüde geliştiriciler tarafından yapılması gerektiğidir ... eğer sadece ürün sahipleri ise, sadece ayı almaya karar verecekler. İşte size (oldukça belirsiz) bir kullanıcı hikayesi bulacağınız yer:

As a non-technical user, I need to have a simpler interface with the API

Ürün sahibi hangi kullanıcı öykülerinin en yüksek öncelik olduğunu tanımlasa da, programcılar bu öncelikleri alır ve bunları bir görev listesine dönüştürür (sprint birikimi olarak adlandırılır). Burada işleri nasıl yapacağınız hakkında fikir edinebilirsiniz ... sprint biriktirme listesi istediğiniz kadar teknik olabilir. Burası aynı zamanda "daha basit bir API elde etmek için, o çılgın COM API'sini yeniden düzenlememiz gerekecek. Bunu nasıl kullanacağını bilen var mı?". Cevap "Cehennem Hayır" olduğunda, o kullanıcı hikayesinin kapsamının göründüğünden daha büyük olabileceğini görmeye başlayacaksınız. Bu göz önüne alındığında, kullanıcı hikayesini görevlere ayırabilirsiniz:

• Mevcut API'yı belgeleme ve anlama
• Yeni API tasarlayın
• Yeni API uygulayın
• Her neyse...

Bu göz önüne alındığında, kullanıcı hikayelerini daha küçük değişikliklere bölmek için müzakere etmek TAMAM. Çevik metodoloji, kişinin istediklerine kademeli adımlarla yaklaşmak istediğiniz anlamına gelir. Yani "Hey bak. API'yi tek bir yinelemede elden geçiremeyiz. Bunu 'Teknik olmayan bir müşteri olarak iyi belgelenmiş bir API'ya ihtiyacım var' şeklinde bölelım.

Kısa cevap

Dev Team teknik şeyleri yazıyor. Scrum, teknik arıza ile ilgili size biraz yardımcı olur ama çok fazla değil. bir Kullanıcı Hikayesine başlarken. Scrum neredeyse Ne-Dünya -sadece. Teknik dökümü How-World .

Scrum tarafından sağlanan arıza:

• Kullanıcı Hikayesi -> Kabul Kriterleri

İnsanların genellikle bunun üzerinde kullandıkları arıza:

• Epic -> Kullanıcı Hikayeleri
• Kullanıcı Hikayesi -> Alt Görevler
• Kabul Kriterleri -> Kabul Testleri

Ayrıca ekip, yapılması gerektiğini bildikleri şeyler için Teknik Görevler yazabilir (yani projenin başlangıcında herkes için IntelliJ IDEA'yı kurabilir), ancak İşletme Değeri olmayan.

Arıza çalışması, dikkat konusunda daha fazla rehberlik için XP (Extreme Programming), Temiz Kanunu , Pragmatik Programlama , Yazılım Mühendisliği , CRC-Kartlar , cepten / OOA / OOD , Tasarım Kalıpları , Refactoring , Etkili Legacy Kanunu ile çalışma , TDD ( Test Odaklı Geliştirme), BDD (Davranış Odaklı Geliştirme), ATDD (Kabul-Test Odaklı Geliştirme).

Uzun cevap

Scrum Nasıl Düşünür?

Ne-Dünya ve Nasıl-Dünya

Bir yoktur Ne-Dünya ve Nasıl Dünya . Doğru keçe gibi, Kullanıcı Hikayesi içindir Kullanıcılar üreten İşletme Değerinin aka İkincil Değer içinde ne-World . Scrum çoğunlukla sadece Ne-Dünya'dır. How-World hakkında çok az şey söyler , temelde "How-World Dev-Team'in sorumluluğudur" dan başka bir şey yapmaz .

Kullanıcı Hikayesi ve Görev

Genellikle, How-World için olan İş Listeleri Öğelerine Kullanıcı Hikayesi değil Teknik Görev veya Alt Görev denir . Birçok araç parçalayarak izin Kullanıcı Story gelen ne-World içine alt görevler de nasıl-World .

Scrum Nasıl Yardımcı Olur ve Yardımın Nerede Bittiği

Scrum'ın How-World için yardımı Sprint Planlama Toplantısında birkaç noktada sona erer :

• [Sprint Planlama Toplantısı] Planning Poker -> Tartışma sırasında farklı takım arkadaşları farklı Hikaye Puanı tahminleriyle karşılaşırsa, takım hikayenin yanlış anlaşılmasını keşfeder .
• [Hazır Tanımı] Takım çok büyük Kullanıcı Hikayelerini kabul etmiyor (Hikaye Puanları çok yüksek). Pek çok Hazır Tanımı'nda bulunan bir kural , Öykü Puanlarının ekibin hızının yarısından daha az olması gerektiğidir.
• [Hazır tanımı] Ekip, Kabul Kriterleri hakkında yeterli açıklama yapılmaksızın Kullanıcı Öykülerini kabul etmemektedir. Takımın Kabul Testlerini yazmaya nasıl başlayacağına dair yeterli güveni varsa Kabul Kriterleri yeterlidir.

Scrum Seviyesi hakkında birkaç ipucu

Biriktirme Ayrıntılandırma toplantıları sırasında veya Sprint Planlama Toplantısının en azından ikinci bölümünde (bazı takımlar Sprint Planlama 2 Toplantısı için) Kullanıcı Öykülerinin Alt Görevlere ayrılmasını yararlı buldum .

Deneyimsiz ekiplerle , İş Listesi İyileştirme ve Sprint Planlama sırasında Atomik Kullanıcı Hikayeleri için çaba göstermeyi yararlı buldum . Bir Atomik Kullanıcı Hikayesi, İş Değerini tamamen kaybetmeden Küçük Kullanıcı Hikayelerine daha fazla bölünemeyen bir Kullanıcı Hikayesidir. Genel olarak Kullanıcı Öyküleri Atomik olmak zorunda değil, sadece deneyimsiz ekiplerle bana yardımcı olduğunu buldum.

Ve Kullanıcı Öyküleri olarak "Özellik X'in (Mimari | Tasarım | Uygulama | Test)" ifadesini kullanmayın. Alt Görev olarak bundan kaçınmaya çalışmanızı tavsiye ederim.

Atomik Kullanıcı Hikayelerim varsa ve uygulanacak Kabul Kriterleri dışında daha fazla arızaya ihtiyaçları varsa, bana göre bir şey optimum düzeyde çalışmıyor demektir. Mimari yanlış / çok karmaşık, yani iş odaklı değil tekniktir. Veya ekip deneyimsizdir. Ya da her ikisi de. Her durumda, bilgiyi eğiterek ve yayarak durumu iyileştirmek için harekete geçilmesi gerekecektir.

Scrum'ın Ötesinde

Scrum'ın ötesinde Scrum Master

Bugün, Scrum Master çoğunlukla Yönetimsel bir Rol olarak anlaşılıyor ve bu saçmalık. Başlangıçta, Scrum Usta oldu ve bu savunan, bir teknik Rol gibi değil, bir idari rolü Coach içinde XP .

Scrum ve Scrum Master'a güvenmek ve böylece büyük bir boşluğa düşmek çok kolaydır, çünkü Scrum How-World hakkında neredeyse hiçbir şey söylemez.

Döner Scrum Master

İdeal olarak, Scrum Master, takımdaki herkes Scrum Master'ın gereksiz hale geldiği kadar derinden “Denetle ve Uyarla” yaşayana kadar yeterli yönetim ve iletişim becerilerine sahip deneyimli geliştiriciler arasında döner; hiç kimse ve herkes aynı zamanda Scrum Master olamaz.

Ama dikkat edin, Scrum Mastery daha çok yemek pişirmek gibidir, masayı temizlemek ve bulaşık yıkamak gibi değildir. Herkesin yapabileceği gibi, masayı kimin temizlediğini ve bulaşıkları yıkadığını döndürmek isteyebilirsiniz. Ama pişirmeyi herkese çevirmek istemezsiniz, çünkü pişiremeyen veya pişirmeyi sevmeyen insanlar var ve iyi yemek yemek istiyorsunuz.

Scrum Master'ı uzman geliştiriciler arasında döndürmeyle ilgili iyi şey, ekibin daha fazla yöntem hakkında bilgi edinme olasılığının yüksek olmasıdır.

Kendi Kendini Düzenleyen Ekip

Scrum açısından, takım ideal olarak Scrum Master'ın yardımıyla kendini bulmalıdır .

Scrum ayrıca sadece Dev Team'den bahsediyor . Scrum'da Mimar veya Baş Mühendis gibi roller mevcut değildir. Bu yasaklandıkları anlamına gelmez, sadece Scrum'ın onlar hakkında hiçbir şey söylemediği anlamına gelir. Scrum, Kendi Kendini Düzenleyen bir Ekip ilan eder, yani ekip bir Mimar ilan ederse, ekibin bir Mimarı vardır. Bu Scrum tarafından tanımlanmadı, ancak Scrum ile uyumlu. Sadece adanmış Mimarlar ilan etmiyorum (yıllarca atanmış bir mimar olarak çalıştım ve onu sevmeme rağmen, temel olarak belirlenen bir Mimar fikrine karşıyım), sadece bir örnek veriyoruz.

Kabul testleri

Kullanıcı Öyküleri Kabul Kriterleri'ne sahiptir . Bu Kabul Kriterleri Kabul Testlerine dönüştürülür

Diğer şey

Arıza için daha fazla şeyin bir listesi için bkz . Bir programlama projesinin diğer geliştiriciler için görevlere nasıl bölünür?

Bu yardımcı olur umarım.

Ekipte en iyi kalifiye olan kişi, ürün sahiplerinin gereksinimlerini eyleme geçirilebilir kullanıcı hikayelerine dönüştürmesi gerekir. Deneyimlerime göre, aşağıdaki yaklaşımı kullandık:

• Hikayeleri her zaman ürün sahipleriyle yapılan tartışmalara dayanan bir geliştirici olmuştur.
• Bu hikayeler daha sonra geliştiriciler tarafından tahmin edilir (puanlara veya zamana göre)
• Ürün sahipleri daha sonra işlerin nasıl önceliklendirileceğine karar verir.

Geliştiriciler bir hikayenin nasıl uygulanacağını bilmiyorlarsa, bu durumlardan biri doğru olabilir:

• Görev yeterince net olmayabilir (daha fazla ayrıntı / ekran görüntüsü / maket ekleyin)
• Belirli görevlerin daha net olması için daha fazla parçalanması gerekiyor
• Geliştiricinin araştırması ve nasıl uygulanacağını öğrenmesi için daha fazla zamana ihtiyacı var. (Bu görevi tahmin ederken, bunu hesaba katmak için daha fazla zaman ekleyin)
• Geliştirici, uygulamayı uygulayacak kadar nitelikli değildir ve başka birine atanması gerekebilir veya geliştiriciye başka biri tarafından yardım edilmesi gerekir.

Bu kursu Udemy'deki SCRUM'da ücretsiz olarak alabilir ve SCRUM sürecinin bireysel yönleri hakkında bilgi edinebilirsiniz - https://www.udemy.com/scrum-methodology/

Kısa cevap şudur: ürün sahibi, ekibin sunması gereken hikayeleri oluşturmaktan sorumludur. Hikayelerin nasıl iletileceğine karar veren ekip. Teslimatın bir kısmı bazı teknik hikayeler içeriyorsa, bu hikayeleri yazan ekiptir. Ekip daha sonra önceliğe karar vermek için ürün sahibiyle birlikte çalışır.

Yine PO, neyin inşa edileceğine karar verir , ekip bu hikayeleri nasıl uygulayacağına karar verir .

Bu Çevik bir sorun değil. Sorun, ekibin bir kullanıcı hikayesini (çevik) veya bir gereksinimi (geleneksel) tamamlamak için yeterli teknik bilgiye sahip olmamasıdır. Agile bu durumda yardımcı olabilir mi? Hayır, eğer takım dikkatlice seçilmemişse ve takımdaki hiç kimse görevlerini yerine getirecek kadar teknik deneyime sahip değilse. Evet, bazı ekip üyeleri diğer ekip üyelerinin görevlerini yerine getirmesine yardımcı olabilecek iyi teknik bilgiye sahipse. Çünkü o takımın kendi kendini organize etmesi gerekiyor ve bunun güçlü ve zayıf yanlarını bilmesi gerekiyor.

lütfen aşağıdaki Agile prensibini hatırlayın.

"En iyi mimariler, gereksinimler ve tasarımlar, kendi kendini düzenleyen ekiplerden ortaya çıkar"

Bunun nedeni, Çevik ortamda ekip güveninin yüksek olması ve kendi aralarında çalışma yetkisi vermeleridir.