चंचल विकास में परावर्तन
ऐप डेवलपमेंट प्रोजेक्ट में, ऐप डिज़ाइन में प्रोजेक्ट के पूर्ण दायरे पर विचार नहीं किया गया था। इसलिए, परिवर्तनों को समायोजित करने के लिए कोडों का लगातार रिफैक्टिंग परियोजना की डिलीवरी की समयावधि को नकारात्मक रूप से प्रभावित कर रहा है, जो स्प्रिंट के दौरान आवश्यक हो गया है। परियोजना वितरण की सहमति की तिथि को कम करने के जोखिम को कम करने के लिए यह सबसे अच्छा कैसे नियंत्रित किया जा सकता है, क्योंकि हितधारक समझौता करने के लिए तैयार नहीं हैं?
जवाब
टी एल; डॉ
किसी भी परियोजना प्रबंधन ढांचे का हिस्सा, लेकिन विशेष रूप से स्क्रम की तरह फुर्तीली रूपरेखा, हितधारक अपेक्षाओं को लगातार प्रबंधित करने की आवश्यकता है। लोग चाहते हैं कि वे जब चाहते हैं, लेकिन परियोजना प्रबंधन का एक बड़ा हिस्सा लोगों को समझा रहा है कि परियोजना को प्रभावित करने वाली विभिन्न बाधाओं के भीतर वास्तव में उनके पास क्या हो सकता है । जैसा कि यह परियोजना विकसित होती है, इसलिए तत्कालीन-वर्तमान बाधाओं के भीतर वर्तमान में क्या संभव है, इसकी समझ होनी चाहिए, खासकर जब मूल रूप से जो योजना बनाई गई थी, उससे क्या संभव है।
वर्क की उम्मीद है
पुनर्रचना बाहरी व्यवहार को बदलने के बिना कार्यान्वयन बदल जाता है। सभी संभावना में, आप वास्तव में refactoring नहीं हैं; आप तकनीकी ऋण का भुगतान कर रहे हैं, या फिर से काम और एकीकरण कर रहे हैं, जो आंतरिक रूप से समान चीजें नहीं हैं।
स्क्रैम जैसे फ्रेमवर्क विभिन्न प्रकार के काम (रिफ्लेक्टरिंग और रीवर्क सहित) को अनुभवजन्य नियंत्रण और डिजाइन के लिए स्वीकार्य व्यापार के रूप में मानते हैं। यह अनुमान प्रक्रिया में संभाला जाता है, और (सही ढंग से) तकनीक ऋण, जटिलता या परिवर्तन की गति के रूप में वेग पर खींचें के रूप में दिखाता है। यह एक पुनरावृत्त ढांचे में अपेक्षित और वांछनीय दोनों है , क्योंकि प्रत्येक निरीक्षण-और-अनुकूल लूप गुंजाइश, प्राथमिकता, या दृष्टिकोण को बदलने का अवसर प्रदान करता है।
अनुष्ठान अनुभवजन्य नियंत्रण की लागत है। सॉफ्टवेयर डेवलपमेंट जैसी जटिल परियोजनाओं में आप वास्तव में इससे बच नहीं सकते। स्क्रम सिर्फ टीम में और हितधारकों को आवश्यक या वांछनीय परिवर्तन करने की लागत के रूप में दिखाई देने वाले कार्य को बनाता है ।
फिक्स्ड-सब कुछ संभव नहीं है
"लौह त्रिकोण" का मानना है कि आप बजट, गुंजाइश, या अनुसूची के लिए नियंत्रित करके एक परियोजना को समायोजित कर सकते हैं, गुणवत्ता के साथ अन्य तीन स्लाइडर्स द्वारा प्रभावित एक चतुर्थ आयाम है। निम्नलिखित ग्राफिक में यह दर्शाया गया है।
स्क्रम जैसी चुस्त रूपरेखा आमतौर पर स्कोप और मुख्य रूप से प्रॉजेक्ट स्कोप को मुख्य स्लाइडर के रूप में पूछती है:
हम एक एकल स्प्रिंट के टाइम बॉक्स में कितना स्कोप कर सकते हैं, या हमारी फुर्तीली रिलीज़ योजना में फिट हो सकते हैं ?
वर्तमान में, आपकी परियोजना गुंजाइश और शेड्यूल दोनों को ठीक करने का प्रयास कर रही है। यह केवल आपके उपलब्ध स्लाइडर के रूप में बजट छोड़ता है। यदि आप उसे भी बंद करने का प्रयास करते हैं, तो या तो आपकी परियोजना विफल हो जाएगी, या गुणवत्ता को नुकसान होगा, या दोनों। आप बस गुणवत्ता को बनाए रखते हुए किसी भी परियोजना के ढांचे में निश्चित मूल्य, निश्चित गुंजाइश और निश्चित अनुसूची नहीं कर सकते हैं ; स्क्रम बस इसे और अधिक स्पष्ट करता है, और व्यापार-बंद को अधिक स्पष्ट बनाता है।
Scrum की बात जादुई रूप से लोहे के त्रिकोण को गायब नहीं करना है। इसके बजाय, यह परियोजना (साथ ही हितधारकों और प्रायोजकों) को निहित व्यापार-बंदों के साथ आने के लिए मजबूर करता है। Scrum हितधारकों को यह निर्धारित करने में सक्षम बनाता है कि प्रत्येक स्प्रिंट के अंत में जहाज करने के लिए कुछ "अच्छा पर्याप्त" है, और उत्पाद स्वामी को बैकलॉग शोधन और स्प्रिंट योजना के दौरान गुंजाइश और प्राथमिकता को समायोजित करने का अवसर मिलता है। हितधारकों को इन घटनाओं का लाभ उठाने की जरूरत है ताकि यह सुनिश्चित किया जा सके कि वे रिलीज योजना के भीतर सबसे अधिक मूल्य प्राप्त कर सकें; यह कभी भी धन-वापसी की गारंटी नहीं है कि स्प्रिंट की एक निश्चित श्रृंखला के अंत में परियोजना 100% पूर्ण या फिट होगी।
घट सनक लागत
चुस्त विकास का एक अन्य पहलू "जल्दी असफल होने" का अवसर है। जब किसी कारण से किसी परियोजना के विफल होने की संभावना होती है, तो स्क्रम जैसी चुस्त रूपरेखा उत्पाद मालिक को स्प्रिंट को रद्द करके और बदले हुए अपेक्षाओं के आधार पर एक नई योजना बनाकर, या हितधारकों को परियोजना के शेष को रद्द करने की अनुमति देने का अवसर देती है। उनके उद्देश्यों की सेवा नहीं करेगा। उत्तरार्द्ध परियोजना को सफल नहीं बनाएगा, लेकिन यह परियोजना से जुड़े डूब लागत को कम करेगा।
कोई भी कुछ भी गारंटी नहीं देता है कि एक परियोजना सफल होगी। आप जो सबसे अच्छा कर सकते हैं, वह इसके लिए नियंत्रण है, और जल्द से जल्द एक बर्बाद परियोजना को मारना जब सफलता अब कोई विकल्प नहीं है।
अब आप क्या कर सकते हैं
सबसे पहले, स्वीकार करें कि आप मौत के रास्ते पर हैं। यदि आप उस सच्चाई का सामना नहीं करेंगे, तो आप जो कुछ भी करेंगे, वह मायने नहीं रखेगा।
इसके बाद, यह पता लगाएँ कि क्या समस्या डिज़ाइन, तकनीकी ऋण, अनुचित अपेक्षाएँ, या कुछ और है। इससे कोई फर्क नहीं पड़ता कि मूल कारण या कारण क्या हैं; आपको बस उन्हें दिखाई देना है ताकि टीम और हितधारक उन्हें सहयोग कर सकें।
अंत में, वर्तमान स्थिति को स्पष्ट रूप से संवाद करें। यदि आप मूल रूप से अनुमानित डिलीवरी की तारीख से पहले कुछ पूर्ण-रिलीज़ रिलीज़ के लिए गति पर हैं, तो चर्चा करें कि क्या परियोजना "समय" शीर्ष को समायोजित कर सकती है। यदि आप शेड्यूल को समायोजित नहीं कर सकते हैं या नहीं कर सकते हैं, तो आप अभी भी लागत या दायरे को कम करके निश्चित समय सीमा को पूरा कर सकते हैं। क्या हितधारक थोड़े समय की कार्यक्षमता की कटौती के लिए समय पर डिलीवरी का व्यापार करेंगे? जब तक आप पूछेंगे आपको पता नहीं चलेगा।
यदि परियोजना ऊपर दी गई चीजों में से कोई भी नहीं कर सकती है या नहीं करेगी, तो असफलता के लिए तैयार रहें। अपने रिज्यूमे को ब्रश करें, और आशा करें कि आपने बहुमूल्य सबक सीखे हैं जिनका उपयोग आप अपनी अगली परियोजना या अगली नौकरी पर कर सकते हैं। सबसे अधिक, आशा है कि आपने मान्यताओं, चुनौतियों, रूपरेखा आवश्यकताओं और व्यापार-बंदियों के बारे में जल्दी और अक्सर संवाद करना सीख लिया है, और निरंतर-प्रबंधन हितधारकों की अपेक्षाओं के महत्व को आंतरिक कर दिया है।
क्या आप प्रत्येक स्प्रिंट उत्पाद की तैनाती में वृद्धि कर रहे हैं? यदि ऐसा है तो सहमत डिलीवरी की तारीखें पहले से ही पूरी हो रही हैं और जोखिम को कम करने और आप जो कर रहे हैं उसमें ग्राहक को विश्वास देने का सबसे अच्छा तरीका है। हितधारकों (उत्पाद स्वामी के माध्यम से) को यह तय करना चाहिए कि उन्हें कौन सी चीजें चाहिए और कब, इसलिए सबसे महत्वपूर्ण यह है कि वे आपको मूल्य वितरित करते हुए देखते रहें और आपको उत्पाद में सुधार, परिवर्तन और सुधारों के बारे में उनकी प्रतिक्रिया मिलनी चाहिए। उनकी प्रतिक्रिया प्राप्त करना यहां महत्वपूर्ण है। अगर समयरेखा बिना किसी नए कार्यात्मक दायरे के साथ विस्तारित होती है, तो ग्राहक काफी चिंतित हो सकते हैं, लेकिन जैसे ही आप नवीनतम सुधारों को शुरू करते हैं, जिन्हें वे प्राथमिकता के रूप में देखते हैं, वे लचीलेपन की आवश्यकता की सराहना करने की अधिक संभावना होगी।