कैसे जल्दी में अंडे पकड़ने से रोकने के लिए, एक साथ समय सीमा छोड़ने? किस टूलचिन को एक बार में कई कार्यों को नष्ट करने के लिए चुनना है? हम अपने लेख में यह सब प्रकट करेंगे।

सभी अंडों को पकड़ने की कोशिश की जा रही है

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

हम एक टूलकिन का चयन करते हैं

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

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

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

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

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

किताबें झूठ नहीं बोलती थीं

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

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

एक छड़ी दुखती है, कई लाठियाँ जानलेवा होती हैं

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

संक्षेप में देना

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

पुनश्च:

यहाँ एक नमूना सूची और हमारे द्वारा देखे गए चरणों का समय है:

योजना गठन ~ 4 महीने
लघु संचार के साथ काम करें ~ 1 महीने
एक उपयुक्त टूलकिन और वर्कफ़्लो विकास के लिए खोजें ~ 2 महीने
कार्यप्रणाली की पसंद ~ 2 महीने
वर्कफ़्लो को स्क्रम का परिचय ~ 8 महीने

और यहाँ हमारे सीईओ से एक छोटा सा चयन है:

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

एक स्टार्टअप का विकास। येल्तसलोव से चिकेन आक्रमणकारियों तक चुस्त