"शुद्ध चंचल" पुस्तक। लचीलापन की मूल बातें

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

अंश। पहली बात पता है

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

उसी समय, आवश्यकताओं को एक सतत स्ट्रीम में बदल सकते हैं जिसे ठीक नहीं किया जा सकता है।

और इसका एक कारण यह भी है - ग्राहक अक्सर यह नहीं जानते कि वे वास्तव में क्या चाहते हैं। उन्हें पता लगता है कि उन्हें किस समस्या को हल करने की आवश्यकता है, लेकिन इस तरह के ज्ञान को परियोजना आवश्यकताओं में अनुवाद करना हमेशा मुश्किल होता है। इसलिए, आवश्यकताओं का निरंतर आश्वासन और पुनर्विचार है। नई सुविधाएँ जोड़ी जाती हैं।

कुछ पुराने गायब हो जाते हैं। उपयोगकर्ता इंटरफ़ेस जल्दी से बदलता है - सप्ताह में, यदि दिन नहीं।

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

संग्रह

कैस्केडिंग मॉडल ने हमें इस कार्य को बायपास करने का एक तरीका प्रदान किया। यह समझाने के लिए कि यह एक ही समय में कितना मोहक और अप्रभावी था, मैं एक बैठक को उदाहरण के रूप में उद्धृत करूंगा।

यह मई का पहला था। बिग बॉस ने अधीनस्थों को सम्मेलन कक्ष में बुलाया।

बॉस शुरू हुआ: “हमारे पास एक नया प्रोजेक्ट है। नवंबर के पहले तक इसे खत्म करना आवश्यक है। हमारी अभी तक कोई आवश्यकता नहीं है। अगले कुछ हफ्तों में उन्हें हमारे लिए घोषित किया जाएगा। परियोजना का विश्लेषण करने में कितना समय लगेगा? ”

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

“कल्पना करो कि वे हैं! बॉस को चिल्लाया। "आप जानते हैं कि सब कुछ कैसे काम करता है।" आप विशेषज्ञ हैं! मुझे सटीक तिथियों की आवश्यकता नहीं है। मुझे बस किसी तरह शेड्यूल भरने की जरूरत है। ध्यान रखें कि यदि दो महीने से अधिक समय लगता है, तो आप आत्मविश्वास से परियोजना के बारे में भूल सकते हैं। ”

किसी ने सवालिया अंदाज में कहा: "दो महीने?" बॉस ने इसे शर्तों के लिए सहमति के रूप में लिया: "महान! बस मुझे यही विचार आ रहा था। अब बताइए कि डिजाइन कितना लेता है? ”

और फिर से हर कोई हतप्रभ रह गया, कमरा मृत चुप्पी से भर गया। हम गिनते है। और हमें एहसास हुआ कि नवंबर के पहले तक केवल छह महीने। निष्कर्ष खुद पता चलता है। "दो महीने?" - तुम पूछो।

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

विश्लेषण चरण

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

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

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

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

फिर जुलाई का पहला चमत्कार होता है। विश्लेषण पूरा हो गया है।

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

डिजाइन चरण

अब क्या करे? बेशक, हम डिजाइन करेंगे। लेकिन डिजाइन क्या है ?

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

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

और फिर एक नया चमत्कार घटित होता है। पहली सितंबर को हम अचानक डिजाइन पूरा करते हैं। और क्यों? हाँ क्योकि। सितंबर का पहला। कार्य अनुसूची के अनुसार, हमें पहले ही समाप्त कर देना चाहिए था। संकोच करने की जरूरत नहीं है।

तो एक और पार्टी। गुब्बारे और भाषण। और हम अगले चरण के माध्यम से तोड़ते हैं - कार्यान्वयन।

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

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

कार्यान्वयन चरण

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

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

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

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

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

और वे सही हैं, वे नहीं हैं?

जीवन रक्षा मैराथन

और अस्तित्व मैराथन शुरू होता है। ग्राहक नाराज हैं। हितधारक चरम पर आ गए हैं। दबाव बढ़ रहा है। हम ओवरटाइम काम करते हैं। कोई प्रोजेक्ट छोड़ देता है। बस नरक!

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

मैं इसे ब्लोटिंग आउट ऑफ कंट्रोल प्रक्रिया कहता हूं। हम अगली बार एक ऐसी विधि का उपयोग करते हुए बेहतर काम करने जा रहे हैं जो काम नहीं करती है।

»आप प्रकाशक की वेबसाइट पर प्री-ऑर्डर कर सकते हैं ।

पुस्तक के पेपर संस्करण के भुगतान के बाद, पीडीएफ भेजा जाता हैपुस्तक के पहले 105 पृष्ठों के साथ।