स्क्रम में एजाइल आकलन? स्टोरी पॉइंट और प्लानिंग पोकर

सॉफ्टवेयर विकास प्रक्रिया में, टीम को अक्सर एक सवाल होता है:

काम के समय का अनुमान अधिक सटीक कैसे लगाया जाता है?

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

बहुत सारे डेवलपर्स को लगता है कि पीएम समय सीमा का उपयोग आगे-पीछे कर रहा है। वे यह नहीं चाहते कि क्या फीचर गुणवत्ता के साथ पूरा हो सकता है।

इसलिए

बहुत सारे पीएम्स को लगता है कि डेवलपर्स अपने काम के अनुमान लगाते समय अधिकतर “अतिशयोक्ति” करते हैं। ऐसा लगता है कि वे सभी एक आम काम अनुमान विधि का उपयोग करते हैं: “वास्तविक समय के तीन गुना का बफर अनुमान लगाएं”

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

समस्याएं

डेवलपर की खाई

• “यह बहुत आसान है। इसे बनाने में बहुत लंबा समय नहीं लगना चाहिए?”
• पीएम आज आपसे कहते हैं: “मुझे आने वाले कल से पहले इसे सौंपना है। ‘गुणवत्ता के लिए खोजने से पहले इसे पूरा करो’”
• कल के बाद के दिन पीएम आपसे कहते हैं: “कार्यक्रम की गुणवत्ता इतनी खराब क्यों है?”
• जब इसमें देरी होती है, तो अन्य सहकर्मी: “आपको इतना लंबा समय क्यों लगा? इसके लिए तैयार कोड उपलब्ध है। इसके लिए अच्छी बॉटम लेयर उपलब्ध है। आपने मुझसे क्यों नहीं पूछा?”
• अन्य सहकर्मी: “मुझे केवल एक दिन लगता है, आपने इतने दिन क्यों बर्बाद किए?”
• “यह सामान्य बुद्धि है! अगर हमने आवश्यकता का उल्लेख नहीं किया, तो आपको पता होना चाहिए कि आपको क्या करना है।”

पीएम/पीओ की खाई

• “यह तो बहुत आसान है! इतना लंबा समय क्यों लग रहा है?”
• “आपको देख रहा हूं कि आप फेसबुक पर जा रहे हैं, लेकिन इसे बनाने के लिए समय नहीं है?”
• “बनाए गए चीजों की गुणवत्ता इतनी खराब क्यों है?”
• “वह पिछली बार इसे कैसे बनाया, आपको कितने दिन लगे?”
• क्योंकि विनिर्माण या आवश्यकताएं स्पष्ट रूप से लिखी नहीं गई हैं, डेवलपर को आवश्यकता परिवर्तन के रूप में वर्णित किया जाता है।

परिणाम

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

समाधान

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

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

यहाँ आवश्यकताओं की जटिलता का आकलन करने के लिए उपयोग किया जाने वाला इकाई स्टोरी पॉइंट (आपेक्षिक इकाई) है, कार्य घंटे (निरपेक्ष इकाई) नहीं।

यहाँ आवश्यकता की जटिलता का आकलन करने के लिए उपयोग की जाने वाली इकाई स्टोरी पॉइंट (आपेक्षिक इकाई) है, कार्य समय (निरपेक्ष इकाई) नहीं। इसके कई कारण हैं:

1. तुलना व्यक्ति से व्यक्ति तक नहीं बदलती है: आवश्यकता की जटिलता अक्सर व्यक्ति से व्यक्ति तक नहीं बदलती है, और अभ्यास के लिए आवश्यक समय व्यक्ति से व्यक्ति तक बदलता है।

2. “आपेक्षिक” का आकलन “निरपेक्ष” की तुलना में आसान है: यदि आप कार्य घंटों पर ध्यान देते हैं, तो आपको निरपेक्ष संख्या का आकलन करने की आवश्यकता होगी, और आकलन प्रक्रिया में अनुप्रयोग विवरण पर विचार करने की आवश्यकता होगी। स्टोरी पॉइंट का उपयोग करके जटिलता का आकलन करने के लिए, आपको केवल अन्य आवश्यकताओं के साथ आकार की तुलना करने की आवश्यकता होती है।

उदाहरण के लिए, यह स्पष्ट रूप से कहना मुश्किल है कि “एक टावर कुछ मीटर ऊँचा है”, लेकिन यह आसान है कि “यह टावर उस इमारत से लगभग 2 गुना ऊँचा है।”

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

हालांकि आवश्यकता की जटिलता अक्सर कार्य घंटों से सकारात्मक रूप से संबंधित होती है, अलग-अलग कार्यान्वयन स्थितियों के कारण, एक उच्च स्टोरी पॉइंट वाली विशेषता होने की संभावना है, जिसके लिए कार्य घंटों की आवश्यकता स्टोरी पॉइंट से कम होती है। लेकिन स्क्रम में, आप आवर्ती स्प्रिंट का उपयोग करके यह आकलन कर सकते हैं कि प्रत्येक स्प्रिंट टीम कितनी जटिलता को समायोजित कर सकती है। PO/PM के लिए, असफल समय अनुमान के बजाय, एक अधिक सटीक और वस्तुनिष्ठ समय अनुमान करना बेहतर है, ताकि वे पहली बार में समझ सकें कि प्रोजेक्ट के अपेक्षित समय अनुमान से कितने दूर हैं। यदि संसाधन सीमित हैं, तो आवश्यकताओं को कैसे प्राथमिकता देनी है या अन्य सहायता कैसे प्राप्त करनी है।

अगला, हल के विभिन्न पहलुओं की व्याख्या करें।

जब

किसी को करने के लिए तय करने से पहले आकलन करें: इसका लाभ डेवलपर के व्यक्तिगत कारकों को कम करना है। क्योंकि आप नहीं जानते कि कौन करेगा, अपने कार्य या अंतिम तिथि के कारण बफर जोड़ने के लिए अतिरिक्त आकलन करने की आवश्यकता नहीं है।

कौन

केवल वे लोग जो काम करते हैं, उन्हें साथ में आकलन करना चाहिए: दो महत्वपूर्ण बिंदु:

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

क्या

स्टोरी पॉइंट का आकलन करने के लिए प्लानिंग पोकर का उपयोग करें।

पोकर कार्ड और फिबोनाची अनुक्रम

दफिशर श्रृंखलाके एक दिलचस्प विशेषता है, और प्रत्येक संख्या पहली दो संख्याओं के योग के बराबर होती है। दूसरी ओर, संख्या और अगली संख्या के बीच अंतर जितना बड़ा होता है, उतना ही बड़ा अंतर होता है।

जैसा कि ऊपर दिखाया गया है, 8 और 13 के बीच का अंतर 5 है, और 13 और 20 के बीच का अंतर 7 है। हालांकि, यह आवश्यकता की जटिलता के आकलन से कैसे संबंधित है? हम गणित की कक्षा में नहीं हैं।

फिबोनाची अनुक्रम से संबंधित आकलन की विशेषताएं

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

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

क्योंकि बड़ी संख्या के बीच का अंतर बड़ा है (फर्मी श्रृंखला के दो आगे और पीछे के मानों का अंतर अनुपात लगभग 1.618 के करीब है), इससे बचा जा सकता है कि “क्या इस जटिलता का मान 20 या 21 है?” का आकलन करने की आवश्यकता हो। “ यदि आपको 13 चाहिए, तो आपको 20 चाहिए, यदि आपको 40 चाहिए।

ऐसा अंतर समान आवश्यकता के आकलन में अंतर को उजागर कर सकता है, क्योंकि लगभग सभी अधिक तीन गुना बेहतर हैं। इस अनुपात को मानवों के लिए आपेक्षिक आकार का आकलन करना आसान है, इसलिए बहुत सारे नुक्कड़ और अनावश्यक पुनराकलन प्रक्रिया लागत को कम कर सकता है।

पोकर कार्ड में विशेष संख्याएं

इसके अलावा, ऊपर दिखाए गए चित्र में कुछ विशेष संख्याएं देखी जा सकती हैं, जो 0, अनंत और प्रश्न चिह्न हैं।

• 0 का अर्थ हो सकता है कि इस आवश्यकता को करने की आवश्यकता नहीं है, या इसे पहले ही पूरा कर लिया गया है।
• अनंतता का अर्थ है कि मांग स्पष्ट है, लेकिन अधिकतम संख्या से अधिक वाली मांग को बहुत छोटी आवश्यकताओं में विभाजित करने की आवश्यकता होती है।
• प्रश्न चिह्न इंगित करता है कि मांग स्पष्ट नहीं है और PO/PM को इसकी व्याख्या या स्पष्टीकरण करने की आवश्यकता है।

कैसे

1. सबसे पहले जटिलता की इकाई 1 को परिभाषित करें, जैसे एक तालिका के सम्पूर्ण प्रश्न का कार्य। चूंकि हमारी आकलन प्रक्रिया सापेक्ष आकार पर आधारित है, हम सबसे पहले तुलना के आधार को परिभाषित करते हैं, और टीम के आकलन के बाद तुलना के आधार बन जाता है।

2. मेजबान मांगों (जैसे उपयोगकर्ता कथा कार्ड) को आवाज में पढ़ता है ताकि सभी को मांगों की समझ हो और प्रत्येक व्यक्ति अपनी आकलित जटिलता प्रस्तुत करे। योजना पोकर का उपयोग करने का कारण यह है कि आप आकलित संख्याओं को एक साथ प्रस्तुत कर सकते हैं, बजाय इसके कि आप अपने आकलित नंबरों को चक्कर लगाएं। यह संख्याओं को बाहर निकालने में आसान होता है और इससे पिछली संख्याओं के प्रभाव के कारण पीछे वाले लोगों के परिणाम प्रभावित हो सकते हैं।

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

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

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

5. यदि संख्या अभी भी एक स्तर से अधिक के अंतर पर है, या यदि सहमति प्राप्त नहीं होती है, तो चरण 3 से 5 को दोहराएं जब तक सहमति प्राप्त नहीं हो जाती है।

फिर से, केवल वे लोग जो वास्तव में कार्य करते हैं या आवश्यकताओं को पूरा करते हैं, वे मतदान प्रक्रिया में भाग ले सकते हैं, और PO/PM हस्तक्षेप नहीं कर सकते हैं।

क्यों

इस आकलन तरीके के कई लाभ हैं:

1. जो व्यक्ति साथ में काम कर रहे हैं, वे एक उचित और वस्तुनिष्ठ आकलन परिणाम तय करते हैं, भागीदारी का अहसास करते हैं और कोई शिकायत नहीं करते हैं।
2. निर्णय का परिणाम PO और टीम के बीच सहमति है, जो भविष्य में बदले के रूप में घटनाओं के घटित होने को कम करेगा।
3. हर कोई आवश्यकता को समझ सकता है। भविष्य में, हर कोई आवश्यकता को पूरा करने वाले व्यक्ति के रूप में कार्य कर सकता है। जब समर्थन की आवश्यकता होती है, तो लोग एक-दूसरे की मदद या समर्थन कर सकते हैं।
4. इससे पहले कि आप इसे करें, आप उस भाग को स्पष्ट कर सकते हैं जो स्पष्ट नहीं है और जिसमें संदेह है।
5. इसे करने से पहले, आप टीम में काम करने का सबसे अच्छा और सबसे कुशल तरीका ढूंढ सकते हैं।
6. अगर पूरी टीम अविश्वसनीय व्यक्ति नहीं है, तो यह संख्या यह दर्शाती है कि आकलन टीम के बीच साझा है, और PO को मांग और आकलन के बीच के अंतर को समझने में मदद मिलती है।
7. आवश्यकताओं के बीच जटिलता के सापेक्ष आकार की तुलना करके, भविष्य के PO को एक इटरेशन में कितना काम पूरा किया जा सकता है, इसका वचन देने में सक्षम होगा, और तुलना के लिए आधार बनेगा।

निष्कर्ष

उपरोक्त आकलन प्रक्रिया के माध्यम से, ऐसा निर्णय खुला, पारदर्शी, वस्तुनिष्ठ और सहमति से लिया गया है। दो भूमिकाओं के लिए:

PO/PM के लिए:

• कुछ सदस्यों द्वारा बफर के लिए कार्य का अतिरिक्त आकलन करने के बारे में चिंता न करें।
• आकलन प्रक्रिया में आवश्यकताओं या कार्यों को लागू करने की आंतरिक कठिनाई को समझना।
• यह समझना कि क्या आवश्यकता के किसी भाग को स्पष्ट रूप से बताने की आवश्यकता है या गलत तरीके से समझा गया है।

टीम के लिए:

• जो लोग अब काम नहीं कर रहे हैं, उन्हें अनुपयुक्त समय सीमा निर्धारित की जाती है जो अंतिम तिथि के अनुसार होती है।
• कार्य करने से पहले डेवलपर्स के बीच ज्ञान का आदान-प्रदान। आकलित संख्या बढ़ी या घटी हो, आवश्यकता अधिक स्पष्ट होती है और आकलन अधिक वस्तुनिष्ठ होता है।
• क्योंकि आप अभी भी नहीं जानते कि यह कार्य किसने लिया है, इसलिए आकलन प्रक्रिया को वस्तुनिष्ठ और टीम की सहमति के साथ प्राप्त किया जा सकता है, आप इस प्रक्रिया के माध्यम से जान सकते हैं कि कौन इस कार्य से परिचित है। जब आप इसे वास्तव में करते हैं, तो आप पेयर प्रोग्रामिंग कर सकते हैं या जान सकते हैं कि किससे मदद मांगनी है।

इस पत्र में प्रस्तावित समाधान एक सामान्य समाधान है। फोकस रूप पर नहीं है, बल्कि एजाइल आकलन प्रक्रिया के प्रत्येक चरण के डिजाइन उद्देश्य पर है, ताकि किस प्रकार की समस्या का समाधान किया जा सके।

स्क्रम तकनीकों में लेख

• स्क्रम इवेंट्स क्या हैं?
• स्क्रम समारोह क्या हैं?
• प्रोडक्ट बैकलॉग ग्रॉमिंग क्या है?
• डेली स्क्रम में 3 महत्वपूर्ण प्रश्न क्या हैं?
• 8 चरणों में स्क्रम स्प्रिंट चक्र
• स्क्रम में स्प्रिंट क्या है?
• स्क्रम का हृदय — डेली स्टैंडअप
• डेली स्क्रम मीटिंग — एक त्वरित मार्गदर्शिका
• स्क्रम में निश्चित लंबाई के स्प्रिंट क्यों?
• स्क्रम रिलीज योजना क्या है?
• स्प्रिंट योजना क्या है?
• स्प्रिंट समीक्षा क्या है?
• स्क्रम में स्प्रिंट रिट्रोस्पेक्टिव मीटिंग क्या है?
• प्रोडक्ट बैकलॉग रिफाइनमेंट क्या है?
• स्क्रम में निरंतर एकीकरण / डिलीवरी / डेप्लॉयमेंट क्या हैं?
• स्क्रम में समय-बॉक्स इवेंट्स क्या हैं?
• स्क्रम में स्पाइक क्या है?
• एजाइल में प्लानिंग पोकर क्या है?

यह पोस्ट Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 और 繁體中文 में भी उपलब्ध है।