दीर्घकालिक योजना और चुस्त?

Question

मेरी टीम हाल ही में हमारे काम के लिए लगभग एक वर्ष की योजना बनाने की प्रक्रिया से गुजरी। हमने योजना को तीन चरणों में अलग किया। प्रत्येक चरण में कुछ लॉन्च शामिल होंगे।

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

Comments

+1 फुर्तीली सॉफ्टवेयर विकास और परियोजना प्रबंधन के बारे में इसकी प्रथाओं के बारे में पूछने के लिए। मैंने यहाँ पर Scrum के बारे में चर्चा की, क्योंकि मैं PSM I प्रमाणित हूँ, इसलिए Scrum वही है जो मैं जानता हूँ। शायद हमारे समुदाय के दोस्त स्क्रम की तुलना में कुछ अलग हो सकते हैं और आपकी विशेष स्थिति के आधार पर आपके लिए अधिक उपयुक्त हो सकते हैं।

— विल मार्कोइलर

हेहेहे ... यह एक टिप्पणी नहीं होनी चाहिए (यहाँ मजाक कर रहे हैं)? ; नोह नाह, कोई मजाक नहीं, यह एक विपणन योजना की तरह लग सकता है, लेकिन यह नहीं है। मैं बस एक ओपी के साथ अपने ज्ञान को साझा करना चाहता था, जिसने एक साधारण क्वेसिटोन से पूछा, और उसे बहुत सारी जानकारी प्रदान की जिससे मुझे मदद मिली, जबकि मुझे उम्मीद थी कि मैंने मदद की है। मैं व्यक्तिगत रूप से स्क्रम को पसंद करता हूं, लेकिन मुझे पता है कि ऐसे अन्य तरीके भी हैं जो बस काम कर सकते हैं, यह सब ओपी के परिदृश्य पर निर्भर करता है। वैसे भी नमक के अपने अनाज के लिए धन्यवाद! =)

— मार्कऑलर

ईमानदार रहें, यह कहने के बजाय कि प्रोजेक्ट एक्स को 3 सप्ताह लगेंगे, आप यह कहते हुए बेहतर हैं कि 2% संभावना है कि इसमें 2 सप्ताह लगेंगे, 60% संभावना है कि इसमें 3 सप्ताह, 10% मौका लगेगा जो इसे लगेगा 4 सप्ताह, 10% संभावना है कि इसे 5 सप्ताह, 10% मौका लगेगा कि यह 6 सप्ताह लगेगा, और 8% संभावना है कि इसमें अधिक समय लगेगा। En.wikipedia.org/wiki/Long_Tail के साथ वितरण का उपयोग करके , आप ईमानदार हो रहे हैं। अब बड़ी परियोजना को 10 यादृच्छिक चर के योग के रूप में समाप्त करने के लिए अनुमानित समय का इलाज करें। अंत में विचरण बहुत अधिक है, लेकिन आप ईमानदार हैं। एक लंबी पूंछ का उपयोग करना महत्वपूर्ण है!

— नौकरी

Answer 1

जहां परियोजना जाने के लिए है का एक सपना के बाद एक है अच्छी बात ^टीएम ।

यह मानते हुए कि जो होगा वह ठीक नहीं है।

"युद्ध की तैयारी में मैंने हमेशा पाया है कि योजनाएँ बेकार हैं, लेकिन योजना अपरिहार्य है।"

- ड्वाइट डी। आइजनहावर

चंचल कार्यप्रणालियों का दृष्टिकोण है कि चीजों को पचने योग्य टुकड़ों में तोड़ दिया जाए, और प्रत्येक टुकड़े को पचाने के बाद दृष्टि को फिर से समायोजित किया जाए।

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

Comments

एक ग्राहक को यह उत्तर पसंद नहीं आएगा।

— eddy147

एक और ग्राहक प्राप्त करें! ;-)

— पीटर के।

Answer 2

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

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

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

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

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

Comments

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

— फ़िलिप डूपानोविक

@ filip-dupanovic: साबित करें कि क्या गलत है?

— btilly

Answer 3

जब तक आप इसे कार्य-प्रगति और पत्थर में लिखी गई चीज़ नहीं मानते, तब तक योजना बनाना ठीक है।

यहां कुंजी नियमित रूप से (कम से कम मासिक) रिलीज करने के लिए है , अपने उपयोगकर्ताओं से वास्तविक प्रतिक्रिया एकत्र करें और उस प्रतिक्रिया के आधार पर अपनी योजना को अपडेट करें ।

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

Comments

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

— मार्टिन ब्लेयर

Answer 4

द्वारा मान लिया गया project-managementऔर agileआपका मतलब था स्क्रैम, यह जाने का सटीक तरीका नहीं होगा।

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

एक Sprintमहीने से अधिक नहीं रह सकता है, जहां की स्थिति Teamलाने के Sprint Backlog Itemsलिए प्रतिबद्ध है Done।

Doneयहां एक महत्वपूर्ण शब्द है, और प्रत्येक की Scrum Teamएक परिभाषा होनी चाहिए, यानी जहां कोई कार्य शेष नहीं है। जब एक किया Sprint Backlog Itemजाता है , तो इसका मतलब है कि विश्लेषण, वास्तुकला और तकनीकी दस्तावेज लिखे गए हैं, और यह कि सुविधा को पूरी तरह से परीक्षण किया गया है (इकाई परीक्षण, एकीकरण परीक्षण, कार्यात्मक परीक्षण ...)।

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

यह उस दौरान है Sprint Planning Meetingकि टीम इस बात पर प्रतिबद्ध होगी कि अगले के लिए क्या विकसित होगा Sprint, इसलिए इसे बनाना Sprint Backlog। Sprint Backlogएक उपसमूह पर आधारित होते हैं Product Backlog Itemsकि Teamप्रतिबद्ध स्प्रिंट के अंत में किया जाएगा। उदाहरण के लिए, 50 आइटमों के उत्पाद बैकलॉग को ध्यान में रखते हुए, और सभी 50 आइटमों को करने के लिए एक वर्ष की आवश्यकता होगी, तो टीम का चयन करना चाह सकती है कि उत्पाद बैकलॉग से 5 आइटम कहें, और इन 5 वस्तुओं के साथ स्प्रिंट बैकलॉग बनाएं। आवश्यकता पड़ने पर इन 5 वस्तुओं को कई अन्य मदों में विस्तारित / विस्फोट किया जा सकता है, इस प्रकार टीम शायद संशोधन के बाद अपना दिमाग बदल लेती है और उत्पाद बैकलॉग से पहले से चयनित 5 में से केवल 4 आइटम करने के लिए प्रतिबद्ध है।

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

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

यह उस Sprint Review Meetingजगह के दौरान है जहां यह Product Ownerकहा जाना आवश्यक Teamहै कि स्प्रिंट के दौरान जो किया गया था, वह प्रदर्शित करता है, और जहां यह बताने की आवश्यकता है कि यह क्यों नहीं किया गया है, यदि लागू हो, तो सभी कार्य जो इसे करने के लिए प्रतिबद्ध हैं। पूर्ववत कार्य को फिर वापस रखा जाता है Product Backlogऔर अगले के लिए उपलब्ध होता है Sprint। जब तक कि उद्देश्य बदल न गया हो, उत्पाद के स्वामी द्वारा अन्यथा नहीं बताए जाने तक, इन पूर्ववत वस्तुओं को अगले स्प्रिंट में शामिल किया जाएगा। लेकिन सबसे महत्वपूर्ण बात, हालांकि एक स्प्रिंट के दौरान एक प्रणाली का उद्देश्य बदल गया, लेकिन इसे तब तक बाधित न करें जब तक कि बिल्कुल आवश्यक न हो। स्प्रिंट को बाधित करने का अधिकार केवल उत्पाद स्वामी के पास है।

एक बार Sprint Review Meetingखत्म होने पर, जो मासिक स्प्रिंट के लिए 4 घंटे से अधिक नहीं रहना चाहिए (यदि मुझे सही याद है), तो इसे प्राप्त करने का समय है Sprint Retrospective Meeting। ऐसा होने के लिए Sprint Retrospectiveयह आवश्यक Teamहै कि यह चर्चा कर सके कि स्क्रम मास्टर और प्रोडक्ट ओनर (वैकल्पिक) की मौजूदगी में क्या गलत हुआ, कैसे स्क्रैम टीम अपने प्रदर्शन में सुधार कर सकती है, आदि और तदनुसार समायोजन लाएं।

जब टाइम-बॉक्स Sprint Retrospectiveखत्म हो जाता है, तो नया Sprint Planning Meetingअगले की योजना Sprintबनाने और नया बनाने के लिए होगा Sprint Backlog।

याद रखें, 15 मिनट की स्टैंड-अप मीटिंग Teamको बनाए रखने के लिए ज़िम्मेदार है , Daily Scrumजहां हर टीम सदस्य तीन सवालों के जवाब देता है (उस क्रम में नहीं):

1. आपने पिछले डेली स्क्रम के बाद से क्या किया है?
2. अगले दैनिक स्करम तक आप क्या करने की योजना बना रहे हैं?
3. पिछले डेली स्क्रम के बाद आपको क्या समस्याएं या बाधाएं आईं?

Scrum Masterनहीं है के लिए बाध्य वहाँ हो लेकिन आश्वस्त करने के लिए है कि टीम डेली स्क्रम में मिलता है और है कि सदस्यों को तीन सवालों का जवाब ठीक से की आवश्यकता है।

स्क्रम मास्टर अन्य स्क्रम टीम के सदस्यों (स्क्रम मास्टर, प्रोडक्ट ओनर एंड टीम) द्वारा स्क्रम नियमों के सम्मान के लिए जिम्मेदार है।

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

क्या आपको Scrum और Agile Software Development के बारे में और विस्तृत जानकारी की आवश्यकता है, कृपया Scrum.org और उनके Scrum Guide को देखें ।

खैर, यह काफी जवाब है! मुझे उम्मीद है कि यह आपके प्रोजेक्ट प्रबंधन के माध्यम से कम से कम आपकी मदद करेगा।

EDIT # 1

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

Comments

+1, लेकिन आपको 6 वें पैराग्राफ के बाद बंद कर देना चाहिए। :)

— पी शेव्ड

बैकटिक्स में बहुत सारे गैर-कोड शब्द।

— रीन हेनरिच

Answer 5

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

2. हालांकि आपको बिग डिज़ाइन अप फ्रंट नहीं करना चाहिए , मुझे लगता है कि बड़ी तस्वीर के बारे में हर बार सोचना अच्छा है जब आप बैकलॉग को समायोजित करने और फिर से भरने के लिए, दोनों स्क्रैम के लिए (अगले स्प्रिंट के लिए) और कानबन / प्रवाह (जब वहाँ कमरा हो WIP की सीमा में)। यदि आप संपूर्ण (उत्पाद, सेवा, आदि) पर विचार करते हैं, तो यह विचार करना आसान है कि किस काम के आइटम से आपको अगले मूल्य मिलेंगे।

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

संक्षेप में, मुझे लगता है कि आप और अधिक चुस्त हो जाते हैं जितना अधिक आप निरीक्षण और अनुकूलन करते हैं।

Answer 6

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

तुम्हे करना चाहिए:

1. एक मास्टर प्लान (अधिमानतः बिना डेडलाइन के संलग्न), जो आपके जाते ही विकसित होगा।

2. जब आप स्प्रिंट को परिभाषित करते हैं, तो आप सुनिश्चित करते हैं कि स्प्रिंट बड़ी तस्वीर के अनुरूप है। इसका मतलब यह नहीं है कि आप स्प्रिंट के लिए वांछित अपने विचार को बदल दें। कभी-कभी आपको पता चलता है, जब एक स्प्रिंट को परिभाषित करते हुए, कि आपकी बड़ी तस्वीर को समायोजित किया जाना चाहिए। एक तरह से या किसी अन्य बड़े चित्र की योजना और स्प्रिंट को स्प्रिंट में जाने के लिए एक दूसरे के अनुरूप होना चाहिए।

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

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

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

यह विधि चुस्त की शक्ति को बनाए रखती है, और आपके प्रोजेक्ट के सभी तत्वों को संरेखित करने की शक्ति जो आप किसी भी समय बड़ी तस्वीर योजना के माध्यम से प्राप्त कर सकते हैं।

जिम

Answer 7

मैं अपने एंटी-एजाइल रैंट के संक्षिप्त रूप को यहां जोड़ूंगा।

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

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

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

Comments

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

— मार्टिन विकमैन

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

— मार्टिन विकमैन

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

— मार्टिन विकमैन

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

— मार्टिन विकमैन

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

— 21