वेब साइट की दुकान के लिए आप किस फुर्तीली पद्धति की सिफारिश करेंगे?क्या फुर्तीली पद्धति?
हमारे पास विभिन्न छोटी परियोजनाएं हैं और कुछ बड़े हैं, टीम क्रॉस-प्रोजेक्ट हैं और वे मल्टीटास्क हैं। हम वास्तव में स्क्रम में रुचि रखते हैं, लेकिन ऐसा लगता है कि यह छोटी परियोजनाओं (2 सप्ताह से कम) पर लागू नहीं होगा, जो वर्तमान में हमारे बहुत सारे समय को बनाते हैं।
हमारी स्थिति में चुस्त सिद्धांतों को लागू करने के लिए क्या विकल्प हैं?
हमने स्क्रम के साथ शुरुआत की क्योंकि इसकी औपचारिक संरचना (अनुमान, उपयोगकर्ता कहानी योजना, कार्य योजना, दैनिक बैठकों, पूर्वदर्शी) ने हमें अपने पुराने तरीकों से अधिक चुस्त होने में मदद की। हमने पाया है कि सुबह की बैठकों में कार्य/उपयोगकर्ता की कहानी के आधार पर 3 योजना और अनुकरण मीटिंग की जा सकती है।
हमारे पास एक बड़ी पिन बोर्ड है और प्रत्येक उपयोगकर्ता कहानी के लिए इंडेक्स कार्ड पर पिन है। प्रगति और काम में बोर्ड शुरू नहीं हुआ है। हम यह सुनिश्चित करते हैं कि जब हम इसे तोड़ते हैं तो किसी भी कार्य में एक दिन से अधिक समय नहीं लगता है, और जिस दिन हमें इसकी आवश्यकता होगी उस दिन की दैनिक बैठक में हम प्रत्येक उपयोगकर्ता की कहानी को तोड़ देते हैं। यह हमें चुस्त रखता है ताकि उपयोगकर्ता कहानियों के रूप में "विशेषताओं" की सूची हमारे कार्यों को तोड़ने में समय बिताने के बिना बदल सकती है। यह सुनिश्चित करता है कि दो हफ्ते की परियोजनाओं को आसानी से उसी तरह से संभाला जा सकता है जैसे बड़े लोग भी हैं।
वेग का अनुमान लगाने के लिए हम सप्ताह के अंत में कार्ड को गिनते हैं ताकि यह देखने के लिए कि हमने कितने कार्य किए हैं। नकारात्मकता यह है कि रिलीज प्लानिंग और वेग अनुमान स्क्रैम के साथ सटीक नहीं है लेकिन यह हाइब्रिड एक्सपी पद्धति डेवलपर्स को कार्यों पर ध्यान केंद्रित करने में मदद करती है और बैठकों में बहुत अधिक समय बर्बाद नहीं करती है।
छोटे कार्य होने से स्रोत नियंत्रण में अधिक नियमित प्रतिबद्धताएं होती हैं और एक बिल्ड सर्वर और तैनाती स्क्रिप्ट के साथ मिलकर हम दिन में एक बार आवेदन में प्रगति प्रदान कर सकते हैं - क्लाइंट से फीडबैक प्राप्त करने के लिए बहुत अच्छा। हमारे पास साप्ताहिक रेट्रोस्पेक्टिव भी हैं और यह सुनिश्चित करने के लिए कि हम सही रास्ते पर बने रहें, हर 3 महीने में एक हफ्ते तक एक चुस्त सलाहकार में किराए पर लें।
प्रति परियोजना एक पद्धति का प्रयास करें और देखें कि क्या अच्छी तरह से काम करता है।
स्क्रम निश्चित रूप से दो सप्ताह की परियोजनाओं पर लागू हो सकता है। आप या तो स्प्रिंट अवधि को छोटा कर सकते हैं या प्रति स्प्रिंट की कई परियोजनाएं कर सकते हैं।
इसके अलावा, ऐसा कुछ भी नहीं है जो कहता है कि आप अपनी परियोजना में उपयोग करने के लिए विभिन्न पद्धतियों के कुछ हिस्सों को नहीं चुन सकते हैं और चुन सकते हैं।
स्क्रम इस तरह की एक छोटी परियोजना के लिए काम नहीं करेगा। चूंकि इसकी परिभाषा में स्क्रम स्पिंट 2 सप्ताह लंबा है। एक्सपी, या चरम प्रोग्रामिंग की कुछ भिन्नता अधिक उपयुक्त होगी। हालांकि, 2 सप्ताह में एक प्रोजेक्ट प्राप्त करना, यदि यह जटिल है, तो आपके डेवलपर्स को अत्यधिक ध्यान केंद्रित करने की आवश्यकता होगी।
इसके अलावा, आपके द्वारा चुने गए किसी भी तरीके से, अपनी टीम को बेहतर तरीके से फिट करने के लिए प्रक्रिया को संशोधित करने से डरो मत।
मुझे लगता है कि आपको केविन की तरह कुछ प्रयास करना चाहिए, यह देखने के लिए कि आपकी वर्तमान टीम इसके साथ कैसे काम करती है। कुछ व्यक्ति XP या अन्य नई पद्धतियों को आजमाने के लिए बहुत खुले नहीं हैं। आपको अपने छोटे और आपके लिए बड़ी परियोजना के लिए विभिन्न तरीकों का भी प्रयास करना चाहिए। 2 साल की परियोजनाओं के लिए 2 सप्ताह की परियोजना के लिए पद्धतियां बदल सकती हैं। 2 सप्ताह की परियोजना में आपके पास 1 पुनरावृत्ति हो सकती है और आप पूरे 2 सप्ताह के लिए योजना बना सकते हैं, यह 2 साल की परियोजनाओं के लिए कुछ भी संभव नहीं है।
मैं आपकी सामान्य परियोजनाओं के छोटे होने के बावजूद स्क्रम का उपयोग कर दूसरा चाहता हूं। अपने स्पिंट को दो, तीन या चार दिन लंबा होने के रूप में देखें। आप अभी भी अपनी परियोजना में स्क्रम के "जारी चल रहे फीडबैक" आधार को शामिल कर सकते हैं।
आप दो सप्ताह के लिए कुछ काम नहीं करना चाहते हैं, केवल ग्राहक अंत में कहने के लिए "ओह, यह वही नहीं है जो हम बाद में थे!"
केन श्वाबर के छोटे talk about Scrum पर IT Conversations पर सुनें जो कि महान पॉडकास्ट बीटीडब्ल्यू से भरा है।
फिर मैं टिम मैककिन्नन के talk on Agile को InfoQ पर देखता हूं जो कि महान वार्ता और साक्षात्कार से भरा हुआ है।
एचटीएच।
चियर्स,
रोब
मुझे लगता है कि TDD (विकास संचालित परीक्षण) का उपयोग कर इन परियोजनाओं में लाभ का एक बहुत प्रदान करेगा। यह विकास और डिजाइन में मदद करेगा। कार्यान्वयन विवरण और डिजाइन निर्णयों के लिए यूनिट परीक्षण भी "माइक्रो दस्तावेज" हो सकता है।
मैं स्क्रम की सिफारिश करेंगे।
स्क्रम के कुछ विचार बैठकें सामना करने के लिए दैनिक स्टैंड-अप जैसे काम कर सकते हैं, लेकिन मुझे लगता है कि XP में युग्मित प्रोग्रामिंग जैसी अवधारणा छोटी परियोजनाओं के लिए अधिक उपयोगी होगी। और सच "scrummists" 2 सप्ताह अंतराल के समय को बदलना पसंद नहीं है। – stephenbayer
वास्तव में, केन Schwaber (स्क्रम के रचनाकारों में से एक) विशेष रूप से अपनी पुस्तक है कि आप स्क्रम प्रक्रिया (स्प्रिंट अवधि सहित) के अनुरूप अपनी टीम की आवश्यकता के अनुसार होना चाहिए में कहते हैं। –
मुझे अपनी सबसे छोटी औपचारिक परियोजना को आज तक 5 सप्ताह तक स्वीकार करना है, और मैंने इसके साथ काफी सख्त XP विधि का उपयोग किया है। आम तौर पर मैं सख्त स्क्रम के साथ 3 से 6 महीने की परियोजनाओं पर काम करता हूं। मैंने माइक्रो (2 सप्ताह) परियोजनाएं नहीं की हैं। मैं उन्हें मिश्रण करने के बजाय कड़ाई से पद्धतियों का पालन करने की कोशिश करता हूं। – stephenbayer