आईटी टीम में लचीली प्रक्रियाएं

सभी को नमस्कार, मेरा नाम अलेक्सई फेडोरोव है, मैं सिटीमोबिल में वित्त टीम का टीम लीडर हूं। इस लेख में मैं साझा करना चाहता हूं कि हमारी टीम में चुस्त विकास प्रक्रिया कैसे काम करती है।

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

स्क्रेम क्यों नहीं

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

मेरी राय में, घोटाले की मुख्य समस्याएं हैं:

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

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

टीम

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

जैसा कि हमारे साथ

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

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

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

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

हम प्रत्येक कार्य के लिए कम से कम 75% कार्य समय के लिए लॉग इन करने का प्रयास करते हैं। इसके द्वारा हम दो लक्ष्य प्राप्त करते हैं:

1. हम समय-हत्यारों की तलाश करते हैं और समाप्त करते हैं: ऐसे कार्य जो समय लेने वाले थे, लेकिन अपेक्षित लाभ नहीं ला पाए।
2. हम पहले से किए गए आधार पर कार्यों का मूल्यांकन करते हैं, जिससे मूल्यांकन की सटीकता बढ़ जाती है।

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

परिणाम

कई टीमों और कंपनियों में लागू मामूली बदलावों के साथ वर्णित प्रक्रिया। उन्होंने खुद को सभी के लिए सबसे लचीले और पारदर्शी के रूप में स्थापित किया।

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

निरंतर सुधार की प्रक्रिया हमारी टीम की नींव है।