विफल स्प्रिंट और समय सीमा से निपटना


80

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

यह डेवलपर के दृष्टिकोण से बहुत अच्छा लगता है, हालांकि, मान लें कि हमारे पास एक सॉफ़्टवेयर कंपनी " स्क्रैम-एडिक्ट्स एलएलसी " है जो गंभीर ग्राहकों के लिए कुछ विकसित कर रहा है (" मनी-बैग्स कॉर्पोरेशन "):

  1. Scrum-Addicts के प्रबंधकों ने मनी-बैग्स के लिए एक सॉफ्टवेयर बनाने का सुझाव दिया है
  2. वे सुविधाओं की एक सूची पर सहमत होते हैं, और मनी-बैग शिपिंग तिथि प्रदान करने के लिए कहते हैं
  3. स्क्रैम-एडिक्ट्स मैनेजर अपनी स्क्रैम टीम से परामर्श करते हैं, और टीम का कहना है कि सभी सुविधाओं को पूरा करने के लिए 3 सप्ताह का समय लगेगा
  4. स्क्रैम-एडिक्ट्स प्रबंधक सुरक्षित होने के लिए 1 सप्ताह जोड़ता है, 1 महीने में सॉफ़्टवेयर को शिप करने का वादा करता है और मनी-बैग के साथ एक अनुबंध पर हस्ताक्षर करता है।
  5. 4 स्प्रिंट (शिपिंग समय सीमा) के बाद, स्क्रैम टीम केवल 80% सुविधाएं दे सकती है (क्योंकि नई प्रणाली के साथ अनुभवहीनता के कारण, उत्पादन वातावरण, आदि में पिछली विशेषताओं में महत्वपूर्ण कीड़े को ठीक करने की आवश्यकता है ...)
  6. जैसा कि स्क्रैम बताता है, इस बिंदु पर, उत्पाद संभावित रूप से shippable है, लेकिन अनुबंध में उल्लिखित मनी-बैग को 100% सुविधाओं की आवश्यकता होती है। इसलिए वे अनुबंध को तोड़ते हैं और कुछ भी नहीं देते हैं।
  7. स्क्रैम-एडिक्ट्स दिवालिया होने के कगार पर हैं क्योंकि उन्हें मनी-बैग्स से कोई पैसा नहीं मिला था, और निवेशक परिणामों से निराश थे और कंपनी को और अधिक मदद करने के लिए तैयार नहीं थे।

जाहिर है, कोई भी सॉफ्टवेयर कंपनी स्क्रम-एडिक्ट्स के जूते में नहीं रहना चाहती। चंचल और स्क्रम के बारे में समझने में मैं क्या असफल हूँ, वे सुझाव देते हैं कि कैसे टीमों को ऊपर वर्णित स्थिति से बचने के लिए योजना और समय सीमा से निपटना चाहिए। इसलिए, संक्षेप में, मेरे 2 प्रश्न हैं:

किसे दोष दिया जाएं?

  1. प्रबंधकों, क्योंकि यह उचित कार्य करने के लिए उनका काम है
  2. टीम, क्योंकि वे अधिक से अधिक काम करने के लिए प्रतिबद्ध थे
  3. कोई और

क्या करना है?

  1. प्रबंधकों को मूल टीम के अनुमान की तुलना में बाद में समय सीमा 2x (या 3x) को स्थानांतरित करना चाहिए।
  2. टीम के सदस्यों को वह सभी काम करने के लिए प्रोत्साहित किया जाना चाहिए जो उन्होंने बिना किसी समस्या के किए हैं (विफल स्प्रिंट के लिए दंड जारी करके)
  3. टीम को स्क्रैम को छोड़ देना चाहिए क्योंकि यह कंपनी की समय सीमा नीति के अनुकूल नहीं है
  4. हम सभी को सॉफ्टवेयर विकास को छोड़ देना चाहिए और एक मठ में शामिल होना चाहिए
  5. ???

31
आप 3 बिंदु के तहत "करने के लिए" माना जाता है कि स्क्रम का उपयोग नहीं करने से एक महीने में तैयार सुविधाओं का केवल 80% होने में कुछ भी बदल जाएगा। ये बेहूदा है।
डॉक ब्राउन

7
@DocBrown, मैं सहमत नहीं हूँ यह हास्यास्पद है। पूर्वव्यापी और प्रदर्शन बैठकों जैसी कुछ स्क्रम गतिविधियों को छोड़ने से विकास को गति मिल सकती है। और एक ठोस-ठोस अनुबंध के मामले में यह अंतिम लक्ष्य को प्राप्त करने में मदद कर सकता है: समय सीमा के अंत में निश्चित मात्रा में सुविधाएं प्रदान करें।
आंद्रे बोर्जेस

26
@AndreBorges रेट्रोस्पेक्टिव्स और प्रदर्शनों को छोड़ने का आपका सुझाव एक कार से ब्रेक हटाने के सुझाव के समान है। यकीन है, ब्रेक केवल आपको धीमा करता है। लेकिन यह वही है जो आपको वास्तव में तेजी से जाने की अनुमति देता है।
व्यंग्यात्मक

13
एक ही समस्या किसी भी प्रणाली के तहत बनी हुई है - ध्यान दें कि आप बहुत अधिक एक बराबर झरने के साथ घोटाले को बदल सकते हैं और कंपनी अभी भी बस्ट
जेके।

6
शायद अगर उन स्क्रैम-एडिक्ट्स प्रबंधकों ने उन pesky "पूर्वव्यापी" बैठकों के दौरान अधिक ध्यान दिया था, तो उन्हें सप्ताह 1 या 2 पर ब्रेक मारने का मौका मिला होगा, बजाय परियोजना की चट्टान को देखे, और गैस पेडल मारा ।
डोरस

जवाबों:


134

मुझे आपके उदाहरण में कई मूलभूत प्रबंधन मुद्दे दिखाई देते हैं:

  • यदि एक स्क्रम-व्यसनी प्रबंधक "हार्ड-डेडलाइन" अनुबंध पर हस्ताक्षर करता है, लेकिन ऐसी स्थिति में 33% का केवल एक सुरक्षा मार्जिन जोड़ता है जहां "एक नई प्रणाली शामिल है", जो बहुत लापरवाह है।

  • एक महीने के बाद कम से कम x% सुविधाओं को वितरित करने की उपलब्धता का उपयोग एक अनुबंध पर बातचीत करने के लिए किया जा सकता है जहां ग्राहक कम से कम आंशिक रूप से पैसे का भुगतान करता है जब उसे समय सीमा पर केवल 80% सुविधाएँ मिलती हैं। एक ऑल-एंड-नथिंग कॉन्ट्रैक्ट कुछ है जो न तो सॉफ्टवेयर विक्रेता और न ही ग्राहक को फायदा होगा - इसका मतलब है कि विक्रेता के लिए न केवल 0 पैसा है, बल्कि ग्राहक के लिए 0 सुविधाएँ भी हैं। और "वाटरफॉल" जैसी सभी या कुछ भी नहीं विकास पद्धति आपको केवल ऐसे अनुबंध लिखने देगी, एक चुस्त दृष्टिकोण अतिरिक्त संभावनाएं प्रदान करता है।

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

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


47
+1 के लिए "एक ऑल-एंड-नथिंग कॉन्ट्रैक्ट कुछ ऐसा है जो न तो सॉफ़्टवेयर विक्रेता और न ही ग्राहक को फायदा होगा" । यह चुस्त अनुबंध के बारे में महत्वपूर्ण बात है।
guillaume31

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

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

6
लेकिन इस विशिष्ट उदाहरण के लिए ... अगर किसी ने कैमरों को हार्डवेयड्राइवर खत्म करने में विफल रहने पर किसी को भी नए क्षितिज नहीं भेजे होंगे। लेकिन उस पैमाने पर परियोजनाओं के लिए भी मैं शर्त लगा सकता हूं कि हर उस विशेषता के साथ अंतरिक्ष में नहीं जा रहे हैं जिसकी वे कल्पना कर रहे थे।
ज़ैबिस

6
शायद प्रति मील का पत्थर या कार्यक्षमता का भुगतान भी एक विकल्प हो सकता है।
ब्रैम

68

" एगाइल सॉफ्टवेयर डेवलपमेंट के लिए मैनिफेस्टो " के मूल्य विवरणों में से एक है:

अनुबंध बातचीत पर ग्राहक सहयोग

तथ्य यह है कि स्क्रैम-एडिक्ट्स एलएलसी ने एक ग्राहक के साथ सहयोग स्थापित करने के बजाय एक अनुबंध पर बातचीत की, जिससे मुझे उनकी चपलता पर सवाल उठा।

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

यह ग्राहक की गलती है कि वे अपने अनुबंध बुलबुले में समय-सीमा के विकास के साथ बंद हैं।


9
@ रुबरडैक अभी तक एक सॉफ्टवेयर परियोजना प्रबंधन पद्धति है जो सुविधाओं को सामने तय करने की समय सीमा निर्धारित करती है और बहुत महंगी नहीं थी। स्कोप, समय, धन; दो चुनें।
युफोरिक

8
@ रबरडक: परियोजना पहले से ही चुस्त नहीं है, क्योंकि आवश्यकताओं को पत्थर में सेट किया गया है। और अनुमान केवल तीन सप्ताह का है। झरने के बारे में जादुई रूप से बुरा कुछ भी नहीं है जो इसे हमेशा देर से बनाता है, यह सिर्फ अस्पष्ट आवश्यकताओं और परिवर्तन से निपट नहीं सकता है। हाँ, मैं इस मामले में "झरना" का उपयोग करूंगा, या अधिक सटीक रूप से "चलो तय करें कि क्या करना है और क्या करना है"।
रेमकोगर्लिच

3
@RemcoGerlich विडंबना यह है, "चलो तय करते हैं कि क्या करना है और क्या करना है" उल्लेखनीय रूप से फुर्तीली है :-)
gbjbaanb

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

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

15

किसे दोष दिया जाएं?

प्रबंधकों, कानूनी विभाग, लेखाकार - लेने के लिए अपने ...

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

ग्राहक अपने केक को खाना चाहते हैं और इसे खाते हैं - वे झरना, मिनी-झरना, फुर्तीली, ला-ला-लैंड स्वीकार करने में प्रसन्न होते हैं जब तक कि उन्हें उत्पाद Z $ Y के लिए तारीख Z से मिलता है।

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


12

अज्ञात के साथ आईटी परियोजनाएं निपटती हैं ; इन अज्ञात में से कुछ अज्ञात अज्ञात भी हैं । इसका क्या मतलब है?

उदाहरण के लिए अपने मॉडल रेल के लिए एक खिलौना पुल लें। आपके लिए ज्ञात सभी पैरामीटर हैं:

  • आपको पता है कि घाटी कितनी बड़ी है

  • आप पहाड़ों की सामग्री, उनकी ऊँचाई, स्थिरता आदि जानते हैं।

  • आपको पता है कि आपको कितनी सामग्री की आवश्यकता है

  • आप पहले की "परियोजनाओं" से जानते हैं कि इसी तरह की चीजों को बनाने में आपको कितना समय लगा

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

उदाहरण को एक कदम आगे बढ़ाएँ:

  • कहते हैं कि आप अपने खुद के मॉडल रेल के लिए पुल का निर्माण नहीं करते हैं, इसके बजाय आप इसे एक पूर्ण अजनबी के लिए बनाते हैं: आपका काम दो पहाड़ों के बीच एक रेल पुल का निर्माण करना है

  • मान लें कि आपके पास मॉडल परिदृश्य के बारे में पहले से कोई जानकारी नहीं है

  • परिदृश्य के बारे में जानकारी है, कि दो पर्वत हैं, जो बहुत बड़े नहीं हैं

  • पहाड़ की स्थिरता चट्टान और जेली के बीच है

  • कुल लागत में अधिकतम 10 $ है

  • कार्यस्थल पूरा अंधेरा है और प्रकाश की कोई संभावना नहीं है: आपके पास केवल 8 मैचों का एक बॉक्स है

  • समय सीमा 3 घंटे है

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

हर आईटी कंपनी को पता होना चाहिए कि उन्हें परियोजना जोखिम से निपटना होगा।

1) (वित्तीय) जोखिम को कम करने के कई तरीके हैं: इस सौदे में ग्राहक को हर काम करने वाली वेतन वृद्धि के लिए भुगतान शामिल किया जा सकता है। इसलिए वेतन वृद्धि 1 के बाद, एक आंशिक दर का भुगतान किया जाना है। जब तक Scrum-Addicts LLC उद्धार करता है, तब तक न्यूनतम वित्तीय जोखिम होता है। जितने बेहतर स्प्रिंटेड गोल की योजना बनाई जाती है, हर स्प्रिंट का कुल जोखिम उतना ही कम होता है। इसका मतलब है, अगर मनी-बैग्स कॉरपोरेशन को अनुबंध का 80% प्राप्त होता है, तो उन्हें कम से कम 80% अनुबंध मूल्य का भुगतान करना चाहिए। यदि वे विफल स्प्रिंट के बाद भुगतान करने से इनकार करते हैं तो जोखिम 100% का भुगतान करने से इनकार करने के रूप में उच्च नहीं है।

2) Scrum-Addicts LLC को अपने डेवलपर्स के साथ समस्या है

स्क्रम-एडिक्ट्स के प्रबंधक अपनी स्क्रैम टीम से परामर्श करते हैं, और टीम का कहना है कि सभी सुविधाओं को पूरा करने के लिए 3 सप्ताह तक का समय लगेगा, स्क्रेम-एडिक्ट्स प्रबंधक सुरक्षित होने के लिए 1 सप्ताह जोड़ता है, सॉफ़्टवेयर को 1 महीने में शिप करने का वादा करता है और एक अनुबंध पर हस्ताक्षर करता है मनी-बैग के साथ

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

किसे दोष दिया जाएं?

1) प्रबंधन

जैसा कि ऊपर कहा गया है: जोखिम प्रबंधन में स्पष्ट रूप से विफलता है। अगर कंपनी दिवालिया होने की कगार पर है, तो कंपनी इसकी हकदार है। यदि आप ऐसी कंपनी में काम करते हैं: छुट्टी!

2) टीम

यहां तक ​​कि अगर प्रबंधन पूरी तरह से मूर्ख है, तो टीम को इस तरह के प्रोजेक्ट के खिलाफ बोलना चाहिए था। एक अच्छे प्रबंधक को जोखिमों को जानना चाहिए; लेकिन एक अच्छे डेवलपर को जोखिमों को इंगित करना चाहिए। और इन सबसे: टीम को कुछ असफल होने पर जल्दी रिपोर्ट करनी चाहिए।

क्या करना है?

अब: मनी-बैग्स को अदालत में ले जाएं

भविष्य के लिए: ऐसे अनुबंध न करें

प्रबंधन की विफलता के लिए घोटाले को दोष नहीं दिया जाता है। कई आईटी परियोजनाओं के असफल होने के अनुभव के आधार पर स्क्रम विकसित किया गया था। यह विफलता को रोक नहीं सकता है, न ही यह टीमों या प्रबंधन की अक्षमता को ठीक कर सकता है। मूल विचार है:

  • संचार के तरीकों को बनाने के लिए (जो कब किससे बात करता है)

  • डेवलपर की विफलता को जल्दी प्रोत्साहित करने के लिए

  • कार्यों और उपकेंद्रों में समस्याओं को विभाजित करने के लिए

  • संरचना समय और क्षमता (जो कब क्या काम करता है)

  • समय स्लॉट पर कार्यों को वितरित करने के लिए

  • अप्रत्याशित को थोड़ा और अधिक पूर्वानुमानित करें (योजना निर्विकार)

या समग्र: जोखिम को कम करने के लिए।

स्क्रेम एक उपकरण है जैसा कि एक हथौड़ा है। क्या यह एक अच्छा उपकरण है, यह आपके ज्ञान पर निर्भर करता है कि इसका उपयोग कैसे किया जाए। लेकिन कभी-कभी एक पेचकश बेहतर फिट बैठता है। यह आप पर निर्भर करता है।


1
स्क्रम का एक और पहलू है जो यह समझना महत्वपूर्ण है कि यह परियोजना क्यों विफल रही: स्क्रम विफलता को गले लगाता है । यह उम्मीद की जाती है कि एक नई टीम या परियोजना के स्प्रिंट के पहले जोड़े विफल होंगे। रेट्रोस्पेक्टिव के स्कोर प्रक्रिया के माध्यम से टीम में सुधार होगा और दीर्घकालिक उनके अनुमानों में सटीक हो जाएगा, लेकिन जब तक वे एक ही प्रोजेक्ट पर काम कर रहे एक ही टीम बने रहेंगे। जब दोनों में से कोई एक परिवर्तन हो तो आपको एक बार फिर से कुछ असफलता की उम्मीद करनी चाहिए क्योंकि अंतर्निहित चर बदल रहे हैं।
Cronax

9

सबसे पहले, "किसे दोष देना है?" गलत सवाल पूछना है। दोष सौंपना मजेदार और सभी है, और शायद सभी को बनाएगा सिवाय दोषी व्यक्ति (ओं) को राहत महसूस करने के (एक "हे, यह मेरी गलती नहीं है, बॉस ने ऐसा कहा!" भावना), लेकिन यह आपके समय का उत्पादक उपयोग नहीं है। , और वास्तव में उल्टा हो सकता है और कर्मचारी मनोबल में गिरावट का कारण बन सकता है।

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

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

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

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


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

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

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

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

4

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

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

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

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

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

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


6
"क्रिसमस के लिए तैयार खेल" स्क्रम के लिए एक पोस्टरचाइल्ड हो सकता है। आपके द्वारा पूरा किया गया 80% शिप करें, शेष को डीएलसी के रूप में बेच दें। यह काल्पनिक स्थिति पर चर्चा नहीं की गई है, जहां समय सीमा और समय सीमा दोनों तय की गई है, आंशिक डिलीवरी के लिए 100% जुर्माना।
MSalters

2
@MSalters आप मान लेते हैं कि गेम पूरी तरह से काम करता है, 80% गायब फीचर्स नहीं हो सकते जिन्हें बाद में जोड़ा जा सकता है, लेकिन कार्यक्षमता को तोड़ना या बग्स को तोड़ना। यह एक खेल होना जरूरी नहीं है, कोई भी सॉफ्टवेयर हो सकता है जिसे एक निश्चित, और अपरिवर्तनीय समय सीमा के लिए
भेजना होगा

6
यह स्क्रैम का मूल आधार है! टूटी हुई कार्यक्षमता की गिनती नहीं है। यदि आप वाटरफॉल बैकग्राउंड से आते हैं, तो आप पाएंगे कि स्क्रम इसलिए नई सुविधाओं को जोड़ने पर बगफिक्सिंग को प्राथमिकता देता है। "80% किया गया" का अर्थ है कि लापता स्तर, लापता बॉस आदि हैं।
एमएसलटर्स

1
@gbjbaanb उस तर्क के अनुसार, कुछ किया जा सकता है 99.9%, लेकिन फिर भी काम नहीं करता है क्योंकि यह स्टार्टअप पर तुरंत दुर्घटनाग्रस्त हो जाता है।
इमिबिज़

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

4

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

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

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


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

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

2
@AndreBorges निश्चित रूप से ग्राहक 0% सुविधाओं को देखने की तुलना में 80% सुविधाओं को देखकर खुश होंगे? कम से कम उस तरह से, ग्राहक जानता है कि उत्पाद ज्यादातर किया जाता है।
इबिबिज़

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

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

1

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

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

यह डेवलपर के दृष्टिकोण से बहुत अच्छा लगता है, हालांकि, मान लें कि हमारे पास एक सॉफ़्टवेयर कंपनी "स्क्रैम-एडिक्ट्स एलएलसी" है जो गंभीर ग्राहकों के लिए कुछ विकसित कर रहा है ("मनी-बैग्स कॉर्पोरेशन"):

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

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

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

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

WHY MB के बारे में सोचें कि वे अपनी गेंद लेकर घर जाना चाहते हैं। एमबी ने एक महीने में काम शुरू करने की मांग नहीं की। SA ने एक महीने में 100% महत्वपूर्ण सुविधाओं का वादा किया और वितरित नहीं किया। SA ने समय सीमा तय की MB नहीं। एसए ने भी मनमाने ढंग से समय सीमा में एक सप्ताह जोड़ दिया। तो यह एक समय सीमा क्यों है?

कभी-कभी जब काम करने वाली कंपनियों के लिए प्रतिस्पर्धा होती है, तो चंद्रमा को दिखाने और वादा करने का प्रलोभन दिया जाता है। पेशेवर सावधानीपूर्वक स्थापित करते हैं कि क्या चंद्रमा की भी आवश्यकता है। मनीबैग के लिए अधिक महत्वपूर्ण आवश्यकता कौन सी है? 100% सुविधाएँ या एक महीने के समय में एक कार्यशील उत्पाद? क्या वे भी जानते हैं कि वास्तव में क्या महत्वपूर्ण है? क्या कोई आगामी घटना एक कठिन समय सीमा तय कर रही है?

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

इस तरह से एक महीने में सब कुछ अचानक पूरी तरह से काम करने की उम्मीद करने के बजाय वे 1 से 2 सप्ताह में पहले सुपुर्दगी का मूल्यांकन करने की उम्मीद करेंगे।

इसलिए, संक्षेप में, मेरे 2 प्रश्न हैं:

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

सड़क पर एक महीना उतरने से पहले कोई भी इस संकट को रोक सकता था।

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

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

क्या करना है?

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

प्रबंधकों को मूल टीम के अनुमान की तुलना में बाद में समय सीमा 2x (या 3x) को स्थानांतरित करना चाहिए।

डेडलाइन मल्टीप्लायर आपके वॉच को 15 मिनट पहले सेट करने में उतना ही उपयोगी है जितना कि आपको कभी देर नहीं होगी। आप अपने आप को केवल तभी तक मूर्ख बना सकते हैं जब तक आपको एहसास हो जाए कि आप क्या कर रहे हैं।

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

टीम के सदस्यों को वह सभी काम करने के लिए प्रोत्साहित किया जाना चाहिए जो उन्होंने बिना किसी समस्या के किए हैं (विफल स्प्रिंट के लिए दंड जारी करके)

टीम के सदस्यों को प्रोत्साहित किया जाना चाहिए। विफल, प्रतिबद्ध, या अन्यथा। सजा या बोनस (गाजर और छड़ी) जैसे किसी भी कृत्रिम परिणाम के निर्माण के बजाय, अध्ययन से पता चला है कि प्रोग्रामिंग जैसे रचनात्मक कार्य करने वाले लोग तीन चीजें प्रदान करते हैं तो सबसे अच्छा जवाब देते हैं: स्वायत्तता, महारत और उद्देश्य।

डैनियल पिंक ने इस बारे में एक टेड बात की है। बात चपलता की नहीं बल्कि प्रेरणा की है, लेकिन मैंने आसानी से देखा कि चुस्त करने के लिए इन बिंदुओं को कैसे चित्रित किया जाए:

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

टीम को स्क्रैम को छोड़ देना चाहिए क्योंकि यह कंपनी की समय सीमा नीति के अनुकूल नहीं है। स्क्रैम वाटरफॉल की तुलना में अधिक समय सीमा को हिट कर सकता है। एक समय सीमा को देखते हुए घोटाले को पूरा कर सकते हैं। यह समय, सुविधा और कौशल के आधार पर 47 में से केवल 1 सुविधाओं के साथ मिल सकता है, लेकिन यह इसे पूरा कर सकता है।

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

हम सभी को सॉफ्टवेयर विकास को छोड़ देना चाहिए और एक मठ में शामिल होना चाहिए

ठीक है, मुझे वास्तविक जीवन से दूर एक कमरे में बंद करने की तरह है, जिससे मुझे कम से कम कोड लिखना है।

मैंने इस उत्तर को आकार में नीचे संपादित किया है। यदि आप उत्सुक हैं तो संपादित इतिहास पढ़ें।


मैं आपको केवल स्प्रिंट नहीं बैकलॉग का मतलब मान लेना चाहता हूं - मेरा मतलब है कि मैंने सवाल में क्या लिखा था: स्प्रिंट बैकलॉग
आंद्रे बोर्ग्स

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

@AndreBorges तुम सही हो, मैं उत्पाद बैकलॉग के बारे में सोच रहा था। हाल ही में मैं एक उपकरण के साथ काम कर रहा हूं, जो स्प्रिंट बैकलॉग को स्प्रिंट कहता है और उत्पाद बैकलॉग को बैकलॉग करता है। आपने मुझे अपनी शब्दावली को मालिकाना बनाए रखने की लड़ाई हारते हुए पकड़ा।
कैंडिड_ओरेंज

@AndreBorges प्रोग्रामिंग कभी लिफाफा भराई नहीं होगी। यह दृढ़ता से एक मोमबत्ती की समस्या है। कारण यह है कि किसी भी दोहराए जाने वाली समस्या को उसी कोड से हल किया जा सकता है जिसने पहली समस्या को हल किया था। इसके बावजूद प्रबंधन एक मानसिकता में आ सकता है जहां उन्हें लगता है कि रचनात्मकता पर मुहर लगाने की समस्या है। मैंने इनमें से कई दुकानों से काम किया है। वे अच्छे लोगों को नहीं रखते। वे अच्छे सॉफ्टवेयर का उत्पादन नहीं करते हैं। डेवलपर कारीगर हैं। उन्हें विधानसभा लाइन के कार्यकर्ताओं में बदलने की कोशिश केवल आपके कारण को नुकसान पहुंचाती है। मेरा काम अंडे फुलाना नहीं है। यह सुनिश्चित करना है कि अंडे फ़्लिप किए जाएं।
कैंडिड_ओरेंज

0

सभी को चुस्त रहना होगा। जो कुछ भी आप तय करते हैं वह होगा, जैसे, सभी पक्षों द्वारा क्या, कैसे, कब, कहाँ और क्यों किया जाता है। चुस्त ग्राहक, प्रबंधन और डेवलपर्स।

आप भविष्य में बहुत दूर शिपिंग तिथि नहीं दे सकते। आप एक अनुमान देते हैं।

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

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

कौन जानता है, कुछ परियोजनाओं पर, आप जल्द ही जहाज कर सकते हैं।

यदि ग्राहक नहीं चाहता है तो आप चुस्त नहीं हो सकते।


0

लक्ष्य

मेरा मानना ​​है कि निम्नलिखित दो "मेट्रिक्स" किसी भी व्यावसायिक निर्णय के लिए आधार होना चाहिए:

  • काम लाभदायक है (ग्राहक के लिए)
  • क्या हम यथासंभव कुशल काम कर रहे हैं

ये काफी सार्वभौमिक हैं। बेशक, यह बहुत अधिक जटिल हो जाता है, उदाहरण के लिए, काम का लाभदायक होना उत्पाद के सही काम करने के बारे में है, उपयोगकर्ता उत्पाद का उपयोग करने में सक्षम है, उत्पाद को सही ढंग से विपणन किया जा रहा है आदि - इनमें से बहुत सारे के लिए " स्क्रम-एडिक्ट्स " एलएलसी ”जिम्मेदारी वहन नहीं कर रहा है।

मुद्दा

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

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

दिन के अंत में, हमें एक समझौता चुनना होगा जो हमें अपने लक्ष्यों को यथासंभव बेहतर बनाने की अनुमति देगा।

यह है कि यह कैसे काम करना चाहिए

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

अच्छी तरह से मैं मूल रूप से कहा "चुस्त हो"। अब यहाँ क्यों है:

  • प्रक्रिया और अनुबंध लक्ष्य के रूप में संभव के रूप में लक्ष्य पर अधिक पैसा खर्च करने के लिए अनुकूलित कर रहे हैं
  • आपको अपना काम करने के लिए ठेकेदार पर भरोसा करना होगा, और यह सत्यापित करने के लिए बहुत सारे पैसे का निवेश करने की आवश्यकता नहीं है कि वह नौकरी पर है।
  • अपने ठेकेदार पर मुकदमा करने की क्षमता यदि आपकी अपेक्षाओं / अनुबंध को पूरा नहीं किया जाता है तो आमतौर पर मदद नहीं मिलती है, क्योंकि ऐसा करने से इसे छोड़ने की तुलना में अधिक खर्च होगा। यहाँ मुख्य चिंताओं में से कुछ समय-समय पर बाजार में हैं। आप सबसे अधिक संभावना है कि आप अदालत में जाकर अधिक पैसा / व्यवसाय खो देंगे।
    • दिन के अंत में आपको बस कुछ जोखिम खुद उठाने होंगे।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.