पूर्ण होने की परिभाषा

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

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

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

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

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

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

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

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

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