Story Point निरर्थक हैं, Queue को मापिए

 (brightball.com)
7 पॉइंट द्वारा GN⁺ 2024-07-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Story Point पूरी तरह भरोसेमंद नहीं हैं, भ्रम पैदा करते हैं, और संबंधित लोगों को लगातार उनका अर्थ याद दिलाना पड़ता है
    • कम point value अपेक्षाकृत अधिक सटीक होती हैं, लेकिन बड़े point value अधिक variability मानते हैं और एक range को दर्शाते हैं, इसलिए उन्हें सटीक रूप से जोड़ा नहीं जा सकता
    • Story Point समय को नहीं दर्शाते, लेकिन जब इन्हें velocity metrics के साथ जोड़ा जाता है, तो वे व्यवहार में समय का अर्थ लेने लगते हैं, जिससे शुरुआत से ही numbers और ranges को जोड़ने की क्रिया बिगड़ जाती है
  • Software estimation कठिन है, और इस process का output आम तौर पर input की तुलना में बहुत उपयोगी नहीं होता
  • कम व्यवधान वाली छोटी teams ऐसा दिखती हैं मानो वे सटीक अनुमान लगा रही हों, इसलिए ज़्यादातर मामलों में यह आभास बनता है कि उनका काम ठीक चल रहा है
  • जब capacity पूरी तरह उपयोग हो जाती है, तो हर काम की variability तेज़ी से बढ़ जाती है, और इसका असर सभी estimates और timelines पर अचानक पड़ता है
  • Measured queue अल्पकालिक और दीर्घकालिक estimation समस्याओं को हल करती है, scope change को स्वाभाविक रूप से संभालती है, uncertainty को हटाती है, और बड़ी teams के लिए कहीं अधिक मूल्यवान अभ्यास प्रदान करती है
  • Measured queue velocity या cycle-time संबंधित metrics की तुलना में 20 गुना तेज़ी से समस्याओं का अनुमान लगाने वाला leading indicator देती है

Story Point क्या हैं?

  • Atlassian के अनुसार, Story Point एक ऐसी unit है जो product backlog item या किसी अन्य task को पूरी तरह implement करने के लिए आवश्यक कुल effort के अनुमान को व्यक्त करती है
  • Point complexity, काम की मात्रा, risk या uncertainty, और task के आकार को दर्शाते हैं
  • Complexity का मापन सापेक्ष होता है, इसलिए अलग-अलग teams एक ही काम को अलग तरह से आँक सकती हैं
  • Points की relative प्रकृति के कारण teams के बीच तुलना अर्थहीन है, और management स्तर पर यह अक्सर समस्या बनती है

अंतर्निहित variability

  • Story Point Fibonacci sequence पर आधारित होते हैं, इसलिए value जितनी बड़ी होती है, variability उतनी ही अधिक दर्शाई जाती है
  • अधिक variability वाले point values को जोड़ना अर्थहीन है, और velocity metric में points को जोड़ना गलत है
  • Goodhart's law के अनुसार, जैसे ही कोई measurement लक्ष्य बन जाता है, वह measurement अच्छा measurement नहीं रह जाता

ज्ञात समस्याएँ

  • Story Point की समस्याएँ अच्छी तरह ज्ञात हैं, लेकिन वैकल्पिक estimation techniques भी मिलती-जुलती समस्याओं से जूझती हैं, इसलिए इनका उपयोग अब भी जारी है
  • Story Point के रचयिता Ron Jeffries ने स्वयं इससे दूरी बनाई है और इसके दुरुपयोग की आलोचना की है
  • Scrum में "Commitment" को "Forecast" में बदला गया, फिर भी इसका गलत उपयोग जारी है
  • अनुमान से अधिक काम पूरा कर देने पर भी उल्टा डाँट पड़ने जैसी विरोधाभासी स्थिति बन जाती है

ROI के आधार पर प्राथमिकता तय करना

  • Business resources (समय, पैसा, tools, लोग) को optimize करने के लिए कामों की priority तय करता है
  • Development estimation निवेश लागत की गणना के लिए ज़रूरी है, लेकिन estimation स्वयं कठिन और महँगी होती है
  • Software Estimation: Demystifying the Black Art estimation की कठिनाई पर एक बेहतरीन पुस्तक है

Process का output

  • Story Point estimation process में बहुत समय लगता है, लेकिन उसका output मूल्यवान नहीं होता
  • नियमित grooming sessions समय लेने वाले होते हैं और teams के बीच बिना किसी consistency के अलग-अलग तरह से लागू किए जाते हैं
  • Story Point की जगह अर्थपूर्ण task list बनाना अधिक मूल्यवान है

विकल्प का प्रस्ताव

  • T-shirt sizing से अनुमान लगाना एक बेहतर विकल्प हो सकता है, लेकिन इसमें भी समस्याएँ हैं
  • समय के आधार पर estimation में भी समान समस्याएँ हैं, क्योंकि team वास्तव में जितना समय काम करती है और business जिस समय की अपेक्षा करता है, उनमें अंतर होता है
  • छोटी teams में time estimation अच्छी तरह काम कर सकती है, लेकिन team बड़ी होने पर estimation की सटीकता घटती जाती है
  • Donald Reinertsen की पुस्तक "The Principles of Product Development Flow" एक विकल्प प्रस्तुत करती है
    • मुख्य बात queue management पर ध्यान देकर काम के flow को optimize करना है
    • Capacity planning करना और variability को समायोजित करने के लिए buffer capacity सुरक्षित रखना ज़रूरी है

समाधान

  • शुरुआत इस बात से होती है कि team मिलकर काम का विश्लेषण करे, उसे छोटे task units में बाँटे, और uncertainty को हटाए
  • Task list एक queue बन जाती है, और tasks की कुल संख्या काम की मात्रा (Job Size) को दर्शाती है
  • Story Point की जगह Average Task Rate का उपयोग estimation के लिए किया जाता है
  • औसत कार्य गति के आधार पर काम को track किया जाता है और task completion rate की गणना की जाती है
  • नई जानकारी या feedback के अनुसार tasks अपडेट करने पर estimation स्वाभाविक रूप से समायोजित हो जाता है
  • Developers को estimation से जुड़े मनोवैज्ञानिक दबाव का सामना नहीं करना पड़ता

Queue एक leading indicator है

  • Average task completion rate, Cycle Time, Velocity आदि lagging indicators हैं, जबकि Queue एक leading indicator है
  • Queue का आकार बढ़ने पर समस्याओं को पहले से पहचानकर उन पर प्रतिक्रिया दी जा सकती है

सारांश

  • Story Point भ्रम पैदा करते हैं, भरोसेमंद नहीं हैं, और विफल होने के लिए ही बने हुए लगते हैं
  • इसके बजाय team का साथ मिलकर समस्या को समझना, uncertainty हटाना, काम को tasks में बाँटना, और Queue को manage करने में समय लगाना अधिक सार्थक और मूल्यवान है

GN+ की राय

  • लेख में प्रस्तुत queue management का तरीका agile development में estimation की कठिनाइयों से निपटने के लिए एक व्यावहारिक विकल्प लगता है
  • हालांकि tasks को बहुत छोटे हिस्सों में बाँटने की प्रक्रिया developers के लिए मेहनतभरी हो सकती है, और project के शुरुआती चरण में इसमें अधिक समय लग सकता है
  • साथ ही, task analysis process में developers की सक्रिय भागीदारी और खुलकर राय देने की प्रवृत्ति पहले से मानकर चलनी होगी
  • दूसरी ओर, इससे यह सकारात्मक प्रभाव भी हो सकता है कि development team business requirements को गहराई से समझे और उन पर मिलकर विचार करे

संबंधित पढ़ाई

2 टिप्पणियां

 
heal9179 2024-07-19

क्या वह Kanban methodology नहीं है..?
 
GN⁺ 2024-07-17
Hacker News राय

  • मेरे व्यक्तिगत अनुभव में स्टोरी पॉइंट्स की संख्या महत्वपूर्ण नहीं थी, लेकिन टीम द्वारा काम की जटिलता का आकलन करने की प्रक्रिया बहुत उपयोगी थी

    • काम के समय का अनुमान लगाने के लिए स्टोरी पॉइंट्स का उपयोग एक भरोसेमंद मेट्रिक नहीं था
    • टीम और डोमेन में बदलाव, डेवलपमेंट के बाहर के काम की परिवर्तनशीलता आदि कई कारणों से मैं स्टोरी पॉइंट्स से बचने की कोशिश करता था
    • जिन टीमों में स्टोरी पॉइंट्स का उपयोग होता था, वहाँ इन्हें काम की समझ साझा करने के एक टूल के रूप में इस्तेमाल किया जाता था

  • Scrum गाइड में "Commitment" को "Forecast" में 2011 में नहीं बदला गया था

    • 2010 और 2011 गाइड की जाँच करने पर पता चला कि "Commitment" शब्द 2011 से पहले के संस्करणों में था ही नहीं
    • "Forecast" ने 2020 गाइड में "Estimate" की जगह ली

  • काम के पैकेजों को atomic units में तोड़ना और queue length मापना एक अलग स्तर का मुद्दा है

    • टीम के साथ work packages को refine करते समय स्टोरी पॉइंट्स का उपयोग किया जा सकता है
    • सभी कामों को 1 स्टोरी पॉइंट में तोड़ना अक्षम था
    • queue length और variability के प्रभाव को जोड़ना एक दिलचस्प अवधारणा है

  • कुछ मामलों में waterfall तरीका और समय-आधारित estimation अच्छी तरह काम करता है

    • छोटे specialized services टीम में customer requirements को document करने और टीम के साथ चर्चा करने के बाद time range के रूप में estimate किया जाता है
    • ग्राहक की मंजूरी के बाद detailed design, development, QA, और release की प्रक्रिया से गुजरा जाता है
    • 20 साल से प्रक्रिया नहीं बदली और टीम को high-productivity टीम माना जाता है

  • स्टोरी पॉइंट्स समय की इकाई नहीं बल्कि relative complexity और uncertainty को दर्शाते हैं

    • स्टोरी को बड़े numbers से मापा जा सकना चाहिए
    • कुछ टीमों में 7 से अधिक points नहीं दिए जाते
    • दूसरी जगहों पर 21, 30, 50 points भी दिए गए हैं

  • स्टोरी पॉइंट्स मोटे तौर पर समय की इकाई जैसे ही थे

    • स्टोरी पॉइंट्स को किसी स्पष्ट समय इकाई से बांधना भ्रामक हो सकता है
    • यह अनुमान लगाना महत्वपूर्ण है कि डेवलपर किसी काम पर कितना समय लगाएगा
    • queue analysis के उपयोगी होने के लिए हर task का expected time पता होना चाहिए

  • जब मैंने पहली बार Scrum का उपयोग किया, तब Rally इस्तेमाल किया था

    • स्टोरी पॉइंट्स, estimated time, और actual time सभी को track किया जाता था
    • Jira पर स्विच करने के बाद time tracking खत्म हो गई
    • expected time अधिक सटीक होने पर टीम के काम का संतुलन बैठाना आसान हो गया

  • स्टोरी पॉइंट्स काम की जटिलता पर चर्चा करने में उपयोगी हैं, लेकिन velocity मापने के लिए उपयुक्त नहीं थे

    • एक नए engineer के रूप में मैंने बहुत सारे स्टोरी पॉइंट्स पूरे किए, लेकिन management ने इसे adjust करने की कोशिश की
    • जटिल कामों का उचित आकलन करना कठिन था

  • software development projects का भरोसेमंद अनुमान लगाना कठिन है

    • टीम के साथ काम को छोटे units में बाँटना और time range का अनुमान लगाना महत्वपूर्ण है
    • project आगे बढ़ने के साथ feature list और नए estimation range की रिपोर्ट करना महत्वपूर्ण है

  • समय-आधारित estimation बेहतर तरीका है

    • स्टोरी पॉइंट्स अंततः समय इकाई में बदल ही जाते हैं
    • Scrum की जटिल प्रक्रिया से बचकर काम पूरा करना अधिक कुशल है