फुर्तीली सॉफ्टवेयर विकास: उपयोगकर्ता की आवश्यकताओं को बदलने के लिए आप * वित्तीय रूप से * प्रतिक्रिया कैसे करते हैं?

Question

एसई और अन्य साइटों पर यहां इस "चुस्त विकास" सामान के बारे में पढ़ते हुए एक बात मुझे हमेशा आश्चर्यचकित करती है:

"पारंपरिक" सॉफ्टवेयर इंजीनियरिंग में, आप

1. उपयोगकर्ता की आवश्यकताओं को एकत्रित करें,
2. इन आवश्यकताओं के आधार पर एक विनिर्देश लिखें,
3. ग्राहक को दें और अब तक किए गए काम के लिए उसे बिल दें,
4. एक मोटा (मोटा) तकनीकी डिजाइन करें, ताकि आप कार्यान्वयन की लागत का अनुमान लगा सकें,
5. कार्यान्वयन के लिए उपयोगकर्ता को एक मूल्य उद्धरण दें,
6. ग्राहक के विनिर्देशन पर हस्ताक्षर करने और प्रस्ताव स्वीकार करने की प्रतीक्षा करें,
7. डिजाइन, लागू, परीक्षण,
8. बिल।

यदि, प्रक्रिया के दौरान, आवश्यकताओं में परिवर्तन होता है, तो आप वांछित बदलावों के लिए एक प्रस्ताव (कीमत के साथ) भेजते हैं (या यदि मुफ्त में बदलाव छोटा है, तो आप ग्राहक को पसंद करते हैं और ग्राहक अक्सर ऐसा नहीं करता है) ।

तो, यह कैसे काम करता है (आर्थिक रूप से) एक फुर्तीली परियोजना में, जहां लगातार आवश्यकता परिवर्तन प्रक्रिया का एक हिस्सा हैं?

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

Comments

मुझे लगता है कि अंतर यह नहीं है कि "लगातार आवश्यकताएं परिवर्तन प्रक्रिया का एक हिस्सा हैं", लेकिन यह कि वे प्रक्रिया का एक स्पष्ट रूप से स्वीकार किए जाते हैं ।

Answer 1

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

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

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

यहां नोट के योग्य दो जोखिम हैं। पहले यह है कि ग्राहक को डर लग सकता है, अगर वह चपलता को समझ नहीं पाया है। ऐसा लगता है कि वह सभी जोखिम ले रहा है। केवल अनुभव से पता चलता है कि वह वास्तव में नहीं है।

दूसरी यह है कि उन्हें पूरी प्रक्रिया के दौरान लगे रहना चाहिए, या सभी को खोना होगा। बहुत से ग्राहक यह समझने में विफल रहते हैं कि जब तक बहुत देर नहीं हो जाती तब तक वे कितने व्यस्त रहेंगे।

लेकिन यदि आप, एक कंपनी के रूप में, इसे पर्याप्त रूप से समझाते हैं, तो हर कोई विजेता है।

Comments

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

— रॉबिन्स

+1 - पहला पैराग्राफ एक अच्छा, रसीला है, जो कि एजाइल आपको दे सकता है। "दूसरा यह है कि उनकी सगाई होनी चाहिए" भी बहुत महत्वपूर्ण है।

— ओज

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

— लोरेंजो सोलानो

क्या इसका मतलब यह है कि चुस्त परियोजना के अनुबंध प्रकार की कीमत तय नहीं होनी चाहिए?

— बेन चेंग

Answer 2

कुछ लोगों ने अतीत में निर्धारित मूल्य परियोजनाओं में चपलता का उपयोग करने के लिए समाधान देने का प्रयास किया । मुझे लगता है कि यह आमतौर पर संभव नहीं है।

विशेष रूप से स्क्रम उत्पाद सॉफ्टवेयर कंपनियों के लिए अनुकूल है , और सेवा कंपनियों में इसका कम उपयोग किया जाता है।

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

कृपया चपलता के लिए सॉस की सेवा न करें । हमें किसी समस्या के उचित समाधान का उपयोग करना चाहिए।

Comments

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

— maple_shaft

@maple_shaft: हाँ यह वास्तव में संभव है और अनुशंसित है। मेरे द्वारा जोड़े गए लिंक उन लोगों से हैं जो दावा करते हैं कि यह काम किया है। लेकिन आपको इस तरीके से काम करना होगा (ग्राहक के लिए निश्चित मूल्य और समय या निश्चित मूल्य और समय पर निश्चित गुंजाइश के लिए गुंजाइश बनाए रखना)।

Answer 3

यह वास्तव में एजाइल प्रोग्रामिंग या आपके द्वारा उपयोग किए जाने वाले मॉडल से संबंधित नहीं है। एक फ्रीलांसर के रूप में काम करते हुए, मैं झरना और वी-मॉडल के मिश्रण का उपयोग करता हूं, लेकिन अभी भी एक ही समस्या है: क्या होगा यदि ग्राहक विस्तृत डिजाइन के दौरान कुछ बदलना चाहते हैं? यदि वह कार्यान्वयन के दौरान परिवर्तन करता है तो क्या होगा?

आपके द्वारा उपयोग किया जाने वाला दृष्टिकोण ग्राहक और आपके संबंधों पर निर्भर करता है।

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

अन्य ग्राहकों के लिए, जो दृष्टिकोण अच्छी तरह से काम करता है वह निम्नलिखित है:

• पहले प्रस्ताव पर हस्ताक्षर करते समय, अनुमानित लागत और अधिकतम लागत निर्दिष्ट करें। अनुमानित लागत का कानूनी रूप से कुछ भी मतलब नहीं है: यह सिर्फ एक अनुमान है। अधिकतम लागत का कानूनी मूल्य है: यदि आप कहते हैं कि उत्पाद का मूल्य आपके ग्राहक के लिए $ 3,000 होगा, और अंत में इसकी कीमत आपको $ 3,157.24 होगी, तब भी ग्राहक को $ 3,000 का भुगतान करना होगा। व्यवहार में, ज्यादातर मामलों में, वास्तविक लागत दिए गए अधिकतम से कम होगी, और आपके अनुमान के करीब होगी।

• जब ग्राहक एक आवश्यकता को बदलने के लिए कहता है, तो इसकी लागत का अनुमान लगाएं और इसकी वास्तविक लागत और स्थिति से तुलना करें। यदि आपने उत्पाद को लगभग समाप्त कर दिया है और वास्तविक लागत $ 2,108.36 है और परिवर्तन की लागत $ 150 अनुमानित है, तो बस करें। यदि, दूसरी ओर, अधिकतम तक पहुंचने का जोखिम है, तो अपने ग्राहक को बताएं कि आपको समग्र लागत का एक साथ पुनर्मूल्यांकन करना है।

Answer 4

चंचल और 'एक प्रस्ताव लिखें' एक विरोधी की तरह लगता है :) - उत्तरार्द्ध उत्पादक सॉफ्टवेयर इंजीनियरिंग नहीं है: डी

ठीक है, अब जब हमने मजाक किया है - वापस असली चीज़ पर।

"यह कैसे चुस्त काम करता है ?" - अनुबंध चीजों को जटिल करता है लेकिन मुझे यह स्पष्ट करने की उम्मीद है। चंचल 'ट्रस्ट' और 'को-वर्किंग' की प्रधानता पर स्थापित होता है, जिसका अर्थ है कि ग्राहक को जो भी, जब भी और जो कुछ भी बदलने की आवश्यकता होती है उसे बदलने की अनुमति दी जाती है या यदि गैर-घुसपैठिया हो सकती है, तो बिना किसी अतिरिक्त लागत के।

इसका क्या मतलब है? इसका मतलब है कि अनुबंध यह बताता है कि हम (ग्राहक) लागत का एक प्रारंभिक अनुमान और +/- संस्करण% तय करते हैं जिसे हम जैसे $ 100K बोली संभाल सकते हैं, लेकिन मैं $ 120K तक जाने के लिए तैयार हूं (यह मई नहीं होना चाहिए) अनुबंध का हिस्सा है, लेकिन ग्राहक के दिमाग में)।

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

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

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

उम्मीद है की यह मदद करेगा!

Answer 5

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

1. परिवर्तनों के लिए कुछ ओवरहेड में निर्माण करें (उदाहरण के लिए, 10%)
2. बिल्ट-इन कॉस्ट से परे बड़े बदलाव या एग्रीगेट और बिल में बदलाव के लिए आकलन और अलग से बिल (एक अच्छा, यद्यपि प्रोग्रामिंग नहीं है, उदाहरण डिजाइन का काम है, जहां अक्सर प्रारंभिक लागत शामिल होती है, 3 संशोधन कहते हैं, और बाद के संशोधन या शायद कुल रीडोज होते हैं) अतिरिक्त)

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

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