काम करने के लिए "एजाइल" तत्वों के लिए निश्चित डिलीवरी की तारीखें हैं?


47

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

मेरे लिए यह सबसे खराब अर्थों में झरना जैसा लगता है, तकनीकी टीम के बिना इनपुट वाली एक योजना तैयार की गई है जहाँ योजना की कुछ कहानियाँ बहुत अस्पष्ट हैं और देव टीम द्वारा किसी का अनुमान नहीं लगाया गया है।

हालाँकि, मुझे पता है कि उनका तर्क होगा "वरिष्ठ हितधारकों के पास तारीखें होनी चाहिए और एक योजना होनी चाहिए, हम सिर्फ एक बैकलॉग से काम नहीं कर सकते हैं।" मेरे लिए ऐसा लगता है कि वरिष्ठ हितधारकों ने एजाइल में खरीदारी नहीं की है और इसलिए हम इसे निचले स्तर पर लागू करने में विफल हैं।

क्या यह एक उचित निर्णय है या क्या मैं इस योजना को खत्म कर रहा हूँ !?


28
आपका प्रबंधन क्या लेकर आया था, इसका एजाइल से कोई लेना-देना नहीं है।
यूफोरिक जूल

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

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

3
@Kyralessa कम से कम मेरे अनुभव से, स्क्रम लगभग हमेशा एक चुस्त कार्यप्रणाली के रूप में बेचा जाता है।
टी। सर -

3
त्वरित अनुसंधान से @kyralessa मैं कर सकता था ऐसा लगता है कि आप केवल एक ही कहना है कि SCRUM चुस्त नहीं है। यदि आपके पास इसे वापस करने के लिए कुछ संदर्भ है तो मुझे उन्हें पढ़ना अच्छा लगेगा।
न्यूटॉपियन

जवाबों:


60

समय सीमा को पूरा करने और सभी आवश्यकताओं को पूरा करने के बीच एक अंतर है। इसकी पुरानी कहावत की तरह "तेज, अच्छा या सस्ता, दो उठाओ"।

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

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

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


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

3
@ क्रोनैक्स नाम के लायक हर प्रबंधक समय को समझेगा और सुविधाएँ विरोध कर रही हैं। आप चुनते हैं कि कौन सा सबसे महत्वपूर्ण है। यदि वे तय करते हैं कि उन्हें पूर्ण और समय-समय पर फीचर किया जाना है, तो टीम को उचित रूप से प्रबंधित नहीं करने के लिए उनकी गलती है। (मुझे पता है, मुझे पता है ...)
gbjbaanb

3
@ क्रोनैक्स गरीब प्रबंधकों पर बहुत मुश्किल नहीं है, अक्सर इसकी बिक्री जो उन्हें इसमें छोड़ देती है।
gbjbaanb

5
इसे पढ़ते हुए कहा गया "सभी काम वे चाहते हैं कि हम प्रत्येक तत्व के खिलाफ तारीखों के साथ वितरित करें और तिथियों को फिर से प्रदर्शित करें कि प्रत्येक में क्या प्रदर्शित किया जाएगा," ऐसा नहीं लगता है कि दी गई तारीखों को पूरा करने के लिए योजना लचीली है।
जिम्मीजम्स

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

37

नहीं, यह गैर-सॉफ्टवेयर कंपनियों के लिए सही चीजें हैं। योजनाएं, और समय सीमाएं और बजट हैं। और यह अनिवार्य रूप से विफल हो जाएगा, क्योंकि मनुष्य भविष्य की भविष्यवाणी करते हुए चूसते हैं।

आइए यहां विभिन्न बिंदुओं से गुजरते हैं:

हमें बताया जाता है कि हम वरिष्ठ प्रबंधन द्वारा एक नई परियोजना पर चुस्त तरीके से काम करने जा रहे हैं।

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

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

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

देव टीम द्वारा किसी का अनुमान नहीं लगाया गया है।

तो प्रबंधन को पता है कि इस योजना व्यवहार्य है सब पर ? एजाइल में, काम एक बातचीत है। व्यवसाय कहता है: हम इसे पसंद करेंगे। इंजीनियरिंग का कहना है: ठीक है, XYZ संभालने, कि 3 सप्ताह लगेंगे। आप जो वर्णन कर रहे हैं उसमें कोई ग्राहक सहयोग नहीं है। कोई व्यक्ति और सहभागिता नहीं।

मेरे लिए ऐसा लगता है कि वरिष्ठ हितधारकों ने एजाइल में खरीदारी नहीं की है और इसलिए हम इसे निचले स्तर पर लागू करने में विफल हैं।

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

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


6
निराशावाद @Wildcard? या यह यथार्थवाद है ?
रबरडक

7
@Wildcard और विडंबना यह है कि भविष्य के बारे में भविष्यवाणियां करना ;-)
Cort Ammon

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

8
@ गिल्डकार्ड - No plan survives contact with the enemy। और आप मुझे बता नहीं सकते कि NYSE जनवरी 2020 को सबसे बड़ा विजेता कौन होगा। यह सच है। हमारे पास कई सहस्राब्दियों के आंकड़े हैं जो यह बताते हैं कि यह सच है। और जानते हुए भी क्या तुम नहीं / नहीं कर सकते पता है की है महत्वपूर्ण असहायता जब निर्माण सॉफ्टवेयर करने के लिए योजना बना। ओपी की स्थिति को देखें - उनकी योजना का भारी बहुमत अनुमानों पर बनाया गया है जो मौका से बेहतर नहीं है । मुझे लगता है कि यह योजना बनाने का एक भयानक तरीका है। यहां तक ​​कि अगर आपको लगता है कि यह मेरे लिए भोला और घातक है, यह अभी भी चुस्त नहीं है।
तेलस्तीन

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

18

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

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

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

यदि आप एक एकीकृत मोर्चे को प्रस्तुत करने के लिए देव टीम प्राप्त कर सकते हैं, तो आपको वास्तव में वापस धक्का देना चाहिए और गुणवत्ता पर रेखा को पकड़ना चाहिए। मेरा अनुभव है कि परियोजना प्रबंधक सॉफ्टवेयर उत्पादन को रैखिक मानते हैं। अर्थात्, प्रत्येक अवधि X, Y 'प्रीसेंटेज पूर्ण' का उत्पादन करेगा। यही है, यदि आप अनुमत समय के माध्यम से आधे रास्ते तक "50% पूर्ण" नहीं हैं, तो klaxons धुंधला होने लगती हैं। वास्तव में, यदि आप इसे सही कर रहे हैं, तो पहली विशेषता 50 वें फीचर (समान आकार) की तुलना में बहुत अधिक समय लेती है। यदि आप उस प्रारंभिक खतरे के संकट काल ("क्या हो रहा है?", "I don ') के माध्यम से प्राप्त कर सकते हैं। t कुछ भी करते देखिए! ") आप शायद ठीक हो जाएंगे।


9

वास्तविक व्यवसाय में आपका स्वागत है।

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

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

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

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

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

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

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

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


4

एजाइल आपको मील के पत्थर की योजना बनाने से नहीं रोकता है (जैसे हम 3 महीनों में वी 1.0 जारी करेंगे), लेकिन प्रत्येक मील के पत्थर में जो जाता है उसे ठीक नहीं किया जा सकता है।

मुझे लगता है कि आपको कैसे प्रतिक्रिया करनी चाहिए यह परियोजना की प्रकृति पर निर्भर करता है। यदि परियोजना को Q2 2017 तक एक आदमी को चंद्रमा पर भेजना है, तो हर कोई सहमत होगा कि यह विफल होने के लिए बर्बाद है। यदि आपको लगता है कि आप Q2 2017 के अंत तक MVP वितरित कर सकते हैं, तो आपको स्प्रिंट द्वारा उस पर काम करना चाहिए।

यदि प्रबंधन को लगता है कि आपकी टीम अपना सर्वश्रेष्ठ प्रदर्शन कर रही है और आप प्रत्येक स्प्रिंट के साथ प्रगति दिखा सकते हैं तो आपको अधिक समय तक बातचीत करने में सक्षम होना चाहिए।


4

हर कारोबारी प्रासंगिक परियोजना में अड़चनें हैं:

  • समय
  • साधन
  • एक अपेक्षित न्यूनतम सुविधा सेट

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

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

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

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


3

जैसा कि किसी ने घोषणा पत्र से पहले ही बताया है:

व्यक्तियों और बातचीत प्रक्रिया पर

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

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

यह वह बिंदु है जहां यह दो रास्ते जा सकता है।

  1. उत्पाद के मालिक और व्यवसाय आपके तर्क से सहमत होते हैं और समय सीमा को पूरा करने के लिए संसाधन बढ़ा सकते हैं यदि यह विकल्प है या वे समय सीमा को पूरा करने के लिए कुछ सुविधाओं को छोड़ने का चयन कर सकते हैं।

  2. वे अभी भी टीम की सामूहिक राय के खिलाफ अपने स्वयं के संस्करण से चिपके रहना चाहते हैं।

यदि परिणाम # 2 है तो यह फुर्तीली नहीं है।

यदि आप # 1 के साथ समाप्त होते हैं, तो मैं कहूंगा कि टीम सही रास्ते पर है, क्योंकि एजाइल सिर्फ देवों के बारे में नहीं है "बदलने का जवाब" यह व्यवसाय के बारे में भी है जो परिवर्तन का जवाब देने में सक्षम है।


2

किसी के लिए एक दीवार, एक घर और फिर एक पूरी गली को रंगने के लिए कहने की कल्पना कीजिए, आप उस व्यक्ति को इसे करने के लिए कितना समय देंगे?

आपका जवाब जो भी हो, आप गलत होंगे। बस।

कोई तरीका नहीं है कि वे तारीखों के बारे में सही हो सकते हैं यदि वे उन लोगों से नहीं पूछते हैं जो काम करने की ज़रूरत है जो वे सोचते हैं।

वैसे, यदि आप (एक टीम के रूप में) इन तारीखों को स्वीकार करते हैं , तो आप वहां गलत हैं।

आपको हितधारकों के साथ इस योजना पर काम करने के लिए कुछ समय मांगना चाहिए, ताकि आप चीजों को प्राप्त करने के लिए कितना आसान और तेज हो, इसके आधार पर प्राथमिकताएं निर्धारित कर सकें।

उदाहरण के लिए, हो सकता है कि अंतिम काम में दो बार लगेंगे जब तक उन्होंने सोचा था, लेकिन वे जितनी जल्दी हो सके एक बीटा का उपयोग कर सकते थे।

सब के सब, आप लोगों को यह सोचने नहीं दे सकते हैं कि आप वाई समय में एक्स कर पाएंगे यदि आप नहीं कर सकते हैं या तेज हो सकते हैं, तो यह आपकी जिम्मेदारी है कि आप इस बारे में स्पष्ट करें कि आपको विवरण और समय के संदर्भ में क्या चाहिए।


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

-2

इसका एग्ली प्लानिंग नं।

लेकिन अगर आप सलाह देते हैं कि आप योजना नहीं जानते हैं और बस स्प्रिंट द्वारा काम करते हैं। यह काम करने वाला अग्ली हो सकता है।

हमेशा डेट्स और बजट होने वाले हैं। हमेशा एक जोखिम होता है कि वे छूट जाएंगे या खत्म हो जाएंगे और जब ऐसा होता है तो आपको हमेशा एक योजना बी में वापस आना होगा।

अगर आप चुस्त तरीके से काम कर रहे हैं तो प्लान बी उम्मीद के आखिरी स्प्रिंट के डेमो है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.