मुझे अपनी टीम के लिए SCRUM बनाम कम औपचारिक, अधिक हल्की प्रक्रिया की आवश्यकता क्यों है?


25

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

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

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
  • व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
  • अनुबंध बातचीत पर ग्राहक सहयोग
  • एक योजना के बाद बदलने का जवाब

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

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

scrum 

मुझे यकीन नहीं है कि मैं समझता हूं कि "अधिक हल्के" से आपका क्या मतलब है। क्या ऐसा है ... कुछ भी नहीं? कोई प्रक्रिया नहीं? या कुछ स्पेक्स, JIRA कार्यों और व्यक्तिगत डेवलपर योगदान की तरह? तो कृपया स्पष्ट करें कि आपका क्या मतलब है।
Schultz9999

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

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

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

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

जवाबों:


13

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

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

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

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

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

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


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

11

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

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


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

+1 (+100, अगर मैं कर सकता था): यहाँ भी वही अनुभव।
जियोर्जियो

7

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

इसलिए मैं यह कहना चाहता हूं कि दूसरे लोग पहले से ही क्या कह रहे हैं, लेकिन अधिक प्रत्यक्ष भाषा में: SCRUM का मुख्य लक्ष्य सॉफ्टवेयर विकास का प्रबंधन नहीं है, SCRUM का मुख्य लक्ष्य सॉफ्टवेयर विकास को मापना है।

अन्य प्रणालियों ने पहले भी कोशिश की है और लोगों ने सॉफ्टवेयर विकास की कोशिश करने और मापने के लिए अनगिनत मैट्रिक्स का प्रस्ताव दिया है लेकिन असफल रहे हैं। SCRUM अपने सिर पर समस्या को चालू करता है और प्रबंधकों से दूर और स्वयं डेवलपर्स पर माप के बोझ को स्थानांतरित करता है। तर्क सरल है: यह अनुमान लगाने में बेहतर है कि काम करने वाले लोगों की तुलना में कुछ करने में कितना समय लगता है?

अब, इसके साथ समस्या यह है कि प्रोग्रामर बहुत अधिक आशावादी होने के लिए जाने जाते हैं। एक प्रोग्रामर से पूछें कि उसे कुछ करने में कितना समय लगता है और वह आमतौर पर इस बात को कम आंकता है कि वास्तव में कार्य कितना कठिन है। SCRUM इसे नियंत्रित करने के लिए उपकरण प्रदान करता है:

  • प्रगति को नापने और परियोजना का एक बड़ा-चित्र देखने के लिए दैनिक बैठकें
  • अनुमान समय को दूर करने के लिए घंटों / दिनों के बजाय "बिंदुओं" में किया जाता है
  • बर्न-डाउन चार्ट और पॉइंट्स के वेग की कल्पना करने के लिए टार्चर / हर चार्ट
  • कार्यभार का समग्र दृष्टिकोण प्राप्त करने के लिए एक बोर्ड पर कहानियां और कार्य
  • स्प्रिंट और पुनरावृत्तियों को समय सीमा के रूप में कार्य करने के लिए ताकि हम प्रगति को माप सकें
  • धोखा देने से बचने के लिए मास्टर, मालिक और टीम के सदस्य के लिए विशिष्ट भूमिकाएँ

आदि।

आप देख सकते हैं कि उपरोक्त सभी मुख्य रूप से दो चीजें करते हैं:

  1. वे काम को मापते हैं। या तो किया जाने वाला काम या किया जा रहा काम या पूरा किया हुआ काम।
  2. वे एक बेहतर, अधिक यथार्थवादी अनुमान प्राप्त करने के लिए ओवरोप्टिमिस्टिक प्रोग्रामर की समस्या से बचने के लिए बहुत प्रयास करते हैं।

अब आप SCRUM को अधिक सटीक रूप से कार्यान्वित करेंगे तो आप अपना अनुमान लगा पाएंगे। वास्तव में, मैं व्यक्तिगत रूप से विश्वास करता हूं कि स्प्रिंट + एक बैकलॉग + एक बर्न-डाउन चार्ट अकेला है, जो प्रोग्रामर को यह अनुमान लगाने के लिए पर्याप्त है कि कुछ करने में कितना समय लगता है।


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

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

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

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

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

2

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


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

1

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

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

पुनश्च: स्क्रम यह अनिवार्य नहीं करता है कि आपका स्प्रिंट दो सप्ताह लंबा होना चाहिए। यह महीने भर (आपका मामला) हो सकता है।


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

1

कृपया मेरी टिप्पणियों को पहले प्रश्न पर देखें।

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

2 सप्ताह तक घूमना कठिन है। बहुत मुश्किल। 3 सप्ताह बेहतर है, लेकिन वास्तव में अनुभवी और प्रक्रिया टीम से परिचित है। हमारे पास 4 सप्ताह या एक महीना था। इससे हमें शुरुआत में बोलने के लिए "व्यवस्थित" होने के लिए पर्याप्त समय मिला और पूरे परीक्षण के बाद अंत में अधिक आत्मविश्वास मिला। मुझे यह पसंद आया और मैं कम से कम 3 सप्ताह तक रहना चाहूंगा।

मैं जिस दूसरी टीम के साथ काम कर रहा था, उसके पास बैकलॉग के अलावा कुछ नहीं था। वे एक साथ मिलेंगे, स्थिति पर रिपोर्ट करेंगे और आगे क्या होगा और यही है। एक बार सब कुछ हो जाने के बाद, वे एक और बैकलॉग लेकर आएंगे। उन्हें पता था कि यह SCRUM नहीं है, लेकिन यह उनके लिए काम करता है और यही महत्वपूर्ण है।

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

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

बस ... चपल रहें ;-)


1

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

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

गंभीरता से, हालांकि, मुझे नहीं लगता कि आपको स्क्रम की आवश्यकता है। घोटाले में ऐसा कुछ भी नहीं है जो अन्य प्रतिस्पर्धी चुस्त प्रक्रियाओं से बेहतर हो। इसके अलावा, यह चीजों के लिए बहुत सारे बेवकूफ नाम हैं।


1

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

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

तब मुझे बताया गया है कि कार्यप्रणाली हमें परिवर्तन का जवाब देने में मदद करती है। SCRUM के कौन से विशिष्ट पहलू मुझे इतने लचीले होने की अनुमति दे रहे हैं कि मैं पहले अपने तदर्थ बैठकों, क्यूब चर्चाओं, और डेवलपर नियोजन बैठकों के साथ प्राप्त नहीं कर रहा था?

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

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

ओरिजिनल स्क्रम महीने-महीने के स्प्रिंट को निर्धारित करता है। ऐंठन को कम करने में फुर्तीली machismo की ओर एक बुरा रुझान है। ("हाँ, अच्छी तरह से हमारे स्प्रिंट केवल एक दिन हैं ...") ग्राहक / ग्राहक जो कोई भी यह कहने का अधिकार रखता है कि परियोजना जाने के लिए अच्छा है, या अधिक काम करने की आवश्यकता है। यदि आप हर महीने ऊपरी प्रबंधन के लिए प्रदर्शन कर रहे हैं, तो वे शायद आपके ग्राहक हैं, और आप शायद पहले से ही स्क्रैम के बहुत करीब हैं।

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

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


0

हम काम में स्क्रम का उपयोग नहीं करते हैं। हम एजाइल और लीन में स्थापित एक पद्धति का उपयोग करते हैं जो कई मामलों में समान है। मैंने इस प्रक्रिया का उपयोग लीड सहित 3-5 लोगों के बीच अलग-अलग आकार में किया है। हालांकि ऐसे मतभेद हैं जो मुझे लगता है कि आप यह पता लगाने में मदद कर सकते हैं कि क्या आपकी स्थिति के लिए स्क्रैम उपयोगी है।

मेथडोलॉजी एक्सप्लिसिट बनाना

हम अपनी प्रक्रिया को स्पष्ट करते हैं क्योंकि हम प्रत्येक स्प्रिंट रैप-अप / समीक्षा के साथ हमारी प्रक्रिया की समीक्षा करते हैं। रैप-अप / समीक्षा का हिस्सा उन प्रथाओं की पहचान करना है जो हमारे लिए काम नहीं कर रहे हैं। हम उन प्रथाओं पर भी चर्चा करते हैं जो हमें लगता है कि हमारे लिए काम करेंगे और यदि कोई पर्याप्त समझौता है तो हम इसे आजमाएंगे। हम अपनी कार्यप्रणाली को संहिताबद्ध किए बिना ऐसा नहीं कर पाएंगे।

साइन ऑफ़

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

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

लंबवत स्लाइस

हम अपने विकास के सभी ऊर्ध्वाधर स्लाइस में करते हैं। यह एक पूर्ण सुविधा के साथ-साथ इन अन्य कारणों से साइन ऑफ करने की क्षमता का समर्थन करता है।

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

स्वीकृति टीडीडी

हम स्वीकृति tdd के लिए इकाई परीक्षण ढांचे का लाभ उठाते हैं। इससे हमें कई लाभ मिलते हैं।

  • बड़े पुनर्गठन से परीक्षण के समय में बहुत खर्च नहीं होता है।
  • हम ग्राहक कार्यक्षमता का आश्वासन देते हैं।
  • हम कोड एकीकरण को कवर करते हैं।
  • वर्टिकल स्लाइस डेवलपमेंट प्रैक्टिस का समर्थन करें।

द बिल्ड इज ऑल्वेज़ रिलीजेबल

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

  • हमें आसानी से सुविधाओं को काटने की अनुमति देता है क्योंकि हम क्रॉस निर्भरता के बहुत से समाप्त करते हैं।
  • अगर हमें दिशा बदलने की जरूरत है तो हम विकास को काट सकते हैं।
  • हम पुनरावृत्त रिलीज़ कर सकते हैं , ग्राहक को कार्यक्षमता प्रदान कर सकते हैं ।

लगातार मेल जोल

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

कार्ड के लिए प्वाइंट अनुमान

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

वेग

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

वृद्धिशील सुधार और डिजाइन

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

अधिकांश भाग के लिए ये नियम हैं जिनका हम पालन करते हैं और हम उनका पालन क्यों करते हैं।


0

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

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

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

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

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