Öykü Noktalarının ne olduğunun en iyi açıklaması nedir?

Çevik gelişimimiz için burada hikaye puanları kullanmaya başlıyoruz ama açıklamakta zorlanıyorum ve onların ne olduğuna dair kesin bir cevap bulamıyorum. Yapabileceğim en iyi şey, diğer sitelere ( http://blog.mountaingoatsoftware.com/tag/story-points gibi ) işaret etmek ve ne oldukları hakkında belirsiz genellemeler vermek. Başkalarının kullanması için faydalı olabilecek bazı kullanım örnekleri ile ilgili iyi bir açıklama arıyorum. Hikaye noktalarını açıklamak için iyi kaynaklar var mı?

Bu bir başlangıç ​​olarak yardımcı olabilir: Hikaye noktalarında Mike Cohn . Fakat bu çok daha iyi: Çevik Kalkınma Ekipleri: Mike Cohn ile Kapsam ve Ölçek

Mike'ın yazılım tahmin metriklerine çözümü basit ve etkilidir. Biyolojik gerçekler:

• İnsan beyni tam olarak zamanı doğru olarak tahmin edememektedir. Özellikle birkaç saatten fazla ise.
• Bu, yazılım geliştiricideki belirsizliklerin, yönetimden kaynaklanan psikolojik baskıların (tahmin ettiğinizde, taahhüt ettiğiniz ...) ve ekipteki becerilerdeki farklılıklarla büyük ölçüde güçlendirilir.
• Ancak, şeyleri karşılaştırmakta oldukça iyiyiz. Orada oldukça haklıyız.

Buradaki fikir, bir referans kullanıcı hikayesi almak , sonra ona isteğe bağlı sayıda (hikaye) puan vermek , ardından diğer hikayeler bu referansla ilgili puanlar elde etmektir.

Referans hikayeniz 100 puansa ve başka bir hikaye üç kat daha büyükse, 300 puan olacaktır.

Hikaye noktalarını planlamanız için zamana dönüştürmek için hızınızı bilmeniz gerekir .

Doğru bir hız elde etmek için birkaç yineleme yapmanız ve ekibinizin belirli bir sürede ne kadar puan tamamladığını hesaplamanız gerekir.

Çalışıyor .

@ 305 numaralı her şeye katılıyorum: yukarıda belirtilenler: (100 referans noktasından ayrı).

Eklemek istediğim tek şey (vurgu), görevleri tahmin etmekte iyi olmadığımızdır. Kabaca aynı büyüklükte oldukları sürece diğer görevlere göre görevleri tahmin edebiliriz. Görevler arasındaki fark arttıkça daha da kötüye gidiyoruz.

Bu yüzden 100 başlangıç ​​noktası kullanmak konusunda aynı fikirde değilim.

Bir sonraki görevi referans görevin% 42'si olarak tahmin edeceksiniz. İşin yarısı aynıdır, iş ikiye katlanır, ikiye katlanır.

Ekibimiz Planing Poker kullanıyor : Bu konuda 2 hikaye puanından oluşan bir referans görevimiz var. Daha sonra Fibonacci serisini görevleri tahmin etmek için kullanıyoruz: 1,2,3,5,8,13,21, Huge ,? referans görevine göre (Fibonacci yerine diğer takımların 2 güç kullandığını gördüm. 1,2,4,8,16,32, Kocaman,) Başka takımların kullandığını gördüm (küçük (1), orta ( 2), büyük (3), XLarge (4) hızlarını hesapladıklarında hala çalışıyorlardı.).

Mesele şu ki, görevin büyüklüğü referans göreve göre arttıkça, maliyetini doğru bir şekilde tahmin edemiyoruz. Yani denemenin anlamı yok. Bu, tahmin izinin sonundaki daha büyük gradyan ile yansıtılır.

Öyleyse referans göreviniz 2SP ise. Ardından, görev benzer büyüklükte olduğu için 1/2/3/5 tahmin etmek oldukça kolaydır. Referans görevinden (5SP) 3 kat daha büyük geçmişe geçtiğinizde tahmin zorlaşır (8/9 / 10SP önemli mi) Söyleyebileceğiniz tek şey 5SP'den daha büyük ve 13SP'den daha küçük, 8SP faturaya uyuyor.

SP değeri 13/21 / Huge olan herhangi bir şey sprint biriktirme için çok büyük. Bunlar, henüz üzerinde çalışmaya hazır olmadığınız şeylerin tahminleridir (ve bu nedenle daha küçük işlere bölünmemişlerdir (onları ihtiyacınız olana kadar ayırmayın)). Ancak size ürün biriktirme listesindeki bir görevin büyüklüğü için bir tahmin sunarlar (ki bu, bazı gelecek planlamalarına izin verir). Onlar üzerinde çalışacağınız noktaya geldiğiniz zaman, onları sprint birikintisi için daha küçük görevlere bölmek ve onları bireysel olarak yeniden tahmin etmek için yeterli bilgiye sahip olmalısınız (Not: parçalar orijinaline eşittir).

• Büyük olarak tahmin ettiğiniz her şeyin daha küçük görevlere bölünmesi gerekir.
• Tahmin edilen bir şey var mı? tahmin etmek için yeterince iyi tanımlanmadığı anlamına gelir
  . Görevi tanımlamak için özel olarak bir görev eklemeniz gerekir
  (örn. bazı belgeler veya sunumlar yazınız).

Öykü noktaları, bir görevin ne kadar zor olduğunun göreceli bir ölçümüdür. Bunun nedeni, insanların kesin ölçümlerden daha göreceli tahminlerde daha iyi olmalarıdır.

Hikaye noktalarını kullanma şekliniz, projede yaklaşık iki görev almanız ve onlara iki farklı hikaye noktası değeri atamanızdır. Daha sonra, bu iki hikaye noktası yaklaşımını kullanarak tahmininiz için temel olarak diğer görevleri de tahmin edersiniz. Yani Görev C, A görevinden çok daha zor değildir ancak B görevinden çok daha kolaydır, bu yüzden A görevinden sadece 2 hikaye puanı daha fazladır.

Şu ana kadar sahip olduğunuz tüm gereklilikleri tahmin ettiğinizde, bir sprintte kaç tane yapabileceğinizi tahmin edersiniz. Sonraki birkaç sprintte, kaç tane tamamladığınızı tahmin edersiniz. Bir gereksinimin öykü noktaları, yalnızca gereksinimin yerine getirilmesi durumunda tamamlanmış sayılır. Scrum'da "% 80 tamamlanmadı" yoktur. Bunun sebebi, insanların tamlığı tahmin etmede aslında kötü olmalarıdır. Birkaç sprintten sonra, sprint başına kaç tane hikaye puanı yapabileceğinizi bilmelisiniz.

Nasıl tahmin edersiniz? Planlama pokerini , geliştiricilerinizin bir gereksinimin temel gereksinimlerinize göre ne kadar alacağını düşündüğünü belirlemek için kullanabilirsiniz .

Ayrıca Çevik Samuray'ı okumanızı tavsiye ederim . Bu ve diğer Çevik kavramları açıklamak bence iyi bir iş çıkarır.

İşte hikaye noktaları hakkında daha fazla bilgi içeren bir link.

İşte başka bir link.

Onlar zaman kaybı.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Bu fikrin şimdi, Scrum ve XP'yi Trenches'den yazan ve şirket ismi ( Crisp ) dünyadaki pek çok ekip tarafından kullanılan pek çok poker kartının destelerinde bulunabilecek olanlardan geliyor.

OP'nin son cümlesi: "Hikaye noktalarını açıklamak için iyi kaynaklar var mı?" Evet, bu kitap iyi bir kaynak. Düşünce için yiyecek.

Bulabileceğim en kolay açıklama somut ve somut bir örnek verebilecek bir nesne kullanmak.

Bir mobil ev al. Mobil ev işinde olsaydım, tek bir geniş bina inşa etmenin tipik olarak 5 (puan, kurbağa, alet ... ölçüm formunun keyfi olduğunu) ve bu nedenle bir çift geniş bina inşa etmenin iki ya da 10 puan alması gerektiğini bilirdim. , kurbağalar, aletler).

Programcılar zihniyet bu noktada devreye girecek ve aerodinamik bir yaklaşım hakkında konuşacak; zamanın en büyük bölümünü kullanan altyapı ve diğer benzer örnekler nedeniyle iki kat daha uzun sürmez. Bu kaçınılmazdır. Bunun bir tahmin (gerçeğe, kurbağalara, widget'lara) ilişkin bir tahmin olduğu gerçeğinden yararlanın, çünkü ASLA zamanı doğru olarak tahmin edemeyiz ve böylece tahmin etme (noktaları, kurbağalar, widget'lar) yapabileceğimiz inancını ortadan kaldırır.

Bir şeyin inşa edilmesinin ne kadar süreceğini bilmek zaman içinde trendlerimizden faydalanacağız; bu nedenle zaman içinde tahminlerimizde daha doğru bir sonuç almak.

Takım hazır olduğunda poker planlamayı unutma .

Başkalarının da belirttiği gibi, bir kullanıcı hikayesi için hikaye noktaları göreceli bir karmaşıklık ölçümüdür. Hikaye noktalarının gerçek yararı,

1. Puanlar, uygulamadan sorumlu birim tarafından ölçülür (bir birey veya ekip).
2. Sabit bir süre (hız) içerisinde aynı birim tarafından kaç tane toplama noktasının tamamlandığına ilişkin ölçümler tutulur.

Hikaye noktalarında birkaç ölçüm tekrarından ve izleme hızından sonra, belirli bir zaman aşımına (kaçınım veya sprint kullanıyorsanız) kaç tane hikaye noktasının sığabileceğini doğru olarak tahmin edebilmelisiniz. Bu tekniği bir gruba uygulamak ve bu ölçümleri farklı bir ekip için kullanmaya çalışmak işe yaramayacaktır. Eğer takım a iki haftalık sprintte 120 hikaye puanı tamamlayabiliyorsa, b takımının aynı sonuçları almasını beklemek gerçekçi değildir.

Bir başkasının da belirttiği gibi, poker planlaması bu yöntemi kullanırken çok yardımcıdır, çünkü daha fazla ayrıntılandırılması gereken hikayeleri belirlemeye yardımcı olacaktır (oylar arasında bir tutarsızlık varsa, şartlarda belirsizlik olduğu anlamına gelir).