उपयोगकर्ता कहानियों का आकलन करते समय हम आदमी दिनों के बजाय कहानी बिंदुओं का उपयोग क्यों करते हैं?

Question

चुस्त कार्यप्रणाली (जैसे SCRUM) में, उपयोगकर्ता कहानियों के लिए आवश्यक जटिलता / प्रयास को स्टोरी पॉइंट में मापा जाता है। स्टोरी पॉइंट्स का उपयोग यह गणना करने के लिए किया जाता है कि टीम कितने उपयोगकर्ताओं को एक पुनरावृत्ति में ले जा सकती है।

एक अमूर्त अवधारणा (कहानी अंक) को शुरू करने से क्या फायदा है, जहां हम अनुमानित मानव-दिनों की तरह एक ठोस माप का उपयोग कर सकते हैं? हम अनुमानित मानव-दिनों का उपयोग करके वेग, अनुमान की कवरेज आदि की गणना भी कर सकते हैं।

इसके विपरीत, कहानी के बिंदुओं का उपयोग करना कठिन है (क्योंकि अवधारणा सार है), और हितधारकों को समझाने के लिए भी कठिन है। क्या लाभ प्रदान करता है?

Comments

आप क्यों मान रहे हैं कि कहानी की तुलना में मानव-दिवस अधिक ठोस है, इसके नहीं।

— रयथल

क्या यह समझाना आसान है कि आपके 5 मानव-दिनों के अनुमान का मतलब है कि इसे पूरा करने में 1 महीने का समय लगेगा क्योंकि आपका वेग 0.25 मानव-दिन / कैलेंडर-दिन है?

— पैट्रिक

@ इज़्काता केवल सच है अगर आप वेग हमेशा 1

— पैट्रिक

@ पैट्रिक मानव-दिनों का उपयोग करते समय ( विकिपीडिया पर मानव-घंटे देखें ), वेग की कोई अवधारणा नहीं है। वह एक फुर्तीली / डरावनी चीज है।

— इजाकाता

दिलचस्प बात यह है कि जैसे ही वेग स्थिर होता है, कहानी बिंदुओं की पहचान एक निश्चित संख्या में घंटों या दिनों के साथ होती है। जैसे, 1 कहानी बिंदु = 1 दिन। अगर मुझे लगता है कि इसमें 2 दिन लगेंगे, तो मैं 2 कहानी बिंदुओं का अनुमान लगाऊंगा।

— जियोर्जियो

Answer 1

मुझे लगता है कि मुख्य लाभ में से एक यह है कि मनुष्य और डेवलपर्स विशेष रूप से समय का अनुमान लगाने में बहुत बुरे हैं। विकास की प्रकृति के बारे में भी सोचें - यह शुरू से अंत तक कुछ रैखिक प्रगति नहीं है। यह अक्सर "10 मिनट में 90% कोड लिखता है और फिर 17 घंटों के लिए अपने बालों को डीबगिंग से फाड़ देता है।" घड़ी की सूझबूझ का अनुमान लगाना बहुत कठिन है।

लेकिन एक अमूर्तता का उपयोग वास्तविक समय को घंटों या दिनों में बंद कर देता है और इसके बजाय अन्य कार्यों की तुलना में किसी कार्य के सापेक्ष खर्च और जटिलता का वर्णन करने पर ध्यान केंद्रित करता है। उस पर मनुष्य / डेवलपर्स बेहतर हैं। और फिर, एक बार जब आप उन बिंदु अनुमानों और कुछ वास्तविक प्रगति के साथ गुनगुनाते हैं, तो आप समय को और अधिक आनुभविक रूप से देखना शुरू कर सकते हैं।

मुझे संदेह है कि एक पर्यवेक्षक प्रभाव भी है जो समय अनुमानों के साथ होता है जो बिंदु अनुमानों के साथ नहीं होगा। उदाहरण के लिए, एक अनुमान के अनुसार सैंडबैग को प्रोत्साहन और "शेड्यूल से आगे" एक बिंदु आधारित प्रणाली में अप्रत्यक्ष रूप से म्यूट होने जा रहा है।

Comments

जटिलता पर ध्यान देने के लिए +1 , समय नहीं। एक बार आपके बेल्ट के नीचे पर्याप्त स्प्रिंट होने पर कच्चे घंटे में अनुवाद करना आसान होगा। मैंने पाया कि समय के साथ कहानियों के बीच परिवर्तनशीलता समाप्त हो जाती है।

— क्रिस्टो

तो वास्तव में, जटिलता अंक कहानी के बिंदुओं की तुलना में एक स्पष्ट शब्द हो सकता है, और बहुत सारे जटिलता बिंदुओं के साथ कोई भी कार्य बहुत जटिल है और संभवतः सभी को एक ही बार में निपटने के लिए बहुत सारे जोखिम और अज्ञात शामिल हैं। जटिलता की घातीय लागत है, और उस कार्य के साथ खराब हो जाने वाले खराब sod एक छेद खोदते जा रहे हैं ताकि वह हफ्तों या महीनों तक फिर से दिखाई न दे। बेहतर पहले जटिल कार्य को समझने का एक सरल कार्य करें, और इसे कम जोखिम वाले और बेहतर समझ वाले जटिलता वाले छोटे कार्यों में विभाजित करें।

— सुप्र

समय और लागत प्रभाव हैं, जटिलता का कारण है, और आप जटिलता को समझे बिना समय को नहीं समझ सकते हैं।

— सुप्र

कहानी के अंक = जटिलता अंक - 2 शब्दांश। :-D

— क्रिस्टो

क्या किसी ने कभी कॉलिंग पॉइंट "कास्टिंग कॉस्ट" पर विचार किया है? => nerd

— आरोन जिब्राल्टर

Answer 2

यदि आप फाइबोनैचि संख्याओं (या कुछ इसी तरह) का उपयोग कर रहे हैं, तो यह कहानी का अनुमान लगाते समय विकल्पों की संख्या को सीमित करता है। मैंने एक ऐसे समूह के साथ काम किया जो केवल निम्न संख्याओं का उपयोग करता था: 1, 2, 3, 5, 8, और 13. हमारे पास एक संदर्भ कहानी थी जो एक थी 5. यह हमें पोकर की योजना बनाते समय एक कहानी की जटिलता पर आसानी से निर्णय लेने में सक्षम बनाता था । दूसरा साइड इफेक्ट यह था कि किसी भी चीज को 13 की श्रेणी में रखा गया था, जिसके बारे में शायद अपर्याप्त जानकारी थी और इसे और भी तोड़ दिया जाना चाहिए। मुझे गंभीरता से संदेह है कि अगर हम कच्चे घंटे का उपयोग कर रहे हैं तो यह आसान और सीधा होगा।

आपका उत्पाद स्वामी आपके हितधारकों की भाषा बोलता है और आवश्यकतानुसार कहानी बिंदुओं और मानव-घंटों (या अन्य इकाइयों) के बीच अनुवाद करने में सक्षम होना चाहिए। पीओ के रूप में मेरे समय के दौरान, मेरे पास कुछ कठिन आंकड़े थे जो 1 स्टोरी पॉइंट = 4 मैन-घंटे थे, लेकिन जाहिर है कि हर टीम अलग है।

संपादित करें:

इस ज्ञान के साथ कि 1 अंक = 4 घंटे, आप सैद्धांतिक रूप से अपने नियोजन पोकर डेक को 4, 8, 12, 20, 32 और 52 में बदल सकते हैं। लेकिन उन नंबरों से निपटने के लिए कठिन लगता है। मुझे लगता है कि मैं मानसिक रूप से कुछ वापस करने के लिए मानसिक रूप से अमूर्त करूंगा, उदाहरण के लिए, "एक दिन से भी कम", "एक सप्ताह से अधिक", आदि और अगर मैं ऐसा करने जा रहा हूं, तो मैं सार इकाई के साथ छड़ी कर सकता हूं -विहीन कहानी अंक।

Comments

हम इसी पद्धति का उपयोग करते हैं, और हमारे नियोजन डेक की संख्या अधिक होती है, लेकिन हमने 20 को परिभाषित किया है जिसका अर्थ है कि यह टूट गया है या बेहतर परिभाषित किया गया है। हमारे लिए एक 13 हमारा सबसे बड़ा काम है और आमतौर पर ये ऐसे कार्य हैं जिन्हें समाप्त करने के लिए एक सप्ताह में अधिक से अधिक समय लगता है।

— बिल लीपर

"दूसरा साइड इफेक्ट यह था कि 13 में से कुछ का मूल्यांकन किया गया था, जिसके बारे में शायद अपर्याप्त जानकारी थी और आगे भी टूटने की जरूरत थी।" और मुझे लगता है कि अगर यह और टूट गया, तो इसे बराबर फाइबोनैचि भागों में तोड़ दिया जाएगा?

— जो जे।

@ जोज़ेंग, हाँ, वे अक्सर 8 + 5 या 5 + 5 + 3 बन गए। हालाँकि यह एक सार माप है, इसलिए यदि नई कहानियाँ पर्याप्त हैं, तो मुझे बहुत चिंता नहीं थी। टीम आम तौर पर एक 13 को दो 8 या तीन 5 के रूप में अवशोषित कर सकती है, लेकिन तीन 8 का मतलब है कि मुझे हितधारकों के साथ एक स्पष्ट बात करने की आवश्यकता है। आदर्श रूप से, हमने पहले से काफी अनुमान लगाया था कि यह वर्तमान स्प्रिंट को प्रभावित नहीं करेगा।

— क्रिस्टो

जरुरी नहीं। हमारे पास 5 अंक होने के बारे में धारणाएं हैं, और अधिक विस्तृत, टूटी-फूट योग 15 बिंदुओं की सीमा में है। होता है।

— ashes999

Answer 3

यह समय के साथ बेहतर होने के लिए अनुमान को सक्षम करने के लिए है, बिना अनुमान के सभी अपने अनुमान को समायोजित करने के लिए।

अनुमान लगाने में शामिल सभी के बजाय "ओके .. 2 आदमी दिनों की तरह लगता है .. लेकिन पिछले स्प्रिंट हमने सब कुछ कम करके आंका था, इसलिए शायद यह वास्तव में 2.5 आदमी दिन है। या 3?", वे हमेशा की तरह ही चलते हैं। "5 कहानी अंक!"

फिर, आप अपने अनुमान को समायोजित करते हैं कि पिछले स्प्रिंट में वास्तविक मापी गई उपलब्धि के आधार पर एक अंक में टीम कितने अंक प्राप्त कर सकती है। "हम पहले प्रति स्प्रिंट 90-110 कहानी अंक कर रहे हैं!"

मैं कहूंगा कि इसके पीछे सिद्धांत यह है कि डेवलपर्स विभिन्न देव कार्यों की सापेक्ष जटिलता का अनुमान लगाने में बेहतर हैं, क्योंकि वे निरपेक्षता का अनुमान लगा रहे हैं । खासकर अगर कई लोग एक ऐसे कार्य का अनुमान लगा रहे हैं जो उनमें से किसी एक द्वारा किया जा सकता है (और हर कोई उसी गति से काम नहीं करता है जैसा हर कोई करता है)।

निंदक विकल्प: मैंने देखा है कि डेवलपर्स समय के अनुमान के अनुसार कभी नहीं आते हैं। यदि अनुमान से अधिक समय लगता है, तो आप खत्म हो गए हैं। लेकिन अगर कुछ अनुमानित से कम समय लेता है , तो डेवलपर्स इसके साथ सो सकते हैं, गोल्ड-प्लेट, या बस धीमा कर सकते हैं और इसे आसान कर सकते हैं क्योंकि उन्हें एक कुशन असाइनमेंट दिया गया है। एक अनुमान के अनुसार समय की वास्तविक इकाइयों को लेने से इन प्रवृत्तियों पर अंकुश लग सकता है। अंतिम निंदक विकल्प।

Comments

वह भी खौफनाक नहीं है। यह "तेज या सस्ता या अच्छा" का सिद्धांत है। मैं आपको FizzBuzz का अधिकतर स्थिर, अधिकतर काम करने वाला संस्करण दे सकता हूं, जो आपको वह देगा जो आप आम तौर पर कुछ मिनटों के भीतर चाहते हैं, लेकिन यदि आप उपयोगकर्ता सहभागिता चाहते हैं, तो आपको अधिक समय लगेगा, और यदि आप प्रतिगमन परीक्षण चाहते हैं, तो वह आपको ले जाएगा अब, और यदि आप चाहते हैं कि जब आप MAX_INT से टकराते हैं तो यह विफल न हो, इसमें अधिक समय लगेगा। मुझे गति को प्राथमिकता देने के लिए कहें, और मैं पुनः डंप करना शुरू कर दूंगा। मुझे हर चीज को प्राथमिकता देने के लिए कहो, और मैं अपने दिए गए हर समय का उपयोग करूंगा।

— डेवॉर्ड

Answer 4

आदमी दिन या आदमी घंटे के रूप में आप ठोस कहते हैं। इसलिए जब किसी कार्य का 5 घंटे का अनुमान लगाया जाता है और 6 लगते हैं तो यह अब देर से आने वाला कार्य है।

जब आपके पास एक कहानी है जो 3 अंक है और इसमें 6 घंटे लगते हैं, तो 6 घंटे लगते हैं, यह देर नहीं हुई है, बस छह घंटे लगते हैं। की तुलना में वेग माप अधिक है कि आप उन बिंदुओं में से कितने अंक एक स्प्रिंट में करते हैं, और यह संख्या में उतार-चढ़ाव हो सकता है, क्योंकि यह ठोस नहीं है। आप प्रत्येक कार्य को नहीं, बल्कि सभी कार्यों को भी माप रहे हैं। जब आपके पास प्रत्येक कार्य के घंटे होते हैं, तो प्रलोभन प्रत्येक कार्य को मापने के लिए होता है। जब ऐसा होता है, तो आपको समय के तहत परिष्करण के लिए स्प्रिंट का कोई लाभ नहीं मिलता है और यह किसी भी कार्य के समय पर परिष्करण के लिए एक परिणाम है।

यह अंकों के संदर्भ में सोच के लिए एक संक्रमण हो सकता है। एक जगह मैंने काम किया, इससे पहले कि हम भी प्रयास के स्तर पर एक विचार प्राप्त करने के लिए चुस्त टी-शर्ट आकारों का परिचय दिया। अंक उसी का एक विस्तार हैं।

यह कहना नहीं है कि विवाद या कुछ मनमाने ढंग से असाइनमेंट नहीं है। हमारे पास हमारी टीम के सदस्य हैं जो लगभग हमेशा सबसे कम संख्या में मतदान करते हैं, और शिकायत करते हैं जब उन्हें लगता है कि एक कार्य 1 है और हमें लगता है कि यह एक 3 है जो हम बिंदु मुद्रास्फीति से पीड़ित हैं।

Answer 5

अमूर्त बिंदु की तरह है। माप के रूप में 'मैन डे' के उपयोग से कई नुकसान होते हैं, जिनमें शामिल हैं:

1. यदि टीम उस तकनीक से परिचित नहीं है जिसका वे उपयोग करने जा रहे हैं, तो वास्तव में कठिन समय का अनुमान लगाने में मुश्किल हो सकती है कि किसी कार्य में कितना समय लग सकता है। वे अच्छे सापेक्ष अनुमान देने में सक्षम होने की अधिक संभावना रखते हैं - उदाहरण के लिए "कार्य ए को संभवतः कार्य बी के रूप में दो बार लगेगा"।
2. अलग-अलग लोग अलग-अलग दरों पर काम करते हैं! यदि आप 'मैन डेज' का उपयोग करते हैं, तो आपको एक डेवलपर से दूसरे डेवलपर के पास एक कार्य के पारित होने के समय के अनुमान को बदलना होगा। कौन परिभाषित करता है कि किसी भी कार्य को 'मैन डे' कितना माना जाता है?

यदि आप मानव-दिवस का अनुमान लगाना चाहते हैं तो यह एक सरल गणना है:

user points in story / average user points per developer per day = estimated man days

Comments

बिंदु 2 के बारे में: कहानी बिंदु इससे कैसे हल होता है? आप एक कहानी का अनुमान 4 कहानी बिंदुओं के रूप में लगाते हैं। आप इसे तेज़ प्रोग्रामर को देते हैं और इसमें 4 दिन लगते हैं। आप इसे एक धीमी प्रोग्रामर को देते हैं और इसमें 8 दिन लगते हैं। यह मुझे लगता है कि समस्या हल नहीं हुई है, लेकिन बस घूम गई है।

— जियोर्जियो

बिंदु 1 के बारे में। विचार यह है कि यदि टीम परियोजना के लिए आवश्यक तकनीकों से अधिक परिचित हो जाती है, तो उनका वेग बढ़ जाएगा और कहानी के बिंदुओं में मापा गया कहानियों का सापेक्ष आकार समान रहेगा। लेकिन क्या होगा अगर दो उपयोगकर्ता कहानियों को अलग-अलग ज्ञान की आवश्यकता होती है? उदाहरण के लिए, आपके पास जावास्क्रिप्ट / HTML में किया जाने वाला एक फ्रंट-एंड यूज़र स्टोरी और जावा में एक बैक-एंड यूज़र स्टोरी है। जैसा कि टीम जावास्क्रिप्ट, एचटीएमएल और जावा के बारे में अधिक जानती है, उन्हें पता चलता है कि फ्रंट-एंड भाग बैक-एंड भाग की तुलना में बहुत आसान है और कहानियों के सापेक्ष अनुमान फिर से गलत हैं।

— जियोर्जियो

@ जियोर्जियो रे। बिंदु 2: आपके तेज़ प्रोग्रामर की कार्य दर 1 स्टोरी पॉइंट / दिन है, और आपके धीमी प्रोग्रामर की कार्य दर 0.5 स्टोरी पॉइंट / दिन है। यदि आप इसे घंटों में करते हैं, तो या तो आपका तेज प्रोग्रामर स्वयं काम करने जा रहा है, या आपके धीमी प्रोग्रामर को बर्खास्त करने की आवश्यकता है। बिल लीपर का जवाब इस बात को बहुत अच्छी तरह से बताता है।

— विन्गंड्रोइड

पुन। बिंदु 1: मेरे पैसे के लिए, यदि आप तकनीक के 2 अलग-अलग सेट और उत्पाद के 2 अलग-अलग क्षेत्रों के बारे में बात कर रहे हैं, तो आपको दो टीम मिल गई हैं।

— विन्गंड्रोइड

आगे फिर से। बिंदु 2: उपयोगकर्ता की कहानियां टीम द्वारा विकसित की जाती हैं , व्यक्तिगत डेवलपर्स द्वारा नहीं। यह टीम का कार्य-दर है जो महत्वपूर्ण हिस्सा है। ध्यान रखें कि उपयोगकर्ता कहानियों को लागू करते समय आपको पहले कार्यों में उन्हें तोड़ना चाहिए। तेज डेवलपर को अधिक कार्य दें!

— विघ्नहर्ता

Answer 6

जैसा कि पहले ही उल्लेख किया गया है, कहानी अंक जटिलता का एक सापेक्ष माप है। एक अनुमान के लिए 2 श्रृंखला की शक्ति (1,2,4,8,16 ...) या एक फाइबोनैचि स्केल (1,2,3,5,8,13,20 ...) का उपयोग कर सकता है। जैसा कि जासूसी करने वाले डेवलपर्स कुछ इस तरह कहने में माहिर होते हैं:

फ़ीचर A, फ़ीचर B से लगभग दुगना है

लेकिन 'फीचर को लागू होने में कितना समय लगेगा' यह कहना वाकई मुश्किल है। आप इसे वेग से संतुलित होने दें। इसलिए अगर किसी चीज़ का अनुमान 5 था, लेकिन 13 निकला, तो धीमी गति सामान्य होगी जो पुनरावृत्ति के लिए सामान्य होगी (या आप फिर से अनुमान लगा सकते हैं)।

अब, एक और विकल्प है, इसे 'आदर्श दिन' कहा जाता है (कुछ ऐसा है जो मानव-दिनों के समान है लेकिन मुझे यकीन नहीं है कि अगर आपका मतलब है तो) और मुझे ऐसी कुछ टीमों का पता है जो इसे पसंद करते हैं। आदर्श दिनों की व्याख्या इस प्रकार की जानी चाहिए:

यदि वह सब कुछ है जो मैं कार्यालय में आने के बाद करता हूं और केवल आवश्यक ब्रेक लेता हूं, तो कोई रुकावट नहीं है और मेरे पास 'कहानी को लागू करने' के लिए सब कुछ होगा, यानी कोई परिधीय गतिविधियां जैसे बैठकें, मेल का जवाब देना आदि।

माइक Cohn, कई अच्छी तरह से पता है कि चुस्त प्रचारकों में से एक कहानी बिंदुओं और आदर्श दिनों के बीच तुलना प्रदान करता है

कहानी के अंक

• क्रॉस-फ़ंक्शनल व्यवहार को ड्राइव करने में मदद करता है अर्थात टीमें अनुमान लगाती हैं कि यूटी से लेकर डीबी और बैक तक सभी तरह की कार्यान्वयन जटिलताएं हैं।
• एसपी का अनुमान क्षय नहीं होता है यानी अब से कुछ महीने बाद 5 अंक की कहानी 5 अंक होने की संभावना है, लेकिन उस विशेष प्रोग्रामर के अधिग्रहीत विकास कौशल / गति के आधार पर एक आदर्श दिन का अनुमान बदल सकता है।
• एसपी आकार का एक शुद्ध माप हैं अर्थात वे केवल और केवल आकार की जटिलता को दर्शाते हैं। अवधि। कोई अवधि आदि नहीं, इसे फेंक दिया। वह वेग का काम है। लेकिन आदर्श दिनों के साथ ऐसा नहीं है। वास्तव में आदर्श दिनों के साथ कैलेंडर दिनों के साथ इसे गुनगुनाने की प्रवृत्ति होती है। इसे अमूर्त रखने के रूप में एसपी वास्तविकता से तुलना करने के प्रलोभन से लड़ते हैं। आकार का सिर्फ एक उपाय। कोई बकवास नहीं।
• आदर्श दिनों की तुलना में आम तौर पर तेज है। यह पहली कहानियों के लिए मुश्किल हो सकता है, लेकिन एक बार जब आप इसे लटका लेते हैं, तो यह तेज़ हो जाता है।
• अलग-अलग डेवलपर्स एक कहानी को पूरा करने के लिए अपने आदर्श दिन अनुमान पर एक अलग ले सकते हैं। मैं 3 में ऐसा ही कर सकता था और आप 5 में कर सकते थे। एसपी बोर्ड में कमोबेश एक जैसे होते हैं। वे बोलने के लिए खेल के मैदान को समतल करते हैं।

आदर्श दिन

• टीम के बाहर समझाने में आसान; ज़ाहिर कारणों की वजह से :)
• ऊपर बताए अनुसार सबसे पहले अनुमान लगाना आसान है। लेकिन एक बार जब आप एसपी को लटका देते हैं तो यह स्वाभाविक रूप से आता है

अब, टीम में से किसे चुनना है। हालांकि, यहां और मेरे व्यक्तिगत अनुभव के अधिकांश उत्तर के रूप में, मैं कहानी बिंदुओं को पसंद करता हूं। आदर्श दिनों में वास्तव में एसपी पर अधिक लाभ नहीं होता है (और माइक कोहन एसपी के साथ-साथ कई अन्य खुशहाल प्रचारकों की भी वकालत करता है)।

Comments

अगला फिबोनाची संख्या 21 नहीं 20 है।

— जो जेड।

अनुमान लगाते समय 21 या 20 मायने नहीं रखता। झूठी परिशुद्धता की भावना को खत्म करने के लिए एसपी अगले रिट्रेसमेंट नंबर को राउंड ऑफ करते हैं। अनुक्रम में अगली संख्या 34 नहीं है, लेकिन 40 (20 का दोगुना) और फिर 100 है। संख्या जटिलता में 'अनिश्चितता' का प्रतिनिधित्व करती है और सटीक नहीं। यह केवल एक सन्निकटन है।

— पीएचडी

यह सच है, मैं सिर्फ निट्स (और मज़ाक) कर रहा था।

— जो जे।

@PhD: "एसपी का अनुमान क्षय नहीं होता है यानी अब से कुछ महीने बाद 5 अंक की कहानी 5 अंक होने की संभावना है, लेकिन एक आदर्श दिन का अनुमान उस विशेष प्रोग्रामर के अधिग्रहीत विकास कौशल / गति के आधार पर बदल सकता है": यह अंतर्निहित रूप से यह माना जाता है कि टीम परियोजना के सभी क्षेत्रों में समान रूप से अपने कौशल में सुधार करेगी। मैं यह नहीं देखता कि हमेशा ऐसा क्यों होना चाहिए: एक परियोजना के कुछ हिस्से (और उनके लिए आवश्यक तकनीकें) दूसरों की तुलना में कठिन हो सकती हैं, जिससे कहानी की सापेक्ष जटिलताओं का प्रारंभिक अनुमान अवैध हो जाता है।

— जियोर्जियो

Answer 7

कहानी के अंक आपको समय के साथ टीम के प्रदर्शन में सुधार करने में मदद करते हैं। इसके अलावा, आपको प्रदर्शन में सुधार के रूप में सब कुछ फिर से अनुमान लगाने की आवश्यकता नहीं है।

इस उदाहरण को लें जो मानव दिनों का उपयोग करता है:

टीम मानव-दिवस के साथ विभिन्न कार्यों का अनुमान लगाती है। यह कुछ समय के लिए काम करता है, लेकिन कुछ समय बाद आप देखते हैं कि टीम मूल रूप से सोचे गए कार्यों की तुलना में कई काम तेजी से कर रही है। इसलिए टीम कार्यों का फिर से अनुमान लगाती है। यह थोड़ी देर के लिए काम करता है, और कुछ समय बाद आप फिर से उसी चीज को देखते हैं: टीम फिर से कई कार्यों के साथ तेजी से किया जाता है। तो आप फिर से अनुमान लगाते हैं , और यह कहानी फिर से दोहराती है, और बार-बार ...

क्यों? क्योंकि आपकी टीम का प्रदर्शन बढ़ गया। लेकिन आप इसके बारे में नहीं जानते हैं।

कहानी अंक के साथ एक ही उदाहरण:

टीम उपयोगकर्ता कहानियों के आकार का अनुमान लगाती है । कुछ स्प्रिंट के बाद, आप देखते हैं कि टीम प्रति स्प्रिंट के बारे में 60 कहानी अंक कर सकती है। बाद में, आप देखते हैं कि टीम ने 60 से अधिक कहानी अंक हासिल किए हैं, शायद 70. और टीम उसी तरह जारी है और अगले स्प्रिंट के लिए अधिक उपयोगकर्ता कहानियों को खींचती है और उन्हें वितरित करती है।

क्यों? क्योंकि प्रदर्शन बढ़ गया है। और आप इसे माप सकते हैं। और आपको अपनी टीम के प्रदर्शन में वृद्धि के बाद सब कुछ फिर से अनुमान लगाने की आवश्यकता नहीं है।

Comments

"क्यों? क्योंकि आपकी टीम का प्रदर्शन बढ़ गया।": एक वैकल्पिक व्याख्या यह है कि थोड़ी देर के बाद टीम अधिक सटीक / यथार्थवादी समय का अनुमान देना शुरू कर देती है (क्योंकि वे पिछले स्प्रिंट में कुछ कार्यों के साथ देर हो चुके थे, वे अधिक समय असाइन करना शुरू करते हैं जब बाद के स्प्रिंट के लिए कहानियों का अनुमान लगाना)।

— जियोर्जियो

Answer 8

सबसे पहले, लोग पूर्ण अनुमान की तुलना में सापेक्ष अनुमानों में बेहतर हैं। बेबीलोनियन मैपिंग और तारों की सापेक्ष चमक को रेटिंग देना एक बेहतरीन उदाहरण है। उन्हें पूर्ण आंकड़े सही नहीं मिले, लेकिन यह आदेश ज्यादातर समान तीव्रता के लिए भी हाजिर था।

दूसरा फायदा यह है कि इस अभ्यास को करने का एक प्रमुख कारण बातचीत को चलाना है। यदि आप सटीक दिनों में चर्चा शुरू करते हैं, तो बातचीत जल्दी से पटरी से उतर सकती है।

जैसा कि नेपोलियन ने कहा: योजना बेकार है, योजना अमूल्य है।

तीसरा, परियोजना प्रबंधक को सभी अनुमानों को संपादित करने की आवश्यकता नहीं है, सिर्फ इसलिए कि यह पता चलता है कि अनुमान 130% के कारक से बंद थे।

Answer 9

स्टोरी पॉइंट्स समस्या की जटिलता को दर्शाते हैं, और इसलिए, अनुमान कितना सही है, इसके आत्मविश्वास (या जोखिम) को दर्शाते हैं।

एक उच्च कहानी के साथ एक कहानी मुझे बताती है कि उपयोगकर्ता कहानी के साथ बहुत कुछ चल रहा है जो ठोस नहीं है।

विचार यह देखना है कि अलग-अलग कहानी बिंदुओं का एक अच्छा संतुलन क्या है। अगर मुझे सभी उच्च कहानी बिंदुओं वाली कहानियों के साथ एक पुनरावृति योजना दिखाई जा रही है, तो यह मुझे थोड़ा विश्वास दिलाता है कि पुनरावृत्ति को उम्मीद के अनुसार निष्पादित किया जाएगा और हमें पुनरावृत्ति के लिए अन्य कहानियों को देखना होगा या कहानियों को तोड़ना शुरू करना होगा।

एक प्रबंधक या उत्पाद मालिक के साथ संवाद करते समय, उच्च कहानी बिंदुओं का मतलब है कि यह बहुत ही धुंधला होगा जब वे एक विशेष सुविधा प्राप्त करेंगे। इसका एक समाधान कहानी को तोड़ना है और उम्मीद है कि आपके पास काम करने के लिए कम और उच्च कहानी बिंदुओं का एक संयोजन होगा ताकि आप उत्पाद स्वामी की प्रगति को प्रदर्शित कर सकें।

Answer 10

मैन डेज़ कुछ करने के लिए लगने वाले समय का अनुमान लगाता है। उनका सबसे अच्छा उपयोग तब किया जाता है जब आप जिन वस्तुओं का आकलन कर रहे हैं वे बहुत सटीक और औसत दर्जे का हैं। विशिष्ट, अच्छी तरह से जाना जाता है, दोहराए जाने वाले कार्य आदमी के दिनों में अनुमानित हैं।

उदाहरण के लिए, यदि कोई बिक्री व्यक्ति प्रति दिन 20 ग्राहक कॉल कर सकता है, तो हम औसतन यह गणना कर सकते हैं कि प्रत्येक कॉल में कितना समय लगता है और इससे हम अनुमान लगा सकते हैं कि 1000 कॉल करने में कितने आदमी दिन लगेंगे।

इस उदाहरण में कोई व्यक्ति किसी कॉल की औसत लंबाई के बारे में सांख्यिकीय शब्दों में सोच सकता है क्योंकि सभी कॉलों को समान रूप से प्रभावी माना जा सकता है।

कहानी के बिंदु यह निर्धारित करते हैं कि कहानियों का संयोजन किस पुनरावृत्ति में किया जा सकता है। उनका उपयोग फजी सीमाओं के साथ विषम लक्ष्यों को संयोजित करने और यह निर्धारित करने के लिए किया जाता है कि एक निश्चित समय सीमा में कितने किए जा सकते हैं। वे एक-दूसरे की तुलना में काम के विखंडन की जटिलता का अनुमान लगाते हैं ताकि वे उन्हें एक साथ जोड़ सकें।

उदाहरण के लिए, आपकी टीम ने पुनरावृत्ति 1 में कुल 23 बिंदुओं के लिए 5 कहानियां विकसित कीं, और पुनरावृति 2 में 20 अंकों के लिए 8 कहानियाँ। इससे आप अनुमान लगा सकते हैं कि पुनरावृत्ति में आपकी टीम कुछ कहानियाँ करेगी, जिनकी कुल संख्या लगभग 20 अंक है यात्रा 3 में।

ध्यान दें कि हमें एक बिंदु के आकार को निर्धारित करने की आवश्यकता नहीं है और विशेष रूप से कोई धारणा नहीं है कि समान आकार की प्रत्येक कहानी को विकसित होने में एक ही समय लगेगा! हम केवल रकम पर और प्रति पुनरावृत्ति बिंदुओं पर काम करते हैं। मैंने यह भी उल्लेख नहीं किया कि चलना कितना लंबा है।

Answer 11

यदि आप सड़क पर एक मानव के लिए चलते हैं और पूछते हैं कि "टी-रेक्स कितना बड़ा था?" उत्तर में भले ही मनुष्यों को पता हो कि टी-रेक्स कितना बड़ा है, यह कितना उतार-चढ़ाव भरा होगा, लेकिन वास्तव में कुछ के लिए कोई नहीं जानता - क्योंकि हमारे पास आधार रेखा से कोई सापेक्षिक पैमाना नहीं है।

यह वह संज्ञानात्मक व्यवहार है जिसे आप पूर्वानुमान के साथ जानने की कोशिश कर रहे हैं और कई कार्यप्रणालियों के साथ चक्र लगा है " मुझे मिल गया है! .. मेरे पास सटीक पूर्वानुमान का रहस्य है! " जनता को सांप का तेल। जब आप वास्तव में पूर्वानुमान लगाते हैं तो आप वास्तव में कह रहे हैं " मैं इसे पूरा करने के लिए x दिन / घंटे / अंक प्राप्त करूंगा " - इस अर्थ में उस घटना के लिए एक "टाइमबॉक्स" बनाना।

मेरे लिए, पॉइंट्स बस सीमाओं को पार कर रहा है, दिन के अंत में जब तक आप एक ऐसी टीम में न हों जो यह कहने में प्रसन्न हो "" वैसे हमारे पास प्रति सप्ताह 3 सप्ताह है, और अंगूठे को चूसना है ... मुझे लगता है कि हमें शूट करना चाहिए उस चक्र को पूरा करने के लिए 30 अंक! मेरे साथ कौन है! * "और यह उतना ही गहरा है जितना कि आप पूर्वानुमान मॉडलिंग में जाते हैं - ठीक है! ..तो वास्तव में आप सिर्फ एक मध्यस्थ बजट निर्धारित कर रहे हैं और वह यह है। तब आप भी पूर्वव्यापी कार्य में "पवित्र बकवास" की भावना के साथ काम पूरा करते हुए देख रहे थे, हमने 33 प्रयास किए कि स्प्रिंट, यह बहुत अच्छा था "और इसके बारे में बहुत कुछ नहीं किया जा सकता है। आप मध्य-स्प्रिंट का निर्धारण करने के लिए वेग का उपयोग कर सकते हैं जिसे आप अपने बजट रुपये के लिए धमाकेदार तरीके से पूछ रहे हैं " क्या हमने अभी तक 15 बार मारा है? क्या हम करेंगे?""लेकिन यहां खतरा यह है कि अब आप वेग का उपयोग उत्पादकता को मापने के लिए कर रहे हैं न कि क्षमता जिसे मैं समझता हूं कि प्रतिक्रियाशील रिलीज मैनेजमेंट (कहानी अंक) को सिर में मारता है।"

बिंदु प्रणाली लगभग बहुत चालाक है कि आप अभी भी समीकरण के सापेक्ष समय संलग्न नहीं करते हैं, आपके सहमत "स्प्रिंट साइकिल" से सब कुछ आपके दैनिक स्टैंडअप के लिए जिसमें आप अवधि + जटिलता के आसपास कुछ छिपे हुए नियम को लागू करते हैं = " अधिकतम समय लग रहा है उस कार्य के साथ "जन्मजात कण्ठ भावना टीम कोड लाल पल?

मानव मस्तिष्क का अनुमान नहीं लगाया जा सकता है क्योंकि इसमें बहुत सारी कार्यशील मेमोरी शामिल होती हैं जो लंबे / अल्पकालिक स्मरण के साथ मिश्रित होती हैं, इसलिए इसकी तरह एक नौसिखिया गणित के छात्र को अपने सिर पर फ्रैक्चर करने के लिए कहता है न कि कागज पर .. यही कारण है कि अन्य उद्योग कभी भी पूर्वानुमान पर सहमत नहीं होते हैं और रिश्तेदार समय में लगातार मान्य पूर्वानुमान (जैसे भूविज्ञानी ने पूर्वानुमान मॉडलिंग को कभी नहीं रोका जब तक कि घन मीटर जमीन से बाहर नहीं खोदा गया हो और फिर उसका "किया गया")।

मैं कहता हूं कि यदि आप पूर्वानुमान नहीं लगा रहे हैं तो प्वाइंट सिस्टम काम करता है । आप एक ऐसे काम के लिए सहमत हो रहे हैं जो उप-मंथन एल्गोरिथम पर आधारित है लेकिन यह संभव के रूप में पूर्वानुमान के लिए वास्तव में आपका निकटतम दृष्टिकोण है। वास्तव में आप जारी कर रहे हैं प्रबंधन "बैकलॉग" कतार में प्राकृतिक विराम की तलाश करेगा जो थीम (एस) के आसपास फिट होता है (यानी सिल्वरलाइट में हम उत्पाद प्रबंधकों को इंतजार करना होगा जब तक कि वे अपने बैकलॉग को पूरा करने और टुकड़ों को एक साथ पूरा करने के लिए शुरू में सेट नहीं करते हैं। यह कभी नहीं पता था कि इंजीनियरिंग टीम विशेष रूप से क्या कर रही थी, हमारे पास सिर्फ एक बुनियादी रूपरेखा थी। हम तब काम के उस निकाय को ले लेंगे और इसके आसपास अपनी मार्केटिंग घटना का निर्माण करेंगे (Microsoft मिक्स)

जब आप स्प्रिंट चक्रों के अंदर वेग अपेक्षाओं को बंद करना शुरू करते हैं, जो कि वेग + समय पर निर्भर करते हैं, तो आप इस बार फिर से केवल अनुमान लगाने के लिए वापस आ रहे हैं, क्योंकि आप "खेल निर्भर करता है" खेल रहे हैं क्योंकि आप इससे भी बदतर हैं ... अधिक महत्वपूर्ण बात टीम के विकास / कैरियर के विकास के लिए भी संभावित हत्या कर रहे हैं।

अंक बनाम समय के लिए आप जो कर अदा करते हैं, वह उन बिंदुओं के साथ होता है, जिन्हें आपको ओएनजीसी कौशल विकास / सलाह / डेवलपर व्यवहार को ट्रैक करने के लिए वैकल्पिक माप सूत्रों की तलाश में होना चाहिए।

जैसा कि आप अभी भी एक "औसत डेवलपर" को अपने आदर्श व्यक्ति के रूप में देखने के लिए कौशल / प्रयास के साथ संलग्न करने की आवश्यकता होगी, तो आप उस व्यक्ति के साथ अन्य डेवलपर्स को आधारभूत बनाने के लिए यह निर्धारित कर सकते हैं कि वे आपकी टीम के भीतर चल रहे विकास में कैसे निष्पक्ष हैं। यह उन स्थितियों पर भी प्रकाश डालता है जहां "तेज" डेवलपर्स अधिकांश पानी ले जा रहे हैं, लेकिन ऊब रहे हैं या खराब हो रहे हैं वे लंबे समय तक काम कर रहे हैं और प्रतिस्पर्धा की समय सीमा के कारण कोई मान्यता / इनाम नहीं है। स्टैंडअप वास्तव में यह पता नहीं लगाते हैं, वे वास्तव में हैं। "प्रति व्यक्ति संघर्ष कर रहा है, मदद करने देता है"

इसके बाद "कैरी ओवर" कहानियां भी आती हैं, कहानियां जो उस स्प्रिंट चक्र में नहीं मिलतीं लेकिन फिर अगले स्प्रिंट चक्र पर फैल जाती हैं। यदि आप समय में फैक्टर कर रहे हैं, तो आप आसानी से एक नॉक-ऑन प्रभाव पैदा कर सकते हैं, लेकिन जिस समय आप रिश्तेदार समय में कारक हैं। पानी को गंदा करना।

यदि आप उन बिंदुओं पर जाते हैं जिन्हें आपने समय को पूरी तरह से नजरअंदाज कर दिया है और मेरा मतलब है कि जिस समय आप विचार / पद्धति को जुआ खेलने में समय रेंगने देते हैं।

एक इवेंजेलिस्ट के रूप में दुनिया भर में यात्रा करने के बाद, मैंने देखा कि बहुत सारी टीमों ने अपने हाथ की कसम खा ली है कि वे जो कुछ भी प्रिय रखती हैं, वह फुर्तीली पूर्वानुमान कोड को क्रैक कर दिया है ... लेकिन मैंने हमेशा अपनी जीभ पर क्लिक किया, मुस्कुराया और सोचा कि " हाँ " के साथ चली गई। ... आपने लगभग किया, लेकिन उस मालकिन को हम 'समय' कहते हैं ... वह सिर्फ क्रूर है ... "

Answer 12

माइक कोहन की पुस्तक "एजाइल एस्टिमेटिंग एंड प्लानिंग" में "आदर्श दिनों" या कहानी बिंदुओं के साथ अनुमान लगाने के फायदे और नुकसान का वर्णन किया गया है, इसलिए आपके प्रश्न का त्वरित उत्तर यह है कि आपको कहानी अंकों के साथ अनुमान लगाने की आवश्यकता नहीं है। यदि आदर्श दिनों में अनुमान लगाना अधिक स्वाभाविक है, तो ठीक है।

Comments

यह जरूरी सवाल का जवाब नहीं है; यह केवल एक पुस्तक संदर्भ प्रदान करता है। आप फायदे और नुकसान का सारांश प्रदान करके अपने उत्तर को मजबूत कर सकते हैं।

Answer 13

मुझे लगता है कि स्टोरी-पॉइंट विधि में मैन-डे पद्धति पर कम से कम दो महत्वपूर्ण फायदे हैं: पहला, सपा में अनुमान लगाना आसान है। सपा सापेक्ष है और हम जैसे मानव-निरपेक्ष अनुमान की तुलना में मानव-मानव बेहतर है।

दूसरा, जब आप सपा में अनुमान लगाते हैं, तो आपको "टीम एसपी" नहीं "व्यक्तिगत मंडे" मिलता है। जब आप पूछते हैं कि "इस कार्य में कितना समय लगेगा?", वरिष्ठ देव आपको 1 दिन दे सकते हैं लेकिन एक जूनियर के लिए 5 दिन। वह मैन-डे इस बात पर निर्भर है कि उस कार्य को कौन करेगा। यदि स्वामी को परिवर्तित करने के लिए मजबूर किया जाता है (और यह होगा!) तो आपको अपना सब कुछ फिर से शेड्यूल करना होगा। एसपी के साथ, यह अभी भी वही है जो कोई भी कार्य लेता है।

Answer 14

मुझे आश्चर्य है कि किसी ने अभी तक पार्किंसंस कानून का उल्लेख नहीं किया है।

इसके विस्तार के लिए उपलब्ध समय को भरने के लिए काम का विस्तार होता है।

मूल रूप से यदि आप बड़े कार्यों के लिए किसी भी प्रकार की समय इकाई का अनुमान लगा रहे हैं, तो डेवलपर्स इसे पूरा करने के लिए समय निकालेंगे या इसे पूरा करेंगे। जब आप कहानी अंक या शर्ट आकार जैसे एक नेबुला समय में अनुमान लगाते हैं तो आप इस नुकसान से बच जाते हैं।

Comments

"जब आप कहानी अंक या शर्ट की तरह एक अस्पष्ट समय में अनुमान लगाते हैं, तो आप इस नुकसान से बचते हैं।" पूरे दो सप्ताह और प्रति सप्ताह 5 कहानी बिंदुओं को वेग सेट करें। मुझे लगता है कि कार्यों की जटिलता को मापने के लिए उपयोग की जाने वाली इकाई की तुलना में उत्पादकता में वृद्धि टीम की प्रेरणा और काम करने की स्थिति के साथ अधिक है।

— जियोर्जियो

मैं उत्पादकता में वृद्धि का उल्लेख नहीं कर रहा था, इस तथ्य से अधिक है कि अगर एक कहानी के लिए एक अनुमान 3 दिनों के लिए निकलता है। एक डेवलपर को अनुमान के तहत आने की तुलना में इसे खत्म करने में 3 या अधिक दिन लगने की संभावना है।

— वादिम

क्या पार्किंसंस कानून के लिए अच्छे सबूत हैं? विकिपीडिया पृष्ठ में किसी का उल्लेख नहीं है।

— bdsl

Answer 15

कहानी बिंदु अनुमान इस प्रकार है कि श्रृंखला १,२,३,५,13,१३,२१ ...

एक मानव मस्तिष्क आसानी से आकार के आधार पर चीजों को मैप कर सकता है। उदाहरण के लिए: हमारे पास एक पोस्ट है जो कार्ड है और इसे एक स्टोरी पॉइंट 2 और तीन पोस्ट करें यह कार्ड के आकार का अर्थ होगा 2 * 3 = 6 स्टोरी पॉइंट।

स्टोरी पॉइंट 6, 5 और 8 के बीच की श्रृंखला के बीच आता है, जिसमें 5 सबसे करीब होते हैं और इसलिए कहानी 5 होगी।

Comments

हम आकार के आधार पर चीजों को मैप नहीं करते हैं, हम वास्तव में काम करने के लिए "स्कीमा" के रूप में इनका इलाज करने के लिए मेमोरी का उपयोग करते हैं। हमारे मस्तिष्क की तरह ही RAM की एक छोटी मात्रा है कि जब हम छोटे विवेकाधीन पैटर्न (फाइबोनैचि, A000079, टी-शर्ट आकार आदि) में फ़ीड करते हैं, तो ये हमारी आंतरिक संज्ञानात्मक शक्तियों से इस मामले में परियोजना की मदद करने की अपील कर सकते हैं - एक उत्तर। , जो वास्तव में एक "सापेक्ष पूर्वानुमान" मॉडल है।

— स्कॉट बार्न्स