फुर्तीली टीम और निश्चित मूल्य अनुबंध

फिक्स्ड प्राइस कॉन्ट्रैक्ट्स बुराई हैं, यह वही है जो चुस्त पालन से सुना जा सकता है। दूसरी ओर, ऐसे अनुबंध एक वास्तविकता हैं जो कई चुस्त टीमों का सामना करते हैं। लेकिन क्या होगा अगर हम इस बुराई पर काबू पाने की कोशिश करें, न कि उससे लड़ें?



कम जोखिम के साथ बेहतर परिणाम प्राप्त करने के लिए एक कंपनी एक लचीली कार्यप्रणाली का उपयोग करके इस तरह के अनुबंध को कैसे निष्पादित कर सकती है? इस लेख में हम इन सवालों के जवाब देने की कोशिश करेंगे।



तो चलो अनुबंध के साथ ही शुरू करते हैं।

निर्धारित मूल्य, समय और दायित्वों की मात्रा

ऐसे अनुबंध तुरंत तीन जादूई कारकों को ठीक करते हैं - धन, समय और दायित्वों की मात्रा। क्या कीमत और समय चुस्त टीमों के लिए एक समस्या है? खैर, नहीं होना चाहिए। वास्तव में, टाइमबॉक्सिंग एक आम बात है। बजट को सीमित करने से केवल टाइमबॉक्सिंग बेहतर काम करता है।



निश्चित मूल्य अनुबंधों के साथ वास्तविक समस्या दायित्वों की मात्रा है, क्योंकि यह आमतौर पर बताया जाता है कि वास्तव में हमें कितना काम करना चाहिए, इसके बजाय क्या करना चाहिए।



ग्राहकों को प्रतिबद्धता की एक निश्चित राशि के साथ क्यों देखा जाता है? हम समझते हैं कि वे जानना चाहते हैं कि उन्हें कितना भुगतान करना होगा (और कौन नहीं चाहता?) और जब उन्हें परिणाम मिलेगा। केवल एक चीज जो वे नहीं जानते हैं कि वे वास्तव में क्या प्राप्त करना चाहते हैं (भले ही वे कहते हैं कि वे जानते हैं)।



दायित्वों की निश्चित राशि के साथ समस्या की जड़ें इस प्रकार हैं:

• ग्राहक और ठेकेदार के बीच विश्वास की कमी
• सॉफ्टवेयर विकास प्रक्रिया की समझ का अभाव
• "दायित्वों की गुंजाइश" का अर्थ समझने में विफलता।

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



दायित्वों की मात्रा तय करते समय मुख्य गलत धारणाएं :

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

प्रतिबद्धता की एक निश्चित राशि से एक निश्चित बजट तक

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



इसका मतलब है कि आवश्यकताओं का एक विस्तृत विवरण प्रदान करने के बजाय, हमें उपयोगकर्ता कहानियों के रूप में यथासंभव अधिक से अधिक ट्रैकिंग पर ध्यान देने की आवश्यकता है। हमें उत्पाद के लिए कार्यों की एक प्रारंभिक सूची बनाने की जरूरत है, जिसे हम पोकर प्‍लानिंग (प्‍लानिंग पोकर) जैसे कठिनाई बिंदुओं (कहानी बिंदुओं) और टीम-वाइड मूल्यांकन तकनीकों का उपयोग करके मूल्यांकन करने का प्रयास करेंगे।



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



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



कहानियों का मूल्यांकन करने के तरीके के रूप में कठिनाई अंक (कहानी अंक) पहले ग्राहक को समझाना मुश्किल है, क्योंकि यह प्रयासों को व्यक्त करने का एक सामान्य तरीका नहीं है। लेकिन दूसरी ओर, वे दायित्वों की मात्रा को कम आंकने के जोखिम को कम करते हैं। यह कैसा चल रहा है? जटिलता स्कोर प्रकृति में सापेक्ष हैं, यहां ध्यान या तो कुल मात्रा पर है, या कहानियों के समूह पर है, जबकि पारंपरिक मूल्यांकन (आमतौर पर मैन-आवर्स में किया जाता है) प्रत्येक फ़ंक्शन का व्यक्तिगत रूप से विश्लेषण करने की कोशिश करता है।



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



उदाहरण के लिए, एक ताजा वेब एप्लिकेशन में कहानियों के लिए तत्परता मानदंड में निम्नलिखित आइटम शामिल हो सकते हैं:

• IE 7/8, फ़ायरफ़ॉक्स 3.x और क्रोम के तहत परीक्षण किया गया
• "उपयोगकर्ता गाइड" में संबंधित अनुभाग बनाए गए हैं।

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



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



हालाँकि हमारे पास प्रतिबद्धता की एक निश्चित राशि है, फिर भी हम लचीले ढंग से परिवर्तनों को स्वीकार करना चाहते हैं। हमारे पास उपकरण (कहानियां और कठिनाई स्कोर) हैं जिनका उपयोग आप आवश्यकताओं की तुलना करने के लिए कर सकते हैं। यह हमें दायित्वों के एक निश्चित मात्रा के भीतर शेष, आवश्यकताओं का आदान-प्रदान करने की अनुमति देता है। और अगर हम इस ढांचे के भीतर रह सकते हैं, तो हम एक निश्चित समय सीमा और कीमत में फिट हो सकते हैं।

प्रारंभिक मूल्यांकन

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



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



अगला कदम उपयोगकर्ता कहानियों को इकट्ठा करना है । इसे 1-2 दिनों में कई त्वरित सत्रों के रूप में व्यवस्थित किया जा सकता है। यह समय अधिकांश कहानियों को खोजने के लिए पर्याप्त है जो कार्यक्षमता के जंगल में गहरे उतरे बिना उत्पाद की दृष्टि बनाएंगे। इस दृष्टिकोण से, ग्राहक के साथ कहानियों, पुनरावृत्तियों और रिलीज़ के लिए तत्परता मानदंड पर चर्चा करना बहुत महत्वपूर्ण है।



हमें पता होना चाहिए:

• वह वातावरण जिसमें आप कहानियों का परीक्षण करना चाहते हैं (ब्राउज़रों या मोबाइल प्लेटफार्मों की संख्या, या ऑपरेटिंग सिस्टम)
• आवश्यक दस्तावेज
• आपको पूर्ण कहानियों को प्रकट करने की आवश्यकता नहीं है, ताकि क्लाइंट उनकी ओर देख सके
• ग्राहक को क्या करना चाहिए (उदाहरण के लिए, डेमो सत्र में भाग लें)
• कितनी बार मिलना है और कौन प्रतिभागी हैं

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



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



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

फाइबोनैचि श्रृंखला (1, 2, 3, 5, 8, 13, 20, 40, 100) के समान एक पैमाना जटिलता बिंदुओं में कहानियों के मूल्यांकन के लिए बहुत सुविधाजनक है। एक सापेक्ष मूल्यांकन सबसे सरल या छोटी कहानियों के चयन के साथ शुरू होता है। उन्हें कठिनाई के 1-2 अंक मिलते हैं - यह आगे के मूल्यांकन के लिए मूल स्तर है।

वास्तव में, प्रारंभिक मूल्यांकन के दौरान, सबसे कम मूल्यों का उपयोग करके कहानियों का मूल्यांकन करना अक्सर मुश्किल होता है, जैसे कि 1 और 2. तथ्य यह है कि स्कोर जितना अधिक होगा, हम कहानी के बारे में उतना ही कम जानते हैं। इसलिए, इस प्रारंभिक स्तर पर स्कोरिंग आसान है, क्योंकि यह कहना आसान है कि कहानी ए कहानी बी की तुलना में 2 गुना अधिक कठिन है, यह कहना कि कहानी ए को 25 व्यक्ति-घंटे लगेंगे (तत्परता मानदंड याद रखें?), और कहानी बी ले जाएगी। 54 घंटे।



यह बहुत अच्छा काम करता है, भले ही हम 3 या 5-बिंदु वाली कहानियों को एक बुनियादी स्तर के रूप में लेते हैं, इस मामले में हमारे लिए उन्हें विकास की अवस्था में पहले से ही छोटी कहानियों में तोड़ना आसान होगा। 20, 40 या 100 अंकों के साथ कहानियों से सावधान रहें। मूल्यांकन का यह तरीका मानता है कि हमें इस बारे में कुछ भी पता नहीं है कि क्या लागू किया जाएगा, इसलिए हमें तुरंत ग्राहक के साथ और अधिक विस्तार से सब कुछ पर चर्चा करने की जरूरत है, न कि खुशी-खुशी उन्हें अनुबंध में दर्ज करें।



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

कीमत और समय तय करना

कहानियों के एक सेट के आधार पर गणना की गई कठिनाई बिंदुओं की कुल संख्या सीधे हमें मूल्य और समय नहीं देती है। उन्हें कैसे प्राप्त करें? हमें मैजिक नंबर चाहिए।



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



मान लीजिए कि हमने कुल 300 संदर्भ बिंदुओं के साथ अपनी कहानियों का मूल्यांकन किया। हमें निम्नलिखित के आधार पर टीम के प्रदर्शन को निर्धारित करने की आवश्यकता है:

• पास्ट प्रोजेक्ट्स पर टीम का प्रदर्शन
• प्रत्येक पुनरावृत्ति पर की जाने वाली क्रियाओं की संख्या (पढ़ें तत्परता मानदंड)
• क्लाइंट के साथ संचार में आसानी (आदर्श, और विकल्प तक पहुंचने में मुश्किल, यह तब होता है जब क्लाइंट टीम के हिस्से के रूप में होता है, लेकिन आमतौर पर ऐसा नहीं होता है। अलग-अलग ग्राहकों के पास अलग-अलग समय होते हैं, जो वे टीम के साथ संवाद करने में खर्च करने के इच्छुक होते हैं - कम समय होता है। ग्राहक हम पर है, हमारी उत्पादकता कम है
• बस संवेदनाएँ कि परियोजना पर काम का आयतन हम में है (हाँ, हम इसे वैध मानते हैं)

मान लीजिए कि हमारी टीम में 5 लोग शामिल हैं - 3 प्रोग्रामर, 1 टेस्टर और 1 टीम लीडर - जो ग्राहकों और इच्छुक पार्टियों के साथ संवाद करेंगे, ठीक उसी तरह जैसे टीम के बाहर के अन्य लोगों के साथ (उदाहरण के लिए, स्क्रैम मेथोडोलॉजी में स्क्रम मास्टर)।



मान लीजिए कि हमारी टीम 2-सप्ताह के चलना में 20 नियंत्रण बिंदुओं की गति प्राप्त करने का प्रयास करेगी। यह अनुबंध में हमारा मुख्य जादू नंबर है। किसी परियोजना पर काम करने के पूरे समय के दौरान कई कारक उत्पादकता को प्रभावित कर सकते हैं, हालांकि, यदि हम जिस टीम के साथ काम कर रहे हैं, वह नई नहीं है, और परियोजना स्वयं पूरी तरह से अज्ञात नहीं है, तो ये संख्या पिछले अनुभव से ली जा सकती है।



अब हम अनुबंध में क्लाइंट द्वारा हम पर लगाए गए दो प्रतिबंधों में से एक का सामना कर सकते हैं:

• ग्राहक जल्द से जल्द इस उत्पाद को प्राप्त करना चाहता है (और, अधिमानतः, और भी तेजी से)
• ग्राहक चाहते हैं कि हम तारीख X (जो हमारी समय सीमा हो) के अनुसार अधिकतम करें।

परिदृश्य 1

पहले परिदृश्य में, हम निम्न सूत्र का उपयोग करके अनुमानित पूरा होने का समय निर्धारित कर सकते हैं:



समय = (<जटिलता अंक> / <प्रदर्शन>) * <पुनरावृत्ति लंबाई>



हमारे परिदृश्य में यह होगा:



समय = (300 अंक / 20 अंक) * 2 सप्ताह = 30 सप्ताह (या 15 पुनरावृत्तियों)



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

परिदृश्य २

हम जानते हैं कि परियोजना 20 सप्ताह में पूरी हो जाएगी, और यह हमारे पुनरावृत्तियों में से केवल 10 हैं, इसलिए हम अपने कार्यक्षेत्र से केवल 20 बिंदुओं का प्रदर्शन कर सकते हैं। अब यह क्लाइंट पर निर्भर करता है कि किसी ऐसे काम को करने की क्षमता को खोए बिना काम के दायरे से क्या हटाया जा सकता है, जिसमें आवश्यक मूल्य है।



यहां हम प्रदर्शन को बेहतर बनाने के लिए आवश्यक टीम का आकार बदल सकते हैं।



आवश्यक टीम का आकार और अंतिम तिथि जानने के बाद, हम अंत में मुख्य अनुबंध मूल्य - कार्य समय की लागत की गणना कर सकते हैं:



पैसा = <प्रति घंटे प्रति घंटे की संख्या> * पुनरावृत्तियों की संख्या> * <लोग> * <एक घंटे के काम का मूल्य>



हमारे उदाहरण में, हमें मिलता है:



पैसा = 80 घंटे * 15 पुनरावृत्तियों * 4 लोग * $ 100 = $ 480,000



अब हमारे पास एक निश्चित मूल्य अनुबंध के मूल्य हैं:

• मूल्य - $ 480,000
• समय - 15 पुनरावृत्तियों (30 सप्ताह)
• वॉल्यूम - 300 संदर्भ बिंदु

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



एक और सवाल है। ग्राहक पूछता है: "यह इतना महंगा क्यों है?" यह वह जगह है जहां बातचीत वास्तव में शुरू होती है, और एकमात्र कारक जो निर्माण कंपनी बदल सकती है वह एक मानव-घंटे की लागत है। ये वे $ 100 हैं जिनके बारे में हम बातचीत कर रहे हैं। पुनरावृत्तियों की लंबाई नहीं, पुनरावृत्तियों की संख्या भी नहीं। हमारी टीम के पास सुपर पॉवर नहीं है, और अगर हम सिर्फ इस पर सहमत हैं तो हम दो बार तेजी से काम नहीं करेंगे।

यह वह धन है जिसे हम खोने के लिए सहमत हैं। यदि हम कहते हैं कि हम कीमत कम कर सकते हैं, तो यह केवल इसलिए है क्योंकि हम कम कमाते हैं, और इसलिए नहीं कि हम तेजी से काम करेंगे।

अपनी प्रगति और बजट को ट्रैक करें।

अब हमारे अनुबंध पर हस्ताक्षर किए गए हैं (यह आसान था, ठीक है?), एक सहमत ढांचे में सॉफ्टवेयर बनाने का समय है। आपने पहले ही सुना होगा कि एक लचीली कार्यप्रणाली आपकी समस्याओं को हल नहीं करेगी, लेकिन उन्हें दिखाई देगी। इसलिए, हम यह जानना चाहते हैं कि आवश्यक कार्रवाई करने के लिए चीजें कैसे चल रही हैं। आखिरकार, एक संभावना है कि अनुबंध में हमारा जादू नंबर (हमारा प्रदर्शन) गलत था।



कई फुर्तीली परियोजनाओं में प्रगति को ट्रैक करने के लिए बर्न्डाउन चार्ट एक बहुत ही सामान्य तरीका है।





. 1 — .







वे नियोजित प्रगति और वास्तविकता को देखने के लिए महान हैं। उदाहरण के लिए, चित्रा में burndown आरेख 1 अच्छा लग रहा है:



हम योजना में थोड़ा फिट नहीं हैं, लेकिन इसका मतलब यह नहीं है कि हमने अनुबंध पर चर्चा करने की प्रक्रिया में प्रदर्शन का निर्धारण करने में एक बड़ी गलती की। ज्यादातर टीमें शायद यही चाहेंगी कि उनके ग्राफिक्स इस तरह से दिखें। लेकिन समस्या यह है कि यह ग्राफ तीन में से केवल दो कारकों को प्रदर्शित करता है - प्रतिबद्धता और समय की मात्रा। लेकिन पैसे का क्या?





. 2 — .







चित्र में आरेख। 2 दो पैमाने दिखाता है - काम की मात्रा और बजट। इन दोनों कारकों को अच्छे कारण के प्रतिशत के रूप में यहाँ व्यक्त किया गया है। आखिरकार, इन दो संकेतकों की तुलना करने का कोई अन्य तरीका नहीं है (एक को कठिनाई बिंदुओं में माना जाता है, और दूसरा - मानव-घंटे या कम खर्च में)।



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



इस तरह से काम और बजट की मात्रा को ट्रैक करने के लिए, हमें चाहिए:

• प्रत्येक पुनरावृत्ति पर पूर्ण कठिनाई बिंदुओं को ट्रैक करें
• ट्रैक समय वास्तव में प्रत्येक पुनरावृत्ति (मैन-आवर्स में) पर खर्च होता है
• कुल कार्य के प्रतिशत के रूप में पुनर्गणना करें और कुल के प्रतिशत के आधार पर एक पैमाने बनाएं
• अनुबंध में निर्धारित बजट (या उसके हिस्से का) को आदमियों की कुल संख्या में पुनर्गणना करें - ये हमारे बजट का 100% हैं - और कुल बजट के प्रतिशत के आधार पर बजट खर्च का पैमाना

पिछले उदाहरण में, हमारे पास था:

• काम का दायरा - कठिनाई के 300 अंक
• 30 सप्ताह का बजट * 4 लोग * प्रति सप्ताह 40 घंटे = 4,800 आदमी घंटे

ये हमारे सामान्य संकेतक हैं। 6 जटिलता बिंदुओं के लिए 120 घंटे की खपत का मतलब है कि हमने 2% काम पर बजट का 2.5% खर्च किया।

परिवर्तनों की स्वीकृति

हमें उस समय एक बार फिर से लौटने की आवश्यकता है जब हमने दायित्वों की निश्चित मात्रा को निर्धारित बजट में बदल दिया। पिछले उदाहरणों से 300 कठिनाई बिंदु हमें उपयोगकर्ता कहानियों की मूल सूची की सामग्री को बदलने में मदद करेंगे। यह सबसे महत्वपूर्ण बिंदुओं में से एक है जो हम एक निश्चित मूल्य अनुबंध पर एक लचीली कार्यप्रणाली को लागू करके आना चाहते हैं।



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



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



या हो सकता है कि ग्राहक एक और पुनरावृत्ति जोड़ना चाहता है (प्रति चलना 20 बिंदुओं के प्रदर्शन को याद रखें?)। इन नई कहानियों की कीमत की गणना बहुत सरल है:



पैसा = 1 पुनरावृत्ति * 80 मानव-घंटे * 4 लोग * $ 100 = $ 24,000



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

भवन का भरोसा

फिक्स्ड प्राइस कॉन्ट्रैक्ट में इन सभी तकनीकों का उपयोग करने के लिए, एक चीज की आवश्यकता है - विश्वास । लेकिन, जैसा कि हम जानते हैं, हमारी टीम ग्राहक के लिए क्या शानदार काम करेगी, इसका वर्णन करके विश्वास हासिल करना असंभव है।



चंचल सिद्धांत इस समस्या को हल करने का एक शानदार तरीका प्रदान करते हैं। प्रत्येक पुनरावृत्ति के साथ, हम क्लाइंट के लिए कुछ मूल्य बनाते हैं। लेकिन सबसे महत्वपूर्ण बात यह है कि हम सबसे मूल्यवान सुविधाओं पर ध्यान केंद्रित करते हैं। इसलिए, ग्राहकों का विश्वास हासिल करने का सबसे अच्छा तरीका अनुबंध को कई हिस्सों में तोड़ना है।



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



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

सारांश

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



वास्तव में, निर्धारित कारकों के कुछ पहलू चुस्त टीमों के लिए और भी बेहतर हैं, क्योंकि हम समय ब्लॉक में काम करने के लिए उपयोग किए जाते हैं, और अनुबंध में एक निश्चित तिथि (साथ ही एक निश्चित मूल्य) ये समय ब्लॉक और सीमाएं हैं। केवल एक चीज जो वास्तव में हमें परेशान करती है वह दायित्वों की मात्रा है, और इस लेख में हमने इस प्रतिबंध से निपटने के तरीकों पर विचार एकत्र करने की कोशिश की।



इस लेख का विचार यह कहने के लिए नहीं था कि चुस्त-दुरुस्त मूल्य अनुबंधों की सभी समस्याओं के लिए एक रामबाण है, लेकिन एक लचीली कार्यप्रणाली का उपयोग करके इस क्षेत्र में काम करने के अन्य तरीकों को दिखाना है।

लेखक के बारे में

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