क्या SCRUM का उपयोग उस परियोजना के लिए किया जाना चाहिए जिस पर केवल एक व्यक्ति काम कर रहा है?


19

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

  • मैं सोच रहा था कि क्या किसी ने SCRUM को किसी एकल डेवलपर और फजी कार्यों वाले प्रोजेक्ट के लिए अच्छी तरह से काम करते देखा है, और आपने प्रक्रिया को अच्छी तरह से कैसे बनाया है?

  • उन कार्यों का अनुमान कैसे लगाया जाए, जिनमें नई तकनीकों पर शोध / महारत हासिल करना शामिल है (इसमें नई प्रोग्रामिंग भाषाओं, प्लेटफार्मों और विकास उपकरण सीखना शामिल है)?

  • क्या कोई व्यक्ति विशेष परियोजनाओं के लिए SCRUM का उपयोग नहीं करने के लिए प्रबंधन को समझाने में सफल रहा है, और यदि हाँ, तो कौन से तर्क सबसे सफल थे?

धन्यवाद!

scrum 

लगता है कि आपके प्रबंधन को फैंसी शब्द का उपयोग करना पसंद है, यहां तक ​​कि यह समझने के बिना कि उस शब्द के पीछे क्या है। कोई भी स्क्रैम आपके वातावरण के लिए नहीं है और यह आपको लगता है जैसे आपको दूसरी नौकरी की तलाश करनी चाहिए। प्रत्येक कार्य को किसी अन्य तकनीक में करना संभवतः आपके समय की बर्बादी है।
लादिस्लाव मृक्का


१-व्यक्ति परिमार्जन = अनुशासन। आपको सबसे पहले सबसे महत्वपूर्ण / जोखिम भरा काम करना सीखना होगा। यह ... सामान्य ज्ञान है।
जॉब

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

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

जवाबों:


8

"पर्सनल स्क्रैम" देखें ... मैंने ऐसा करने वाले लोगों के कुछ या तीन ब्लॉग पोस्ट देखे हैं। पूर्ण स्क्रैम में कुछ धारणाएं हैं जो एकल व्यक्ति टीमों के लिए पूरी तरह से अनुवाद नहीं करेंगे। (मेरा अनुभव - लगभग 4 लोगों का एक निश्चित "महत्वपूर्ण द्रव्यमान" टीम-सामान को अच्छी तरह से काम करने के लिए लगता है।)

उदाहरण के लिए http://blog.jgpruitt.com/tag/personal-scrum/

लेकिन कार्य आकलन, वेग, और समयबद्ध स्प्रिंट जैसी चीजें जिनके दौरान कार्य-सूची "संरक्षित" है, यहां तक ​​कि 1 के लिए भी अच्छी तरह से काम करती है।


व्यक्तिगत स्क्रैम का उपयोग करते हुए एक पूरी स्नातक परियोजना के लिए एक अच्छी कड़ी के लिए +1: "पूरी परियोजना नीचे दी गई सामग्रियों में पुरानी हो गई है। मेरी जानकारी के लिए, यह व्यक्तिगत स्क्रैम परियोजना का पहला पूरी तरह से प्रलेखित उदाहरण है, और यह निश्चित रूप से सबसे अधिक है। खुला हुआ।"
ह्यूगो

7

बिलकूल नही। आपके दैनिक स्क्रम्स बहुत कम होंगे, और अविश्वसनीय रूप से उबाऊ होंगे!

आप उन बिट्स को चुन सकते हैं जो आपको लगता है कि आपकी मदद करेंगे, हालांकि कार्ड्स का मतलब है कि आपको उन्हें पूरी तरह से भरना नहीं है; अपनी प्रगति की जांच करने के लिए निर्धारित समय के बाद रुकना भी समझ में आता है। लेकिन अगर आप ऐसा कर रहे हैं, तो कान्बन, क्रिस्टल और अन्य सभी चुस्त तरीकों को भी बिट्स के लिए देखें जो आपकी मदद करेंगे।


3

नहीं, आप एक टीम के बिना घोटाला नहीं कर सकते। SCRUM द्वारा परिभाषित टीम "उत्पाद को विकसित करने के लिए खुद को प्रबंधित करने के लिए जिम्मेदार लोगों का एक क्रॉस-फ़ंक्शनल समूह है" जो SCRUM में एक महत्वपूर्ण भूमिका है।

Http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf के अनुसार

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

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


3

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

चंचल उत्साही लोगों के लिए, झरने का उपयोग करने का मात्र उल्लेख पवित्र है। लेकिन लोगों को सामान्य ज्ञान का उपयोग करने की आवश्यकता है।

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

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

समस्या का एक हिस्सा यह है कि कुछ लोगों को लगता है कि आप अगले पांच स्प्रिंट की योजना पहले ही बना सकते हैं। मेरे साथ भी ऐसा ही हुआ है। आपको दो से अधिक स्प्रिंट की योजना नहीं बनानी चाहिए क्योंकि यदि आप हैं तो आप स्प्रिंट होने के पूरे उद्देश्य को हरा रहे हैं। एक स्प्रिंट को समय की एक निर्धारित मात्रा के भीतर वास्तविक मात्रा में वृद्धि देने के लिए एक प्रतिबद्धता माना जाता है। आपको ऐसी किसी चीज़ के लिए प्रतिबद्ध नहीं होना चाहिए, जिसके बारे में आप निश्चित नहीं हैं। स्प्रिंट योजना इसकी प्रकृति अल्पकालिक योजना है, लेकिन यह इस तरह की बात है। यदि आपके पास एक दीर्घकालिक कार्यक्रम है, तो चीजों को छोटे डिलिवरेबल्स में तोड़ने के बारे में सोचें। या जहाँ आप SDLC में हैं, उसके आधार पर चेकपॉइंट मीटिंग सेट करना।

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


1

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

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

नहीं, आपको वास्तव में अपने स्टैंडअप के रूप में सभी डेवलपर्स के साथ नहीं मिलना चाहिए। आपको अपनी टीम के साथ मिलना चाहिए , जो फिर से सिर्फ डेवलपर्स नहीं है।

सौभाग्य। आशा है कि आप लोग समझ गए होंगे।


1

मान लें कि आपके पास एक उत्पाद का स्वामी और एक स्कैम मास्टर है (यदि नहीं, तो इसका घोटाला नहीं है), स्क्रैम एक आदमी टीम के लिए काम कर सकता है। स्क्रम कलाकृतियों (बैकलॉग, बर्डडाउन चार्ट) का उपयोग उसी तरह किया जाएगा जैसे वे बहु-लोक टीम में किया जाता है। अब बैठकों के बारे में:

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

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

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