2009-08-06 15 views
5

में स्टोरी अनुमान हमने एक परियोजना शुरू की जिसे स्क्रम/एक्सपी के साथ प्रबंधित किया जाएगा। हमने मूल्यांकन उद्देश्यों के लिए पूरे उत्पाद बैकलॉग को आगे लिखा है। हमें यकीन है कि कर रहे हैं सभी कहानियों ग्राहक केंद्रित कर रहे हैं और हमस्क्रम

  • कहानी व्यापार मूल्य द्वारा उन्हें मूल्यांकन कर रहे हैं: मास्को तकनीक -,,,/इस कार्यान्वित
  • हो सकता था चाहिए अवश्य होता नहीं
  • कहानी प्रयास/जटिलता (= कहानी अंक): 1, 2, 3, 5, 8, 13, 21, 100 - आदर्श दिनों कहानी जटिलता/प्रयास के बजाय अवधि

100 कहानी अंक से संबंधित हो सकता है कि कुछ कहानियां हों/नहीं होंगी क्योंकि वे वास्तव में बड़ी जटिल कहानियां हैं जो आवश्यक होने पर बाद में टूट जाएंगी।

परिकलित कहानी महत्व मूल्य & पर आधारित है जो MoSCoW कहानियों को ओवरलैप नहीं कर रहा है।

लेकिन 100 बिंदुओं की कहानियों के बिना हमारी कहानियां अब तक (यहां तक ​​कि टूटी हुई) में 2 और 8 के बीच जटिलता है जो हमें लगता है कि माइक्रोमैनेजमेंट से बचने के लिए एक उपयुक्त कहानी आकार है। लेकिन कुछ कहानियां एक दूसरे पर संबंधित या निर्भर हो गईं। हमारे पास ऐसी कहानियां हैं जो पहले किए जाने पर अधिक ले सकती हैं, और यदि कुछ अन्य कहानी उनके सामने की जाएगी तो कम होगा।

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

+1

वहाँ एक जानकारीपूर्ण ब्लॉग अनुमान और नियोजन से संबंधित पोस्ट है: [स्प्रिंट योजना - बस इतना वक्त रहते] (http: //www.agile42।com/सेमी/ब्लॉग/2009/07/6/स्प्रिंट योजना-बस-काफी-जस्ट-इन-समय /)। – Doro

+1

@ वादिमकोटोव यह परियोजना प्रबंधन या यहां तक ​​कि सॉफ्टवेयर इंजीनियरिंग से संबंधित होगा, लेकिन चूंकि यह बहुत पुराना है, इसलिए मैं इसे खोल दूंगा। – Korcholis

+0

@ कोर्कोलिस हम पुराने ऑफ-विषय प्रश्नों को बंद करने पर भी काम कर रहे हैं। हालांकि इतिहास के लिए इसे बंद कर दिया जा सकता है (बंद राज्य में)। यह नए उत्तरों और नए समान ऑफ-विषय प्रश्नों को रोकने के लिए किया जाता है –

उत्तर

5

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

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

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

निर्भर कहानियों के लिए आपको अपने उत्पाद स्वामी के साथ काम करना चाहिए। अगर टीम उनसे बात करती है तो आप आमतौर पर कहानियों को पुनर्व्यवस्थित कर सकते हैं। अधिकांश लोग किसी ऐसे व्यक्ति के प्रति ग्रहणशील होते हैं जो उन्हें बताता है "अगर हम अब करते हैं तो यह पूर्ण स्प्रिंट लेगा, लेकिन अगर हम बाद में ऐसा करते हैं तो इसमें स्प्रिंट का 15% हिस्सा लगेगा" जो इसे काफी समझदार बनाता है।

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

आशा है कि यह जानकारी उपयोगी है।

+0

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

+0

अनुमान अवधि पर आधारित नहीं होना चाहिए, वे जटिलता पर आधारित होना चाहिए। शायद मैंने सवाल को गलत समझा। लेकिन बस शब्दों को तब तक रखें जब तक स्प्रिंट के हिस्से के रूप में कहानी काम नहीं की जा रही है, तब तक उत्पाद मालिक ठीक है, तब तक इसे पुन: व्यवस्थित/पुनर्व्यवस्थित करना स्वीकार्य है। बैकलॉग पर चुस्त कुछ भी इस बारे में अच्छी बात है कि वर्तमान स्प्रिंट के हिस्से तक बदला जा सकता है। – CertifiedCrazy

0

मैं केवल अपनी समाप्ति का वर्णन कर सकता हूं।

जब हम पहली स्प्रिंट की योजना बना रहे थे तो हमने फैसला किया कि हम 18 अंक पूरा कर सकते हैं। इसलिए हमने कई कहानियां ली और कुल अनुमान 15 अंक थे। जैसा कि मैंने उपरोक्त उल्लेख किया है, हम स्क्रम में अपना पहला कदम उठा रहे थे और इसीलिए हमने फैसला किया कि 3 अप्रयुक्त अंक और फॉर्म-कारक 0.6 हमारी सफलता की गारंटी देते हैं।

लेकिन प्रत्येक कहानी का हमारा अनुमान केवल अनुमानित था। हमारे पास कुछ निर्भर कहानियां भी थीं। और हमने प्रत्येक कहानी के कार्यान्वयन की योजना नहीं बनाई क्योंकि हमने सोचा था कि यह चुस्त पद्धति के साथ अनैतिक है।

नतीजतन हम केवल 8 पूर्ण अंक के साथ हमारे पहले स्प्रिंट में विफल रहे।

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

लेकिन दूसरा स्प्रिंट बहुत बेहतर था और हमने लगभग सभी किया है (वास्तव में हमने कुछ बग के साथ सब कुछ किया है)। मुझे लगता है कि हम तीसरे स्प्रिंट में कम फॉर्म-फैक्टर लेंगे और यह सफल होगा।

+0

अच्छा है तो क्या आपने वास्तव में कहानी बिंदु बदल दी? क्या आपकी कहानी बिंदु जटिलता या अवधि से संबंधित हैं? आपके वास्तविक वेग के आधार पर आपकी समाप्ति तिथि भी काफी बदल गई है। –

+0

नहीं, मैंने नहीं किया। कार्यान्वयन के दौरान हुई नई समस्याएं हमने उच्च प्राथमिकता (जैसे बग) के साथ नई कहानियों के रूप में व्याख्या की। लेकिन, imho अच्छी मुश्किल योजना स्क्रम में बेहद महत्वपूर्ण है। – Roman

2

आपकी व्याख्या से आप पहले से ही एक महान काम कर रहे हैं। बेशक हमेशा एक निर्भरता के साथ कहानियां होगी। कुछ लोगों को सीधे ग्राहक मूल्य दिखाई नहीं दे सकता है; यानी एक वास्तुकला और कुछ ढांचे को स्थापित करने के लिए प्रारंभिक प्रयास)।लेकिन अगर आप उन्हें छोड़ देते हैं तो आप बहुत सारे तकनीकी ऋण बनाएंगे। यदि आप कर सकते हैं, तो मैं सुझाव दूंगा कि आप समीकरण को पूर्ण करने की कोशिश करें और किसी भी तरह से कार्यों के बीच संबंध दिखाएं।

उदाहरण के लिए: - कार्य 2 के बाद किए गए कार्य 3 8 अंक हैं, लेकिन 12 अंक स्वतंत्र रूप से किए जाते हैं।

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

शुभकामनाएं!

+0

हम इन कहानियों को "तकनीक कहानियां" कहते हैं। हमने किसी की योजना नहीं बनाई है, क्योंकि हमारे पास पहले से ही अधिकांश मौलिक सिद्धांत हैं। बकाया वाले ग्राहक ग्राहक केंद्रित के भीतर किए जाएंगे। –

+0

डबल अनुमानों के बारे में थोड़ा मुश्किल यानी है। चूंकि हम पहली बार उन कहानियों पर काम करते हैं जिनके पास सबसे कम मूल्य कम से कम प्रयास होता है, ऐसा हो सकता है कि स्टोरी 2 स्टोरी 1 से पहले आएगी। लेकिन उस स्थिति में आप उच्च जटिलता का उपयोग करेंगे और आपको पुन: व्यवस्थित करना होगा ... मुझे लगता है कि इस मामले में स्वचालन प्रश्न से बाहर है। लेकिन डबल अनुमान के साथ आपका सुझाव ठीक है। हम इसे टिप्पणियों में जोड़ देंगे और स्प्रिंट योजना बनाते समय इसका इस्तेमाल करेंगे। –

0

कुछ पैटर्न हैं जो उपयोगकर्ता कहानियों को विभाजित करने में आपकी मदद करेंगे ताकि वे निवेश बने रहें, जिसका अर्थ है कि आप विशेष रूप से निर्भरता, आकार, परीक्षण और मूल्य को बचाने की कोशिश करेंगे। आप इसके बारे में और अधिक पढ़ सकते हैं: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ रिचर्ड सक्रिय रूप से आवेदन कर रहा है और उन्हें सुधार रहा है, और वह अकेला नहीं है ;-)

बस जागरूक रहें और निर्भरता को बनाए रखना (जो एक गैंट चार्ट में एक महत्वपूर्ण पथ बनाने जैसा है) टीम की रचनात्मक होने की क्षमता को कम करने जा रहा है, और उन कहानियों पर बातचीत करने के लिए, और एक "गैर-मूल्यवान प्रस्ताव" भी छिपा सकता है।

HTH
ANdreaT

संबंधित मुद्दे