एजिल फॉर ऑल बुक

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

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

चंचल अभ्यास में गोता लगाएँ: "हूपी!"

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

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

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

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

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


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

चरण 1: क्यों

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

उदाहरण के लिए, जब हम एक बैठक के बाद एक विश्लेषणात्मक रिपोर्ट विकसित करते हैं, तो हम अक्सर स्टिकर पर तीन मुख्य "क्यों" लिखते हैं:

• परियोजना के ड्राइविंग बल की समझ को वरिष्ठ प्रबंधन तक पहुँचाना।
• बैठक में मुख्य अंतर्दृष्टि के उपस्थित लोगों को याद दिलाएं।
• बैठक में शामिल नहीं होने वाले कर्मचारियों में रुचि।

कृपया ध्यान दें कि इनमें से कोई भी बिंदु सीधे इंगित नहीं करता है कि हम अपने लक्ष्यों को कैसे प्राप्त करने जा रहे हैं - बाद में और अधिक!

चरण 2: कैसे

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

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

अंतिम खंड से "क्यों" को देखते हुए, हम वर्कफ़्लो को निर्देशित करने के लिए निम्नलिखित "कैसे" की पहचान कर सकते हैं:

• एक दो-पृष्ठ विश्लेषण रिपोर्ट बनाएँ जिसे आसानी से समझा और प्रसारित किया जा सकता है।
• वरिष्ठ प्रबंधन को ड्राइविंग बल की समझ के लिए प्रतिभागियों के यादगार उद्धरणों का उपयोग करें।
• आनंदमय क्षणों के प्रतिभागियों को याद दिलाने के लिए मीटिंग फ़ोटो का उपयोग करें।
• सकारात्मक परिणामों को बढ़ावा दें और परिणाम को केंद्रित रखने और व्यापक ब्याज उत्पन्न करने के लिए विस्तार की मात्रा को सीमित करें।

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

चरण 3: प्रोटोटाइप

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

• एक प्रोटोटाइप एक मॉडल या योजना दस्तावेज नहीं है; यह वांछित परिणाम या परिणाम के रूप में एक ही प्रारूप में बनाया गया है। उदाहरण के लिए, स्लाइड के साथ एक प्रस्तुति का "प्रोटोटाइप" स्लाइड के साथ एक प्रस्तुति है। एक मुद्रित विवरणिका का "प्रोटोटाइप" एक मुद्रित विवरणिका है।
• एक प्रोटोटाइप समय की एक सीमित और पूर्वनिर्धारित अवधि में बनाया जाता है। (टाइम-बॉक्सिंग के हिस्से के रूप में बनाया गया।)

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

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

एक नियम के रूप में, हम प्राथमिक प्रोटोटाइप बनाने के लिए जिम्मेदार एक टीम के सदस्य को नामित करते हैं। अक्सर यह खाली समय का मामला बन जाता है: पहला प्रयास करने के लिए अगले दिनों में कई घंटे कौन सेट कर सकता है? हमने पाया कि दो घंटे का कार्य एक प्रोटोटाइप बनाने के लिए मानक सीमा है, जो आपको परियोजना के लक्ष्यों की तुलना के लिए एक आधार बनाने की अनुमति देता है और विकास और पुनरावृत्ति के लिए जगह छोड़ देता है।

चरण 4: Iteration

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

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

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

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

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 25% की छूट - फुर्तीली

पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।