कांटे और तारों पर विकास प्रक्रियाओं के अनुकूलन के रास्ते पर

सपने, सपने

शीत शरद ऋतु की शाम को, हम और 3 डी विज़ुअलाइज़ेशन अनुप्रयोगों के डेवलपर्स ने रसोई में इकट्ठा किया ... कॉफी पिया ... और इसके बारे में सोचा ... विकास के संदर्भ संगठन के बारे में।

- मेरे लिए फुर्तीले काम पर मेरे दोस्त: स्प्रिंट, कहानी अंक, सभी चीजें ...
- हां, हम कम से कम समीक्षा करेंगे ...



तथ्य यह है कि उन दिनों में, यह हमारे साथ बहुत सहज नहीं था। उदाहरण के लिए, git में प्रोजेक्ट्स को संग्रहीत करना बहुत ही असामान्य था:

• कई रिपोजिटरी थे, और प्रत्येक भाग में परियोजना का एक टुकड़ा था;
• कुछ रिपॉजिटरी आम थे, कुछ केवल कुछ परियोजनाओं से संबंधित थे, कुछ केवल एक के लिए;
• एक कामकाजी प्रतिलिपि प्राप्त करने के लिए, आपको सभी रिपॉजिटरी की सामग्री को डाउनलोड करना होगा और उन्हें विशिष्ट फ़ोल्डरों में डालना होगा।

चूँकि हम 3 डी ग्राफिक्स के साथ काम कर रहे हैं और फिर "नियंत्रण + टेम्पलेट्स (स्क्रीन पर तत्वों का स्थान, संक्रमण का तर्क)" की अवधारणा का उपयोग किया जाता है, और अधिक विशिष्ट होने के लिए, चीजें इस तरह थीं:

• नियंत्रणों पर काम करते समय, बुनियादी नियंत्रणों के साथ कमेट्री रिपॉजिटरी में चली गई और, संभवतः, संसाधनों के साथ रिपॉजिटरी में (यदि पहले से उपयोग किए गए तीन-आयामी मॉडल का कहीं और उपयोग करना होगा);
• नियंत्रण और टेम्पलेट्स के साथ काम करते समय (उदाहरण के लिए, यदि हेल्प पैनल के तहत एप्लिकेशन में पृष्ठभूमि को बदलना आवश्यक था), चित्रों को संसाधनों के साथ रिपॉजिटरी में अपलोड किया जाना था, और टेम्पलेट के साथ रिपॉजिटरी में संपादित लेआउट। यदि पृष्ठभूमि एक त्वचा (एकल शैली) के साथ बनाई गई थी, तो 3 रिपॉजिटरी शामिल हो सकते हैं।

इस दृष्टिकोण के साथ, कोड समीक्षाएं लागत के लिए एक लक्जरी थीं:

• विकास एक ही शाखा में किया गया था;
• एक कार्य में परिवर्तन ने कई रिपॉजिटरी और ट्रैकिंग को प्रभावित किया जो कि किस कार्य से संबंधित था, बहुत समस्याग्रस्त था।

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

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

"जहाँ सपना होता है, वहाँ हमेशा एक मौका होता है"

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

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




यहाँ, वैसे, हमने क्या किया

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

हमारा संशोधित Gitflow इस प्रकार है:

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

जब सभी कार्य बंद हो जाते हैं, तो हम रिलीज़ चरण में प्रवेश करते हैं:

• रिलीज़ शाखा को मास्टर से दूर कहा जाता है, जिसे दो अंक कहा जाता है, उदाहरण के लिए, रिलीज़-3.0, जहां 3 परियोजना का संस्करण संख्या है, और 0 रिलीज़ शाखा की संख्या है (क्रमशः, अगली रिलीज़ शाखा को रिलीज़-3.1 कहा जाएगा, आदि। );
• जारी करने वाले उम्मीदवार का आगे परीक्षण किया जाता है (आमतौर पर छोटे डेमो का विकास);
• यदि परीक्षण के दौरान कोई दोष नहीं पाया गया, तो रिलीज़ उम्मीदवार उत्पादन के लिए तैयार है: रिलीज़ शाखा में आखिरी प्रतिबद्ध 3 अंक (उदाहरण के लिए, ठेस-3.0.0, जहां 3 परियोजना संस्करण संख्या है, 0 से युक्त उत्पादन टैग के साथ चिह्नित है) - रिलीज शाखा संख्या, 0 - उत्पादन संस्करण संख्या), फिर रिलीज शाखा मास्टर में फंसी हुई है और हटा नहीं है, क्लासिक गिटफ्लो के विपरीत;
• यदि दोष अभी भी पाए जाते हैं, तो वे जीरा में बग के रूप में पंजीकृत हैं और फिर बग फिक्सिंग की प्रक्रिया सुविधा शाखा में एक कार्य के साथ काम करने के समान है (यह केवल रिलीज से जाँच की जाती है, मास्टर से नहीं) और जब सभी बग बंद हो जाते हैं, तो हम उत्पादन टैग को नीचे रख देते हैं, संस्करण ठेस के लिए आउटपुट है और रिलीज शाखा को हटाए बिना, मास्टर में विलय कर दिया जाता है।

यदि उत्पादन में बग पाए जाते हैं, तो एक समझौता भी होता है:

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

तो क्यों वास्तव में Gitflow और बस?

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

चंचल के बारे में क्या?

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



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

• नई उपयोगी सुविधाओं की पेशकश की जाती है, क्योंकि यह डेवलपर्स के लिए अधिक स्पष्ट हो जाता है कि सामान्य रूप से क्या और कहां सुधार किया जा सकता है;
• अधिक बार त्रुटियां और दोष पाए जाते हैं जो केवल प्लेटफॉर्म के संचालन के समय स्पष्ट रूप से ध्यान देने योग्य बन सकते हैं।

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

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

"और जल्दी से चलो" या एक महीने के लिए 3 पूर्ण-डेमो अनुप्रयोगों

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

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

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

• सभी विकास को विकसित शाखा में किया गया था, लेकिन अपंजीकृत कार्यों की उपस्थिति को बाहर करने के लिए, प्रत्येक प्रतिबद्ध को जीरा से कार्य कोड के साथ चिह्नित किया जाना चाहिए, जिसके ढांचे में यह किया गया था;
• जब रिलीज के लिए योजनाबद्ध सभी कार्यों को हल किया गया था, तो एक नया बिल्ड इकट्ठा किया जा रहा था: एक टीम लीड ने विकसित शाखा की समीक्षा की और, अगर सब कुछ ठीक था, तो बिल्ड नंबर के साथ एक टैग के असाइनमेंट के साथ परिवर्तन को मास्टर में मिला दिया गया था। यदि समीक्षा के दौरान सकल त्रुटियां और अनियमितताएं सामने आईं, तो संशोधन के लिए कोड भेजा गया था और प्रवेश करने के बाद ही पुन: जांच की गई थी कि क्या यह मास्टर में गया है।
• बिल्ड दो अंकों के साथ गिने जाते थे, उदाहरण के लिए, 0.1 - यह हमेशा पहले टेस्ट बिल्ड की संख्या होती है, जहां 0 - का मतलब उत्पादन संस्करण से संबंधित है, 1 - बिल्ड नंबर। और इसलिए, प्रत्येक अगले परीक्षण बिल्ड की संख्या में, अंतिम अंक बढ़ गया, जब तक कि परीक्षक और प्रबंधक एक निष्कर्ष देते हैं कि निर्माण उत्पादन में आउटपुट के लिए तैयार है। तदनुसार, यदि यह चौथा परीक्षण बिल्ड (0.4) था, तो यह पहला उत्पादन बिल्ड (1.0) बन गया और संबंधित टैग मास्टर शाखा में डाल दिया गया। यदि उत्पादन में दोषों का पता लगाया जाता है, और उत्पादन का निर्माण संपादन के लिए भेजा गया था, तो बाद के सभी बिल्ड (1.1, 1.2, आदि) को क्रमबद्ध करते समय दूसरा अंक भी बढ़ता है।

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

मेरी विनम्र राय में

मैं व्यक्तिगत रूप से इस बारे में क्या सोचता हूं?

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

यहाँ रहस्य है

उपरोक्त निष्कर्ष के बावजूद, और कुछ और मेरे लिए स्पष्ट हो गया:

- हर कोई इस बात के लिए तैयार नहीं होता है कि वे क्या सपने देखते हैं।

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

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

- , , :

— , — , , , , , — .



, , , . — . , , — .

, , « ». , , , , — . , , .

, — , .