क्या डेडलाइन है फुर्तीली?

Question

स्पष्टता के लिए, एक समय सीमा है:

एक समय सीमा या समय सीमा समय का एक संकीर्ण क्षेत्र है, या समय में विशेष बिंदु है, जिसके द्वारा एक उद्देश्य या कार्य पूरा होना चाहिए।

^{से विकिपीडिया}

मेरा पूरा सॉफ्टवेयर डेवलपमेंट करियर मैं "एजाइल" कर रहा हूं, जो हर जगह कम से कम निम्नलिखित प्रथाओं का पालन करने का मतलब लगता है:

• साप्ताहिक या द्वि-साप्ताहिक स्प्रिंट
• रेट्रोस्पेक्टिव्स स्प्रिंट प्लानिंग
• एक उत्पाद का मालिक
• जमघट
• प्रयोक्ता कहानियां

हालाँकि, मैं कभी भी हर परियोजना की समय सीमा तय करने पर जोर देता हूं। यह देखते हुए कि एजाइल अनुकूली योजना, लचीलेपन और परिवर्तन पर ध्यान केंद्रित करने का प्रयास करता है; डेडलाइन्स हैं फुर्तीली?

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

Comments

स्प्रिंट एक समय सीमा के रूप में नहीं है?

— जेएफओ

@ जेफे एक स्प्रिंट एक प्रतिबद्धता है, जो आपकी टीम के वेग के आधार पर बदलता है। डेडलाइन IMO है, क्लाइंट के लिए ईमानदारी या पारदर्शिता के बिना प्रतिबद्धता। वे सॉफ्टवेयर परियोजनाओं को बनाने में जाने वाले अन्य जोखिमों या अन्य जोखिमों की भीड़ को ध्यान में नहीं रखते हैं।

— स्टेवबोट

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

— कैलफूल

यहाँ रॉन जेफ्रीज़ '(एजाइल मेनिफेस्टो के मूल लेखकों में से एक) समय सीमा पर है: xprogramming.com/articles/jatmakingthedate

— जूल्स

मेरे कुछ डेडलाइन काफी चुस्त साबित हुए हैं।

— psr

Answer 1

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

कार्य पूरा होने के लिए उपलब्ध समय को भरने के लिए विस्तार करता है।

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

समय सीमा के संबंध में, एजाइल कुछ चीजें करने की कोशिश करता है:

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

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

तो हाँ। "फुर्तीली" और "समय सीमा" पूरी तरह से संगत हो सकती है।

Comments

@stevebot यह वही स्थिति है जो पार्किन्सन के कानून का संकेत देती है। मैं एक ऐसे ग्राहक से कभी नहीं मिला हूं जो जोड़ने के लिए और अधिक सुविधाओं के बारे में नहीं सोच सकता है। समय सीमा के बिना, सुविधा सूची, और इस प्रकार परियोजना अनंत है।

— एरिक किंग

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

— एरिक किंग

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

— कैफूल

"हमें 28 जुलाई तक जहाज चलाना होगा।" इस वाकये की समय सीमा 28 जुलाई है। आपके पास "कुछ" आवश्यकताओं का एक पूर्व निर्धारित सेट हो सकता है, या यह हो सकता है जो भी तैयार हो। "कुछ" हिस्सा समय सीमा नहीं है। तारीख की समय सीमा है।

— एरिक किंग

@stevebot "(जवाब) पाठक को यह विश्वास दिलाने के लिए गुमराह करता है कि एजाइल + डेडलाइन = पूरी तरह से ठीक है।" हालांकि यह बात है। चंचल है समय सीमा के साथ बिल्कुल ठीक। या बिना अपना चयन ले लो। अन्यथा कहने के लिए मूल रूप से कह रहा है "ठीक है, क्योंकि हमारे पास एक समय सीमा है, हम इस परियोजना को चुस्त नहीं कर सकते हैं!" जो बाल्नी है। मैंने कई परियोजनाओं पर काम किया है जिनमें दोनों समय सीमाएं हैं और "चुस्त" रही हैं। क्या समय सीमा चुस्त हैं? खैर, वे चुस्त नहीं हैं ।

— एरिक किंग

Answer 2

डेडलाइन जीवन का एक तथ्य है। ऐसी चीजें हैं जो बहुत ही दृढ़ तिथि हैं।

हमें Comdex द्वारा सॉफ्टवेयर की आवश्यकता है

या

ब्लैक फ्राइडे तक गेम को स्टोर शेल्फ पर होना चाहिए

और जैसे। कोई भी कॉमडेक्स या ब्लैक फ्राइडे को स्थगित नहीं कर सकता है - बाकी दुनिया उस तरह से काम नहीं करती है।

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

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

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

चंचलता के संदर्भ में जो दूसरा भाग करना चाहता है, वह यह है कि भले ही सुविधाओं पर सहमति का केवल एक हिस्सा पूरा हो (जो भी कारण हो), सॉफ्टवेयर का वर्तमान संस्करण उपयोगी और तैनाती योग्य है।

ठीक है, हम 15 अप्रैल को तैनात किए जाने वाले कर सॉफ्टवेयर के लिए हम चाहते हैं कि सब कुछ होने से चूक गए, लेकिन हमें 75% मिला है और हमारे पास क्या काम है और पिछले नवंबर से शुरू होने के बाद से हम काम कर रहे हैं। हमें पता है कि हम दिसंबर के मध्य से पूर्ण सुविधा सेट को तैनात करने में सक्षम नहीं होंगे और ग्राहक आधार के 80% पर हमारे प्रयासों को फिर से शुरू करेंगे।

Comments

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

— कलफूल

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

— EKW

Answer 3

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

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

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

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

Answer 4

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

डेडलाइन हमेशा गलत नहीं होती है। जैसा कि हम सभी ने ओबी-वान से सीखा है:

"केवल सीथ सौदा में निरपेक्षता"

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

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

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

Answer 5

यदि कोई समय सीमा निर्धारित करना चाहता है तो वह ठीक है और समय सीमा तय की जा सकती है, लेकिन उन्हें जो समझना चाहिए वह है कि यदि समय सीमा तय हो गई है, तो गुंजाइश लचीली रहनी चाहिए।

tl; डॉ

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

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

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

देव टीम (D): "क्या आप उन सुविधाओं को प्राथमिकता दे सकते हैं जिन्हें आप वितरित करना चाहते हैं, सबसे महत्वपूर्ण सबसे पहले?"

ग्राहक (C): "सब कुछ प्राथमिकता 1 है - मैं चाहता हूं कि ये सभी अगले महीने के अंत तक हो जाएं।"

डी : "यह संभव हो सकता है, लेकिन यह संभव नहीं हो सकता है अगर आवश्यकताएं बदल जाती हैं या हम उन मुद्दों की खोज करते हैं जो हम विकास से गुजरते समय उम्मीद नहीं करते थे।"

C: "ठीक है अगर मैं तुम्हें और पैसे दूं तो क्या होगा?"

डी: " आह ... और भी अधिक संसाधन के साथ, यह वास्तव में प्राप्त करने के लिए उन्हें एक महीने के लिए ले जा रहा है; इसलिए यदि आप सुनिश्चित नहीं हैं कि सुविधाओं को प्राथमिकता कैसे दें तो हमें बताएं कि आप पहले कौन से काम करना चाहते हैं।"

सी: "ठीक है मैं बड़ा बटन चाहता हूं लेकिन इसे वास्तव में बड़ा बना दो, और फिर ... आदि"

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

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

कभी-कभी ग्राहक को यह पसंद नहीं होता है कि उन्हें वह नहीं मिलेगा जो वे एक निश्चित तारीख तक चाहते हैं लेकिन BUT उन्हें समझ में आ जाएगा कि उन्हें क्यों और क्या मिलता है। और सुविधाओं के 6 महीने बाद ग्राहक को परवाह नहीं होगी या याद नहीं होगा कि आपने एक निश्चित तारीख तक दिया है, वे उस उत्पाद की गुणवत्ता को याद रखेंगे जिसका वे अभी भी उपयोग कर रहे हैं।

Comments

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

— एरिक किंग

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

— पोस्टकोडिज्म

Answer 6

समय सीमा परंपरागत रूप से व्यापार जीवन चक्र पर आधारित होती है। 15 अप्रैल तक कर सॉफ्टवेयर की जरूरत है। अगले वित्तीय वर्ष के लिए रिपोर्टिंग जुलाई तक करने की आवश्यकता हो सकती है।

चंचल घोषणापत्र कहता है:

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

व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर

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

एक योजना के बाद बदलने पर प्रतिक्रिया

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

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

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

Comments

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

— एरिक किंग

@ EricKing हाँ, आप सही हैं, फुर्तीली डेडलाइन के साथ काम कर सकती है, मुझे लगता है कि मैं आपके बयानों को "डेडलाइन्स के साथ एजाइल काम करता है" के बजाय "डेडलाइन्स एजाइल" के रूप में पढ़ रहा हूं।

— स्टेवबोट

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

— एरिक किंग

Answer 7

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

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

Comments

BTW, काल, मैं बहुत कुछ आप यहाँ कह रहे हैं के साथ सहमत हूँ। और मुझे नहीं लगता कि उसने जो लिखा है उसका खंडन करता है।

— रॉबर्ट ब्रिस्टो-जॉनसन

Answer 8

टी एल; डॉ

क्या डेडलाइन [a] gile? ... [D] eadlines को हाथ से जाने के लिए देखा जाता है [a] gile डेवलपमेंट।

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

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

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

टाइम-बॉक्स सोचें, डेडलाइन नहीं

हालाँकि, मैं कभी भी हर परियोजना की समय सीमा तय करने पर जोर देता हूं। यह देखते हुए कि एजाइल अनुकूली योजना, लचीलेपन और परिवर्तन पर ध्यान केंद्रित करने का प्रयास करता है; डेडलाइन्स हैं फुर्तीली?

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

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

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

टाइम-बॉक्स के आधार पर रिलीज की योजना

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

उदाहरण के लिए, एक परियोजना 20 पुनरावृत्तियों के अंत में किसी परियोजना के v1.0 को जारी करने के लिए प्रतिबद्ध हो सकती है; जो जारी किया गया है उसका दायरा परियोजना के जीवन पर बदल सकता है (जैसा कि गुंजाइश, सुविधाएँ, और प्राथमिकताएँ हर स्प्रिंट की शुरुआत में बदल सकती हैं), लेकिन परियोजना की योजना में प्रत्येक रिलीज़ के लिए लक्ष्य तिथियाँ निर्धारित हैं। टीम प्रत्येक स्प्रिंट को संभावित-shippable वेतन वृद्धि देने का प्रयास करती है, और Done की परिभाषा में गुणवत्ता जांच जैसे निरंतर एकीकरण शामिल हैं ताकि यह सुनिश्चित हो सके कि परियोजना प्रत्येक स्प्रिंट के अंत में एक भरोसेमंद स्थिति में है।

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

यह सभी देखें

• चंचल रिहाई योजना कैसे करें

Comments

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

— कैलफूल

Answer 9

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

चपलता क्या लाती है जो बीच में होती है। एक सख्त सॉफ़्टवेयर आवश्यकताओं के विनिर्देशन दस्तावेज़ होने के बजाय, जो यह निर्धारित करता है कि आपको किसी दिए गए दिनांक के लिए फ़ीचर A, उप-सुविधाएँ B, C, D और E से बना होना चाहिए, आप किसी दिए गए दिनांक के लिए सुविधा A को वितरित करने के लिए प्रतिबद्ध हैं, जिसे देखते हुए प्रारंभिक चरण, न तो आप और न ही आपके ग्राहक को पता है कि सुविधा कैसी दिखेगी, या इसमें बी, सी, डी और ई या शायद बी और सी, या अन्य उप-सुविधाओं के एक दर्जन उप-विशेषताएं होंगी।

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

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

आपको ग्राहक के दृष्टिकोण को भी समझना चाहिए:

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

• एक प्रतिबद्धता के बिना, यह एक डेवलपर या एक उपठेकेदार के लिए आकर्षक है या तो पूर्णतावादी बनें या परियोजना को कम प्राथमिकता दें। हालांकि स्प्रिंट की नियमितता इस जोखिम को पूरी तरह से रोकती नहीं है।

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

Comments

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

— स्टीवेबोट

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

— आर्सेनी मूरज़ेंको

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

— स्टीवेबोट

Answer 10

एक्सट्रीम प्रोग्रामिंग रिलीज के बारे में बताता है:

रिलीज़ प्लानिंग का आधार दर्शन यह है कि एक परियोजना को चार चर: गुंजाइश, संसाधन, समय और गुणवत्ता द्वारा निर्धारित किया जा सकता है।

जो उचित लगता है। इसमें यह भी कहा गया है कि

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

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

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

Answer 11

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

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

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

Answer 12

डेडलाइन चुस्त नहीं है, वे हैं:

1) झरना, और 2) गलत।

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

"आप समय सीमा जानते हैं और / या बदलने जा रहे हैं, हम इसे जानते हैं, इसलिए हम दाहिने पैर से उतरते हैं और दिखावा भी नहीं करते"

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

जिस किसी ने भी लम्बे समय तक कंप्यूटर गेम खेला वो जानता है कि यह कैसे काम करता है! यदि पहली रिलीज़ बीटा मानकों तक है, तो कई गेमर्स खुश हैं, इसलिए वास्तविक जीवन में "फर्म, रियल डेडलाइन्स" का मतलब कम है।

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

चंचल इस तरह से कोमलता का फायदा उठाने की कोशिश करता है कि वह परियोजना के पाठ्यक्रम को विकसित करने और बदलने की अनुमति देता है ताकि पुल डिजाइन कभी नहीं बन सके।

Comments

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

— कैफूल

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

@ मिचेल्ट: यदि आप पहले से ही नहीं हैं, तो मैं आपको टॉम एंड मैरी पोपेंडीकीक्स की पुस्तक "लीडिंग लीन सॉफ्टवेयर डेवलपमेंट: रिजल्ट्स द नॉट द पॉइंट" को पढ़ने का सुझाव दूंगा। वह बस दुबला / चुस्त हलकों में एक काफी लोकप्रिय मेम बता रहा है। यदि आप और आपकी टीम निरंतर सुधार पर ध्यान केंद्रित करने से अधिक समय सीमा पर ध्यान केंद्रित कर रहे हैं, तो आप वास्तव में चुस्त नहीं हैं। हो सकता है कि आप घबरा रहे हों, लेकिन फुर्तीले नहीं रह रहे हों। क्या लंबी अवधि की समय सीमा मौजूद है? जाहिर है। क्या वे चुस्त टीम पर ध्यान केंद्रित करना चाहिए? बिलकुल नहीं। डेडलाइन चंचल सोच के लिए आकस्मिक हैं ।

— कैफूल

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

— नागोरा

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

— कैलफूल

Answer 13

उत्तर "शायद नहीं"

Project_management_triangle कहा गया है कि लागत, समय और गुंजाइश (और यह भी गुणवत्ता) एक दूसरे पर निर्भर हैं। ("दो चुनें और तीसरा प्राप्त करें")

एक स्क्रम स्प्रिंट निश्चित समय (यानी 7 दिन = स्प्रिंट की लंबाई) और लागत (यानी 7 टीम के सदस्यों के लिए बजट) चुनता है और स्कोप का अनुमान लगाता है (स्प्रिंट में की जाने वाली कहानियों की संख्या)

यदि प्रबंधन या बिक्री-विभाग सभी तीनों (लागत, समय और गुंजाइश) को परिभाषित करने की कोशिश करता है, तो यह घबराहट की स्थिति में फुर्तीली नहीं है, क्योंकि टीम लक्ष्य तक पहुंचने का वादा नहीं कर सकती है (गुणवत्ता का उल्लंघन किए बिना = परिभाषा-रहित)

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

Answer 14

क्या यह सीधे और सीधे जवाब नहीं दिया जा सकता है?

कोई डेडलाइन चुस्त नहीं है।

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

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

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

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

Answer 15

संगठन के चार्ट पर उनकी स्थिति कितनी अधिक है, किसी के काम में अपेक्षित चपलता इसके विपरीत आनुपातिक है।

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

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

लेकिन आत्मज्ञानी की तरह, यह वास्तव में मौजूद नहीं है।

Comments

एक समय सीमा जिसे स्थानांतरित किया जा सकता है वह समय सीमा नहीं है। इसे कैलेंडर तिथि कहा जाता है। डेडलाइन ब्लैक फ्राइडे जैसी चीजें हैं - या तो यह स्टोर में है या यह नहीं है। फिर भी, चंचल का मतलब है कि मेरे पास सबसे अच्छा समय है जो मैं उस समय सीमा तक कर सकता हूं।

— एमएसल्टर्स

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

— रोबर्ट ब्रिस्टो-जॉनसन

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

— एमएसएलटर्स

ऑडियो और संगीत वाद्ययंत्र क्षेत्र में i कोड सुनो। निश्चित रूप से उत्पाद को इसके साथ पैसा बनाने के लिए दरवाजे से बाहर निकलना होगा। लेकिन समय-सीमा ने शाब्दिक रूप से कुछ बीमार-विकसित बकवास के कारण दरवाजे से बाहर जाने के लिए ग्राहकों, कंपनी और भविष्य के डेवलपर्स को वर्षों तक साथ रहने के लिए मजबूर किया।

— रॉबर्ट ब्रिस्टो-जॉनसन

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

— शटल 17