हम स्क्रम-ऑफ-स्क्रम्स का संचालन कैसे करते हैं

स्क्रम-ऑफ़-स्क्रम नियमित बैठकें हैं जिनका उद्देश्य स्क्रम मास्टर्स के बीच विभिन्न मुद्दों पर चर्चा करना है।

एक बार हम चार उत्पादों पर काम कर रहे थे। उनमें से तीन पर एक स्क्रम टीम द्वारा काम किया गया था, और चौथे पर - 25 लोगों ने काम किया था, जिन्हें कई स्क्रम टीमों में विभाजित किया गया था। यह इस तरह दिखता था:

हमारे पास स्क्रम-ऑफ-स्क्रम्स के दो स्तर थे: "उत्पाद स्तर", जो उत्पाद डी टीमों की भागीदारी के साथ आयोजित किया गया था, और सभी टीमों के सदस्यों के लिए "कंपनी स्तर"।

उत्पाद स्तर स्क्रम-ऑफ-स्क्रम्स

ये मुलाकात बेहद अहम थी. हमने इसे सप्ताह में कम से कम एक बार आयोजित किया। हमने एकीकरण, टीमों को संतुलित करने, अगली स्प्रिंट योजना की तैयारी आदि मुद्दों पर चर्चा की। हमने इसके लिए 30 मिनट आवंटित किए, लेकिन अक्सर हमारे पास पर्याप्त नहीं थे। एक विकल्प दैनिक स्क्रम-ऑफ-स्क्रम्स का संचालन करना होगा, हालाँकि, हम इसे आज़माने के लिए कभी तैयार नहीं हुए।

हमारा एजेंडा इस तरह दिखता था:

1. प्रत्येक व्यक्ति ने बारी-बारी से बताया कि उनकी टीम ने पिछले सप्ताह क्या किया, उन्होंने इस सप्ताह क्या पूरा करने की योजना बनाई और उन्हें किन कठिनाइयों का सामना करना पड़ा।

2. एक ही समय में कई टीमों की क्षमता से संबंधित कोई अन्य मुद्दा जिस पर चर्चा की आवश्यकता है। उदाहरण के लिए, एकीकरण मुद्दे.

वास्तव में, स्क्रम-ऑफ-स्क्रम्स एजेंडा उतना महत्वपूर्ण नहीं है - यह अधिक महत्वपूर्ण है कि यह बैठक नियमित रूप से आयोजित की जाए।

स्क्रम एंड एक्सपी: नोट्स फ्रॉम द फ्रंट लाइन्स पुस्तक से लेखक निबर्ग हेनरिक

लाभदायक ब्लॉग पुस्तक से: बनाएं, प्रचारित करें और कमाएं लेखक लिट्विन एवगेनी

लेखक की किताब से

लेखक की किताब से

लेखक की किताब से

हम डेमो कैसे संचालित करते हैं स्प्रिंट डेमो स्क्रम का एक बहुत ही महत्वपूर्ण हिस्सा है, जिसे कई लोग अभी भी कम आंकते हैं। “ओह, क्या हमें डेमो करना होगा? हम वैसे भी कुछ भी दिलचस्प नहीं दिखाएंगे!” "हमारे पास अलग-अलग &%$# ​​डेमो तैयार करने का समय नहीं है!" “मेरे पास बहुत काम है, नहीं

लेखक की किताब से

लेखक की किताब से

हम पूर्वव्यापी कार्रवाई कैसे करते हैं हालांकि मूल प्रारूप थोड़ा भिन्न होता है, आम तौर पर हम यही करते हैं: 1-3 घंटे आवंटित करें, यह इस बात पर निर्भर करता है कि चर्चा कितनी देर तक चलने की उम्मीद है। भाग ले रहे हैं: उत्पाद स्वामी, पूरी टीम और मैं। हम या तो अलग-अलग स्थित हैं

लेखक की किताब से

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

लेखक की किताब से

स्क्रम टीम में परीक्षकों को शामिल करके गुणवत्ता बढ़ाएँ ओह, मैं पहले से ही ये आपत्तियाँ सुन सकता हूँ: “लेकिन यह स्पष्ट है! स्क्रम टीमों को क्रॉस-फंक्शनल होना चाहिए! "स्क्रम टीम में कोई समर्पित भूमिका नहीं होनी चाहिए!" हमारे पास ऐसा कोई व्यक्ति नहीं हो सकता जो केवल परीक्षण में शामिल हो! मैं ऑनलाइन सेमिनार और प्रशिक्षण पाठ्यक्रम आयोजित करूंगा। इस प्रकार की आय सबसे महत्वाकांक्षी और सक्षम ब्लॉगर्स, पेशेवरों, गुरुओं, उनके विषय के विशेषज्ञों के लिए उपयुक्त है। या उन ब्लॉगर्स के लिए, जिन पर खुद का ध्यान नहीं गया, वे एक ब्लॉगर बन गए हैं

माइक कोहन द्वारा प्राक्कथन

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

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

हेनरिक चयनित प्रथाओं का एक सेट प्रदान करता है और लाइव उदाहरणों का वर्णन करता है ताकि हमें यह समझने में मदद मिल सके कि फ्रंट लाइन पर स्क्रम और एक्सपी का उपयोग कैसे किया जाए।

हेनरिक नाइबर्ग

स्क्रम और एक्सपी: फ्रंट लाइन्स से नोट्स

दुर्भाग्य से, हमें कृतज्ञता के लिए केवल एक पृष्ठ दिया गया। इसलिए, मैं अपने सभी कार्यकर्ताओं को तथ्यों के साथ प्रस्तुत करने का प्रयास करूंगा।

मैक्सिम खारचेंको समुद्र में भी अनुवाद करने में कामयाब रहे। धन्यवाद हाइपर. जाल

डिमा डेनिलचेंको निदेशक और अंशकालिक (और ऐसा होता है ☺) हमारे प्रोजेक्ट में सबसे सक्रिय अनुवादकों में से एक है।

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

बोरिया लेबेडा ने मूल को शब्द से विकि प्रारूप में परिवर्तित करने को स्वचालित किया। मुझे नहीं पता था कि यह इतनी आसानी से किया जा सकता है।

जारोस्लाव हनाट्युक हेनरिक को व्यक्तिगत रूप से जानते हैं।

एंटोन मर्युखेंको सबसे युवा और सबसे होनहार हैं।

सर्गेई पेत्रोव सबसे उम्रदराज़ और सबसे अनुभवी हैं।

मरीना कडोचनिकोवा हमारी एकमात्र महिला अनुवादक हैं।

शेरोज़ा मोचन, बेशक, मैं तुम्हारे बारे में नहीं भूला हूँ ☺। बस आपको विशेष धन्यवाद कहना चाहता था। आप दूसरे लोकोमोटिव थे, जिसकी बदौलत हम कड़वे अंत तक पहुंचने में कामयाब रहे। आख़िरकार, जैसा कि एक जापानी कहावत है: "शुरू करना आसान है, जारी रखना कठिन है।"

अंतिम प्रूफ़रीडिंग और संपादन के लिए मरीना ज़ुब्रित्सकाया और लेशा मामची को धन्यवाद। वे स्पष्टतः परिष्कृत पाठ में सौ से अधिक त्रुटियाँ ढूँढ़ने में सफल रहे। पूर्णता की कोई सीमा नहीं है.

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

लेशा सोलन्त्सेव,

पहले यूक्रेनी क्राउडसोर्सिंग प्रोजेक्ट के आरंभकर्ता और समन्वयक, प्रमाणित स्क्रम मास्टर

पी.एस. आप मूल पुस्तक http://www.infoq.com/minibooks/scrum-xp-from-the-trenches पर डाउनलोड कर सकते हैं

ज्योफ सदरलैंड द्वारा प्राक्कथन

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

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

यह क्यों इतना महत्वपूर्ण है? यदि टीम को अपना प्रदर्शन नहीं पता है, तो उत्पाद स्वामी विश्वसनीय रिलीज़ तिथियों के साथ एक रणनीतिक उत्पाद विकास योजना विकसित नहीं कर सकता है। ऐसी योजना के बिना, कंपनी विफल हो सकती है, जिससे निवेशकों को अपना पैसा खोना पड़ सकता है।

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

पुनरावृत्तियों की एक निश्चित लंबाई होनी चाहिए और छह सप्ताह से अधिक नहीं होनी चाहिए।

प्रत्येक पुनरावृत्ति के अंत तक, कोड का गुणवत्ता आश्वासन (क्यूए) द्वारा परीक्षण किया जाना चाहिए और अपेक्षा के अनुरूप काम करना चाहिए।

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

फिर मैंने उनसे पूछा कि क्या वे नोकिया द्वारा विकसित स्क्रम मानक का पालन करते हैं:

स्क्रम टीम में एक उत्पाद स्वामी होना चाहिए और टीम को पता होना चाहिए कि वह कौन है।

उत्पाद स्वामी के पास कहानियों और टीम द्वारा पूरे किए गए उनके मूल्यांकन के साथ एक उत्पाद बैकलॉग होना चाहिए।

टीम के पास एक बर्नडाउन चार्ट होना चाहिए, और टीम को स्वयं अपना प्रदर्शन जानना चाहिए।

स्प्रिंट के दौरान किसी को भी टीम के काम में हस्तक्षेप नहीं करना चाहिए।

स्क्रम को कार्यान्वित करने वाली तीस टीमों में से केवल तीन के पास ऐसी विकास प्रक्रिया थी जो नोकिया मानकों के अनुरूप थी। मुझे लगता है कि केवल इन तीन टीमों को ही उद्यम पूंजीपतियों से और निवेश प्राप्त होगा।

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

माइक कोहन द्वारा प्राक्कथन

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

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

हेनरिक चयनित प्रथाओं का एक सेट प्रदान करता है और वास्तविक जीवन के उदाहरणों का वर्णन करता है ताकि हमें यह समझने में मदद मिल सके कि फ्रंट लाइन पर स्क्रम और एक्सपी का उपयोग कैसे करें।

प्रस्तावना-अरे! लेकिन स्क्रम काम करता है!

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

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

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