Sprint'te pokeri planlamanın amacı nedir?

İş analistimiz ve proje liderlerimiz, müşterinin Hikayeler olarak gereksinimini bize bildirir. Her Sprint planlamasında biz (geliştiriciler) planlama pokeri oynamamız istenir.

Hepimizden 'Çaba' yerine 'Karmaşıklığı' değerlendirmemizi istediler. Gerçekten kafamız karıştı ve toplantılarımızda zaman harcıyoruz. Bir geliştirici, 'Gerçekten neyi dikkate almak istiyoruz? Bu gereksinimde (zaman tahmini) yapmak zorunda olduğumuz kod / DDL değişikliği ile mi ilgili, yoksa gereksinimi anlayıp anlamadığımızla mı ilgili? '

Ancak 'iş gereksinimi uzmanı ve proje liderleri' gerçekten 'gereksinimi anlayın' ve 'bir kart topla' ile ne anlama geliyor?

Ayrıca, her scrum ekibi için verilen görev için zaman tahmini veren bireysel scrum ekipleri için dilimleme toplantılarımız var. Peki Planning Poker'de gerçekten nasıl bir şeyden bahsediyorlar?

Birisi bunu bir örnek kullanarak açıklayabilir mi? 'Karmaşıklık' ve 'Çaba' dediklerinde gerçekte ne hakkında konuştuklarını ayırt etmeye çalışın.

Proje Yöneticisinin bakış açısını göz önünde bulundurun

Karmaşıklık isteyerek, bir takım olarak hızınızı bulmak için bir sonraki sprintinizle karşılaştırabilecekleri bir sayı isterler. Ayrıca, tüm hikayelerin ne zaman yapılacağına dair genel bir tahmin sağlamak için sonucunuzu diğer ekiplerin tahminleriyle bir araya getirmek için kullanmaya çalışıyor olabilirler.

Proje yöneticisi, projenin ne zaman biteceğini veya zaman-fonksiyon-maliyet üçgeninin diğer taraflarında esnek olup olmadıklarını, kalan zamana uydurmak için başka bırakanların ne olabileceğini tahmin ediyor. Bu mantıksız değil. İş kararlarının bu tahmine dayanarak alınması gerekecektir. Sorun, bunu yazılım için tahmin etmenin gerçekten zor olmasıdır. Poker planlaması bu soruna yardımcı olmanın yollarından biridir. Bunu sadece hikaye noktalarının sayısını bir araya getirmek olarak görmek yerine, tahmin edebileceğiniz kadar karmaşık bir işlev olarak düşünün, işi yapın, ne kadar sürdüğünü ölçün, tekrarlayın ve daha sonra tahmin edin.

Tartışma bir sayıdan daha önemlidir

Hikaye işaret eden toplantıların en önemli kısmını ortaya çıkan tartışmalar olarak görüyorum. Takımdaki herhangi biri bir sayı önerdiğinden emin değilse, muhtemelen hikayeyi tam olarak anlamıyorlar ve daha fazla tartışılması gerekiyor. Çevik Manifesto'dan "Sözleşme müzakereleri üzerinde müşteri işbirliği". Bir kullanıcı hikayesi olarak yazılmış bir sözleşme belirtmek ve ekibin tam olarak istediğinizi yapmazlarsa başarısız olduğunu söylemek yerine, müşterinin anlayana kadar gerçekten ne istediğini konuşmak her zaman daha iyidir.

Çabaya Karşı Karmaşıklık

Karmaşıklığa karşı çaba ile ilgili özel sorunuza yanıt vermek için herkesin bu konuda farklı bir görüşü var. Arkalarında keçi olan poker kartlarını planlayan ve sahibi Mike Cohn Agile / Scrum dünyasında büyük olan Mountain Goat , bunun karmaşıklık değil çaba olması gerektiğini söylüyor.

Normalde zamanın bir ölçüsü olarak görülmez (karşı örnek için aşağıdaki örneğe bakın), insanlar zamanı tahmin etmede kötüdür, diğer faktörler verdikleri sayıyı etkiler: örneğin daha fazla özelliğe sığabilmek için sayıyı düşük tutma baskısı bir sorunla karşılaşırsanız kendinize yer açmak için daha yüksek bir sayı vermek için baskı yapın. Bina yazılımı zordur. 100'üncü evinizi inşa ettiğinizde, ondan önce 99 ev inşa ettiğiniz için sizi ne kadar süre alacağını tahmin edebilirsiniz. Oluşturmakta olduğunuz yazılım daha önce oluşturduğunuz programlarla aynıysa, kopyalayıp yapıştırabilirsiniz, yazılım projesi farklı olsa da herhangi bir değer ve başlangıçta öngörmediğiniz problemler olacaktır.

Gizli baskılar içeren zaman tahminlerinde olduğu gibi, bir çaba ölçüsünün de sorunları vardır. Küçük bir geliştirici yüksek bir karmaşıklık tahmin ederse, kendilerini daha düşük bir tahmin verecek diğerlerinden yeterince iyi olmadığı için saldırıya açık bıraktıklarını hissedebilirler. Bu sadece tahminlerinize değil, takımdaki insanlara da zarar verir.

Planlanan poker numaraları 'gün sayısı' veya başka bir zaman ölçüsü değildir, iki kullanıcı hikayesini karşılaştırabilmek için göreceli bir ölçüttür. Yeni bir ekipte yapmanız gereken ilk şey bir temel oluşturmaktır. Karmaşıklık aralığının ortasında yer alan bir kullanıcı hikayesi seçin ve aralığını atamak istediğiniz aralığın ortasında bir sayı olarak takım olarak kabul edin. Şimdi diğer tüm kullanıcı hikayeleri buna göre numaralandırılabilir. Bunun çok daha kolay olduğunu gördüm.

Tahmin verememenizin nedenleri

Proje yöneticileri sizden bir projenin ne zaman yapılacağını sorduğunda, sordukları sorunun karmaşıklığını anlamaları gerekir. Programcılar, ne kadar hızlı yazdıklarını çalışma süreleriyle çarparak üretkenliklerinin ölçülebildiği fabrika çalışanları değildir. Sorunlara cevap buluyorlar ve bu zor. Planlama pokeri oynayarak önce takımda kimlerin hangi sayı atayacakları sorusuna cevap veremediklerini belirlersiniz ve sonra bu soruya neden cevap veremediklerini araştırırsınız. Bence en az dört neden var:

1. Hikaye çok büyük. Daha küçük, daha belirgin kullanıcı hikayelerine ayırın. Her kullanıcı hikayesinin kullanıcıya tek bir değer sağlaması gerektiğini unutmayın; girdi - süreç - çıktı = değer.
2. Sorun alanını, ne kadar zaman alacağını söyleyebilecek kadar iyi anlayamıyorlar, hatta tüm soruları düzgün bir şekilde soruyorlar. Daha önce hiç görmediğiniz ne olursa olsun, bu tür bir uygulama hakkında paydaşların alanı / programlaması hakkında daha fazla bilgi sahibi olan kişilerle konuşun. Bu mümkün değilse veya sizi oraya kadar götürmezse, bir tasarım dikeni kullanabilirsiniz. Bir çözümü gidip prototipleyin, ancak yalnızca sınırlı ve belirli bir süre için. Prototip aşamasının ne kadar süreceğini, çok uzun sürmeyeceğini tanımlayın ve ardından yeni anlayışınızı paylaşmak için tekrar buluşun.
3. Paydaşlarınız yeterince spesifik değiller. "Bana bir bulut oluşturun" kabul edilebilir bir kullanıcı hikayesi değildir. "Talep üzerine VM'leri döndürebildiğim bir sistem kur" daha iyi olduğu için daha iyidir, ancak hala yüz gizli olacağından ne kadar süreceğini doğru bir şekilde tahmin edebileceğiniz seviyede değildir. bu beyanda paydaşınızın onlara bir şey gösterene kadar öğrenemeyeceğiniz varsayımları.
4. Son olarak, bir tahminde bulunabilseniz bile ilk seferinde yanlış olacaktır. Tahmin etmek zor bir problemdir ve zor problemleri çözmenin en iyi yolu bilimsel yöntemi kullanmaktır. Her ekip üyesinin tahmin ettiği sayıları toplayın, sonra ne kadar sürdüğü veya ne kadar karmaşık olduğu konusunda veri toplayın, ancak bu daha zor olsa da, zamanla bunları karşılaştırın. Sonunda kimin hafife aldığını ve kimin hafife aldığını hissedeceksiniz ve ardından bunu ekiple paylaşmalısınız. İnsanlar birbirlerinin tahminlerinde daha iyi olmasına yardımcı olabilirler. Bu sayılar, hikayelerin ne kadar süreceğini daha iyi tahmin etmenize yardımcı olmak için izleme aracınıza da geri gönderilebilir.

Sonuç

Gerçekten tartışma konusu olması gerektiğine inanıyorum, ancak birisine gerçekten bir numara vermeniz gerekiyorsa, o zaman bunu hangi ekip üyesinin üzerinde çalıştığı ve hikayelerin hangi sırada çalıştığı konusunda bağımsız bir tane yapmaya çalışın. Mesele, her ikisi de önceliklendirilmiş bir arka günlüğe ulaşmaktır, böylece Proje Yöneticisi, son teslim tarihinden önce ne kadar daha fazla sığabileceğinizi görebilmeniz için doğru sırada çalışıyorsunuz. Herhangi bir yinelemenin sonunda durabilir ve başlatılan tüm özellikleri tamamlayarak gönderebilirsiniz.

Uyarı

Rakamları kendinize sakladığınız sürece ekibinizdeki görevleri istediğiniz kadar tamamlayabileceğiniz zamanı tahmin edebilirsiniz. Herhangi bir sayının takımdan kaçmasına ve diğer insanlar tarafından görülmesine izin verdiğinizde, bu sayı ile yapmadığınız şeyleri yapacaklardır. Görevleri tamamlamak için birkaç gün olarak kullanmaya çalışacaklar. Sizi göreceli karmaşıklık derecesine tutmaya çalışacak ve bir kullanıcı hikayesini tamamlamanın neden aynı sayıda puanla diğerinden daha uzun sürdüğünü soracaklar. Sayılarınızı bir araya getirecek ve diğer takımın sayılarıyla karşılaştıracak ve bir süre içinde daha fazla hikaye puanı tamamladıkça diğer takımın neden 'daha fazla iş yaptığını' soracaklar. Yapabilirsin'

bir kenara

Planlama poker sayılar kümesi normalde sayılar arasındaki boşluklar daha da büyüyecek şekilde dağıtılır. Bunun, insanların bir kullanıcı hikayesinin 16 mı yoksa 17 mi olduğunu tartışmasını caydırmak anlamına geldiğine inanıyorum, 13'ten büyükse, sadece 20 yapın.

Misal

Poker planlamak için sadece 1, 2, 3 ve 4 sayılarını kullanan en az bir takım biliyorum. Sözleşmeye karşı ve yukarıdaki tartışmanın aksine, bunları programlama günleri olarak tanımlarlar (aslında programlama günlerini eşleştirin, yani kullanıcı hikayesini tamamlamak için aynı makinede birlikte çalışan iki programcının kaç gün sürdüğü). Ekibin bir kullanıcı hikayesini tamamlamanın 4 günden uzun süreceğini düşünüyorsa, hikaye işaret edilmez ve ürün sahibinden hikayeyi daha da yıkmak veya daha tam olarak belirtmek için ekiple birlikte çalışması istenir. gelecekteki bir planlama toplantısı için bu aralığa getirilmelidir. Ancak bu ileri derecede çeviktir ve muhtemelen sadece diğer teknikleri kullanmada deneyimli kişiler tarafından kullanılmalıdır.

Bence Frank ve Encaita'nın cevapları hemen hemen bunu kapsıyor ama dikkate alınması gereken bazı ek şeyler var:

Hikaye noktalarını neden kullanmalıyım?

Hikaye puanları ile tahmin etmenin amacı, uygulamanız için gelişmekte olan özelliklerin göreli karmaşıklığını vermektir. Bunu düşünmenin basit bir yolu, yaklaşan sprint'te bir hikayeyi ele almaktır, örneğin bir url değişikliği. Bunun karmaşıklık açısından basit olduğunu ve kabul kriterlerini açıkça tanımladığını biliyorsunuz, böylece tüm ekip test ederken bile 1 (Fibo ölçeğini kullanarak) olduğunu kabul ediyor.

Tahmin edilecek bir sonraki hikaye, bir dizi kullanıcı verisini toplamak ve bunu ön uçta görselleştirmek. Şimdi bir geliştirici olarak bu bir url değiştirmek çok daha karmaşık olduğunu biliyorsunuz. Hikayeyi ve kabul kriterlerini tartışıyorsunuz ve çok fazla sorunuz var ve bunu yapmak için birkaç potansiyel çözüm görebilirsiniz. Diğer geliştiriciler ve KG de çok karmaşık olduğu konusunda hemfikir. Yani hepiniz bunun 34 puanlık bir hikaye olduğunu kabul ediyorsunuz. Fibo ölçeğinin aynı zamanda esimate'e ne kadar güven duyduğunuzu belirtmenize izin verdiğini belirtmek gerekir - sayılar arasındaki boşluklar büyüdükçe tahmininizdeki güveniniz azalır

Bu noktada Scrum ustanız atlamalı ve bunun tek bir hikaye olarak çok büyük olduğunu ve daha az karmaşıklığa sahip daha küçük hikayelere bölünmesi gerektiğini söylemelidir. Buna SPIKES olarak bilinen şeyi yaparak yaklaşabilirsiniz - bu, bir şeyi araştırmak için bir kenara bırakılmıştır. Bu örnekte siz ve diğer geliştiriciler olası teknik çözümleri tartışmak ve araştırmak için 4 saat istediğinizi kabul ediyorsunuz.

Uzun bir hikayeyi kısaltmak için bu büyük hikayeyi 5, 8, 8 ve 13 puanlık diğer dört hikayeye ayırırsınız. Unutmayın, bu tahminler tamamen göreceli karmaşıklık ile ilgilidir - orijinal tahmine eklemek zorunda değiller, ayrıca daha doğru bir tahmin yapmak için şimdi daha fazla bilgiye sahipsiniz.

Daha sonra bu sprint için 13 puanlık hikayeyi, bir 8 puanlık hikayeyi ve daha önce tanımladığınız 1 puanlık URL değişikliğini tamamlamayı hedefleyeceğiniz bir takım olarak kabul edersiniz. Yani toplam 22 puan. Bir sonraki sprint 27 puan alırsınız, aşağıdaki sprint 18 puan alırsınız. 3 sprintten sonra hızınıza biraz güvenmeye başlayabilirsiniz (hız, ekibinizin bir sprint'te yapabileceği iş miktarıdır). Hızı elde etmek için önceki sprintlerin ortalamasını alın. Yani bu örnekte ortalama (22 + 27 + 18) / 3 = 22,3'tür, bu nedenle 21 olan Fibo ölçeğinde en yakın olana yuvarlayın.

Şimdi bir sonraki sprint için 21 puan almayı hedefleyin.

Hikaye puanı tahmininizin tam olarak doğru olmasını sağlamak için takılmayın - bu tam bir bilim değildir. Bir URL değişikliğinin verileri toplamaktan çok daha az karmaşık olduğunu biliyorsunuz, bu yüzden buna göre puan verin.

Ayrıca bunları bir takım olarak tartışmak da iyidir. Sprint incelemesi sırasında tahminlerinize tekrar bakın ve onlardan memnun olup olmadığınızı tartışın ve bunu bir sonraki sprint planlama oturumuna besleyin.

Tüm takım tahmini

Tüm ekip, her hikaye için tek bir tahmin üzerinde anlaşmalıdır. Bir özellik üretime hazır olana kadar yapılmaz. Sadece kodun yazılması hiçbir şekilde yapılmaz. Deneyimlerime göre Scrum takımları takım olarak çalışırken çok daha etkili oldular. Şu anda birlikte çalıştığım takıma bir örnek verin. Katıldığımda tüm sprint toplantılarını yapıyorlar ve poker planlıyorlardı ama sprint sırasında süreç 1 idi. BA'lar / Ürün Sahipleri gereksinimleri kabul kriterleri ve kabul testleri ile hikayeler olarak tanımlıyorlar. kod 3. Geliştiricinin, QA'nın 4. test etmesi için geliştirme dalında birleştirilmiş kodu vardır.

Burada eksik olan ne? Ön tarafta yeterince tartışma yok ve her ekip üyesi sadece kendi görevini gördü. Şimdi BA / PO, devs ve QA, gereksinimleri ayrıntılı olarak tartışmak ve soruları önceden sormak için herhangi bir kod yazmadan önce bir araya gelir, ardından sprint boyunca tartışmaya devam edin. Bu çok daha verimlidir ve daha kaliteli çözümlere yol açar.

Poker planlamak bu sürece yardımcı olur, çünkü takımı özelliği tartışmaya zorlar ve ekip olarak bu özelliğin ne kadar karmaşık bir şekilde teslim edildiğini kabul eder. Geleneksel yazılım geliştirmede Proje Yöneticisi projenin tesliminden sorumluydu, ancak bu yaklaşımı deneyimleyen herkes bunun işe yaramadığını biliyor çünkü daha sık değil, insanlar uygulamanın teslimindeki rolleri için sorumluluk almıyorlar. Agile'de proje yöneticilerine ihtiyaç duymamalısınız, çünkü takım başvurunun teslimi için bir bütün olarak sorumluluk alır.

Görevlerin zamanında tahmin edilmesi

Görevler üzerinde zaman tahmin eden ekiplerle ve sadece hikaye noktası esim yapan ekiplerle çalıştığım görüşüm ZAMANIN TAHMİN EDİLMEMESİ! Aslında sadece zaman kaybı. Hikaye puanları kadar doğru değiller, çünkü takım değil bireylere özgüdürler ve her bireyin farklı bir zaman tahmini fikri vardır (alev getir).

Hikaye noktaları, şeylerin, yani gereksinimlerin sürekli değiştiğini kabul eder, böylece takımın bir sprint'te neler yapabileceğini gösteren bir göstergeye ihtiyacınız vardır.

Bir hız anlayışına sahip olduğunuzda, her bir sprint'te ne yapabileceğinizi bilirsiniz, örneğin her iki haftada bir, hangi özelliklerin sunulabileceğini bilirsiniz. Scrum master'ınız ve ürün sahipleriniz gelecekteki sprint'lere bakmak için tahmin oturumları yapıyor olmalıdır, o zaman önümüzdeki birkaç ay içinde ne kadar iş yapacağınıza dair bir gösterge alabilirsiniz. Bu, ürün sahiplerinin son uygulamaya hangi özelliklerin dahil edileceğine ilişkin önceliklendirme kararları almalarını sağlar.

Geliştiriciler planlamak için görevler için zaman tahmin etmemizi istedim ama aslında bu yaklaşıma katılmıyorum (aslında bu yaklaşıma kesinlikle katılmıyorum) çünkü doğru değil, örneğin bu beni gerçekten 4 saat sürecek ne demek: bir geliştirici sadece görevin zamanını içerebilir, başka biri çay yapmak için zaman ekleyebilir!

Zaman tahminleri her zaman raporlama amacıyla bir başkasına verilir ve aynı zamanda bir takımın tüm çabalarına karşı bir özellik sunmanın bireysel unsurlarını fazla vurgulamaktadır.

Tahmin en büyük problem değil

Bir yana, tahminleri çözmek takımların çözmesi gereken en büyük sorun değil. En önemli şey, sprint boyunca işleri halletmek için bir ekip olarak birlikte çalışmaktır, böylece son gün test için her şeyi teslim etmezsiniz. 2 haftalık sprint boyunca sürekli bir özellik damlası görmek istiyorsunuz. Yukarıda açıkladığım takım dinamiği bunun büyük bir parçası. Hikaye puanı tahmini, bunu planlamanıza yardımcı olacaktır, çünkü düzenli olarak teste tabi tutulabilecek küçük hikayelere bölünmesi gereken büyük hikayelerin hangileri olduğunu göreceksiniz.

Wikipedia pokeri planlamayı gayet iyi açıklıyor . Durumunuzla ilgili bazı durumları özetleyeyim:

Neden poker planlıyorsunuz?

Her şeyden önce, "normal" bir tahminin yerine neden bir planlama pokeri yaptığınıza dair hepiniz gemide olmalısınız. Nedeni aslında oldukça basit: Bir görev için zaman tahmin etmek söz konusu olduğunda hepimiz büyük zaman geçiriyoruz . Hemen hemen her çalışma, insan beyninin herhangi bir makul zaman alan görevi tahmin etmekten aciz olduğunu ortaya koydu. (Ayrıca, tahminlerinde 2-3 günden fazla olan biletlerin tahminleri açısından neden değersiz olduğu da bir nedendir.)

Neden çabadan ziyade karmaşıklık?

Bu yukarıdakilerle el ele gider. Çaba genellikle zaman demektir ve biz bunu emeriz. Bunun yerine karmaşıklığın nesnel olarak ölçülmesi zordur, bu durumda bu iyi bir şeydir. Bu hikayenin karmaşık olacağını söyleyen bağırsağınız. Başka biri için daha az karmaşık olabilir. Ancak tam olarak ne kadar karmaşık olduğunu ölçmenize gerek yok. XSonunda bunun Xbirkaç gün sürdüğünü kabul etmeniz gereken zamanlanmış bir çabanın aksine, bu karmaşıklığı elde etmenize gerek yoktur .

Kartları neden gizlemeliyim?

Karmaşık misafiriniz olan kartlar gizli olarak oynanır ve sonra bir kerede ortaya çıkar. Bu, kendi ilk tahmininizi yapmadan önce başkalarının görüşlerinden etkilenmemenizi sağlamak için yapılır. Herkes karmaşıklık açısından aynı bağırsak hissine sahipse, işiniz bitti demektir. Eğer çılgınca farklı sayılar varsa, orada tartışılması gereken bir şey olduğunu biliyorsunuz. Bu şekilde, herkesin gerekli karmaşıklık / çaba hakkında aynı fikre sahip olduğu hikayelerle çok hızlı bir şekilde başa çıkabilirsiniz.

Neden Fibonacci sayıları?

Kartlarınızdaki sayılar tipik olarak Fibonacci sayıları veya sayılarda çok fazla boşluk bulunan başka tür bir sıradır. Bu sizi bağırsak hislerinize tam olarak güvenmeye zorlamak içindir. 8 ile 13 arasında seçim yapmanız gerekiyorsa, bu 9 veya 10'a gitmekten çok daha fazla bir ifadedir. Ayrıca, yukarıda belirtildiği gibi, büyük farklılıklar gizli sorunların olduğu yerdir, bu nedenle boşlukları genişleterek bu sorunları daha iyi tespit edebilir.

Bu neden işe yarıyor?

İlginç bir şekilde, planlama pokerini ilk defa yaptığınızda işe yaramaz. Bu kadar basit. "3" veya "5" ne anlama geliyor? Her sayının ne anlama geldiğine dair bir tanım yoktur (bilerek!) Ve bu sayıların her birinin arkasındaki gerçek anlamı keşfetmek tüm ekibinize bağlıdır. Ancak hikayelerinizi bu sayılarla tahmin etmeyi kabul ettikten sonra - ve bunlardan birkaçını fark ettikten sonra - ne zaman 5'i yükseltmeniz ve ne zaman 8 olduğu konusunda daha iyi bir fikir edinebilirsiniz.

Bunu hız kavramı ile birleştirdikten ve bu hikaye noktaları üzerinden sprint ilerlemelerinizi ölçtüğünüzde, geleneksel zaman tahminlerinden aşağı yukarı bağımsız olan yepyeni bir verimlilik ölçeğine sahipsiniz.

Bununla birlikte, kişisel olarak, pokeri planlamanın en yararlı noktası, zaman tahminleri yerine fibonacci sayıları kullanarak, belirsizlikleri tespit etmek için çok daha kolay bir zamanınız olmasıdır. Klasik zaman tahminleri ile bu tür "aşırı" (sayı boşlukları nedeniyle) kararlar vermek zorunda değilsiniz, bu nedenle, tahminler birbirine oldukça yakın olabilir ve takım hikayeyi yeterince iyi anladıklarına yanlışlıkla inanabilir.

Misal

Tipik olarak ne olduğuna dair basit bir örnek, bir hikayenin sunulması ve daha sonra A kişisinin bir itiraz bulmasıdır. "Lütfen bu özelliğin X'i etkilediğini unutmayın ve bu şimdiye kadar düşündüğümüzden daha maliyetli olduğu anlamına gelebilir". Asıl sorun, masada her zaman bu A kişisinin bulunmasıdır. Her zaman birisinin endişe ettiği bir şey vardır. Açık bir ön tartışmanız varsa, X'in bu şeyin ne kadar büyük bir endişe olduğu hakkında hiçbir fikriniz yok.

Zamana dayalı gizli tahminler yaparsanız, biraz daha iyi olur. Fakat yine de, geçerli bir itirazı olan bir kişi henüz tahminde net bir aykırı değer olmayabilir. Öte yandan, planlanan poker ile A kişisi, X'in gerçek bir sorunun ne kadar olduğu hakkında daha fazla düşünmek zorundadır. İki farklı sorun için, bunların önemini yukarıdaki “sözlü itiraz metni” ile doğru şekilde ayırt edemezsiniz. Zaman tahminlerinde bile hangisinin daha sorunlu olduğunu görmek oldukça zordur. Burada planlama poker kullanarak umudu tek itiraz başkalarının tahminlerden sadece 2-3 puan Farklı olmanın sona ama ortanca 5 veya 8 puan uzakta bitti diğer itiraz sadece olabileceğidir en önemli belirsizlik sprint planlama.

Ekibimdeki düzinelerce tekrardan sonra, hikaye noktalarının çoğunlukla orta vadeli proje yönetimi ile ilgili olduğunu anladık. Ürün sahibinin 2 veya 3 sprint ileriye doğru projeksiyon yapmasına izin verir ve temel olarak ortalama bir hıza bağlı olarak bir sürüm hakkında iş ve kapsam kararları verir.

Hikaye puanlarının sprint düzeyinde çok kullanışlı olmadığını keşfettik, çünkü 2 sprint benzer değil ve ne kadar işin yapılacağını tahmin etmek imkansız. Sonuç olarak, tahmin kısmına takıntılı olmamaya karar verdik ve sadece poker oturumlarını özellikler hakkında konuşmak için bahane olarak planlamaya karar verdik.

Bu, Mike Cohn'un burada yaptığı bir nokta ile aynı fikirde .

Bir yan not olarak, bu belirli bir takım için geçerlidir, ancak hikaye noktalarının size nasıl yardımcı olacağına dair bir kural yoktur. Öncelikle metodolojiye bağlı kalmanızı tavsiye ederim , ancak yararlı olup olmadıklarını ve nasıl olduklarını hızlı bir şekilde kendiniz bulmaya çalışın. Retrospektifler bunun üzerine düşünmenize yardımcı olacaktır.

Buradaki temel sorun kırılmış olmasıdır. Başbakan, bir sprint'e kaç takımın (takımın hızı) takılabileceğini bilmek amacıyla planlama pokerini her hikayenin karmaşıklığı hakkında bir fikir edinmek için kullanmak istiyor.

Sonuç olarak, onun "zamana dayalı değil" bir "zamana dayalı değil". Herkesin kafasının karışmasına şaşmamak gerek.

Bu işi sizin için yapmanın yolları var. Öncelikle çabayı unutun ve karmaşıklığa odaklanın. Her hikayenin etkilediği alanlara odaklanmanın ve odaklanmanın ne kadar süreceği hakkında her şeyi unutun. DB'yi, sunucu kodunu, istemci kodunu ve istemci belgelerini güncelleyen bir hikayeniz varsa, bunun 4 noktalı bir hikaye olduğunu söyleyebilirsiniz. Sadece DB sql bir değişiklik ise, o zaman 1 puanlık bir hikaye. Bu, hikayeler arasındaki göreceli karmaşıklığı bulmanın daha anlaşılır bir yolunu sunar. (Koşullarınız için anlamlı olabilecek bazı metrikler, belki de test kapsamı gereksinimleri veya kullanıcı arayüzü karmaşıklığı bulmanız gerekir)

Benim düşüncem genellikle olsa da, sanki küçük şelale projeleri gibi sprint planlamayı teşvik eden anlamsız bir zaman kaybıdır. Bir sprint'e kaç hikaye puanı sığdırabileceğini kim gerçekten önemsiyor? Bir sprint sonunda kalan hikayeleriniz varsa, bunları bir sonrakinde yapın. Bu göz önüne alındığında, birikiminizi sadece sahip olduğunuz her olağanüstü hikayenin boyutuna getirebilir ve zaman içinde yavaş yavaş eritebilirsiniz. Teslim süresi kadar sürer (ancak birikim ve sprint planlama toplantılarında zamanınızın% 20'sini boşa harcamayınca daha hızlı olacaktır). Projenin sonunda, kimse kaç hikaye noktasının teslim edildiğini umursamıyor. İnsanların ilgilendiği şey teslim edilen projedir.

Ayrıca kullanıcı hikayesi işaret, herhangi bir şeyin yeniden pazarlık yapması gerekip gerekmediği konusunda işletmeye kafa yoruyor. 100 olarak aldığınız bir işi tamamlamak için bir ayınız varsa başınız derde girebilir. aynı zamanda destansı bir hikayeyi hala değeri olan ve bir sprint'te tamamlanabilen daha küçük bir şeye bölme şansı verir.