Agile - यह कब अच्छा काम करता है, और यह कब नहीं है?

Question

हमारी टीम इस बात पर बहस कर रही है कि हम Agile बनना चाहते हैं या नहीं। Agile में हम में से कोई भी वास्तव में धाराप्रवाह हैं। मुझे कुछ विचार चाहिए जब Agile अच्छी तरह से काम करता है, और जब यह नहीं करता है।

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

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

धन्यवाद।

Answer 1

राल्फ स्टेसी की जटिलता मैट्रिक्स आमतौर पर चंचल के लिए मिठाई स्थान वर्णन करने के लिए प्रयोग किया जाता है:

alt text http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi

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

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

जब दोनों आवश्यकताओं और प्रौद्योगिकियां अज्ञात हैं, तो आप अराजकता के करीब हैं और विफलता की बाधाएं बहुत अधिक हैं, कार्यप्रणाली के बावजूद।

Answer 2

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

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

मैं सुझाव दूंगा कि आप Agile से प्रथाओं को अपनाना शुरू करें। एक छोटी स्प्रिंट अवधि निर्धारित करना प्राथमिकताओं को बदलने में मदद कर सकता है। एक या दो सप्ताह की अवधि के लिए प्राथमिकताओं को बनाए रखना आसान हो सकता है और प्राथमिकताओं को स्थिर करना आसान हो सकता है। आपको बैकलॉग की भी आवश्यकता होगी (लगता है जैसे आपके पास पहले से ही बड़ा है)।

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

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

Agile एक अनुकूली मेथोलॉजी है। नए या दो साल के लिए अपनी पद्धति में बड़े बदलाव करने की उम्मीद है। आखिरकार, आपको एक ऐसे मंच तक पहुंचना चाहिए जहां आप ठीक ट्यूनिंग कर रहे हों।

Answer 3

मेरा एक related answer पुनः पोस्टिंग:

चर्चा आमतौर पर बनाम झरना चुस्त, सही है? मैं article को जोड़ रहा हूं, लेकिन यह पुर्तगाली में है, इसलिए मैं अपने कुछ विचारों को प्रेषित करने की कोशिश करूंगा:

झरना शतरंज की तरह है। आप सोचते हैं और बहुत योजना बनाते हैं, जितनी जल्दी हो सके हर संभावित मुद्दे की भविष्यवाणी करने का प्रयास करें। बहुत सारी योजनाएं हैं, लेकिन केवल स्थिर और जाने-माने डोमेन पर ही समझ में आती हैं, जहां परिवर्तन की अपेक्षा नहीं की जाती है।

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

IMHO, स्क्रम, उपयोगी होगा क्योंकि:

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

Answer 4

मेरे अनुभव में, आपको काम करने के लिए पूरी तरह से चुस्त (एक्सपी या स्क्रम कम से कम) के लिए निम्नलिखित की आवश्यकता है। इन पूर्व शर्त के बिना आप असफल होने की संभावना है। कठिन।

1. टीम स्थिर और 100% समर्पित होना चाहिए।
2. टीम को एक कार्यक्षेत्र में स्थानांतरित किया जाना चाहिए।
3. ग्राहक/उत्पाद स्वामी हर समय साइट पर उपलब्ध होना चाहिए।
4. प्रबंधन से समर्थन। इसका मतलब है ऊपर दिए गए अंक सुनिश्चित करने के लिए धन और साहस प्रदान करना।

इन बिंदुओं को दें, जब तक आप values पर रहते हैं, तब तक आप शायद कुछ भी निपट सकते हैं।

Answer 5

मैं केवल अनुभव से बोल रहा हूं; YMMV।

मेरी टीम चुस्त काम करने में असफल रही। IMO, ऐसा इसलिए है क्योंकि:

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

तो मुझे पूरा यकीन है कि हम यह सब गलत कर रहे थे। आप भी गलत नहीं करते हैं।

कुछ बातें हमें तेज किया है कि, जो हम उपयोग करने के लिए जारी रखने के लिए:

• स्वचालित बनाता है कि हर किसी की मशीन पर काम
• हमारे कोड भंडार के लिए एक औपचारिक व्यवस्था (विशाल मदद!)
• यूआई कोड को अमूर्त तंत्र लागू लागू करने के लिए सीखने
• रिफैक्टरिंग
• इकाई और एकीकरण परीक्षण
• निरंतर एकीकरण

मैं आप कह सकते हैं कि हमारे कोड, और अधिक चुस्त है, हालांकि हमारी कार्यप्रणाली कम चुस्त है लगता है। जबकि इससे पहले कि हम मांगों के साथ गति नहीं रख सकें, अब हम कर सकते हैं।

(मैं चुस्त यह नहीं कह रहा हूँ बुरा है, मैं तो बस मेरे अनुभव रिपोर्ट कर रहा हूं इसके अलावा, कृपया समझते हैं कि मैं नहीं चुनते क्या कार्यप्रणाली हम का उपयोग करें।।)