क्या चुस्त सिर्फ छोटे झरने से अधिक है?


18

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

क्या मेरी समझ सही है या उससे ज्यादा है? फुर्तीले दर्शन क्या हैं?


4
क्या आपने वास्तव में एजाइल मेनिफेस्टो पढ़ा है? agilemanifesto.org
S.Lott

जवाबों:


20

एक साधारण स्तर पर, हाँ। बस हर दो सप्ताह में एक झरना प्रदर्शन आपको चुस्त नहीं बनाता है , लेकिन यह पुनरावृत्ति (जो कि चुस्त का आधा) है।

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

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

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

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

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

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

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

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

एक योजना के बाद बदलने का जवाब

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

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


2
हां, "चुस्त" विशिष्ट तकनीकों के बजाय दृष्टिकोण के बारे में अधिक है। कुछ संगठनों के "चुस्त" तरीके को अपनाने में विफल रहने के तरीकों के बारे में जानने के लिए अर्धरासैगिलमेनिफेस्टो.org पढ़ें , भले ही वे कुछ "फुर्तीली" विधि का पालन करने का दावा करते हों ...
बिल माइकेल

2

हां और नहीं - वास्तविक प्रक्रिया को छोटे झरनों की एक श्रृंखला के रूप में देखा जा सकता है लेकिन अंतर यह है कि यह प्रक्रिया विकसित होती है और रेट्रोस्पेक्टिव्स में पूरी टीम (देव, क्यूए, व्यापार आदि) के इनपुट से बेहतर होती है, जिसके लिए नेतृत्व करना चाहिए एक बहुत तंग इकाई जो मुद्दों पर प्रतिक्रिया करने और योजना बनाने और वितरित करने में सक्षम है। मैं यहाँ इसे सरल बनाने से अधिक हूँ, इसके लिए बहुत कुछ है, लेकिन मुझे नहीं लगता कि यह एक बुरा शुरुआती बिंदु है।


1

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

यदि आप एजाइल के बारे में गंभीर हैं, तो यहां आपके द्वारा रुचि लिए जा सकने वाले वेबकास्ट की एक अच्छी (और लंबी) श्रृंखला है:

http://autumnofagile.net/


1

चंचल को एक मिनट भूल जाओ, सोचो कि "झरना" का क्या मतलब है।

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

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

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

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

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

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

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

चंचल कार्यप्रणाली क्या करने की कोशिश करती है, के एक उत्कृष्ट अवलोकन के लिए, मैं अत्यधिक ऐलिस्टेयर कॉकबर्न के फुर्तीली सॉफ्टवेयर विकास की सिफारिश करूंगा : सहकारी खेल


0

हां, यह कमोबेश सही है। इसके बारे में जाने के बारे में बहुत कुछ लिखा और चर्चा की गई है, लेकिन छोटे झरनों का एक समूह इसके बारे में है।

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


0

क्या यह सही है या इसके अलावा भी बहुत कुछ है

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


0

यदि आप एक चुस्त परियोजना की स्थिर संरचना (प्रक्रिया परिभाषा) को देखते हैं, तो यह कई छोटे झरनों की तरह दिखता है। लेकिन फुर्तीली परियोजना का लक्ष्य त्वरित और बेहतर प्रतिक्रिया प्राप्त करना है

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

चुस्त घोषणा पत्र पर प्रकाश डाला चुस्त और झरना के बीच कुछ अंतर (के रूप में जो लोग हस्ताक्षर किए द्वारा कथित)।


0

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

उदाहरण के लिए, स्क्रम, 4 सप्ताह के स्प्रिंट का उपयोग करता है, लेकिन स्प्रिंट सिर्फ एक झरना नहीं है (कम से कम, यह नहीं होना चाहिए)। आप हर दिन प्राथमिकताओं को बदल सकते हैं जब भी आप देखते हैं कि स्प्रिंट की शुरुआत में जिस तरह से योजना बनाई गई थी, कुछ नहीं जाता है।

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