Scrum: एक समय में एक कहानी पर काम कैसे करें

Question

मुझे एक नई गठित स्क्रैम टीम में स्क्रैम मास्टर के रूप में नामित किया गया था। हम पहले से ही कुछ स्प्रिंट कर चुके हैं। शुरुआत में मैंने एक समय में एक कहानी पर काम करने के लिए अपनी टीम बनाने की कोशिश की। लेकिन यह काम नहीं किया। मेरी टीम को कार्यों को इस तरह से वितरित करने में कठिनाइयाँ थीं कि वे एक कहानी पर एक साथ काम कर सकते हैं। शायद हम कुछ गलत कर रहे हैं?

उदाहरण के लिए: हमारे पास एक नया संवाद बनाने के लिए एक कहानी है। हम निम्नलिखित कार्य बनाते हैं:

• मॉडल कक्षाएं बनाएं
• डेटाबेस से मॉडल डेटा पढ़ें
• मॉडल कक्षाओं को देखने के साथ कनेक्ट करें
• डायलॉग हैंडलिंग लागू करें
• डेटा को पास पर सहेजें
• टेस्ट डॉक्यूमेंटेशन
• समाधान का वर्णन

क्या एक समय में एक से अधिक लोगों द्वारा कार्य किए जा सकते हैं? कार्य - कम या ज्यादा - एक दूसरे पर निर्माण। या हम कार्यों को गलत तरीके से डिजाइन करते हैं?

Answer 1

सभी टीम को एक ही कहानी पर काम क्यों करना चाहिए?

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

Answer 2

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

Comments

"... अपने डेवलपर्स को प्रत्येक पैर की उंगलियों पर कदम रखने से बचें": यह विचार जोड़ी प्रोग्रामिंग (यह मानते हुए कि यह फिट हो सकता है) के साथ कैसे फिट बैठता है?

— जियोर्जियो

@ जोड़ी प्रोग्रामिंग में जियोर्जियो आपके पास केवल एक प्रोग्रामर "ड्राइविंग" है इसलिए केवल एक व्यक्ति कोई भी बदलाव कर रहा है। समस्याएँ तब होती हैं जब एक से अधिक डेवलपर्स एक ही क्षेत्र में चारों ओर घूमना शुरू करते हैं।

— रायथल

Answer 3

आम तौर पर हम जो करते हैं वह कहानियों को dev / infra / analist उपशीर्षक में तोड़ देता है।

1. आम तौर पर कुछ दिनों के काम से अधिक कुछ भी एक कहानी है।

2. एक बार जब कार्य टूट जाते हैं, तो एक या अधिकतम दो डेवलपर्स एक कहानी पर काम करते हैं, जो हाथ में कार्यों की संख्या पर निर्भर करता है। आमतौर पर इसकी एक।

3. हम बिताए गए समय को लॉग करते हैं, और शेष अनुमान को दिन के अंत में अपडेट करते हैं इससे पहले कि हम छोड़ दें या दैनिक खड़े होने से पहले।

4. उप-कार्य किसी भी नए मुद्दों के लिए बनाए जाते हैं जो काम करते समय सामने आते हैं।

5. 2 सप्ताह से अधिक काम करने वाली कहानी को एक महाकाव्य माना जाता है।

6. एक महाकाव्य को कई कहानियों से बनाया जा सकता है

Answer 4

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

• एक क्रॉस फंक्शनल, ध्वस्त टीम
• एक गैर तुच्छ कहानी
• "किया" की एक परिभाषा जिसका अर्थ है पूरी टीम की भागीदारी

किसी कहानी को कार्यों में तोड़ते समय, टीम पहले से ही स्वीमिंग मोड में होनी चाहिए ताकि उत्पन्न कार्य स्वीमिंग के साथ संगत हो और इसमें पूरी टीम शामिल हो सके।

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

आप एक समय में एक बैकलॉग आइटम पर माइक कोहेन की एक टीम झुंड पढ़ना चाह सकते हैं ? या यह लेख मैंने लिखा था (कल) जो विशेष रूप से बग से निपटता है: झुंड में या झुंड में नहीं

Answer 5

SCRUM का एक बड़ा हिस्सा यह है कि टीम को इस प्रकार के निर्णय लेने चाहिए। बैकलॉग में उपयोगकर्ता की कहानियाँ होनी चाहिए, ताकि उम्मीद की जा सके कि कार्यों की पर्याप्त जानकारी उत्पन्न हो।

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

एक समय में सिर्फ एक कहानी पर काम करने की कोशिश में आप जो दर्द महसूस कर रहे हैं उसे टीम द्वारा स्वीकार किया जाना चाहिए और स्प्रिंट रेट्रोस्पेक्टिव संभावित समाधानों को लाने की जरूरत है। पता लगाएँ कि आप क्या कर रहे हैं और किन चीजों में सुधार करने की आवश्यकता है।

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

Answer 6

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

क्या संभव होगा कि इसे तीन मुख्य चीजों में विभाजित किया जाए, जो कुछ अतिरिक्त काम / सेटअप के साथ लोग समवर्ती रूप से काम कर सकते हैं:

• बैक-एंड (डेटाबेस, मॉडल आदि)
• फ्रंट-एंड (नकली डेटा का उपयोग करके)
• टेस्ट (उम्मीदों, परिदृश्य, आदि की स्थापना)

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

आपको अपनी टीम को केंद्रित रखना चाहिए, हां, लेकिन साथ ही आपको सभी को व्यस्त रखने की जरूरत है, और हर कोई इसमें शामिल है।

साथ ही, आपकी टीम कितनी बड़ी है? यह भी एक कारक है; एक कहानी पर दस लोगों का काम करना बहुत कठिन है, और यदि आप कर सकते हैं, तो आपकी कहानी बहुत दूर है, बहुत बड़ी है और इसे अलग किया जाना चाहिए (जैसा कि आपकी टीम को होना चाहिए)।