स्प्रिंट प्लानिंग से कैसे निपटें बहुत लंबे समय तक?

Question

एक सप्ताह लंबे स्प्रिंट के लिए मुझे स्प्रिंट प्लानिंग में 5 घंटे लगे। जो बहुत ज्यादा लगता है।

हम स्प्रिंट प्लानिंग के बारे में विस्तार से चर्चा करते हैं, क्योंकि टीम के अधिकांश सदस्य वरिष्ठ नहीं हैं। यदि हम इसे लागू नहीं करते हैं और स्प्रिंट के दौरान पुन: डिज़ाइन करने के दौरान गलतियाँ होती हैं।

हम इससे कैसे निपटेंगे?

प्रति सप्ताह स्प्रिंट के केवल 2 घंटे लंबे समय तक इसे फिट करने की योजना के दौरान मुझे कितना विस्तार से चर्चा करनी चाहिए?

Comments

स्प्रिंट प्लानिंग में आप वास्तव में क्या कर रहे हैं? क्या आप कहानियों को तोड़ रहे हैं, आवश्यकताओं को परिष्कृत कर रहे हैं, डिजाइन कर रहे हैं, अनुमान लगा रहे हैं?

— Liath

धन्यवाद मैं बताना भूल गया। हम ज्यादातर समय डिजाइन करने में बिताते हैं।

— b.ben

क्या आप अलग बैठक में बैकलॉग तैयार कर रहे हैं? हम आम तौर पर 1 घंटे प्रति स्प्रिंट और स्प्रिंट की योजना बनाकर 1 घंटे प्रति स्प्रिंट के लिए बैकलॉग बैकलॉग करते हैं। यह हमारे 2 सप्ताह के स्प्रिंट के लिए अच्छा काम कर रहा है।

— बेरिन लोरिट्स

@ b.ben लेकिन "डिज़ाइन" स्प्रिंट प्लानिंग का हिस्सा नहीं है।

— थॉमस जंक

एर प्रतीक्षा, आप स्प्रिंट योजना के दौरान कार्यान्वयन के बारे में क्यों बात कर रहे हैं? स्प्रिंट प्लानिंग इस बारे में है कि कैसे नहीं ।

— candied_orange

Answer 1

आप सही हैं - 1 सप्ताह के लिए स्प्रिंट योजना में 5 घंटे स्प्रिंट लंबे समय तक लगता है। स्क्रम गाइड टाइम-बॉक्स स्प्रिंट 1 महीने स्प्रिंट के लिए 8 घंटे की योजना बना रहा है और कहता है कि "कम स्प्रिंट के लिए, घटना आमतौर पर कम होती है"। यदि आप अनुपात पर विचार करते हैं, तो एक अच्छा लक्ष्य 1 सप्ताह के स्प्रिंट के लिए 2 घंटे का स्प्रिंट प्लानिंग हो सकता है, लेकिन कोई निश्चित समय-सीमा नहीं है।

तो, आप एक लंबी स्प्रिंट योजना को कैसे संबोधित कर सकते हैं?

एक स्क्रम मास्टर के रूप में, मैं निम्नलिखित कदम उठाऊंगा:

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

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

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

इनमें से अधिक चरण गिर सकते हैं, लेकिन यह एक अच्छा शुरुआती बिंदु होगा।

Comments

मूल रूप से टीम अभी भी बैठकों में घंटों की संख्या खर्च करेगी। हम उन्हें अलग-अलग बैठकें कहते हैं। :) टीम को काम का आकलन करने में सहज महसूस करने और काम करने का समय आने पर स्वतंत्र होने के लिए चीजों को तोड़ने में काफी समय लगता है।

— ग्रेग बरगार्ड

@GregBurghardt: ओपी लिखते हैं कि वे ज्यादातर समय डिजाइन करने में बिताते हैं। तो पूरी टीम हर एक कहानी के डिजाइन पर काम करती है। यदि आप इसे तोड़ते हैं ताकि टीम का केवल एक हिस्सा प्रत्येक संबंधित कहानी पर काम करे, तो आप बैठकों में बिताए गए समग्र समय को कम कर देते हैं।

— माइकल बोर्गवर्ड

पुन: "यह सुनिश्चित करें कि टीम को पता चलता है कि उन्हें स्प्रिंट प्लानिंग में हर विवरण प्राप्त करने की आवश्यकता नहीं है": और, अधिक महत्वपूर्ण बात, यह सुनिश्चित करें कि यह वास्तव में सच है कि उन्हें स्प्रिंट पैनिंग में हर विवरण सही प्राप्त करने की आवश्यकता नहीं है ।

— रुख

@GregBurghardt शायद। लेकिन 2 घंटे के प्लानिंग सेशन के बाद 3 घंटे तक पूरी टीम के कमरे में रहने और लोगों के डिफरेंट कॉम्बिनेशन के बीच डिफरेंस वर्क करने से फर्क पड़ता है।

— थॉमस ओवेन्स

Answer 2

मैं तुम्हें सुनता हूं। यह खर्च करने के लिए बहुत लंबा है! उम्मीद है, आपकी टीम आपके रेट्रोस्पेक्टिव्स में इस पर चर्चा कर रही है। हमने मिश्रित परिणामों के साथ कई प्रयोग किए:

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

2. पेयर किए गए डिजाइनों का प्रयास किया गया। दो या तीन के समूह कार्यों में एक टिकट को तोड़ देंगे। पूरी टीम परिणामी योजनाओं की समीक्षा करेगी। यह बहुत तेज़ी से आगे बढ़ा, लेकिन कुछ मिनी पॉड्स में एक ही व्यक्ति के साथ सवार होने का मुद्दा था, जबकि दूसरे ने डिजाइन पर काम किया।

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

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

Comments

विकल्प # 3 नस्लों की टीमें जो किसी एक व्यक्ति या लोगों के छोटे समूह पर भरोसा करती हैं। यदि वह व्यक्ति या लोग आसपास नहीं हैं, तो टीम का वेग शौचालय के ठीक नीचे चला जाता है। मैं अपनी टीम के साथ ऐसा करता था, और किसी भी समय वह व्यक्ति छुट्टी पर चला जाता था। कुछ नहीं किया। फिर टीम लीड ने परियोजना प्रबंधन को शांत करने के लिए 3 सप्ताह का समय बिताया। यदि आप जूनियर या गैर विशेषज्ञों के साथ एक टीम पर काम कर रहे हैं, तो मैं निश्चित रूप से # 3 की सिफारिश नहीं करूंगा। यदि आपको सभी विशेषज्ञ मिल गए हैं (और वे वास्तव में विशेषज्ञ हैं) # 3 एक समय बचाने वाला हो सकता है।

— ग्रेग बरगार्ड

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

— जेसन ज़िनस्क्लाग

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

— ग्रेग बरगदट

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

— जेसन ज़िन्स्चलाग

@GregBurghardt मुझे लगता है कि हमने स्प्रिंट प्लानिंग के दौरान "देव कार्य लिखना" जैसा कुछ किया है। और मुझे यकीन नहीं है कि यह ठीक है?

— b.ben

Answer 3

मुझे @ थॉमस-ओवेन्स से प्राप्त उत्तर पसंद है लेकिन मैं एक और आइटम भी जोड़ूंगा। क्या आपने अपने एजाइल कार्यान्वयन के हिस्से के रूप में जोड़ी प्रोग्रामिंग करना माना है?

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

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

Comments

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

— b.ben

@ b.ben लेकिन जब तक आप ऐसा नहीं करेंगे आपकी टीम के पास पर्याप्त वरिष्ठ नहीं होंगे । यह जोड़ी प्रोग्रामिंग की शक्ति का हिस्सा है। आपको इसके लिए प्रतिबद्ध होना चाहिए।

— अज्ञात कोडर

Answer 4

मैं कोई डरावनी अफिसिओनाडो नहीं हूं और केवल व्यावहारिक अनुभव का एक वर्ष है। तो नमक के एक दाने के साथ पढ़ा जाना चाहिए।

आप जो लिखते हैं उसमें मुझे कई लाल झंडे दिखाई देते हैं:

5 घंटे स्प्रिंट प्लानिंग

यह एक सप्ताह के स्प्रिंट के लिए बहुत लंबा है।

स्प्रिंट प्लानिंग का लक्ष्य AFAIR to है

• वर्तमान प्राथमिकताओं क्या हैं और यह जानने में टीम को सक्षम करें
• आगामी स्प्रिंट के लिए एक युद्ध योजना विकसित करना।

इसे प्रभावी ढंग से करने के लिए, प्रत्येक पक्ष को समझना होगा Product Backlog items।

Product Backlog itemsबैकलॉग को समझने के लिए अच्छे आकार में होना चाहिए।

ठोस नियोजन चरण में, Product Backlog itemsरूपांतरित हो जाते हैं Sprint Backlog items।

एक संभावित कारण यह है कि इन वस्तुओं को पर्याप्त रूप से स्पष्ट / परिष्कृत नहीं किया जाता है।

एक और संभावित कारण यह है कि आइटम बहुत जटिल हैं और बहुत अधिक व्याख्या के लिए जगह छोड़ते हैं।

स्प्रिंट प्लानिंग में बहुत विस्तृत चर्चा करें

जैसा कि ऊपर कहा गया है, चर्चा का चरण छोटा होगा, जब आइटम अधिक ठोस होंगे।

दूसरी ओर: स्प्रिंट प्लानिंग हर प्रतिभागी से पेशेवर व्यवहार की उम्मीद करती है। इसमें बिकेशिंग चर्चाओं से बचना शामिल है ।

शायद चीजें स्पष्ट हैं, लेकिन किसी ने चर्चा शुरू की ।

अधिक: कार्यान्वयन विवरण के बारे में चर्चा से बचें । यद्यपि हर विचार किसी समय कोड में समाप्त होता है, यह चर्चा करने वाले स्प्रिंट प्लानिंग का बिंदु नहीं है, चाहे एक सरल सरणी चाल करेगा, या यह एक लिंक की गई सूची का उपयोग करके बेहतर होगा।

चूंकि टीम के अधिकांश सदस्य वरिष्ठ नहीं हैं

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

स्प्रिंट के दौरान कार्यान्वयन और पुनर्निर्देशन की गलतियाँ

आवश्यकताओं को इकट्ठा करने में एक मौलिक समस्या लगती है, इसके बाद एक बहुत अस्पष्ट उत्पाद बैकलॉग होता है।

जैसा कि मैंने ऊपर कहा है: जब तक Product Backlogयह एक अच्छे आकार में है, तब तक इस बिंदु को याद रखना मुश्किल है।

मैं ऐसी स्थिति की कल्पना नहीं कर सकता:

»एक उपयोगकर्ता के रूप में मैं एक मुट्ठी भर ग्राहक देखना चाहता हूँ!"

»ओह, आप हमारे 2 मिलियन ग्राहकों में से हर एक का मतलब नहीं था ?

OTOH: इस संदर्भ में क्या मतलब है नया स्वरूप ? यदि किसी डेवलपर ने धीमी गति से प्रदर्शन करने वाला एल्गोरिथम चुना है , तो अगला लक्ष्य स्पष्ट है: बेहतर प्रदर्शन करने वाला चुनें। लेकिन यह कोई "नया स्वरूप" नहीं है, यह एक अनुकूलन है।

---

आपके मुख्य प्रश्नों के लिए:

इससे कैसे निपटें?

यह उल्लेख करने के लिए तुच्छ है, लेकिन मैं इसे वैसे भी करता हूं: यह मत भूलना, कि आप मनुष्यों के साथ काम कर रहे हैं ।

विभिन्न दिमागों का एक समूह होना बहुत कठिन है, जो सामान्य अवधारणाओं (जैसे राशोमन ) को साझा करने में सक्षम हैं । इससे प्रभावी ढंग से निपटने के लिए, अपने संचार में यथासंभव अतिरेक का उपयोग करें: उदाहरण के लिए व्यापक वस्तु का संदर्भ स्पष्ट करें, भले ही हर व्यक्ति को "पता होना चाहिए" क्या करना चाहिए। प्रश्न पूछें, क्या प्रत्येक व्यक्ति को दिए गए आइटम का विषय क्या है।

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

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

प्रति सप्ताह स्प्रिंट के 2 घंटे लंबे समय तक फिट होने की योजना के दौरान मुझे कितना विस्तार से चर्चा करनी चाहिए?

सैलोमोनिक उत्तर: जितना संभव हो उतना कम और जितना आवश्यक हो, लेकिन अधिक नहीं।

tl; डॉ

• गलतफहमी से बचने के लिए एक आसान भाषा चुनें (यदि यह सरल अंग्रेजी का उपयोग करती है या ELI5)

• आवश्यकताओं में सुधार लाना

• बैकलॉग में सुधार करें

• एक टीम के रूप में अपनी व्यक्तिगत क्षमताओं के साथ-साथ अपनी क्षमताओं में टीम के सदस्यों का विश्वास बढ़ाएं

• बाइक चलाने से बचें

• व्यक्तिगत अनुशासन में सुधार

• शायद चर्चा करने के लिए हर आइटम के लिए निश्चित समय-सीमा का उपयोग करें

• scrum masterप्रभावी रूप से मध्यम करने की स्थिति को मजबूत करें ।

Answer 5

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