रेडी की परिभाषा - हम किस बारे में बताना भूल गए

परिचय
DoR क्या है
आपको DoR की आवश्यकता क्यों है?
DoR का उपयोग कहाँ करें
DoR का उपयोग कब करें
निवेश मॉडल
निष्कर्ष
संदर्भ

परिचय

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

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

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

DoR क्या है

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

आपको DoR की आवश्यकता क्यों है?

सबसे पहले, हम इस प्रश्न का उत्तर देते हैं: इस कलाकृति की आवश्यकता क्यों है? वह टीम को क्या फायदा पहुंचाएगा? DoR टीम की मदद करेगा:

1. उन विशेषताओं पर काम शुरू करने से बचें जिनमें पूर्णता मानदंडों की स्पष्ट परिभाषा नहीं है। टीम को समझ में आ जाएगा जब उपयोगकर्ता स्टोरी को पूरा माना जाता है, और ऐसा करने के लिए क्या करने की आवश्यकता है।
2. लम्बी चर्चाओं, व्यर्थ के सोचे-समझे कार्यों पर बहुत समय बर्बाद न करें। पूर्व-संसाधित कार्य पूरी टीम के समय को बचाएगा। गणना करें कि एक व्यक्ति के लिए "बुरे" कार्य पर चर्चा करने में कितना समय लगता है। अब टीम में लोगों की संख्या से गुणा करें। और अब ऐसे कार्यों की संख्या के लिए।
3. उन चीजों पर समय और ऊर्जा केंद्रित करें जो यथासंभव "सुरक्षित" हैं। सबसे शक्तिशाली डिमोटिविटर्स में से एक कार्यक्षमता है जिसे बिन में फेंक दिया जाता है।
4. कार्यों की चर्चा में प्रत्येक भागीदार को शामिल करें। सबसे पहले, यह टीम को प्रेरित करता है। दूसरे, यह टीम के प्रत्येक सदस्य को एक विशेषज्ञ के रूप में प्रकट करने में मदद करता है। तीसरा, डेवलपर्स समस्या की अपनी दृष्टि प्रदान करेंगे। चर्चा के दौरान, अन्य समाधान उत्पन्न हो सकते हैं जो मूल विचार से मौलिक रूप से भिन्न होंगे।

आइए उन समस्याओं की सूची पर नज़र डालें जो अप्रत्यक्ष रूप से या सीधे DoR की कमी के परिणामस्वरूप होती हैं:

1. समस्या को समझने में विसंगतियां टीम के सदस्यों के बीच नियमित रूप से दिखाई देती हैं। स्प्रिंट के अंत तक, विसंगति तेज हो जाती है, जो विकास की प्रक्रिया में परिवर्तन होने पर घटनाओं की ओर जाता है, जो स्वाभाविक है। लेकिन इस तथ्य को देखते हुए कि इन क्षणों को दर्ज नहीं किया गया था, केवल एक जिसने सीधे सामना किया था, उनके बारे में जानता है।
2. टीम को समझने के लिए कार्यात्मक आवश्यकताएं तेजी से बदलती हैं। चूंकि कार्य स्प्रिंट में प्रवेश किया, इसलिए उच्च अनिश्चितता के साथ, जब तक कि हिस्सा तैयार नहीं हो जाता और "नींव" रखी जाती है, तब तक नई जानकारी दिखाई देती है जिसके लिए शुरुआत में वापसी की आवश्यकता होगी। जितना बुरा काम किया जाता है, उतनी बार स्प्रिंट में ऐसी स्थिति पैदा होगी। अंत में, यह एक फकैप को जन्म देगा।
3. अक्सर कार्यात्मक से प्राप्त परिणाम का मूल्यांकन करने में समस्याएं होती हैं, टीम को पता नहीं है कि मेट्रिक्स कैसे इकट्ठा करें, या इससे भी बदतर, उनके लिए भूल गए। स्क्रम मुख्य रूप से ग्राहक, उपयोगकर्ता या खरीदार को लाभ के बारे में है। यदि टीम कार्य के लाभों का मूल्यांकन नहीं करती है, तो उसे प्रतिक्रिया और उत्पाद विकास के पाठ्यक्रम को समायोजित करने की क्षमता प्राप्त नहीं होती है। इससे पूर्ण विफलता हो सकती है।
4. इसके अलावा, DoR की कमी का परीक्षण पर बड़ा प्रभाव पड़ता है, और उपयोगकर्ता स्टोरी पर QA परीक्षण अपेक्षाओं के बजाय, यह डेवलपर्स की अपेक्षाओं का परीक्षण करेगा। कोड पूरी तरह से काम कर सकता है, ऑटोटेस्ट घड़ी की कल की तरह काम करेगा, लेकिन कार्यक्षमता उत्पादन पर काम नहीं करेगी।

अंत में, यह एक ऐसे उत्पाद की रिहाई की ओर जाता है जो काम नहीं कर रहा है, बेकार है, प्राथमिक समस्या को हल नहीं करता है। और यह समय की बर्बादी है जो हर कोई महत्वपूर्ण चीजों पर खर्च करना चाहता है। एक लेख में, मैं एक उत्कृष्ट कहावत पर आया: "कचरा आया, कचरा बाहर आया।"

DoR का उपयोग कहाँ करें

DoRs का उपयोग उत्पाद बैकलॉग शोधन पर किया जाता है, जिसे बाद में PBR या अधिक परिचित विरूपण साक्ष्य नाम: ग्रूमिंग कहा जाता है। इस गतिविधि के दौरान, उपयोगकर्ता कहानियां तैयार - तैयार हो जाती हैं। इसका मतलब है कि उत्पाद बैकलॉग में घटना का परिणाम रेडी यूएस है। DoR को उस राज्य का वर्णन करने की आवश्यकता है जिसमें अमेरिका की योजना बनाने पर चर्चा की जा सकती है। इसे टैकिन इन - यूएस द्वारा स्वीकार किया जाता है।

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

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

DoR का उपयोग कब करें

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

जैसा कि ऊपर उल्लेख किया गया है, DoR मापदंड का एक समूह है। टीम इन मानदंडों को स्वयं बनाने की कोशिश कर सकती है। उन "सिग्नल" के माध्यम से कार्य करें जो पुनरावृत्तियों में खोजे गए हैं। इन बिंदुओं पर फिर से विचार करें, मूल कारण खोजें। यदि आप इस पर अगले पूर्वव्यापी खर्च नहीं करना चाहते हैं, तो तैयार समाधान का उपयोग करें।

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

निवेश मॉडल

• स्वतंत्र स्वतंत्रता - ऐसे यूएस बनाने से बचने की कोशिश करें जो एक-दूसरे पर निर्भर हैं। ऐसी निर्भरताएं प्राथमिकता देने और योजना बनाने में समस्याएं पैदा करती हैं। ग्राहक उच्च प्राथमिकता के साथ अमेरिका को चुन सकता है, जो कम प्राथमिकता वाले कार्य पर निर्भर करता है। निर्भर अमेरिका को विलय कर दिया जाना चाहिए, अलग-अलग या स्पाइक को विभाजित करना चाहिए।
• परक्राम्य वार्ता - अमेरिका एक औपचारिक संविदात्मक दायित्व या आवश्यकता नहीं है। यूएस कोई तकनीकी कार्य नहीं है। स्प्रिंट के दौरान, उन पर चर्चा और संशोधन किया जा सकता है। इतिहास के साथ एक कार्ड, जो भी रूप में मौजूद है, कार्यक्षमता का एक संक्षिप्त विवरण है, जिसके विवरण को कार्य के दौरान स्पष्ट किया जाना चाहिए। कार्य पूरा होने पर चर्चा उत्पन्न करने के लिए कार्ड पर नोट्स छोड़ दें। यहां एक मध्य मैदान खोजना महत्वपूर्ण है, क्योंकि नोटों की अधिकता से टीम को संपूर्ण जानकारी के रूप में अनुभव होगा, और इस पर कोई चर्चा नहीं होगी। मेरी टीम इस पर बहुत जल्दी आ गई। चर्चा किए गए विवरण परीक्षण बन जाते हैं जो कागज के पीछे या इलेक्ट्रॉनिक कार्ड पर टिप्पणी में लिखे जा सकते हैं। स्वीकृति परीक्षण सभी के लिए सरल और स्पष्ट हैं।
• उपयोगकर्ता या ग्राहक के लिए मूल्यवान मूल्य - "प्रत्येक कहानी का उपयोगकर्ता के लिए एक निश्चित मूल्य होना चाहिए" - एक बयान जो गलत है। सबसे लगातार खरीदार के बारे में भूल जाते हैं। फोकस, आपकी कंपनी पर निर्भर करता है: बी 2 सी, बी 2 बी, बी 2 जी। मुख्य बात उन कहानियों से बचना है जो केवल डेवलपर्स के लिए मूल्यवान हैं। ऐसी कहानियों में सुधार किया जाना चाहिए ताकि लाभ स्पष्ट हो जाएं और ग्राहक प्राथमिकताएं निर्धारित कर सकें। वास्तु कार्यों को कूड़ेदान में फेंकने की आवश्यकता नहीं है, ग्राहक को समझाएं कि इस तरह के कार्य से क्या लाभ होगा और इसमें सुधार होगा।
• अनुमानित मूल्यांकन - डेवलपर्स को अमेरिका के आकार का अनुमान लगाने में सक्षम होना चाहिए, अर्थात, इसे लागू करने में लगभग अनुमानित समय लगेगा। श्रम की तीव्रता मापने योग्य नहीं होने के तीन मुख्य कारण हैं:
  
  
  1. टीम में विषय ज्ञान का अभाव है
  2. टीम में तकनीकी अनुभव का अभाव है
  3. कहानी बहुत बड़ी है
  
  पहले और दूसरे मामले में, स्पाइक आपकी मदद करेगा। तीसरे में, अमेरिका को छोटे लोगों में विघटित करने की आवश्यकता है।
• छोटी कॉम्पैक्टनेस - बहुत कुछ यूएस के आकार पर निर्भर करता है, बहुत बड़े और बहुत छोटे यूएस का मूल्यांकन करना मुश्किल है। महाकाव्य के साथ काम करना मुश्किल है, क्योंकि वे कई यूएस से मिलकर होते हैं। महाकाव्यों को दो प्रकारों में विभाजित किया जा सकता है:
  
  
  1. समग्र। यहां सब कुछ सरल है - हम विघटित होते हैं। बाकी बिंदुओं पर विचार करें, पहली चीज जो टीम की संभावना होगी: यूएस को आर्किटेक्चरल लेयर के प्रकार से विभाजित करें: यूएस द्वारा एक डेटाबेस, बैकएंड, फ्रंटेंड और इसी तरह।
  2. परिसर। यूएस का बड़ा आकार उनके बहुत सार के कारण है, वे या तो विघटित नहीं होते हैं, या यह बहुत मुश्किल है। इस मामले में, हम स्पाइक का उपयोग करते हैं।
  
  
• परीक्षण योग्य परीक्षणशीलता - पुष्टि है कि अमेरिका को सफलतापूर्वक विकसित किया गया है, एक सफल परीक्षण के रूप में कार्य करता है। यदि अमेरिका का परीक्षण नहीं किया जा सकता है, तो टीम को यह नहीं पता होगा कि निर्माण पूरा होने पर, या स्वयं मापदंड के साथ आएगा। इसके अलावा, टीम का प्रत्येक सदस्य अलग होगा।

निष्कर्ष

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

संदर्भ

1) रोमन Pichler "उत्पाद प्रबंधन स्क्रम में"
2) माइक कोहन "कस्टम कहानियां। लचीला सॉफ्टवेयर विकास ”
3) agilealliance.org
4) लिंक्डइन डॉट कॉम
5) boost.co.nz
6) scruminc.com