क्या किसी के पास झरना संचालित कॉर्पोरेट वातावरण में एग्इल विकास प्रथाओं के लाभों को बढ़ावा देने के तरीके पर कोई अच्छी तकनीक या उदाहरण हैं?Agile बनना
हमने हाल ही में ट्रंक & शाखा कोड प्रबंधन का उपयोग करके सुविधा आधारित विकास पर स्विच किया है, हमारे पास एक परियोजना है जो स्क्रम के साथ अच्छी तरह से चल रही है, लेकिन व्यापक दृष्टिकोण द्वारा इस दृष्टिकोण को अपनाया जाना मुश्किल है।
मुझे आश्चर्य हुआ कि कोई और कॉर्पोरेट मशीन से जूझ रहा है?
G'day,
आप एक आईटी बातचीत पर अधिक Scrum पर केन Schwaber की बात को सुनने के लिए पसंद कर सकते हैं।
एग्इल के एक विशेष "कार्यान्वयन" पर ध्यान केंद्रित करते समय, यह बहुत बुनियादी कारणों को कवर करता है कि एजिल सफल क्यों होता है।
आप Agile एलायंस में articles on introducing agile पर भी देखना चाहेंगे।
एचटीएच।
चियर्स,
रोब
यदि आपके पास पहले से ही आपके संगठन में एक स्क्रूम प्रोजेक्ट चल रहा है, तो 90% युद्ध किया जाता है।
मैं एक केस स्टडी लिखने के लिए कुछ समय लेने का सुझाव देता हूं, शायद इसे अपने इंट्रानेट या इसी तरह से रख दें। पता लगाएं कि कौन सी परियोजनाएं आप अच्छे उम्मीदवारों पर विचार करेंगे, और उनसे बातचीत करें। सभी प्रचारक मत आओ - बस 'अरे, ठीक है, मुझे आपके द्वारा वर्णित समस्या का उपयोग करना पड़ता था, अगर आप कभी भी यह देखना चाहते हैं कि हम परियोजनाओं को कैसे चला रहे हैं, तो http://xyz/
पर एक नज़र डालें दूसरा विकल्प किसी को अपने संगठन में इसे चैंपियन करने के लिए ऊंचा करना है। इससे संक्रमण बहुत तेज़ हो जाएगा, लेकिन आपको उपयुक्त चैंपियन खोजने और लाभों के बारे में समझाने की आवश्यकता है।
सामान्य रूप से बेहतर आरओआई।
एक जलप्रपात प्रक्रिया आपके द्वारा पूरा होने के समय के समाप्त होने के बाद ही समाप्त हो जाती है। जब तक आप समाप्त कर लेंगे तब तक ग्राहक ने जिस तरह से काम किया है, वह बदल गया है।
यही कारण है कि पुनरावृत्ति विकास और पुनरावृत्ति रिलीज झरना से कहीं ज्यादा बेहतर काम करते हैं। आप अनावश्यक पैकेज विकसित करने में कम समय व्यतीत करेंगे और आप उनकी आवश्यकताओं में बदलावों का जवाब देने में सक्षम होने के कारण ग्राहक को भी खुश कर देंगे।
आम तौर पर प्रतिमान बेहतर है। आप ब्लूप्रिंट नहीं करते हैं और पूर्णता बनाते हैं। आप शुरुआत से मानते हैं कि यह सही नहीं होगा और आप इसे लचीला और बदलने में आसान बनाकर सॉफ़्टवेयर "बढ़ाना" चाहते हैं।
मुझे लगता है कि सबसे अच्छा तरीका है छोटे से शुरू और साबित होता है कि दृष्टिकोण वास्तव में काम करता है के लिए है।
जैसा कि पहले चर्चा की गई थी, Scrum and other agile techniques can be introduced step by step।
यदि संगठन यह नहीं पहचानता कि उन्हें कोई समस्या है (और कई जानना नहीं चाहते हैं) तो आपके पास एक उग्र लड़ाई है।
आप सुझाव दे सकते हैं कि आप अन्यथा पद्धति को बदलने के बिना परियोजनाओं के दायरे को कम करें (और इस प्रकार प्रसव के बीच अंतराल का आकार)।
झरना के चरण, जिसमें विश्लेषण, डिज़ाइन, कोड, परीक्षण, कार्यान्वयन और समीक्षा शामिल हो सकती है, स्वयं समस्या नहीं हैं। उन्हें एक परियोजना में मानचित्रित करें जिसमें एक सुविधा तक सीमित दायरा है: विश्लेषण उपयोगकर्ता की कहानी, डिज़ाइन और कोड को टीडीडी लूप बनने में समझ जाता है, परीक्षण उपयोगकर्ता स्वीकृति है और फिर हम इसे उत्पादन में डाल देते हैं। हमने कुछ वर्षों में पूरे सिस्टम की बजाय कुछ दिनों में काम की एक छोटी इकाई की है।
यह काम कर सकता है।
विशेष रूप से प्रबंधन में आगे बढ़ तकनीक लोगों के लिए चुस्त की जानकारी के लिए एक अच्छा स्रोत है।
मैनिंग प्रकाशन यह बहुत ही विषय पर ग्रेग स्मिथ और अहमद Sidky की एक पुस्तक है: link text
शायद मैं सुझाव है कि आप इस तथ्य है कि चंचल में, आप कोडिंग से पहले क्या आप जानते हैं * क्या * यदि आप कोडिंग कर रहे हैं शुरू करने से बचें। – tsilb