स्क्रम कार्यान्वयन पर नोट्स - यदि कुछ नहीं किया जाता है, तो आवश्यक रूप से पुनरावृत्ति की विफलता होगी

नीचे कुछ हैं, कई मायनों में स्पष्ट, ऐसे बिंदु जो नए लोगों को स्क्रम में मदद कर सकते हैं

परियोजना और टीमों के बारे में थोड़ा सा।

वर्णित परियोजना वह पहली है जिस पर हमने पूर्ण रूप से स्क्रैम को लागू करने का निर्णय लिया था।
इससे पहले, उन्होंने पुनरावृत्तियों पर काम किया, लेकिन स्टैंड-अप रैलियों, रेट्रोस्पेक्टिव्स और डेमोस के बिना।

प्रोजेक्ट पर दो टीमें काम कर रही हैं।

टीम 1 एक वर्कफ़्लो सिस्टम बनाता है जिसमें डेटा एक निश्चित एप्लिकेशन के लिए तैयार किया जाएगा जो टीम 2 विकसित कर रहा है।

इस वजह से, कुछ पुनरावृत्तियों में हम एक दूसरे पर निर्भर होते हैं और एक दूसरे पर निर्भर होते हैं

So.

1. पूरी टीम को योजना में भाग लेना चाहिए

अभ्यास से:
परियोजना के पहले पुनरावृत्ति की योजना बनाते समय, उन्होंने दो डेवलपर्स (वास्या और पेट्या) को आमंत्रित नहीं किया, क्योंकि वे पहले अपने कार्यभार पर वास के साथ सहमत थे।

परिणामस्वरूप, पुनरावृत्ति के पहले सप्ताह के मध्य में, यह स्पष्ट हो गया कि काम का हिस्सा ध्यान में नहीं रखा गया था और बोर्ड पर तय नहीं किया गया था।

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

2. एक टीम के भीतर कार्यों के बीच निर्भरता का नियंत्रण

अभ्यास से:

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

परिणाम:

नियोजित कहानी समय पर पूरी नहीं होती है। दूसरा डेवलपर या तो निष्क्रिय है या कम प्राथमिकता के साथ कार्य करने के लिए मजबूर है।

क्या करें:

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

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

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

3. टीम के भीतर फिक्सिंग व्यवस्था

अभ्यास से:

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

टीम के सदस्य मौखिक रूप से इस बात पर सहमत हैं कि कार्य प्रौद्योगिकी N पर किया जाएगा या सक्रिय रूप से तर्क दिया जाएगा कि यह कार्य एक तरफ प्रौद्योगिकी N पर करना आसान है और दूसरी ओर प्रौद्योगिकी J पर करना भी आसान है, लेकिन अंततः यह निर्णय किए बिना असहमत है कि कौन विशेष रूप से कार्य करता है।
सामान्य तौर पर, हमने बातचीत की और फैलाया।
यह गंभीर नहीं लग सकता है, लेकिन हमारे मामले में यह एक पुनरावृत्तियों पर हुआ।

परिणाम:

कार्य पूरा नहीं हुआ था। जब बड़े कार्य को पूरा करने की समय सीमा आ गई, तो क्षेत्र का प्रारूप आसन्न टीम के अनुरूप नहीं था और अगर इसे तुरंत किया गया था तो इसे अधिक से अधिक फिर से तैयार करना होगा।

क्या करें:

सभी मौखिक समझौतों को तुरंत विशिष्ट कलाकारों के लिए कार्यों में तब्दील किया जाना चाहिए।
यह सभी टीम के सदस्यों द्वारा निगरानी की जानी चाहिए।

4. निर्भरता वाले कार्यों पर संबंधित टीमों के साथ सहभागिता

अभ्यास से:

टीम 1 ने टीम 2 के लिए डेटा की वापसी को लागू किया है और इसके अन्य कार्यों के बारे में निर्धारित किया है। 3 दिनों के बाद, टीम 2 टीम 1 में बदल गई - डेटा डाला नहीं गया / डेटा वैध नहीं है, आदि।

परिणाम:

टीम 2 डेटा के इंतजार में बेकार है जिसे टीम 1 पहले ही दे चुकी है।
यह सरल अभी भी हर किसी के लिए वापस आ गया।

क्या करें:

1. टीम 2 में, डेटा प्राप्त करने वाले डेवलपर को निर्धारित किया जाता है
2. कार्य को पूरा करने के बाद, टीम 1 डेवलपर टीम 2 डेवलपर को सूचित करता है - "किया, जाँच"
3. स्टैंड-अप मीटिंग के बाद, जहां निर्भरता कार्य परीक्षण में चली गई, टीम 1 के स्क्रम-मास्टर टीम 2 के स्क्रम-स्वामी को सूचित करता है
4. टीम 2 ने पुष्टि की है कि डेटा प्राप्त हो गया है, टास्क बोर्ड को रेडी पर स्थानांतरित कर दिया गया है।

5. कार्य का सही आकलन करना या स्प्रिंट के दौरान उन्हें अधिक घबराना नहीं चाहिए।

अभ्यास से:

बोर्ड में कुछ दिन "इन प्रोसेस" कई घंटों में अनुमानित कार्य टांग देता है।

कारण यह है कि डेवलपर किसी प्रकार के बग के पार आया था और जल्दी से इसका पता नहीं लगा सका

राय: यदि ऐसे कार्य अक्सर "प्रक्रिया में" लटकाए जाएंगे, तो बोर्ड "प्रवाह" के प्रभाव को खो देगा

क्या करें:

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

6. जिम्मेदारियों को टीम द्वारा लिया जाना चाहिए, न कि केवल स्क्रम मास्टर को

अभ्यास से:

कई स्टैंड-अप रैलियों के दौरान, स्क्रैम-मास्टर उपमहाद्वीपों को आवश्यक डेटा प्रदान करने के लिए बाध्य था, लेकिन अंत में, विभिन्न कारणों से ऐसा नहीं हुआ।

परिणाम:
आसन्न टीमों की राय है कि एक या किसी अन्य टीम पर भरोसा नहीं किया जा सकता है। यह बुरा है, क्योंकि टीमें एक-दूसरे पर निर्भर हैं।
जब तक टीम जिम्मेदारियों को नहीं निभाती है, तब तक वह काम नहीं करने के लिए जिम्मेदार महसूस नहीं करता है।

आउटपुट के बजाय

हम उस पहले पुनरावृत्ति में विफल रहे।

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

और क्या स्पष्ट और आपकी टीम में ऐसी परिस्थितियां नहीं थीं जो पुनरावृत्ति की विफलता का कारण बनीं?