Scrum को एक Volunteer सेटिंग में कैसे बदला जा सकता है?


18

मैं हाल ही में खुद को स्थापित करने की प्रक्रिया में एक युवा हैकरस्पेस में शामिल हुआ हूं। हम भाग्यशाली हैं क्योंकि अंतरिक्ष में कुछ आंतरिक परियोजनाएं हैं जिन पर काम करने की आवश्यकता है और उन पर काम करने के लिए स्वयंसेवकों की कोई कमी नहीं है।

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

हालाँकि मैंने छोटी-छोटी पूर्णकालिक टीमों के लिए स्क्रम को अच्छी तरह से काम करते देखा है, इस संगठन की प्रकृति अलग है:

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

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

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

मुझे लगता है कि जिन चीज़ों से हमें फायदा हो सकता है, उन्हें ट्विक करने की आवश्यकता नहीं होगी:

  • आवश्यकताओं सभा की बैठक (रों)। जहां हर कोई एक मेज के आसपास बैठता है और उपयोगकर्ता कहानियों पर चर्चा करता है, यूआई मोज़ेक को स्केच करता है, और एक उत्पाद बैकलॉग बनाता है।
  • स्प्रिंट रेट्रोस्पेक्टिव । यह हमारे लिए एक दिलचस्प तरीका होगा कि हम एक ऐसी विकास प्रक्रिया में जुट जाएं, जो स्वयंसेवकों की एक टीम के रूप में हमारे लिए काम करे।

जिन चीजों के बारे में मुझे यकीन नहीं है:

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

मेरे सवाल:

क्या स्क्रम स्वयंसेवक-आधारित वातावरण के अनुकूल हो सकता है?
और, क्या मेरा नियोजित दृष्टिकोण अब तक सही दिशा में जा रहा है?


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

जवाबों:


21

कानबन में देखें। यह आपके अवरोधों के लिए SCRUM से अधिक उपयुक्त है।

संपादित करें: SCRUM (बहुत मोटे तौर पर) स्प्रिंट्स और समारोहों के साथ एक बैकलॉग है जो यह सुनिश्चित करता है कि 'प्रगति में काम की मात्रा' नियंत्रण में रहे और हर स्प्रिंट के अंत में कुछ ठोस हो। यदि आप समारोह और स्प्रिंट कैडनेस को समाप्त करते हैं, तो आप कंबन के साथ समाप्त हो जाते हैं: एक ऑर्डरेड बैकलॉग और कार्य को 'प्रगति' में सीधे सीमित करने पर एक ज़ोर है और यह सुनिश्चित करते हुए कि सबकुछ 'किया हुआ' किया जाता है, स्थिरता के अंत में लगाने के बजाय किया जाता है। प्रत्येक स्प्रिंट।

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

आपके पास एक वोट आधारित बैकलॉग हो सकता है, हालांकि एक स्वयंसेवक में कुछ लोग जो कुछ भी चाहते हैं, उस पर काम करते हैं।

(और हाँ, सभी TDD, CI, समीक्षा और सहकर्मी प्रोग्रामिंग विचार अच्छे विचार हैं)।


1
टीडीडी महत्वपूर्ण है। आपको परीक्षण कवरेज के लिए एक मानक निर्धारित करना चाहिए और किसी भी नए कोड को अस्वीकार करना चाहिए जो परीक्षणों के साथ नहीं है।
केविन क्लाइन

1
आंतरिक परियोजनाओं के लिए एक स्वयंसेवी संगठन में भी? मुझे चिंता है कि यह काम की तरह बहुत अधिक महसूस कर रहा है और इसका हिस्सा बनने के लिए एक मजेदार सामुदायिक परियोजना की तरह पर्याप्त नहीं है।
मेटाफाइट

3
विशेषकर एक स्वयंसेवी संगठन में। आपको कुछ स्तर की गुणवत्ता (कोड, डिज़ाइन और सुविधा) बनाए रखने की आवश्यकता है। आपके विकल्प गार्ड (विश्वसनीय कोर टीम को स्वीकार करने और समीक्षा करने के आरोप में) या परीक्षकों की एक सेना (स्वयंसेवक? शुभकामनाएँ) हैं। TDD एक रामबाण नहीं है, लेकिन व्यक्तिगत रूप से सत्यापित करना आसान है, रेपो / CI स्तर (कवरेज) पर लागू होता है और वास्तव में खराब डिज़ाइन या पूरी तरह से गैर-कार्यात्मक कोड को फ़िल्टर करने में मदद करता है।
20

@ मैटाफाइट अगर आप काम को और अधिक मज़ेदार बनाना और बांटना चाहते हैं, तो आप कंबन के लिए KanbanFlow.com को आज़मा सकते हैं। वे पोमोडोरो तकनीक का उपयोग करते हैं और उन लोगों को अंक देते हैं जिन्होंने एक पोमोडोरो (?) को पूरा किया। यह साइटों के Gamification तकनीक में से एक है जो चीजों को अधिक मज़ेदार बनाता है।
जॉन यशायाह कार्मोना

5

आपके द्वारा पहले नोट किए गए मतभेदों को दूर करने के लिए:

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

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

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

दैनिक स्टैंडअप के बारे में, वे अभी भी आपकी सेटिंग में उपयोगी होंगे, यदि केवल यह बताने के लिए कि सभी को क्या करना है या जिनके साथ समस्याएं हैं (और यह जटिलता से स्वतंत्र है)। लेकिन एक दैनिक स्टैंडअप का एहसास करना कठिन हो सकता है, इसलिए आपको वहां समझौता करने की आवश्यकता हो सकती है।

आपके द्वारा उल्लिखित XP प्रथाओं को स्क्रम के उपयोग से स्वतंत्र रूप से पेश किया जा सकता है या नहीं किया जा सकता है और पूर्वव्यापी के दौरान भी प्रस्तावित किया जा सकता है।


5

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

चंचलता संचार और सहयोग के बारे में है। कारण है कि एजाइल मेनिफेस्टो में 4 में से 2 अंक इसके बारे में बात करते हैं।

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

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

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

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

अंतिम बात यह है कि मेरा मानना ​​है कि आपको कम से कम कुछ लोगों को पूर्णकालिक प्रोजेक्ट पर काम करना चाहिए। उन लोगों की विशिष्ट भूमिकाएँ होनी चाहिए:

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

1

आप इसका वर्णन उस तरह से नहीं कर सकते, जैसा आप कर रहे हैं और फिर भी इसे SCRUM कहते हैं। लेकिन मेरी राय में, आप अपने द्वारा बताए गए सेटअप के लिए निम्नलिखित की तरह स्क्रम का उपयोग कर सकते हैं।

  1. नियत चलना है। ताकि आप अपनी प्रगति को माप सकें। यह केवल प्रबंधन के लिए नहीं है, बल्कि टीम के लिए भी है कि वे यह जान सकें कि वे कैसा प्रदर्शन कर रहे हैं।
  2. स्वयंसेवकों को पुनरावृत्ति की शुरुआत में क्षमता साझा करने के लिए कहें। सभी टीम को उन सदस्यों की आवश्यकता होती है जो सदस्य कमिट कर रहे हैं अन्यथा कुछ सदस्य ऐसे काम के लिए टीम छोड़ सकते हैं जो अधिक पेशेवर रूप से किए गए हैं।
  3. कोई समय सीमा नहीं होना ठीक है। स्क्रम इस बात को बल नहीं देता कि आप प्रत्येक पुनरावृत्ति के अंत में क्या करते हैं, संभावित रूप से shippable होना चाहिए। यह आपको यह तय करने देगा कि आपने तब तक जो किया है उसके आधार पर आगे क्या करना है (जो काम कर रहा है)।
  4. कोई भी उत्पाद स्वामी नहीं होने के कारण भी काम कर सकता है .. आपके पास रैंक बैकलॉग को स्टैक करने और किए गए कार्य को स्वीकार / अस्वीकार करने के लिए कुछ प्रकार की वोटिंग प्रणाली हो सकती है।
  5. आवश्यकता एकत्र करना स्क्रम का हिस्सा नहीं है। आप इसे वैसे भी कर सकते हैं जैसा आप चाहते हैं। लेकिन पुनरावृति दायरे के हिस्से के रूप में इसे शामिल न करें। उसके लिए अलग क्षमता रखें। इसलिए एक पुनरावृत्ति के लिए, केवल उसी कार्य की योजना बनाएं जिसके लिए आवश्यकताएं स्पष्ट हैं जैसे टीम स्वीकृति मानदंड जानती है।
  6. पूर्वव्यापी अच्छे हैं। इसलिए इसे स्क्रैम के रूप में शुरू करें लेकिन फिर पूर्वव्यापी का उपयोग करके देखें कि क्या काम कर रहा है और क्या नहीं है जैसे कि आपको पुनरावृत्ति आकार बदलने की आवश्यकता हो सकती है, आपको कुछ स्वयंसेवकों से छुटकारा पाने की आवश्यकता हो सकती है जो हर किसी को खींच रहे हैं।
  7. दैनिक स्थिति अवश्य है। यह टीम को एक दूसरे के साथ समन्वय करने का अवसर देता है अर्थात वे अपने प्रयासों को संरेखित करेंगे ताकि किसी भी कार्य को अन्य सदस्य के वितरण की अनुपलब्धता के कारण अनावश्यक रूप से अवरुद्ध न हो।
  8. XP अच्छा है। XP पर आधारित एक सख्त परिभाषा है उदा। जब तक कोई समीक्षा न हो जाए। अधिक करने के लिए कम करो ।।

1

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

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

यह मुझे एक विकास प्रक्रिया के बारे में सोचने के लिए प्रेरित करता है जो तार फ्रेम और प्रोटोटाइप के आसपास अधिक केंद्रित है।

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


0

मुझे लगता है कि कंबन इस स्थिति के लिए बेहतर फिट होंगे।

Scrum में कुछ चीजें हैं जो फिट नहीं हैं। समय या गुंजाइश माप आवश्यक नहीं है और हमेशा के लिए विकसित करने के लिए बैठकों से एक ही उत्पाद दृष्टि है। जवाबदेही और स्थिरता के साथ एक छोटी योजना का पालन करना व्यावसायिक उद्देश्य हैं।

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

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

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