प्रत्येक स्प्रिंट की शुरुआत में शुरुआती सबटास्किंग


11

मैं एक नई टीम में शामिल हो गया हूँ जो Agile / Scrum का उपयोग कर रहा है, और उनकी विकास प्रक्रिया इस प्रकार है:

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

2) स्प्रिंट किकऑफ के दौरान, पूरी टीम अनुमान लगाती है (पोकर प्लानिंग) कि प्रत्येक कहानी की कहानी कितनी होगी।

3) आखिरकार, प्रत्येक स्प्रिंट शुरू होने के तुरंत बाद, प्रत्येक डेवलपर को समय-समय पर अनुमानों के साथ उप-निर्दिष्ट कहानियों में उत्सुकता से ब्रेक करने की आवश्यकता होती है (जैसा कि प्रत्येक कहानी शुरू करने से पहले उपशीर्षक देने का विरोध किया जाता है)।

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

फिर भी मुझे यह प्रति-उत्पादक लगता है, मुख्यतः निम्नलिखित कारणों से:

  • यदि लक्ष्य मोटा अनुमान प्रदान करना है, तो कहानी अंक (चरण # 2) क्या काम करता है। अन्यथा कहानी के बिंदुओं से क्यों परेशान हैं? - बस जल्दी शुरू करना।
  • यदि उद्देश्य सटीक अनुमान प्रदान करना है, तो यह मानव टास्क स्विचेज माने जाने वाले हानिकारक का वर्णन करने का एक स्पष्ट उदाहरण है । मुझे लगता है कि यह विशेष रूप से ताजा डेवलपर्स के लिए मामला है, जो बड़ी परियोजनाओं में मौजूदा टीमों में शामिल होते हैं, जहां समझने की जरूरत है कि 50% समय लग सकता है। आपको कहानी # 1, फिर कहानी # 2, # 3, इत्यादि का विवरण प्राप्त करना आवश्यक है, जिससे बहुत सी जानकारी प्राप्त होती है।

मुझे यह भी बताया जा रहा है कि इस तरह की प्रथा "पुस्तक द्वारा" है और मैं इस पर चर्चा करने के लिए भी नहीं हूँ। क्या कोई इस तरह के अभ्यास का संदर्भ प्रदान कर सकता है - क्या यह स्पष्ट रूप से स्क्रैम बाइबल्स में परिभाषित किया गया है, और / या शायद कोई अतिरिक्त जानकारी प्रदान करता है?

जवाबों:


3

यह असहमति नहीं है कि हम अपनी कुछ प्रक्रिया को कैसे चलाते हैं। हम

  1. "कहानी अंक" में बैकलॉग के शीर्ष के पास की कहानियों का अनुमान लगाएं
  2. कहानी के आधार पर कहानियों का चयन / व्याख्या करें जो हमें लगता है कि स्प्रिंट को "बनाएंगे"
  3. अधिक विस्तृत तकनीकी कार्यों में कहानियों को तोड़ो
  4. तकनीकी कार्यों का अनुमान लगाएं और मूल कहानी बिंदुओं के अनुमान से तुलना करें (हम जानते हैं कि कहानी बिंदु आमतौर पर कितना विकास समय के बराबर होता है)

लेकिन आप जानना चाहते हैं कि हम दो बार अनुमान क्यों लगाते हैं!

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

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

  • हम एक टीम के रूप में ब्रेकडाउन करते हैं , हम पाते हैं कि ओवरहेड अधिक से अधिक तकनीकी चर्चा है जो हमें इस से मिलती है अक्सर बहुत मूल्यवान होती है और हमारी कहानी में कमियों का पता लगा सकती है। जब हमारे पास अनुभव, ज्ञान या क्षमता की असमानता होती है, तो यह चर्चा भी होती है कि अधिक से अधिक उन लोगों की मदद कर सकते हैं जिनके पास कम (नई इच्छाओं के साथ बहुत उपयोगी) हैं।
  • हम एक टीम के रूप में कार्य स्तर पर अनुमान लगाते हैं , एक कारण "नियोजन पोकर" काम करता है "भीड़ की बुद्धि" घटना के कारण - जैसा कि मैंने टिप्पणियों में उल्लेख किया है, इस बिंदु से एक कार्य का अनुमान लगाने में 30 सेकंड से कम समय लगना चाहिए , इसलिए ओवरहेड नगण्य है।

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

मेरी राय में कार्य स्विचिंग आपके लिए यहां एक समस्या होने की संभावना नहीं है, मुझे नहीं लगता कि विभिन्न कार्यों को तोड़ना वास्तव में एक ही अर्थ में एक कार्य स्विच है जो एक सुविधा को दूसरे भाग में विकसित करने से फ़्लिप करना एक कार्य स्विच है । मुझे लगता है कि स्प्रिंट के समग्र "वास्तुकला" की समझ हासिल करना संभवतः काफी उपयोगी चीज है।

हालाँकि, मुझे लगता है कि कुछ अन्य समस्याएं हो सकती हैं जिन पर आप विचार कर सकते हैं। हमेशा चुस्त रहने के साथ आपको एक समस्या की पहचान करनी चाहिए जो आपके पास है और एक समाधान का प्रस्ताव करना चाहिए , फिर तय करें कि आपका समाधान पूर्वव्यापी में काम करता है या नहीं । यह एक चुस्त समाधान के निर्माण का क्रुक्स है जो आपकी कंपनी और आपकी टीम के लिए काम करता है। तो, कुछ समस्याएं जो आपको हो सकती हैं:

  • आप व्यक्तिगत रूप से ब्रेकडाउन कर रहे हैं - तो आपकी जूनियर / अनुभवहीन टीम के सदस्य आपके वरिष्ठ टीम के सदस्यों से कैसे सीख रहे हैं? यकीन है, वे शायद सब कुछ खुद सीख सकते हैं - लेकिन वे तेजी से सीखेंगे यदि उन्हें सलाह दी जाती है। क्या जूनियर टीम के सदस्यों को चीजों को तोड़ने में काफी समय लग रहा है? क्या वे गलतियाँ कर रहे हैं या उन चीजों को याद कर रहे हैं जो लंबे समय में टीम का समय बिताती हैं? एक टीम के रूप में टूटने से यहां मदद मिल सकती है।
  • आप व्यक्तिगत रूप से अनुमान लगा रहे हैं - वही पहले बिंदु के रूप में लागू होता है, लेकिन इसके अलावा ये अनुमान कम सटीक हैं जितना वे हो सकते हैं?
  • ऐसा लगता है कि कार्य स्प्रिंट की शुरुआत में सौंपा गया है, लेकिन अगर यह मामला है, तो आपको यह कितना महंगा है जब आपको असाइनमेंट बदलना होगा? यदि कोई पीछे छूट रहा है या बीमार है, तो किसी और के लिए अपने कार्यों को चुनना कितना आसान है? क्या उन्हें टास्क ब्रेकडाउन से गुजरना पड़ता है और मूल कार्य को बाधित किए बिना उन्हें समझने की कोशिश करनी होती है? यदि आप एक टीम के रूप में टूटते हैं और अनुमान लगाते हैं तो हर किसी को हर चीज पर काम करने में सक्षम होना चाहिए!
  • क्या आपकी कहानियाँ बहुत बड़ी हैं? यदि ब्रेक डाउन में 50% समय लगता है, तो कहानियां ऐसी लगती हैं जैसे वे बहुत शामिल हों - शायद उन्हें छोटा किया जा सकता है? हम अपनी कहानियों को काम के 1 सप्ताह के भीतर रखते हैं।
  • क्या आपके कार्य बहुत छोटे हैं? यदि आप लंबे समय से कार्य सूची बना रहे हैं तो शायद आप बहुत अधिक विस्तार में जा रहे हैं? हम काम के लायक 1 और 8 घंटे के बीच काम करते हैं ताकि एक दिन में हर कोई अगले दैनिक स्टैंडअप पर रिपोर्ट करने के लिए कुछ प्रगति कर सके।

आपके प्रतिक्रिया के लिए धन्येवाद। जिन कारणों से मैं सुनवाई करता हूं, वे आपके द्वारा सूचीबद्ध समान हैं। हालांकि जिज्ञासा से बाहर, क्या आपका काम उत्पाद-आधारित है (जैसा कि उत्पाद में है और अनुकूलन करते हैं) या परियोजना-आधारित (सलाहकार / आउटसोर्सिंग प्रकार)? और, सबसे महत्वपूर्ण बात, क्या आप वर्तमान मॉडल को उत्पादक पाते हैं?
मनसस

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

3

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

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

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

यह भी मेरी राय है। मेरा सुझाव है कि आप अपने लिए प्रयास करें और परिणाम को देखें - देखें कि मैंने वहां क्या किया :)


3

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

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

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

कुछ और जानकारी प्रदान करने के लिए, स्प्रिंट प्लानिंग मीटिंग के दौरान हमारे वर्कफ़्लो इस प्रकार हैं:

  1. हम उत्पाद बैकलॉग के ऊपर से एक कहानी लेते हैं, और इसे कार्यों में विभाजित करते हैं। अंगूठे के नियम के रूप में, एक कार्य को आम तौर पर एक दिन से छोटा होना चाहिए।

  2. हम उस कहानी का अनुमान लगाते हैं जो दिए गए कार्यों को दी गई है। यदि कहानी बड़ी हो जाती है, तो हम कहानी को छोटी कहानियों में विभाजित करने की कोशिश करते हैं।

  3. कुल्ला और दोहराएं जब तक हम अनुमानित बिंदुओं के कुल तक नहीं पहुंचते

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

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


हां, मुझे लगता है कि मैंने 'समय सीमा' शब्द का गलत इस्तेमाल किया है। वास्तव में मेरा मतलब ऐसी स्थिति से था, जहां कुछ कहानियां / कार्य स्प्रिंट के अंत तक समाप्त नहीं हो पाएंगे और उन्हें पूरा करना होगा।
दिमागी

3

"पुस्तक द्वारा" - यही आपकी समस्या है। यदि आप जलप्रपात काम कर रहे होते तो आप अधिक प्रक्रिया में डूब रहे होते।

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

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

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

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


0

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.