क्या स्कोप + फिक्स्ड डेडलाइन + फिक्स्ड प्राइस कॉन्ट्रैक्ट "एजाइल" के साथ काम करने के लिए बनाया जा सकता है?


32

कुछ परियोजनाएं जो हम आंतरिक रूप से चलाते हैं, वे हैं स्क्रैम, जबकि अभी भी ग्राहक के लिए "सब कुछ तय" किया जा रहा है। हम अपने हिस्से में मिश्रित सफलता का अनुभव कर रहे हैं (ग्राहक को ब्यूरोडाउन चार्ट की दृश्यता पसंद है)। क्या हम जिस प्रकार के प्रोजेक्ट्स पर काम करते हैं, उन्हें फुर्तीली विधियों का उपयोग करके सफलतापूर्वक निष्पादित किया जा सकता है?


17
क्या कार्य करने के लिए निश्चित गुंजाइश + निश्चित समय सीमा + निश्चित मूल्य अनुबंध किया जा सकता है?
कार्सन 63000

4
यह rephrase का एक तरीका नहीं है: "फास्ट, अच्छा या सस्ता। दो उठाओ"?
मैथ्यू एम।

3
चंचल की नियत नहीं है?
मैट एलेन

जवाबों:


10

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

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


71

मैं एक प्रति-प्रश्न खड़ा करना चाहूंगा:

क्या कार्यक्षेत्र, अवधि के लिए निश्चित गुंजाइश + निश्चित समय सीमा + निश्चित मूल्य अनुबंध किया जा सकता है ?

"अच्छा / तेज / सस्ता - दो उठाओ" कह सिर्फ कुछ मूर्खतापूर्ण इंजीनियरिंग मजाक नहीं है। नमक के लायक हर परियोजना प्रबंधक परियोजना प्रबंधन त्रिकोण के बारे में जानता है :

परियोजना प्रबंधन त्रिभुज

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

समस्या यह है कि यह वास्तव में कभी नहीं होता है जब तक कि आपकी परियोजना की योजना बनाई जा रही है और मनुष्यों द्वारा निष्पादित की जाती है।

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

  • अनपेक्षित लागत पॉप अप करने के लिए बजट से अधिक हो जाएगा। एक सदस्यता समाप्त हो गई। एक निर्माता ने आपके द्वारा उपयोग किए जा रहे उत्पाद के लिए अपना समर्थन बंद कर दिया और आपको एक नया खोजना होगा। एक घंटे के ठेकेदार ने प्रस्थान की धमकी के तहत उसकी दर बढ़ा दी। आपकी पूरी टीम सिर्फ 10% वृद्धि और एक अतिरिक्त सप्ताह की छुट्टी की मांग करते हुए, हड़ताल पर चली गई।

  • अनुसूचियां फिसलती हैं। अनुपयोगी समस्याएं फसल देती हैं; 5 वर्षों से आप जिस चार्टिंग घटक का उपयोग कर रहे हैं, वह विंडोज 95 के साथ संगत नहीं है, जिसे आपका ग्राहक अभी भी उपयोग कर रहा है। 64-बिट विंडोज में एक अस्पष्ट बग गंभीर यूआई ग्लिच का कारण बनता है और आप इसे ट्रैक करने और वर्कअराउंड को विकसित करने में लगभग एक सप्ताह खर्च करते हैं (यह वास्तव में मेरे साथ हुआ था)। आपका वरिष्ठ डेवलपर एक बस की चपेट में आ गया और आपको एक नई भर्ती करनी है। आपकी अनुमानित डिलीवरी की तारीख हमेशा गलत होती है। हमेशा।

    देखें हॉफ़स्टैटर का नियम :

    हॉफस्टेडर्स लॉ: यह हमेशा आपकी अपेक्षा से अधिक समय लेता है, तब भी जब आप हॉफस्टैटर के नियम को ध्यान में रखते हैं।

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

यह एक ऐसी परियोजना के साथ कोई मतलब नहीं है जो (या होने का दावा है) या तो निश्चित गुंजाइश या निश्चित अनुसूची है।

अगर एक परियोजना विशेषता (लागत / गुंजाइश / अनुसूची) नियत ना मैं आपको बता होता है कि यह हो सकता है चुस्त तरीके के लिए बिल्कुल उपयुक्त नहीं हो।

यदि दो परियोजना विशेषताएँ तय की जाती हैं, तो निश्चित रूप से आपकी परियोजना चुस्त तरीकों के लिए एक अच्छी फिट नहीं है।

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

यदि यह अनुबंध अभी भी मेज पर है, तो मैं आपसे इसे अस्वीकार करने का आग्रह करता हूं। और अगर आपने पहले ही इसे स्वीकार कर लिया है, तो भगवान आपकी आत्मा पर दया कर सकता है।


4
Hofstadters कानून के लिए +1। मैं इसे अगले अनुमान सत्र में उद्धृत करने जा रहा हूं।
क्रिस बकेट

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

2
मुझे संदेह है कि प्रबंधन ने ग्राहक के साथ कैसे काम किया है।
क्रिस बकेट

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

3
इस उत्तर पर अपवोट की राशि से पता चलता है कि एजाइल + फिक्स्ड प्राइस मेस में कितने टोल दूर हैं।
रिंग बियर

18

मुझे यह उद्धरण पसंद है:

"स्क्रम या तो निश्चित-तिथि चर-दायरे, या" निश्चित-दायरे "(जो हमेशा बढ़ता है) चर-तिथि के लिए बहुत अच्छा है। यदि आप नियत तारीख तय कर रहे हैं, तो मैं वाटरफॉल या आरयूपी की सलाह देता हूं, जो आपको नई नौकरी देखने के लिए कुछ महीने खरीदेगा। ”~ माइकल जेम्स


6

निश्चित रूप से, जब तक आपकी गुणवत्ता पट्टी उल्लेखनीय रूप से कम रखी जाती है। मैं "प्रसव के समय / गुणवत्ता / मूल्य" के पुराने लोहे के त्रिकोण में विश्वास करता हूं जहां आप दो उठा सकते हैं, लेकिन फिर दूसरा एक तैरता है। ऐसा लगता है कि आपने डिलीवरी का समय और कीमत (और भी सुविधाएँ) तय कर ली हैं, इसलिए वास्तव में केवल वही चीज है जो गुणवत्ता दे सकती है।

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

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


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

0

फिक्स्ड प्राइस / फिक्स्ड डेडलाइन / फिक्स्ड स्कोप कम से कम चुस्त होने के साथ-साथ वाटरफॉल में भी हो सकता है।

जलप्रपात में, समय के अनुमान गलत हैं, और विवरण मूल विनिर्देशों की तुलना में अलग तरीके से लागू किए जा रहे हैं। दूसरे शब्दों में, समय सीमा / गुंजाइश पहले से बिल्कुल ज्ञात नहीं हो सकती है।

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

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


पुराना, लेकिन ... यह जलप्रपात की तुलना में एजाइल में असीम रूप से बेहतर किया जा सकता था, और अंतर नहीं बदलेगा। शून्य हमेशा शून्य रहने वाला है। यदि किसी एकल कहानी पर कोई कार्य किसी एकल घटना का सामना करता है जो लागत या प्रयास को बदल देता है, तो आप असफल हो गए हैं।
ईकेडब्ल्यू जूल

0

मैं कुछ हद तक ब्रूस से सहमत हूं। हालाँकि मैं जलप्रपात या आरयूपी से परिचित नहीं हूँ, और इस तरह उस पर कोई टिप्पणी नहीं कर सकता।

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

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

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


2
यदि आप लगातार योजना बना रहे हैं, तो स्क्रैम वास्तव में आपके लिए नहीं है। कानबन कोशिश करने के लिए अधिक उपयुक्त हो सकता है। लेकिन आप एजाइल के बारे में जो कहते हैं, वह हाजिर है।
gbjbaanb 13
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.