it-swarm.dev

Hikaye Puanlarının ne olduğuna dair en iyi açıklama nedir?

Çevik gelişimimiz için burada Hikaye Puanları kullanmaya başlıyoruz, ancak açıklamakta zorlanıyorum ve ne olduklarına dair kesin bir cevap bulamıyorum. Yapabileceğim en iyi şey diğer sitelere ( http://blog.mountaingoatsoftware.com/tag/story-points ) işaret etmek ve ne olduklarına dair belirsiz bir genelleme vermektir. Başkalarının kullanması için yararlı olacak bazı kullanım örnekleri ile iyi bir açıklama arıyorum. Hikaye noktalarını açıklamak için iyi kaynaklar var mı?

36
six8

Bu bir başlangıç ​​olarak yardımcı olabilir: hikaye noktalarında Mike Cohn . Ama bu çok daha iyi: Çevik Geliştirme Takımları: Mike Cohn ile Kapsam ve Ölçek

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

  • İnsan beyni zamanında doğru tahmin edemez. Özellikle birkaç saatten fazla ise.
  • Bu, yazılım geliştiricideki belirsizliklerin miktarı, yönetimden kaynaklanan psikolojik baskılar (tahmin ettiğinizde, taahhüt ettiğiniz ...) ve takımdaki becerilerdeki farklılık ile büyük ölçüde güçlendirilmiştir.
  • Ancak, şeyleri karşılaştırma konusunda oldukça iyiyiz. Orada oldukça isabetliyiz.

Fikir bir referans kullanıcı hikayesi almak, sonra ona rasgele sayıda (hikaye) puan , diğer hikayeler bu referansla ilgili puanlar alır.

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

Hikaye puanlarını planlamanız için zamana dönüştürmek için hız değerini bilmeniz gerekir.

Doğru bir hız elde etmek için, birkaç tekrarlama yapmalı ve takımınızın belirli bir sürede ne kadar puan tamamladığını hesaplamalısınız.

Çalışır .

36
user2567

@Pierre 303: yukarıda belirtilen: (100 referans noktasının dışında) her şeye katılıyorum.

Eklemek istediğim tek şey (vurgu) görevleri tahmin etmede iyi olmadığımızdır. Kabaca aynı boyutta oldukları sürece görevleri diğer görevlere göre tahmin edebiliriz. Görevler arasındaki fark büyüdükçe daha da kötüleşiriz.

Bu yüzden 100 başlangıç ​​noktası kullanmaya katılmıyorum.

Bu, bir sonraki görevi referans görevin% 42'si olarak tahmin edeceğiniz gibi değil. Ya işin yarısı, işin üç katı iştir.

Ekibimiz Planing Poker kullanıyor: Bu konuda 2 hikaye referans görevimiz var. Daha sonra görevleri tahmin etmek için Fibonacci serisini kullanıyoruz: 1,2,3,5,8,13,21, Huge ,? Referans göreve göre (Fibonacci yerine diğer takımların 2 güç kullandığını gördüm. 1,2,4,8,16,32, Huge ,?) Diğer takımların (küçük (1), orta ( 2), büyük (3), XLarge (4) hızını hesapladığında hala çalıştı.).

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

Yani referans göreviniz 2SP ise. Daha sonra 1/2/3/5 tahmini yapmak, görev benzer büyüklükte olduğu için nispeten kolaydır. Referans görevden (5SP) 3 kat daha büyük olduktan sonra tahmin zorlaşır (8/9/10SP önemli mi?) Söyleyebileceğin tek şey 5SP'den daha büyük ve 13SP'den daha küçük sonra 8SP faturaya uyuyor.

SP 13/21/Huge değerine sahip herhangi bir şey sprint biriktirme listesi için çok büyüktür. Bunlar, henüz üzerinde çalışmaya hazır olmadığınız şeyler için tahminlerdir ve dolayısıyla Daha küçük görevler (siz de ihtiyacınız olana kadar onları parçalamayın). Ancak ürün birikimindeki bir görevin boyutu hakkında bir tahmin yaparlar (bu da gelecekteki planlamaya izin verir). onlar üzerinde çalışacaksınız, onları sprint biriktirme listesi için daha küçük görevlere ayırmak ve bunları tek tek yeniden tahmin etmek için yeterli bilgiye sahip olmalısınız (Not: Parçaların toplamının orijinaline eşit olduğu yaygın bir yanlış anlama).

  • 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 ve tanımlamak için özel olarak bir görev eklemeniz gerekiyor
    (yani, bir dokümantasyon veya sunum yazın).
5
Martin York

Bunlar zaman kaybı.

enter image description here

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

İlginçtir ki, bu görüş şimdi Scrum ve XP ve şirket adını ( Gevrek ) dünyanın dört bir yanındaki birçok takım tarafından kullanılan poker kartlarını planlamanın birçok destesinde bulunabilir.

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.

2
azheglov

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

Hikaye noktalarını kullanma şekliniz, projede iki görev üstlenmeniz ve onlara iki farklı hikaye noktası değeri atamanızdır. Ardından, bu iki hikaye noktası yaklaşımını tahmininiz için temel olarak kullanarak diğer görevleri tahmin edersiniz. Yani Görev C, görev A'dan çok daha zor değildir, ancak görev B'den inanılmaz derecede daha kolaydır, bu nedenle görev A'dan sadece yaklaşık 2 hikaye daha fazla iştir.

Şimdiye kadar sahip olduğunuz tüm gereksinimleri tahmin etmeyi bitirdiğinizde, bir sprint'te kaç tane yapabileceğinizi tahmin edersiniz. Sonraki birkaç sprint boyunca, kaç tane tamamladığınızı tahmin edersiniz. Bir gereksinimin öykü noktaları, yalnızca gereksinim yerine getirilirse tamamlanmış olarak sayılır. Scrum'da "% 80 tamamlanmış" yok. Bunun nedeni, insanların eksiksizliği tahmin etmede aslında kötü olmalarıdır. Birkaç sprintten sonra, sprint başına kaç hikaye puanı yapabileceğiniz hakkında bir fikriniz olmalıdır.

Nasıl tahmin edersiniz? Geliştiricilerinizin gereksinimlerinizin temel gereksinimlerinize göre ne kadar çalışacağını düşündüklerini belirlemek için planlama pokeri kullanabilirsiniz.

Ayrıca okuma tavsiye ederim Agile Samurai . Bence bu ve diğer Çevik kavramları açıklamak iyi bir iş çıkarıyor.

İşte hikaye hakkında daha fazla bilgi içeren bir bağlantı.

İşte başka bir bağlantı.

2
indyK1ng

Diğerlerinin de belirttiği gibi hikaye noktaları, bir kullanıcı hikayesinin karmaşıklığının göreli bir ölçümüdür. Hikaye noktalarının gerçek yararı,

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

Hikaye noktalarında ölçüm ve izleme hızını birkaç kez tekrarladıktan sonra, belirli bir zaman bloğuna (scrum kullanılıyorsa yineleme veya sprint) kaç hikaye noktasının sığabileceğini doğru bir şekilde tahmin edebilmelisiniz. Bu tekniği bir gruba uygulamak ve bu metrikleri farklı bir ekip için kullanmaya çalışmak iyi olmayacaktır. Yani a takımı iki haftalık bir sprintte 120 hikaye puanı tamamlayabilirse, b takımının aynı sonuçlara sahip olmasını beklemek gerçekçi olmaz.

Başka birinin belirttiği gibi, poker planlamak bu yöntemi kullanırken çok yardımcı olur, çünkü daha fazla ayrıntılandırılması gereken hikayeleri tanımlamaya yardımcı olacaktır (oylar arasında bir tutarsızlık varsa, bu şartlarda belirsizlik olduğu anlamına gelir).

0
Michael Brown

Bulabileceğim en kolay açıklama, somut ve somut bir örnek sağlayabilen bir nesne kullanmaktır.

Taşınabilir bir eve götürün. Mobil ev işinde olsaydım, tek bir geniş bina inşa etmenin genellikle 5 (puan, kurbağa, widget ... ölçüm formu keyfi) olduğunu ve bu nedenle çift geniş bina yapmanın yaklaşık iki kat çaba sarf etmesini veya 10 (puan) , kurbağalar, widget'lar).

Programcılar zihniyeti bu noktada devreye girecek ve aerodinamik bir yaklaşım hakkında konuşacaktır; zamanın en büyük bölümünü tüketen altyapı ve diğer benzer örnekler nedeniyle iki kat daha uzun sürmüyor. Bu kaçınılmaz. Bunun zaman içinde ASLA kesin olarak tahmin edemeyeceğimiz ve böylece (nokta, kurbağa, widget) tahmininde bulunabileceğimiz için bir tahmin (noktalar, kurbağalar, widget'lar) olduğu gerçeği üzerinde harp.

Bir şeyin inşasının ne kadar süreceğini bilmek için zaman içindeki eğilimlerimizden faydalanacağız; böylece zaman içinde tahminlerimizde gittikçe daha doğru hale gelir.

Takım gitmeye hazır olduğunda poker planlamayı unutmayın .

0
Aaron McIver