जेआईआरए

Question

में स्क्रम "पूर्ण" अवधारणा के लिए सर्वश्रेष्ठ अभ्यास मैं एक छोटी सेवा आधारित कंपनी में काम करता हूं जहां हम स्क्रम प्रथाओं को लागू करना शुरू कर रहे हैं, और हम समस्या ट्रैकिंग के लिए हरीहोपर के साथ जीआईआरए का उपयोग शुरू कर रहे हैं।

• कोडित
• इकाई का परीक्षण किया
• एकीकरण परीक्षण
• सहकर्मी की समीक्षा
• क्यूए परीक्षण
• प्रलेखन अद्यतन

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

मैं इस कार्य के इन सबटास्क को बनाने के लिए तैयार नहीं हूं, क्योंकि मुद्दों का केवल एक-स्तर घोंसला है और मुझे डर है कि उस क्षमता के लिए बेहतर उपयोग है।

मैं वर्कफ़्लो को संशोधित करने के बारे में भी उत्साहित नहीं हूं, क्योंकि यह दृष्टिकोण अन्य प्रणालियों में हमारे लिए बोझ साबित हुआ है।

यदि ये सभी आइटम एक ही टिकट का हिस्सा हैं तो यह मेरे लिए अजीब लगता है क्योंकि काम संभवतः कई टीम के सदस्यों के बीच फैलता है, और 16 घंटे से कम आयु के कार्यों को बनाना मुश्किल होगा जिसमें सभी शामिल हैं उन चीजों।

मुझे लगता है कि मैं सभी मुद्दों को समझता हूं, लेकिन अभी तक मुझे नहीं पता कि सबसे अच्छा समाधान क्या है।

क्या कोई सर्वोत्तम अभ्यास है? या कुछ मजबूत राय?

Answer 1

• कोडित
• इकाई,

IMHO इन साथ रहती हैं परीक्षण किया के रूप में दोनों एक ही व्यक्ति (अधिमानतः TDD, जो वास्तव में यह असंभव इन अलग करने के लिए बनाता है) द्वारा नियंत्रित किया जाना चाहिए।

• एकीकरण

परीक्षण किया हमारी टीम में, यह आमतौर पर एक ही डेवलपर द्वारा किया जाता है, तो हम आम तौर पर ऊपर काम के हिस्से के रूप में यह है। अन्य टीमें इसे अलग-अलग कर सकती हैं।

• टिप्पणी की

आप कोड टिप्पणी मतलब है? फिर, मेरे लिए, यह एक अलग कार्य के लायक नहीं है। अन्यथा, कृपया स्पष्टीकरण दें।

• सहकर्मी

एक अलग डेवलपर (या अधिक) के लिए एक अलग कार्य की समीक्षा की।

• क्यूए परीक्षकों/क्यूए कर्मियों के लिए

एक अलग कार्य का परीक्षण किया।

मैं दस्तावेज जोड़ता हूं - इसकी हमेशा आवश्यकता नहीं होती है, लेकिन अक्सर होती है। फिर, यह एक अलग कार्य होना चाहिए, आमतौर पर उसी व्यक्ति के लिए जो कार्यान्वयन करता था (लेकिन हमेशा नहीं)।

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

Answer 2

मैं निश्चित रूप से उन्हें घोंसला नहीं दूंगा, क्योंकि वे प्रत्येक कार्य के लिए सामान्य कदम हैं। उन्हें उप-कार्य करना सिर्फ सिस्टम की जटिलता और बॉयलरप्लेट को बढ़ाएगा। ये मेरे लिए सही वर्कफ़्लो चरणों की तरह लगते हैं।

सबमिट की तरह कुछ-> असाइन किया गया-> कोडिंग-> समीक्षा-> परीक्षण-> समाप्त हो गया।

जहां कोडिंग को समीक्षा करने से पहले "कोडित", "यूनिट परीक्षण" और "एकीकरण परीक्षण" की आवश्यकता होती है, समीक्षा के लिए समीक्षा करने से पहले पीयर समीक्षा की आवश्यकता होती है, परीक्षण को समाप्त होने से पहले क्यूए परीक्षण की आवश्यकता होती है।

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

Answer 3

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

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

(यह btw अच्छी तरह से पता चलता है कि क्यों एक बग ट्रैकर का उपयोग कर के रूप में एक स्क्रम उपकरण एक बुरा विचार है जो अलग अलग उपकरण है कि अलग अलग चीजों के लिए अनुकूलित किया जाना चाहिए रहे हैं -। भले ही कुछ APIs के माध्यम से एक साथ जुड़े हुए।)

Answer 4

और उन कार्यों को बनाना मुश्किल होगा जो 16 घंटे से कम हैं जिनमें उन सभी चीजों को शामिल किया गया है।

यह आपका असली मुद्दा है; कार्यक्षमता के छोटे उपयोगी ऊर्ध्वाधर स्लाइस में कहानियों को तोड़ने की क्षमता। इस पर काम करने से आपकी टीम अधिक चुस्त हो जाएगी और पीओ को और अधिक लचीलापन मिलेगा।

इसके विपरीत, प्रक्रिया/यांत्रिक चरण द्वारा काम को तोड़ने से आपको केवल कम परेशानी होगी और वास्तव में कोई उपयोगी उद्देश्य नहीं होगा। या तो आप कर चुके हैं या आप नहीं हैं; कोई भी परवाह नहीं करता है कि क्या आप पूर्ण हैं और परीक्षण नहीं किए गए हैं, इसलिए घंटे तक इसे ट्रैक करने से परेशान न करें .... इसका अपशिष्ट।

कार्यों पर नहीं, अपनी कहानियों पर फिर से ध्यान दें।

Answer 5

हम उप-कार्य का उपयोग करते हैं।

यह देखते हुए कि कहानी एक साझा वस्तु है (पूरी स्क्रम टीम उस पर काम करती है), हम सबटास्क का उपयोग 'पोस्ट-नोट नोट्स' के रूप में करते हैं जो उन कार्यों को ट्रैक करने की अनुमति देता है जिन्हें व्यक्तियों से निपटने की आवश्यकता होती है।

हमें यह आवश्यक नहीं है कि कार्य के हर छोटे टुकड़े को उप-कार्य के रूप में दर्शाया जाए।

हम बुककीपर नहीं हैं, लेकिन डेवलपर्स हैं।

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

यदि आप स्वचालित रूप से चेकलिस्ट जेनरेट करना चाहते हैं, तो संक्रमण प्लगइन पर निर्माण उपटस्क देखें। https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition यह कहानी आपको प्रतिबद्ध होने पर स्वचालित रूप से उप-कार्य जोड़ने की अनुमति देती है।

बीटीडब्ल्यू - जेरा एक बग ट्रैकर से अधिक है। हम इसे विभिन्न प्रकार के अनुप्रयोगों में उपयोग कर रहे हैं, जिसमें हमारी स्प्रिंट गतिविधि का प्रबंधन शामिल है। (एक एटलसियन साथी के रूप में, मैं पक्षपातपूर्ण हूं :-)।

फ्रांसिस

Answer 6

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

संदर्भ: स्क्रम गाइड - केन Schwaber और जेफ सदरलैंड (स्क्रम के आविष्कारक)

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

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

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

Answer 7

महत्वपूर्ण बात यह है कि आप वास्तविक कार्य के रूप में उप-कार्य का उपयोग करते हैं; मुख्य कार्य की गतिविधि के रूप में नहीं। समस्या ट्रैकर मुख्य रूप से आप जो कर रहे हैं उसके लिए है; आप कैसे कर रहे हैं और किस क्रम में नहीं।

Answer 8

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

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

Answer 9

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

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