एक चुस्त पुनरावृत्ति कब पूर्ण माना जाता है?

Question

मैं एक टीम है कि तीव्र विकास व्यवहारों को अपनाने की संभावनाओं पर विचार कर रहा है पर काम कर रहा हूँ।

एक सवाल है कि हम के खिलाफ चलाए जा रहे निर्णय लेने से है, जब एक यात्रा (स्प्रिंट) पूरा करना चाहिए।

मान लें कि हमने अपने फीचर बैकलॉग को परिभाषित किया है, और उनके लिए कहानी-बिंदु अनुमान प्रस्तुत किए हैं, और हमने फैसला किया है कि पहले 30-दिन के स्प्रिंट में ए, बी, डी और एफ शामिल होंगे। आपको क्या चाहिए पर अगर आप स्प्रिंट के अंत तक पहुंच रहे हैं और आप पूरा कर दिया है ए, डी, और एफ करते हैं - लेकिन बी केवल 80% पूरा हो गया है। चाहिए तुम:

1. पूरा समय पर स्प्रिंट लेकिन सुविधा बी को बाहर (एक भविष्य स्प्रिंट करने के लिए शेष काम टाल)

2. सुविधा बी पूरा करने के लिए समय के लिए आवश्यक द्वारा स्प्रिंट का विस्तार नहीं बल्कि अगले स्प्रिंट शुरू करें।

3. फीचर बी को पूरा करने के लिए आवश्यक समय तक स्प्रिंट बढ़ाएं और अगले स्प्रिंट पर काम करना शुरू करें।

4. पूरे स्प्रिंट को विफल करें, और भविष्य में रिलीज का हिस्सा बनने के लिए सभी कामों को बंडल करें।

समस्या मैं विकल्प 1 के साथ देखते हैं कि टीम का वितरण नहीं कर रहा है इसे करने के लिए क्या किया है। कुछ मामलों में, आप पूरे रिहाई बेकार (या कम से कम काफी कम मूल्यवान) किए बिना सुविधा बी बाहर करने के लिए सक्षम नहीं हो सकता। यह फीचर बी

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

विकल्प 3 चुस्त की भावना के खिलाफ प्रतीत होता है - आप अगली स्प्रिंट को विकास के अगले पुनरावृत्ति को मार्गदर्शन करने के लिए पहले के परिणामों की अनुमति न देकर जोखिम में डाल रहे हैं।

विकल्प 4 गंभीर लगता है और इसमें विकल्प 1 और 3 की समान समस्याएं हैं। सबसे पहले, आप पूरी तरह प्रतिबद्धता खो रहे हैं। दूसरा, बाद में रिलीज में और अधिक सुविधाओं को बंडल करना ग्राहकों के साथ परीक्षण करना और सत्यापित करना कठिन बनाता है - और यह फिर से पूर्ववर्ती प्रतिक्रियाओं के आधार पर भावी पुनरावृत्ति को मार्गदर्शन करने की क्षमता को रोकता है।

Answer 1

पाठ्यक्रम के विकल्प 1। अगली पुनरावृत्ति के लिए आपके वेग कम होने जा रहा है, क्योंकि यह yesterdays मौसम पर आधारित है, इसलिए अगली पुनरावृत्ति आपके पास पूर्ण होने का एक बेहतर मौका है।

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

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

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

Answer 2

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

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

स्प्रिंट में विफल होने से चीजों में बहुत अधिक पूर्णतावाद प्रस्तुत होता है। क्या ऐसा कुछ है जो 99% बेकार है? मैं ऐसा नहीं सोचूंगा, लेकिन ऐसे कुछ लोग हैं जिनके पास वास्तव में उच्च मानदंड हैं और वे बहुत मांग कर सकते हैं।

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

Answer 3

एक फुर्तीली परियोजना के लिए 'पूर्ण करने की परिभाषा' रखना महत्वपूर्ण है। यह चीजों की एक छोटी जांच सूची है जिसे पूरा करने के लिए कक्षा को पूरा करने के लिए किया जाना चाहिए। यह किया के विभिन्न स्तरों के लिए असामान्य नहीं है:

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

• स्प्रिंट - इस तरह के स्प्रिंट 'पूर्ण' कर रहे हैं (ऊपर देखें, एक पूर्वव्यापी आयोजित किया गया है के लिए सभी कहानियों के रूप में बातें शामिल हो सकते हैं, उत्पाद मालिक कार्यक्षमता आदि आदि का प्रदर्शन देखा है

• रिलीज स्प्रिंट - स्प्रिंट की पिछली श्रृंखला के विकास को सफलतापूर्वक एकीकृत किया गया है और प्रतिगमन परीक्षण किया है, कार्यक्षमता को लाइव वातावरण में जारी की गई है

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

महत्वपूर्ण बात यह है कि इसे लटका नहीं देना है। बस इसे सीखें, अनुकूलित करें और आगे बढ़ें।

Answer 4

आप आमतौर पर विकल्प 1 करेंगे - स्प्रिंट समाप्त करें। पूरा काम का उपयोग करें, अधूरा काम परियोजना वेग में प्रतिबिंबित होने दें - इसलिए भविष्य की योजना आपके द्वारा अनुभव की गई कठिनाइयों का कारण बनती है।

हां, विकल्प 1 का मतलब है कि हमने जो कुछ भी किया है, वह पूरा नहीं किया है - लेकिन यदि ऐसा हुआ तो यह स्वीकार करना बेहतर होगा और इसे छिपाने के बजाय अगली बार बेहतर तरीके से सामना करना सीखना बेहतर होगा। खराब चीजें सभी के साथ होती हैं - महत्वपूर्ण बात यह है कि हम कहां से सुधार करते हैं।

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

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

Answer 5

पहला, नियम: पुनरावृत्त निश्चित-लंबाई समय-बक्से हैं और वे अंत में पूर्ण हैं टाइम-बॉक्स तो यह विकल्प 2 और विकल्प 3 को समाप्त करता है। विकल्प 4 के संबंध में, पुनरावृत्ति असामान्य समाप्ति बहुत विशेष परिस्थितियों में हो सकती है (निश्चितता कि लक्ष्य प्राप्त नहीं किया जा सकता है, बाहरी घटना लक्ष्य को अमान्य कर देती है ...) लेकिन यह एक असाधारण घटना बनी रहनी चाहिए। और निरस्त करने से पहले, सामान्य अन्य विकल्पों में हैं: 1. कुछ और करें/नवाचार करें 2. सहायता/आउटसोर्स प्राप्त करें 3. दायरे को कम करें। और यह आपको विकल्प 1, स्पष्ट पसंद के साथ छोड़ देता है।

विकल्प 1 के साथ मुझे जो समस्या दिखाई देती है वह यह है कि टीम जो कुछ भी करने के लिए प्रतिबद्ध नहीं है वह है। कुछ मामलों में, आप पूरे रिहाई बेकार (या कम से कम काफी कम मूल्यवान) किए बिना सुविधा बी बाहर करने के लिए सक्षम नहीं हो सकता। यह यह मुश्किल सुविधा बी बिना अगले स्प्रिंट की दिशा मार्गदर्शन करने के

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

Answer 6

क्या मैं "यह निर्भर करता है" के साथ जवाब दे सकता हूं? इसके अलावा, मैं एक "परिभाषित पूर्ण" में फेंकना चाहता हूं।

हम इस स्थिति एक दो बार किया था और इसे दूसरे तरीके से परिस्थितियों के आधार पर निपटा दिया है।

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

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

इसलिए, यह या तो विकल्प 4 या हमारे लिए विकल्प 2 जब यह करने का आह्वान किया गया था।

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

यदि आप एक साथ काम कर रहे हैं तो आपको एक विकल्प मिलना चाहिए जो शामिल सभी के लिए काम करता है। (यदि आप किसी भी तरह की अंतर्निहित समस्याएं नहीं कर सकते हैं।) कम से कम चर्चा करने के बिना टीम पर कुछ न छोड़ें या कम से कम कारण बताएं।

विकल्प 3 मुझे सबसे गन्दा जैसा लगता है, इसलिए मैं इसे रद्द कर दूंगा।

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

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

विकल्प 4 के लिए, यह बहुत कठोर है, लेकिन फिर, जब सही ढंग से संवाद किया जाता है तो यह ठीक होना चाहिए। टीम आमतौर पर जानता है कि यह गड़बड़ हो गया है और वितरित करने में सक्षम नहीं होगा, इसलिए ऐसा नहीं है कि आप उन्हें कोई खबर तोड़ रहे हैं।

तो, कुछ चीजों पर विचार करने के लिए कुछ हैं।

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