यह एक जटिल विषय है, और इस विषय पर अक्सर बहस होती है। मुझे इस पर "विहित" राय की अवधारणा पसंद नहीं है: मूल्य के साथ विभिन्न राय हैं। लेकिन सहायक मूल्य, सिद्धांत और व्यवहार हैं जो दृष्टिकोण का मार्गदर्शन करना चाहिए।
निम्नलिखित 10 वर्षों के लिए स्क्रैम टीमों के साथ काम करने वाले मेरे अपने विचारों पर आधारित है। लेकिन यह सिर्फ मेरी राय है।
एक पूर्वानुमान पद्धति के रूप में स्टोरी पॉइंट्स स्टोरी पॉइंट्स का मूल आशय यह है कि किसी टीम को एक समय के दौरान पूरा करने के पूर्वानुमान के उद्देश्य से प्रयास का अनुमान लगाने के लिए एक त्वरित तरीका खोजना चाहिए। "ल्यूमिनेयर" स्थिति में से कुछ का उपयोग केवल लंबी अवधि के दायरे (उदाहरण के लिए, एक उदाहरण पर) का अनुमान लगाने के लिए किया जाता है, और स्प्रिंट स्तर पर क्षमता का निर्धारण करने के लिए नहीं। इसके अतिरिक्त, अवधारणा यह है कि टीमें ऐतिहासिक मूल्यों के आधार पर "सापेक्ष आकार" लागू कर रही हैं (एफ़ोर्ट एक्स एफ़र्ट बी के समान है, जो 3 अंक था)। यह अनुमान लगाने की प्रक्रिया को गति देता है ताकि टीमों को भविष्य के काम को विस्तृत कार्य पैकेजों में तोड़ना न पड़े और सभी कार्यों के लिए घंटे लागू हों। उच्च प्रदर्शन वाली टीमें सभी तकनीकी कर्मचारियों को समान कौशल स्तरों के बहुत सक्षम सदस्यों में विकसित करने का प्रयास करती हैं। (इस अवधारणा को बिंदु # 4 में अधिक खोजा जाएगा) जब यह हासिल किया जाता है, तो व्यक्तिगत कौशल का स्तर वास्तव में आकार देने में परिवर्तनशील नहीं होता है। लेकिन: यह आमतौर पर उस लक्ष्य को प्राप्त करने के लिए काफी लंबा समय और ठोस प्रयास करता है। एसओ ... वहां पहुंचने से पहले हम क्या करते हैं?
टास्क घंटे स्प्रिंट क्षमता का निर्धारण करते हैं: उसी "ल्यूमिनरीज़" के अनुसार जो बताते हैं कि पॉइंट्स का उपयोग दीर्घकालिक पूर्वानुमान के लिए किया जाता है, वे यह भी प्रस्ताव करते हैं कि पॉइंट के बजाय स्प्रिंट क्षमता का निर्धारण करने के लिए टास्क ऑवर का उपयोग किया जाए। मेरी राय में, यह ठीक है, लेकिन मैं कहूंगा कि जब मैंने कोच टीमों को "हाई-परफॉर्मेंस" में मदद की है, तो उनके लेवल-आउट स्किल्स का औसतन पता चला है कि वे कहानी के बिंदुओं का उपयोग करके स्प्रिंट में जो पूरा कर सकते हैं, उसे सटीक रूप से निर्धारित कर सकते हैं। । फिर से, यह एक उद्देश्य हो सकता है जिसकी ओर हम प्रयास करते हैं, लेकिन नई टीमें इसके लिए तैयार नहीं हैं। इसलिए, आप एक एकल स्प्रिंट स्टोरी में 2 अंक के साथ 12 कार्य घंटों का प्रयास कर सकते हैं, और दूसरा 25 घंटे के प्रयास के साथ मिल सकता है। तो तुम क्या करते हो? कुछ लोग जिन्हें मैं "फुर्तीला-शुद्धतावादी" कहता हूं, यह बताएंगे कि कहानी का आकार (अंकों में) अवधि के लिए अज्ञेय होना चाहिए। दूसरे असहमत हैं। आइटम # 3 पर तर्क के माध्यम से पढ़ें और देखें कि आप क्या सोचते हैं।
- आम सहमति से कहानी-संकेत करना: वॉल्यूम, अज्ञात, जटिलता, ज्ञान को लागू करना
इसलिए टीमें काम का एक टुकड़ा देखती हैं और उन बिंदुओं पर सहमत होने की आवश्यकता होती है जो लेवल ऑफ एफर्ट के लिए एक प्रॉक्सी होगी। सही? यह मानते हुए कि सभी कौशल समान हैं, फिर आम सहमति तक पहुंचना आसान है। लेकिन अक्सर टीमों में एक लड़का होता है जो एक जावा गुरु है, दूसरा जो जावा में इतना महान नहीं है (शायद वह एक सी # या। नेट या कोबोल व्यक्ति था और जावा सीख रहा है)। इसलिए बॉब के लिए टास्क एक्स बहुत सरल है। जेन के लिए, यह अधिक कठिन है।
फुर्तीली टीमें सामूहिक कोड स्वामित्व और बढ़ती / विस्तारित विशेषज्ञता को बढ़ावा देने की कोशिश करती हैं। इसलिए हम आमतौर पर लोगों को उनकी विशेषज्ञता के आधार पर कहानियां नहीं देते हैं: हम टीमों को सामूहिक रूप से कहानियों पर काम करना और एक साथ सीखना पसंद करते हैं। यह "गति को धीमा करने" की अवधारणा के साथ संरेखित करता है: यदि हम जावा के साथ जेन अनुभव देने के लिए समय लेते हैं, जबकि यह हमें पहले धीमा कर सकता है, बाद में हमारे पास अधिक सक्षम जावा डेवलपर्स होंगे। वास्तव में, यदि हमारे पास केवल एक जावा विशेषज्ञ है, और हर कोई अपने स्वयं के विशेषज्ञता के क्षेत्रों पर काम करता है, तो हम कई संभावित "विफलता के बिंदु" के साथ एक स्थिति बना रहे हैं। 90% कार्य जावा होने पर स्प्रिंट में क्या होता है, लेकिन बॉब (हमारा जावा विशेषज्ञ) बीमार है या छुट्टी पर है? कौशल का विस्तार करके, हम संभावित बाधाओं को समाप्त करते हैं और जोखिम को कम करते हैं। ये ध्यान रखते हुए: जब टीम एक कहानी को देखती है तो उन्हें साइज़ करते समय कई अवधारणाएँ ध्यान में रखनी चाहिए। इसे याद रखने के लिए आप संक्षिप्त VUCK के बारे में सोच सकते हैं।
वॉल्यूम: कुछ प्रयास काफी सरल हैं, लेकिन बार-बार कार्यों की एक बड़ी मात्रा की आवश्यकता होती है। (मेरे पास एक आदमी था जिसे 50+ तालिकाओं की नकल और सुधार करना था जिन्होंने कहा कि यह 1 अंक था क्योंकि यह सरल था। लेकिन प्रतिबिंब पर टीम को एहसास हुआ कि जब यह आसान था, तो यह समय लेने वाला था और बड़ी मात्रा में तालिकाओं था। ले जाया और अनुकूलित किया जा रहा है। तो हम काम की मात्रा के कारण पढ़ने के लिए अंक)
अज्ञात: कभी-कभी हम सोचते हैं कि हमें पता है कि क्या करना है, लेकिन हम कुछ अज्ञात की भी पहचान करते हैं - ये RISKS का प्रतिनिधित्व करते हैं । और इसका तात्पर्य यह है कि हम अनपेक्षित मुद्दों में भाग सकते हैं जिन्हें हमें हल करना है, या एक अलग समाधान की कोशिश करनी है।
जटिलता: यह एक बहुत स्पष्ट है। कुछ समाधान तकनीकी रूप से जटिल हैं। हम जानते हैं कि क्या करना है, लेकिन इसके लिए तकनीकी विशेषज्ञता की आवश्यकता होती है। जटिलता भी कुछ जोखिम का मतलब है, है ना? यहां तक कि अगर हम सभी के पास समान कौशल हैं, तो तकनीकी जटिलता का अर्थ है कि हम अप्रत्याशित चुनौतियों में भाग सकते हैं। तो हम इस कहानी को बड़ा बना सकते हैं।
ज्ञान: क्या हम वास्तव में जानते हैं कि हम क्या हल कर रहे हैं? कभी-कभी ग्राहक अपने इच्छित समाधान पर पूरी तरह से स्पष्ट नहीं होते हैं, और हम थोड़ा प्रयोग कर रहे हैं। या शायद किसी ने भी इस समाधान को लागू नहीं किया है (नई तकनीक पहले कभी इस्तेमाल नहीं की गई थी) और इसलिए हम नहीं जानते कि हम क्या नहीं जानते हैं।
मेरी राय में, इन विचारों में से प्रत्येक वास्तव में विस्तारित अवधि के लिए एक प्रॉक्सी है। आसान कहानी, आयतन बहुत? इसमें अधिक समय लगेगा, या हमें कहानी को विभाजित करने की आवश्यकता है। अननोंस? जोड़ा गया जोखिम, अनुसंधान, प्रयोग, इसमें अधिक समय लग सकता है या हमें कहानी को विभाजित करने की आवश्यकता है। परिसर? जोड़ा गया जोखिम, कीड़े को ठीक करने की आवश्यकता है, आदि को फिर से तैयार करना चाहिए। क्या हमें आवश्यक ज्ञान नहीं है? हमारे पास अतिरिक्त जोखिम है, प्रयोग करने की आवश्यकता हो सकती है, आदि, इसलिए इसमें अधिक समय लग सकता है ...
देखें यह कहाँ जा रहा है? इसलिए जब कहानी की अवधारणा हमें अनुमान लगाते समय अवधि के बारे में सोचने से हतोत्साहित करती है, तो दूसरी ओर 1-बिंदु वाली कहानी के लिए यह अतार्किक होगा कि हम 4 घंटे में पूरा कर सकते हैं और एक और 1-बिंदु कहानी जो कि सरल है, लेकिन ले जाएगा 2 सप्ताह।
- उच्च प्रदर्शन वाली टीमें सिलोस और अड़चनों को खत्म करती हैं: क्योंकि टीमें सभी सदस्यों को समतल करने की कोशिश करती हैं, उनके पास कभी-कभी कम अनुभवी सदस्य होते हैं जो नई चुनौतियों का सामना करते हैं, या टीम के रूप में सुधार करने के लिए ज्ञान साझा करने के लिए जोड़ी-कोड करेंगे। जैसा कि पहले उल्लेख किया गया है, यह एक अपेक्षित है यदि टीम कभी भी उच्च प्रदर्शन वाले स्तरों तक पहुंच जाएगी।
तो अगर जेन स्वयंसेवक उस जावा प्रयास को लेते हैं और वह प्रयास 2x या 3x को एक ही प्रयास की अवधि में करेगा यदि बॉब यह करना चाहते हैं, तो आप क्या करते हैं? समय के साथ, मेरी टीमों ने प्रयास करने वाले लोगों के लिए प्रयास के स्तर (LOE) / VUCK के आधार पर कहानियों को आकार देने पर समझौता किया। यह बॉब के लिए कोई मतलब नहीं है, टीम गुरु, कहने के लिए "कि एक 1" है जब जेन के लिए यह आसान नहीं होगा और पूरा होने में एक सप्ताह लगेगा, साथ ही जोड़ी कोडिंग और कोड समीक्षा के लिए बॉब के कुछ समय की आवश्यकता है। इसलिए, हमने वास्तविक LOE को प्रतिबिंबित करने के लिए उन बिंदुओं को टकराया। अगली बार इसी तरह की एक कहानी आई, जेन के लिए एक 8 थी जो पहले एक 5. बन गई थी। आखिरकार, हर कोई इस बात से सहमत था कि यह एक आसान 3 है। उस समय, हम जानते थे कि हम एक टीम के रूप में बढ़ रहे थे।