चंचल फुर्तीली परियोजनाएँ

Question

जिस कंपनी में मैं काम करता हूं, वह अस्थायी रूप से एक फुर्तीली परियोजना प्रबंधन रणनीति की ओर बढ़ रही है - जिसमें कई बार एक बार झरने की "खुशियों" का अनुभव होता है। इसके लिए कुंजी एक समय सीमा है, जिसमें कार्यक्षमता को वितरित करने की दिशा में जोर दिया गया है ताकि कठिन समय सीमा को पूरा किया जा सके।

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

मैं फुर्तीली परियोजनाओं के वित्तपोषण में लोगों के विचारों और अनुभवों को सुनना चाहूंगा

संपादित करें: मैं इस बात पर ज़ोर देना चाहता हूं कि मैं लोगों को फुर्तीली विधि के पेशेवरों और विपक्षों को समझाने के लिए नहीं कह रहा हूं, और न ही मेरा मानना ​​है कि एजाइल ने "यह तैयार होने पर तैयार हो जाएगा" के बराबर है, यह एक भय द्वारा व्यक्त भय है। फुर्तीली विकास प्रथाओं की वकालत करते हुए मैंने जिन ग्राहकों / व्यवसायों के साथ काम किया है।

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

Comments

गार्टनर के लिसा क्रिस्पिन और डेविड नॉर्टन के "एजिंग एज़ाइल" के बारे में कुछ अच्छे विचार हैं। एक नज़र डालिए

— फुर्तीला स्काउट

Answer 1

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

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

Comments

"आप बिक्री टीम को फुर्तीले सिद्धांतों का उपयोग करके परियोजना को बेचने का तरीका जानने के लिए बताएं" - मैं इसे अपना सर्वश्रेष्ठ शॉट दूँगा ... {?)

— sunwukung

Answer 2

फुर्तीली परियोजनाएं "तैयार होने पर तैयार रहेंगी" की तर्ज पर काम नहीं करती हैं। यह झरना इंजीनियरिंग से एक शास्त्रीय रेखा है।

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

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

शायद अधिक है, लेकिन आपकी बिक्री लोगों को सही दिशा में लाने के लिए ऊपर पर्याप्त होनी चाहिए।

Comments

पुन: "कोई भी चोट नहीं पहुंचाता, हर कोई मुनाफा" - उस आदमी को छोड़कर जो निकाल दिया गया क्योंकि उसने अपने मालिक से वादा किया था कि $ X के लिए उसे एक सॉफ्टवेयर पैकेज मिलेगा जो XYZ करता है। दुर्भाग्य से, सॉफ्टवेयर पैकेज को चुस्त करने के लिए धन्यवाद केवल XY करता है। प्रबंधक को रोकना होगा, उस व्यक्ति को निकाल देगा जो अधोलोकियों में रहता है। हो सकता है कि मैं ज्यादातर चुस्त प्रस्तावकों से पूरी तरह से अलग उद्योगों में रहा हूं, क्योंकि वे ग्राहक को केवल आंशिक समाधान देने में कोई समस्या नहीं देख सकते हैं। OTOH, मैं एक आंशिक समाधान देने में उद्देश्य नहीं देख सकता क्योंकि ऑड्स हैं जो उत्पाद को ग्राहक के लिए बहुत बेकार बनाता है।

— डंक

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

— wolfgangsz

Answer 3

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

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

Comments

बस स्पष्ट होने के लिए - मैं यह नहीं कह रहा हूं कि मेरा मानना ​​है कि एजाइल उस विवरण के बराबर है, लेकिन यह है कि ग्राहक / बिक्री अक्सर इसे कैसे देखते हैं। Agile की पुनरावृत्तियों में महान है - लेकिन यह परियोजना के अंत को ठीक से पिन करने के लिए कठिन बनाता है?

— सूर्यकुंग

@sunwukung - आपकी बिक्री टीम इस तथ्य को नहीं बेच रही है कि कोई भी शुरुआत में किसी भी सटीकता के साथ एक लंबी परियोजना के अंत की भविष्यवाणी नहीं कर सकता है।

— जेफो जूल

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

— जूनियरडूवलर1208

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

— जूनियरडूवलर १२8 Jul8

क्षमा करें - हाँ, मैं समझता हूँ - हम अनुमानित डिलीवरी विंडो को रफ करने के लिए बैकलॉग विधि का उपयोग कर रहे हैं (Pivotal Tracker, बढ़िया ऐप btw का उपयोग करके)। तनाव इस विधि से उत्पन्न प्रारंभिक मील के पत्थर के बीच विसंगति के संदर्भ में पैदा होता है, और वास्तविक ईटीए के वेग के एक बार शुरू होने के बाद तनाव पैदा होता है। IMO यह सब है कि हम ग्राहक संबंध को कैसे संभालते हैं - लेकिन यह कुछ हद तक राजनीतिक घटक है

— sunwukung

Answer 4

यद्यपि मैं जिस स्थान पर काम करता हूं वह एजाइल का भयानक कमीनापन करता है, मुझे लगता है कि ग्राहक पूर्ण रिलीज की तुलना में पुनरावृत्तियों में सॉफ़्टवेयर विकास को प्राथमिकता देना पसंद करते हैं।

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

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

Comments

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

— एडम लीयर

+1 के लिए "हम इस सुविधा को चाहते हैं, और हम इसके लिए 8 महीने तक इंतजार करना चाहते हैं, अन्य सुविधाओं के एक समूह के साथ वितरित करने के लिए जिनकी हमें परवाह नहीं है।"

— सनवुकंग

Answer 5

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

और फिर एक परियोजना की समाप्ति पर क्या होता है - उदाहरण के लिए, क्या ग्राहक कोड का मालिक है, या केवल निष्पादन योग्य है? लेकिन यह पिछले जलप्रपात प्रकार की परियोजनाओं के अनुरूप होगा।

Comments

मैं इससे सहमत हूं, मुझे संदेह है कि व्यवसाय के लिए समस्या का एक हिस्सा यह है कि यह वार्षिक राजस्व है (इस प्रकार निवेशकों को खुश करने) इन "अल्पावधि" फंडिंग फटने के साथ।

— सूर्यवुंग

मुझे आश्चर्य है कि क्या आप एक अनुबंध मॉडल से चोरी कर सकते हैं? यह डाउनटाइम के जोखिम को जोड़ता है यदि ग्राहक अचानक "धन्यवाद लेकिन नहीं" कहते हैं, जो अनुबंध श्रम के मॉडल के समान होना चाहिए?

— शर्तलक्ष्मी

Answer 6

चंचल का विचार यह है कि आप तेजी से पुनरावृति करते हैं और वास्तव में वही स्थापित करते हैं जो आप प्रत्येक स्प्रिंट के अंत में देने जा रहे हैं, इसलिए जब आपके स्प्रिंट के 2/3/4 सप्ताह का समय है, तो आपके आवेदन / परियोजना में मूर्त विशेषताएं हैं आप अपने ग्राहक को प्रस्तुत कर सकते हैं और प्रतिक्रिया प्राप्त कर सकते हैं।

ईटीए: आप 'स्प्रिंट्स' को 'मील के पत्थर' में स्थापित कर सकते हैं, स्थापित डिलिवरेबल्स के साथ, और प्रति मील का भुगतान प्राप्त कर सकते हैं।

Comments

यह वही है जो मैं व्यवसाय में बढ़ावा देने की कोशिश कर रहा हूं - "स्टेज गेट्स" के लिए भुगतान करें। मुख्य मुद्दा अंतिम वितरण तिथि है - क्या ग्राहक को उस ठोस अंतिम समय सीमा को त्यागना होगा?

— सूर्यकुंग

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

— जूनियरडवेलपर्सन1208

@sunwukung, फिर से आप सभी को पूरी तरह से इसका वर्णन करने के बाद इस बिंदु को याद कर रहे हैं। एजाइल गारंटी देता है कि ग्राहक को हर स्प्रिंट के अंत में काम करने वाला सॉफ्टवेयर मिलता है। अगर वे अभी भी सभी फीचर्स के लिए एक FIRM DATE को BE COMPLETE करना चाहते हैं, तो उनके पास यह हो सकता है, लेकिन केवल उन विशेषताओं के लिए जब उन्होंने सौदे पर हस्ताक्षर किए थे। उनके लिए अपनी आवश्यकताओं को बदलना और उनके लिए समान समय सीमा की अपेक्षा करना अनुचित और अनुचित है!

— maple_shaft

ठीक है, बस उन्हें बताएं कि विकास के दौरान वे हर स्प्रिंट के अंत में अपनी परियोजना को देखने में सक्षम होने जा रहे हैं, हमेशा एक कार्यशील स्थिति में और प्रतिक्रिया के लिए तैयार, यह एक कठिन बिक्री नहीं होनी चाहिए, चुस्त उत्कृष्ट है।

— जूनियरडायपरफ़ॉर्मर Jul१२ १५:१५ पर

@sunwukung, ऐसा लगता है कि कंपनी बेहतर करेगी यदि आप इस मामले में व्यावसायिक शाखा का प्रतिनिधित्व करते हैं :) मुझे नहीं पता कि आप व्यवसाय शाखा को क्या कह सकते हैं उन्हें समझाने के लिए कि आप पहले से ही जानते हैं। वे शायद आपकी बात नहीं सुनेंगे। दुर्भाग्य से लगता है कि तकनीकी पक्ष 21 वीं सदी में प्रगति कर रहा है और व्यापार पक्ष अतीत में है। यह एक आसान समस्या नहीं है और आप इसे ठीक करने की स्थिति में नहीं हैं।

— maple_shaft

Answer 7

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

Iterations समझने के लिए स्पष्ट हैं, और आप दो अवधारणाओं को नहीं मिलाते हैं।

निम्नलिखित दो दस्तावेज आपको एजाइल प्रबंधन और बिक्री प्रक्रिया की बातचीत के बारे में कुछ जानकारी प्रदान करेंगे:

http://www.nayima.be/html/fixedpriceprojects.pdf और http://www.nayima.be/html/agilefixedprice.pdf