आपने एग्इल परियोजना के अनुबंध पर हस्ताक्षर कैसे किए? (आप कैसे सोचते हैं कि आप कैसे करेंगे, आपने कैसे किया)

Question

एक एग्इल परियोजना को निष्पादित करने के लिए आपको पहले अनुबंध की आवश्यकता है। कोई अनुबंध नहीं - कोई परियोजना नहीं! कोई परियोजना नहीं - कोई Agile, SCRUM या जो कुछ भी नहीं!

अनुबंध, अगर हम मध्य से बड़ी परियोजनाओं के बारे में बात कर रहे हैं, तो अच्छी तरह से परिभाषित सुरक्षा ट्रिगर्स होना चाहिए। अर्थात। ग्राहक बहुत निश्चित होना चाहते हैं, कि अगर हम समय = टी, बजट = बी और स्कोप = एस में एक परियोजना को समाप्त करने पर सहमत हैं, तो हम समय = टी × 2, बजट = बी × 3 या स्कोप = एस/2।

दूसरी तरफ, हम उत्पाद को वितरित करने वाली कंपनी के रूप में, यह नहीं चाहते कि परियोजना अप्रत्याशित रूप से समाप्त हो। अर्थात। अगर कुछ पुनरावृत्ति के बाद ग्राहक कहता है, "अब मैं देखता हूं कि यह वास्तव में हमें जरूरी है। हम अभी रुक गए हैं।" और परियोजना के बिना योजनाबद्ध काम के लोगों के मुकाबले एक और 2 महीने के लिए योजना बनाई गई थी। यदि 3-6 लोग बड़ी समस्या नहीं हैं, तो 15-25 वास्तविक समस्या हो सकती है!

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

कृपया नहीं "यह शायद इस तरह से काम करेगा ..." - मैंने इसमें से कुछ पढ़े हैं। केवल "हमारे लिए यह इस तरह से काम किया" में रुचि रखते हैं "। कोई संदेह नहीं है, इसमें सभी आत्मविश्वास जानकारी छोड़ दें।

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

Answer 1

मैं सरकार में काम करता हूं।

हमने हाल ही में एक सॉफ्टवेयर विकास खरीद प्रक्रिया चलाई और तीन विक्रेताओं को एक Agile परियोजना पर काम करने के लिए चुना। कुछ नोट:

1. हम पहले से ही 75% यकीन है कि हम क्योंकि हम जानते थे कि हमारी आवश्यकताओं को अस्पष्ट थे एक चंचल परियोजना को चलाने के लिए चाहते थे और थे क्योंकि यह एक महत्वपूर्ण डिजाइन तत्व के साथ किसी सार्वजनिक संपर्क वाली वेब परियोजना थी। तो मैं कहूंगा कि अगर आपका क्लाइंट एग्इल के बारे में जानता है और शुरुआत से खरीदता है, तो यह बहुत मदद करता है, भले ही वे वास्तव में घर में अभ्यास न करें। ध्यान दें कि Agile की स्वीकृति कुछ (सरकारी) मंडलियों में बढ़ रही है, इसलिए यह आसान हो सकता है।

2. हमारे द्वारा उपयोग किए जाने वाले एक सुरक्षा का उपयोग हमारे लिए काम करने के लिए एक अनुभवी (स्वतंत्र) एससीआरयूएम मास्टर को अनुबंध करना था और हमारी टीम लीड/आर्किटेक्ट/उपयोगिता लड़के की ओर से सॉफ्टवेयर प्रोजेक्ट प्रबंधन कर्तव्यों को संभालना था। हमने इस व्यक्ति को खोजने में काफी समय बिताया, और उन्हें तीन महान आवेदकों से चुना। यह महंगा था लेकिन इसके लायक था।

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

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

5. महीने के अंत तक हम प्रत्येक विक्रेता के लिए अनुबंध एकत्र करते थे (एक देर हो चुकी थी, लेकिन यह ठीक था)। एक विक्रेता ने नमूना अनुबंध आगे बढ़ाए जिनका हम उपयोग कर सकते हैं, एक परियोजना के तीसरे द्वारा भुगतान के आधार पर; दूसरा दौड़ के पूरा होने पर। मुझे लगता है कि अंत में हमने अपने मानक अनुबंध टेम्पलेट के भुगतान खंड में विक्रेता द्वारा सुझाए गए भाषा का उपयोग करके स्पिंट्स (बिल मासिक) पूरा किया था।

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

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

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

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

आपको यह भी दिलचस्प लगेगा: Outsourcing Agile।

Answer 2

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

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

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

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

Answer 3

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

Answer 4

एकमात्र चुस्त परियोजनाओं पर मैंने कभी काम किया है, इन हाउस, टाइम एंड मैटेरियल्स (टी एम) या प्रति चक्र परियोजनाओं का भुगतान करें।

मुसीबत के रूप में आप ने बताया है,/एक परियोजना असफल होने का खतरा जल्दी खत्म होने वाली है कि वहाँ, है। हालांकि, क्या यह किसी भी परियोजना के समान नहीं है? यदि आप टी & एम पर जाते हैं तो आप सभी जोखिम लेते हैं, यदि आप निश्चित मूल्य पर जाते हैं तो ग्राहक सभी जोखिम लेता है। वेतन प्रति चक्र जाकर आप अधिकतर जोखिम ले रहे हैं, लेकिन एक समय में ग्राहक के एक चक्र पर इसके छोटे हिस्से गुजर रहे हैं। जैसा कि ऐसा होता है न तो आप या ग्राहक किसी भी जोखिम को लेना चाहते हैं, यही कारण है कि आपने यह प्रश्न पोस्ट किया है।

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

1. कुछ अमीर मूर्ख को जोखिम को कम करने के लिए प्राप्त करें (यानी बीमा प्राप्त करें)।
2. कई लोगों के बीच जोखिम फैलाएं जब तक कि प्रत्येक व्यक्ति जो जोखिम लेता है वह इतना छोटा नहीं है कि यह स्वीकार्य है।

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

Answer 5

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

Answer 6

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

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

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

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

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

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

Answer 7

जिस तरह से हम इसे संभालने का तरीका काफी उत्पादक है।

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

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