स्टोरी पॉइंट्स क्या हैं, इसका सबसे अच्छा विवरण क्या है?

Question

हम अपने फुर्तीले विकास के लिए यहां स्टोरी पॉइंट्स का उपयोग करना शुरू कर रहे हैं, लेकिन मुझे यह समझाना मुश्किल है और वे जो भी हैं उसका कोई निश्चित उत्तर नहीं पा सकते हैं। सबसे अच्छी बात जो मैं कर सकता हूं वह अन्य साइटों (जैसे http://blog.mountaingoatsoftware.com/tag/story-point ) की ओर इशारा करता है और जो कुछ वे हैं उसका कुछ अस्पष्ट सामान्यीकरण देते हैं। मैं उपयोग के कुछ उदाहरणों के साथ एक अच्छी व्याख्या की तलाश कर रहा हूं जो दूसरों के उपयोग के लिए उपयोगी होगी। क्या कहानी के बिंदुओं को समझाने के लिए कोई अच्छे संसाधन हैं?

Comments

स्पष्टीकरण किससे या आप सामान्य स्पष्टीकरण चाहते हैं? उत्तरार्द्ध के साथ समस्या यह है कि इसे कुछ आंखों के रोलिंग के साथ मिल सकता है क्योंकि हर कोई गहराई से जवाब नहीं देना चाहता है।

— जेबी किंग

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

— छह

Answer 1

यह एक स्टार्टर के रूप में मदद कर सकता है: कहानी बिंदुओं पर माइक कोहेन । लेकिन यह बहुत बेहतर है: एजाइल डेवलपमेंट टीमें: स्कोप और स्केल विद माइक कोहन

सॉफ्टवेयर आकलन मैट्रिक्स के लिए माइक का समाधान सरल और प्रभावी है। जैविक तथ्य:

• मानव मस्तिष्क सही समय पर अनुमान लगाने में असमर्थ है। खासकर अगर कुछ घंटों से अधिक।
• यह सॉफ्टवेयर डेवलपर में अनिश्चितताओं की मात्रा, प्रबंधन से मनोवैज्ञानिक दबाव (जब आप अनुमान लगाते हैं, आप प्रतिबद्ध हैं ...) और टीम में कौशल में अंतर से काफी बढ़ जाते हैं।
• हालांकि, हम सामान की तुलना में बहुत अच्छे हैं। हम वहां काफी सटीक हैं।

विचार एक संदर्भ उपयोगकर्ता कहानी लेने का है , फिर उसे (कहानी) बिंदुओं की एक मनमानी संख्या दें , फिर अन्य कहानियों को उस संदर्भ से संबंधित बिंदु मिलेंगे।

यदि आपकी संदर्भ कहानी 100 अंक की है, और दूसरी कहानी तीन गुना बड़ी है, तो यह 300 अंकों की होगी।

अपनी योजना के लिए कहानी के बिंदुओं को समय में बदलने के लिए, आपको अपने वेग को जानना होगा ।

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

यह काम करता है ।

Comments

+1 सर्वश्रेष्ठ स्पष्टीकरण। लेकिन संदर्भ कहानी को 100 बनाना एक अच्छा विचार नहीं है। जैसा कि इसका अर्थ है कि आप संदर्भ के संबंध में सटीक अनुमान लगा सकते हैं। यानी मेरा अगला काम संदर्भ के काम का 42% है। जैसा कि आप उल्लेख करते हैं कि मानव मस्तिष्क अनुमान लगाने में भयानक है। तो हमारे पास 2 बिंदुओं की एक संदर्भ कहानी है। फिर फाइबोनैचि अनुक्रम का उपयोग करें (संदर्भ कहानी से आगे कि अधिक अशुद्धि आपके पास सटीक होने का कोई मतलब नहीं है)। योजना पोकर अपने दोस्त है।

— मार्टिन यॉर्क

यदि आप Youtube पर माइक कॉइन नहीं देखना चाहते हैं, तो उनके पास इस सामान के बारे में एक बहुत अच्छा ब्लॉग लेख है: blog.mountaingoatsoftware.com/tag/story-point । दिलचस्प बात यह है कि बिंदु प्रणाली के साथ भी उन्होंने कहा कि मनुष्य केवल लगभग 8 तक अच्छे होते हैं, फिर वे कम करके आंकने लगते हैं।

— डीएक्सएम

मैंने इस उत्तर को उकेरा, और इसमें बहुत मूल्यवान जानकारी थी। हालाँकि यह सवाल तकनीकी रूप से अधिक पूछ रहा था कि विशेष रूप से एक कहानी बिंदु को कैसे परिभाषित किया जाए, क्योंकि उन्हें प्रभावी ढंग से कैसे उपयोग किया जाए।

— पैंज़रक्रिसिस

Answer 2

मैं सब कुछ @Pierre 303 से सहमत हूं: ऊपर कहा गया है: (100 संदर्भ बिंदु के अलावा)।

केवल एक चीज जो मैं (जोर) जोड़ना चाहूंगा वह यह है कि हम कार्यों का आकलन करने में अच्छे नहीं हैं। जब तक वे लगभग एक ही आकार के नहीं होते तब तक हम अन्य कार्यों के सापेक्ष कार्यों का अनुमान लगा सकते हैं। हम जितने बुरे कामों में अंतर करेंगे उतना ही बड़ा होगा।

इस प्रकार मैं 100 के शुरुआती बिंदु का उपयोग करने से असहमत हूं।

ऐसा नहीं है जैसे कि आप संदर्भ कार्य के 42% के रूप में अगले कार्य का अनुमान लगाएंगे। यह या तो एक ही आधा काम है काम को दोगुना करता है काम आदि।

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

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

इसलिए यदि आपका संदर्भ कार्य 2SP है। फिर 1/2/3/5 का अनुमान लगाना अपेक्षाकृत आसान है क्योंकि कार्य समान आकार के होते हैं। एक बार जब आप संदर्भ कार्य (5SP) से 3 गुना बड़े हो जाते हैं, तो अनुमान कठिन हो जाता है (क्या 8/9 / 10SP यह मायने रखता है) आप सभी कह सकते हैं कि यह 5SP से बड़ा है और 13SP से छोटा है तो 8SP बिल फिट करता है।

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

• कुछ भी आप अनुमान लगाते हैं कि विशाल को छोटे कार्यों में टूटने की आवश्यकता है।
• जो कुछ भी अनुमानित है? इसका मतलब यह है कि यह अनुमान लगाने के लिए पर्याप्त रूप से परिभाषित नहीं है कि
  आपको कार्य को परिभाषित करने और कार्य को परिभाषित करने के लिए विशेष रूप से जोड़ने की आवश्यकता है
  (यानी कुछ दस्तावेज या प्रस्तुति लिखें)।

Answer 3

कहानी के अंक एक सापेक्ष माप हैं कि कोई कार्य कितना कठिन है। इसका कारण यह है कि मनुष्य वास्तव में सटीक माप की तुलना में सापेक्ष अनुमानों में बेहतर हैं।

जिस तरह से आप स्टोरी पॉइंट का उपयोग करते हैं, आप प्रोजेक्ट पर दो काम करते हैं और उन्हें दो अलग-अलग स्टोरी पॉइंट मान देते हैं। फिर आप अपने अनुमान के आधार के रूप में उन दो कहानी बिंदु सन्दर्भों का उपयोग करते हुए अन्य कार्यों का अनुमान लगाते हैं। Ie टास्क सी टास्क ए की तुलना में बहुत कठिन नहीं है, लेकिन टास्क बी की तुलना में अविश्वसनीय रूप से आसान है, इसलिए यह केवल ए की तुलना में लगभग 2 कहानी अंक अधिक काम है।

जब आपके द्वारा अब तक की गई सभी आवश्यकताओं का आकलन किया जाता है, तो आप अनुमान लगाते हैं कि आप स्प्रिंट में कितने प्राप्त कर सकते हैं। अगले कुछ क्षेत्रों में, आप अनुमान लगाते हैं कि आपने कितने को पूरा किया है। एक आवश्यकता की कहानी के बिंदु केवल तभी पूरे हो जाते हैं जब आवश्यकता पूरी हो जाती है। स्क्रम में कोई "80% पूर्ण" नहीं है। ऐसा इसलिए है क्योंकि मनुष्य वास्तव में पूर्णता का अनुमान लगाने में बुरा है। कुछ स्प्रिंट्स के बाद, आपको इस बात का अंदाजा होना चाहिए कि आप प्रति स्प्रिंट कितने कहानी अंक कर सकते हैं।

आप कैसे अनुमान लगाते हैं? आप यह निर्धारित करने के लिए नियोजन पोकर का उपयोग कर सकते हैं कि आपके डेवलपर्स को कितना काम लगता है कि एक आवश्यकता आपके आधार आवश्यकताओं के सापेक्ष होगी।

मैं द एजाइल समुराई पढ़ने की भी सिफारिश करूंगा । यह मेरी राय में इन और अन्य चुस्त अवधारणाओं को समझाने के लिए एक अच्छा काम करता है।

यहाँ कहानी बिंदुओं पर अधिक के साथ एक कड़ी है।

यहाँ एक और कड़ी है।

Answer 4

वे समय की बर्बादी कर रहे हैं।

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

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

ओपी का अंतिम वाक्य: "क्या कहानी के बिंदुओं को समझाने के लिए कोई अच्छे संसाधन हैं?" हां, यह पुस्तक एक अच्छा संसाधन है। सोच के लिए भोजन।

Comments

इस पर एक राय देना कि वे उपयोगी हैं या नहीं, इस सवाल का जवाब नहीं देते कि वे क्या हैं।

— ब्रायन ओकले

Answer 5

सबसे आसान स्पष्टीकरण मैं एक वस्तु का उपयोग कर सकता हूं जो मूर्त है और एक ठोस उदाहरण प्रदान कर सकता है।

मोबाइल घर ले जाओ। अगर मैं मोबाइल होम बिजनेस में होता तो मुझे पता होता कि एक ही वाइड बनाने में आम तौर पर 5 (अंक, मेंढक, विगेट्स ... मापक फॉर्म मनमाना) लगता है और इसलिए डबल वाइड का निर्माण करने के लिए लगभग दोगुना प्रयास करना चाहिए या 10 (अंक) , मेंढक, विगेट्स)।

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

यह जानने के लिए कि हमें निर्माण में कितना समय लगेगा, हम समय के साथ अपने रुझानों का उपयोग करेंगे; इस प्रकार हमारे अनुमानों में समय के साथ और अधिक सटीक हो रही है।

जब टीम जाने के लिए तैयार हो तो पोकर की योजना बनाना न भूलें ।

Answer 6

जैसा कि दूसरों ने उल्लेख किया है कि कहानी के बिंदु उपयोगकर्ता की कहानी के लिए जटिलता के सापेक्ष माप हैं। कहानी के बिंदुओं का सही लाभ तब मिलता है जब

1. कार्यान्वयन के लिए जिम्मेदार इकाई द्वारा बिंदुओं को मापा जाता है (या तो एक व्यक्ति या टीम)।
2. मेट्रिक्स एक निरंतर अवधि (वेग) के भीतर एक ही इकाई द्वारा कितने कुल अंक पूरे किए जाते हैं।

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

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

Comments

"जैसा कि दूसरों ने कहानी के बिंदुओं का उल्लेख किया है, उपयोगकर्ता कहानी के लिए जटिलता का एक सापेक्ष माप है।" ध्यान दें कि माइक कोहेन वास्तव में तर्क देते हैं कि "इट्स एफर्ट, नॉट कॉम्प्लेक्सिटी", इस विषय पर एक विस्तृत चर्चा के लिए पर्वतारोहण- प्रचारक.com/blog/its-effort-not-complexity देखें ।

— डेटापेंट