हमने टीमों में विकास को कैसे तोड़ दिया (और अंतहीन स्प्रिंट और बेकार स्टैंड-अप के बारे में भूल गए)

मैं UniSender मेलिंग सेवा में PM हूं। 6 साल पहले मैं एक प्रोग्रामर के रूप में आया था, और अब मैं उत्पाद टीमों के बीच बातचीत के लिए जिम्मेदार हूं। पहले, हमारे विकास में एक वितरित टीम शामिल थी और हमें 2 परेशानियां थीं। लेकिन मूर्खों और सड़कों पर नहीं, बल्कि स्प्रिंट्स और उबाऊ स्टैंडअप में आधे घंटे तक देरी होती है।

मैं आपको बताऊंगा कि हमने उन्हें कैसे हल किया।

जैसा कि मैंने कहा, हमें 2 परेशानियाँ थीं:

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

कुछ समय तक हम इन समस्याओं के साथ रहे, फिर लड़ने की कोशिश की।

• उन्होंने मनुष्यों पर नियमों की शुरूआत के माध्यम से स्टैंड-अप को कम कर दिया।
• उन्होंने उपस्थित लोगों की संख्या कम कर दी - केवल टीम लीडर स्टैंड-अप में चले गए।
• साप्ताहिक स्प्रिंट की कोशिश की।
• स्प्रिंट में कार्यों की संख्या कम कर दी।

इन प्रयासों ने अपेक्षित परिणाम नहीं दिया। एक समझ यह आई है कि आमूल-चूल बदलावों से दूर नहीं किया जा सकता है।

यहां आपको उत्पाद के बारे में कुछ शब्द कहने की आवश्यकता है।

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

कानबन जाना

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

स्प्रिंट और टीम काम करते हैं

हमारे संस्करण के बारे में संक्षेप में:

• हमने स्प्रिंट (कार्यक्षमता का एक पूरा टुकड़ा) को काम की इकाई माना।
• कार्य के लिए एक टीम को लोड और आवश्यक कौशल के आधार पर एकत्र किया गया था। एक टीम में आमतौर पर 3 डेवलपर्स और 1 क्यूए तक होते थे। कोई स्थायी टीम नहीं थी।
• एक साथ स्प्रिंट की संख्या एक से अधिक हो गई है।
• कानबन की कोई भौतिक बोर्ड और अन्य विशेषताएं नहीं थीं, कार्यों को जीरा के अलावा के माध्यम से किया गया था।

इस मामले में, टीम को शुरू से अंत तक स्प्रिंट करना पड़ा। यह परीक्षण के चरण पर भी लागू होता है: स्प्रिंट पर काम करने वाले उन्हीं लोगों ने त्रुटियों को ठीक किया।

परिणाम।

• बड़े कार्यों की देरी के साथ, दूसरों को नुकसान नहीं हुआ, जिसका विकास पूरा हुआ।
• तैनाती के दौरान समस्याओं की संख्या में कमी आई है - एक स्प्रिंट में कम प्रेरक कार्य होते हैं।

खड़ा हुआ

स्टैंड-अप को रूपांतरित किया गया था - उन्हें प्रत्येक टीम के एक प्रतिनिधि द्वारा दौरा किया गया था जो एक अलग स्प्रिंट पर काम करता था।

परिणाम।

• स्टैंडअप, स्टैंडअप की तरह हो गए और हम फिर से 10-15 मिनट के मानक में फिट होने लगे।

इस प्रकार, हम महत्वपूर्ण समस्याओं को हल करने में सक्षम थे।

लेकिन ... द्वीप के पीछे से पूरा हिमखंड उभरने लगा!

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

हमने कुछ समस्याओं को हल किया, लेकिन नए सामने आए:

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

कुछ समय तक हम नए नियमों से गुजरे और नई चुनौतियों से जूझते रहे। हमने अलग-अलग तरीकों की कोशिश की और बहुत सारे शंकु भरे।

अंत में, हमें फिर से शक होने लगा कि कुछ गलत हो रहा है। होने के लिए एक नई क्रांति।

टीमों में विभाजन, नए स्टैंड-अप, फायरटेम की शुरूआत

हमने विचार की स्थापना से लेकर उत्पादों में तैयार कार्यान्वयन की तैनाती तक की प्रक्रियाओं का विश्लेषण किया। हमने देखा कि अन्य कंपनियों में चुस्त तरीके कैसे काम करते हैं। हमने महसूस किया कि विकास प्रक्रिया के लिए हमारे दृष्टिकोण इतने बुरे नहीं थे।

किसी कार्य प्रणाली को तोड़ने की आवश्यकता नहीं है, आपको उन क्षणों को ठीक करने की आवश्यकता है जो दर्द का कारण बनते हैं।

विकास प्रक्रिया के दौरान हमने यही बदला।

स्प्रिंट

हमने अभी भी "स्प्रिंट" की अवधारणा पर काम किया है। स्प्रिंट टीम के लिए एक "दो सप्ताह के पास" कार्यक्षेत्र है।

प्लस क्या है? कोड "खराब नहीं होता है" और महत्वपूर्ण देरी के बिना ठेस पहुंचता है। यदि टीम 2 सप्ताह में स्प्रिंट करने जा रही है - आपको इसे एक महीने तक कसने की कोशिश करने की आवश्यकता है।

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

टीमों में विभाजन

हमने एक बड़ी टीम को कई छोटी टीमों में विभाजित किया। उनमें से प्रत्येक में 2-3 डेवलपर्स और एक समर्पित क्यूए शामिल हैं। अब टीमें स्थिर हैं और परियोजना से परियोजना में नहीं बदलती हैं। कभी-कभी लोग रोस्टरों को अनुकूलित करने या टीम में आवश्यक विशेषज्ञता जोड़ने के लिए टीमों के बीच स्विच करते हैं। बीए टीम में भाग लेता है, लेकिन एक ही समय में 2-3 परियोजनाओं का नेतृत्व कर सकता है।


हालाँकि बाकी अभी भी एक टीम है)

इसी समय, पूरी टीम शुरू से लेकर उसके पूरा होने तक एक परियोजना पर काम करती है। एक परियोजना में कई स्प्रिंट शामिल हो सकते हैं।

प्लस क्या है?

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

क्या सुधार किया जा सकता है। मैं टीम में पूरी तरह से बी.ए. यह समस्याग्रस्त है क्योंकि वीए आमतौर पर बाकी टीम की तुलना में पहले काम करना शुरू करता है।

टीम का काम

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

प्लस क्या है? टीम का काम अधिक अनुमानित हो गया है, हर कोई कोड से परिचित है और परीक्षण के दौरान स्प्रिंट का समर्थन कर सकता है। प्रतिभागियों को कार्यों के बीच स्विच करने की संभावना कम है, और स्विच करने की प्रक्रिया अब तेज है।

क्या सुधार किया जा सकता है। आदर्श रूप से, एक टीम के पास काम में केवल एक स्प्रिंट होना चाहिए। लेकिन अभी के लिए, एक आदर्श दुनिया हमारी दुनिया नहीं है।

Fireteam

प्रत्येक टीम एक सप्ताह के लिए चुनी जाती है। यह आदेश सभी बाहरी परेशानियों का जवाब देता है: अन्य विभागों से कॉल, सेवा का असामान्य व्यवहार, हॉटफ़िक्स। हम इस टीम को "फायरटेम" कहते हैं।

प्लस क्या है? फायरटाइम सप्ताह स्प्रिंट समय में टीम की ओर नहीं गिना जाता है। अग्निशमन के बीच, कर्मचारी अपने कार्यों पर ध्यान केंद्रित कर सकते हैं:

• Refactor।
• स्प्रिंट कार्य पूरा करें।
• दस्तावेज लिखें।
• अन्य टीमों के साथ एक ज्ञान हस्तांतरण करें।

कमी। Fireteam सप्ताह में, टीम का जीवन बहुत ही घटनापूर्ण है। सभी विभाग व्यक्तिगत रूप से इन लोगों को प्यार करते हैं और जानते हैं, विशेष रूप से तकनीकी सहायता। आपको विभिन्न कार्यों के बीच लगातार स्विच करना होगा: बहस करना, लॉग पढ़ना, जरूरी कार्य देखना और सभी आगें लगाना। यह सब एक साथ किया जाना चाहिए।

खड़ा हुआ

हमने 2 प्रकार के स्टैंड-अप पेश किए:

1. टीम। उन्होंने एक टीम को शामिल किया जो परियोजना पर काम करती है।
2. जनरल। उन्हें सप्ताह में एक बार आयोजित किया जाता है, प्रत्येक टीम के लीड उनमें भाग लेते हैं।

प्लस क्या है?

• टीम को स्प्रिंट की स्थिति के बारे में सूचित किया जाता है।
• कर्मचारी जानते हैं कि अन्य टीमें क्या कर रही हैं।
• स्टैंड-अप "कागज के कुछ सेटों के टुकड़े से पढ़ने के लिए उबाऊ गतिविधियों" में बदल नहीं जाता है। सभी मौजूद लोग समझते हैं कि दांव पर क्या है। काम पर समस्या वाले क्षेत्रों का पता लगाना आसान हो गया है।
• स्टैंडअप में 5-10 मिनट लगते हैं।

कमी। टीम अभी भी टीम को जानकारी देती है।

परिणाम

इस प्रकार, धीरे-धीरे इस प्रक्रिया को बदलते हुए, हमने दबाव की अधिकांश समस्याओं को हल किया:

• हमने 2-3 डेवलपर्स और क्यूए से स्थिर टीमों को इकट्ठा किया है। प्रत्येक टीम में अब 2 से अधिक स्प्रिंट नहीं हैं, प्रतिभागी अन्य लोगों की परियोजनाओं पर काम नहीं करते हैं।
• एक टीम थी जो अन्य विभागों के संदेशों को संसाधित करती है, सेवा और हॉटफिक्स के असामान्य व्यवहार का जवाब देती है। अन्य टीम इन कार्यों से विचलित नहीं होती हैं।
• अब कंपनी के पास 2 प्रकार के स्टैंड-अप हैं: टीम और सामान्य। सभी कर्मचारियों को स्प्रिंट मामलों की स्थिति के बारे में सूचित किया जाता है, और एक स्टैंड-अप में 5-10 मिनट का मानक होता है।

खैर, हम काम कर रहे हैं।