2010-02-18 6 views
6

एक स्क्रम टीम में, आगे बढ़ने से पहले एक कहानी को पूरा करना कितना महत्वपूर्ण है?क्या कई कहानियों पर एक साथ काम करना बुरा व्यवहार है?

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

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

सवाल का कारण यह है कि मुझे लगता है कि मैं कहता हूं कि मैं किसी भी समय जब मैं फिट बैठता हूं, तो मैं कहता हूं कि मैं किसी भी समय प्रगति पर कहानियां कहता हूं (या 3 अगर कोई विशेष रूप से आसान है) कहकर मैं सबसे कुशलता से काम करता हूं। यह उप-सचेत पृष्ठभूमि विचारों में सहायता करता है जो कार्य को पूरा करने में सहायता करता है। अगर कुछ कहानियों से संबंधित हैं तो यह मुझे बड़ी तस्वीर को बेहतर ढंग से समझने की अनुमति देता है।

हमारी कहानियां आम तौर पर एक या दो दिन के काम के लिए काम करती हैं।

तो, एक समय में दो कहानियों पर काम कर रहा है और यदि ऐसा है तो एक-कहानी-एक-बार आपको क्या खरीदता है?

+4

मैं इस सवाल को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह प्रोग्रामिंग के बारे में नहीं है। –

उत्तर

4

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

3

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

1

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

सामान्य रूप से, मुझे कोड बेस की कई प्रतियां प्रबंधित करने या मेरे कोड को बहुत अधिक स्विच करने की कोशिश करना पसंद नहीं है, इसलिए मैं एक समय में एक कहानी करना पसंद करता हूं, कोई अवरोधक नहीं मानता। जिस कोड बेस के साथ मैं काम कर रहा हूं उसका आकार ~ 1.1 जीबी डेटा 82,000+ फाइलों में फैला हुआ है, इसलिए कई प्रतियां मुझे थोड़ा दर्दनाक होने की कल्पना कर सकती हैं।

इस पर मेरा व्यक्तिगत अनुमान यह है कि यह मानक निर्धारित करने के लिए टीम पर निर्भर करता है और यह देखता है कि यह उनके लिए काम करता है। अगर कुछ एक समय में एक कहानी पसंद करते हैं और अन्य कई करते हैं और सब ठीक है, तो शांत।अगर सभी को पूरा होने के विभिन्न बिंदुओं पर कई कहानियां पसंद हैं, तो यह भी काम कर सकता है।

0

, बैकलॉग ... मेरे अनुभव में नहीं घेर जब कहानियों आकार में 1 और 2 दिनों के बीच कर रहे हैं, वे एक ही डेवलपर द्वारा कार्यान्वित किया जाना है। यदि आप एक साथ 2 या 3 कहानियां काम कर रहे हैं, तो बैकलॉग में चीजों की मात्रा कम हो सकती है जो अन्य डेवलपर्स स्प्रिंट से चुन सकते हैं और खतरे में पड़ सकते हैं।

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

नीचे की रेखा, टीम को निर्णय लेने दें ... और फिर एक पूर्वदर्शी के दौरान परिणामों की समीक्षा करें। यदि आपकी कहानियां, कार्य और कार्य प्रक्रिया उस माहौल का समर्थन करती है जहां टीम के सदस्य उत्पादकता या भविष्यवाणी के बलिदान के बिना एक समय में 2 (शायद 3) कहानियां काम कर सकते हैं, तो आपके एसएम को इसका सम्मान करना चाहिए। लेकिन साथ ही आपको प्रत्येक पूर्वदर्शी के दौरान परिणामों की ईमानदारी से समीक्षा करनी चाहिए और एसएम को काम नहीं करने पर विचार करने के लिए तैयार रहना चाहिए।

0

मैं आम तौर पर सोचता हूं कि सर्वश्रेष्ठ तरीके से काम करने का निर्णय लगभग पूरी तरह से टीम द्वारा किया जाना चाहिए। ScrumMaster की भूमिका टीम की मदद और समर्थन करने के लिए है, स्प्रिंट के दौरान टीम के काम करने के तरीके से सवाल न करें।

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

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

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

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

  1. हाँ, हम काम करते हैं कई कहानियों पर है और यह अब तक ठीक बाहर काम किया है:

    अंत में, मुझे लगता है कि इन दो चीजों के लिए निर्भर करता है।

  2. याद रखें कि स्क्रममास्टर टीम के लिए काम कर रहा है, अन्य रास्ता दौर नहीं।

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

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