क्लाइंट-सर्वर एप्लिकेशन के विकास के लिए स्टोरी पॉइंट खतरनाक हैं

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

हमारी टीम में एक विश्लेषक, परीक्षक, डिजाइनर और 2 डेवलपर्स शामिल थे, हालांकि, अधिक स्पष्टता के लिए, हम केवल डेवलपर्स को छोड़ देते हैं।

हम एक नया स्प्रिंट शुरू करते हैं और सुचारू रूप से उपयोगकर्ता कहानियों के मूल्यांकन के लिए आगे बढ़ते हैं। कोई नई बात नहीं। आगे बढ़ो ...

योजना पूरी हो गई है और परिणाम ऊपर देखे जा सकते हैं। उन्होंने क्रमशः 16, 20 और 37 कहानी बिंदुओं पर 3 उपयोगकर्ता कहानियों का मूल्य लिया। कुल - 73।

इसके अलावा, किसी भी स्वाभिमानी विकास दल की तरह, जो स्क्रैम पर काम करने के सभी प्रसन्नता को स्वीकार करता है, हम इन रेटिंग्स को जीरा से जोड़ते हैं। उसी समय, हम प्रत्येक कहानी के लिए केवल सामान्य (या औसत - और भी बदतर!) का परिचय देते हैं।

कीबोर्ड से अपने हाथों को हटाने के बिना और दो साल तक कार्यालय की कुर्सी से उठे बिना दो सप्ताह का काम, आप नई बनाई गई कार्यक्षमता पर विचार कर सकते हैं।

पर बात क्या है? स्प्रिंट खत्म हो गया है और हम देखते हैं कि सामने वाले ने सब कुछ योजना के अनुसार किया है और उसके पास कोई और कीस्ट्रोक करने का समय नहीं है, और पीछे स्प्रिंट से आगे निकल गया और उसने योजना के मुकाबले अधिक कार्य किए।

और फिर ट्रेंस पीएम से स्क्रैम और एक्सपी, जिन्होंने अभी-अभी पढ़ना समाप्त किया है, प्रकट होता है और कहता है: “सब कुछ स्पष्ट है !!! हमें अगले स्प्रिंट के लिए और अधिक बिल्डिंग पॉइंट लेने होंगे और फिर सब कुछ ठीक हो जाएगा और कोई भी बैकिंग मेरे पास से नहीं भागेगा, उनके साथ स्कूपिंग !!

हम एक नए स्प्रिंट की योजना बना रहे हैं ...।

बहुत बढ़िया! 10 स्टॉर पॉइंट्स ज्यादा लिए गए !!! अब हमने सुनिश्चित करने के लिए सब कुछ गणना की है !!

एक और 2 सप्ताह जल्दी से उड़ते हैं और यह स्टॉक लेने का समय है।

लेकिन सभी के खेद के बाद, स्प्रिंट पूरी तरह से अलग तरीके से समाप्त हो गया, जैसे हम चाहते हैं।

किसी कारण से, पीठ ने फिर से आगे खींच लिया, और सामने वाले के पास ऐसा करने के लिए समय नहीं था जो उन्होंने योजना बनाई थी (संभावना है कि सामने सिर्फ एक अनुभवहीन जून है, और हम पीछे अछूत सीनेटर को कम कर देंगे और कल्पना करेंगे कि पूरी बात केवल गलत नियोजन में है)।

एक और स्प्रिंट एक विफलता थी !!! लेकिन क्यों, हमने सर्वर के पक्ष में काम करने के लिए आवश्यक राशि देने के लिए, केवल अच्छे उद्देश्यों के लिए कुछ और स्टोरीपॉट्स लिए हैं और ??

ये कैसे हो सकता है ?? जवाब सभी मूल्यांकन प्रणाली के बारे में ही है। वापस हमारे स्प्रिंट के लिए।

हम क्या देखते हैं? यह पता चला है कि पीठ को लोड करने के लिए नए स्प्रिंट पर अधिक स्टॉपर पॉइंट्स लेना, हमने बस सामने लोड किया।

इसे समझने के बाद, पीएम के पागल सिर में पहला विचार यह पता लगाना है कि सामने वाले ने कितने स्टोरी पॉइंट्स लिए हैं और कितने बैकिंग हैं। लेकिन जीरा में समग्र ग्रेड को देखना केवल संभव नहीं है, क्योंकि आप सभी को पता लगा सकते हैं कि प्रत्येक कहानी के लिए समग्र (अच्छी या औसत) ग्रेड है, और याद रखें कि कौन सा ग्रेड अब संभव नहीं है।

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

मुझे यकीन है कि एटलसियन डेवलपर्स इस समस्या के समाधान के लिए आएंगे, लेकिन अभी के लिए, बस हमारी गलतियों को दोहराएं नहीं!

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