हम जटिल परियोजनाओं के विकास की प्रक्रिया को गति देते हैं। अराजकता और नसों के बिना

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

ऐसे मामलों में, आप विशेषज्ञों की एक नई टीम से जुड़ सकते हैं, मौजूदा एक में प्रक्रियाएं स्थापित कर सकते हैं या दोनों को जोड़ सकते हैं। प्रत्येक दृष्टिकोण के पेशेवरों और विपक्षों पर विचार करें। तुरंत एक आरक्षण करें कि लेख बड़ी और जटिल परियोजनाओं (10,000 से अधिक घंटे) के विकास पर चर्चा करता है।

आप तुरंत नए विशेषज्ञों को क्यों नहीं जोड़ सकते हैं

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

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

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

उपरोक्त बारीकियों के परिणाम हैं:

• अतिरिक्त समय की लागत जो व्यावसायिक समस्याओं को हल करने पर खर्च की जा सकती है
• पूरे सिस्टम का धीमा विकास
• या ओवरटाइम।

विचार करें कि इस स्थिति से कैसे बचा जाए।

प्रक्रिया विश्लेषण

नए विशेषज्ञों को जोड़ने से पहले, यह पता लगाना सार्थक है कि टीम के काम की व्यवस्था कैसे की जाती है - यह बाधाओं को खोजने और खत्म करने के लिए आवश्यक है। आमतौर पर, पीएम इस मुद्दे से निपटता है, क्योंकि वह परियोजना के लिए जिम्मेदार है, और वह ट्रैकिंग प्रक्रियाओं पर कम ऊर्जा खर्च करना चाहता है।

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

अड़चनों का विश्लेषण दो पक्षों से संभव है: शीर्ष प्रबंधन / विशेषज्ञ से और टीम से। हम प्रत्येक विकल्प का अलग-अलग विश्लेषण करेंगे।



बाहर के विशेषज्ञ। इस दृष्टिकोण में, कार्य प्रक्रिया का विश्लेषण या तो बाहरी विशेषज्ञों की बाहरी टीम द्वारा किया जाता है, या प्रोजेक्ट मैनेजर द्वारा टीम लीडर के साथ मिलकर किया जाता है। उत्तरार्द्ध के साथ, यह तथ्य नहीं है कि यह बदल जाएगा - यह महत्वपूर्ण है कि वे परियोजना की सभी बारीकियों को छोड़ सकते हैं, अन्यथा विश्लेषण व्यर्थ होगा।

एक महत्वपूर्ण शर्त परियोजना प्रबंधन और परिवर्तन के लिए तत्परता का समर्थन है।

तदनुसार, विशेषज्ञ परियोजना में डूब जाता है और प्रलेखन, स्रोत कोड, डेटाबेस संरचना, उत्पादन प्रक्रिया (एनालिटिक्स से जारी करने के लिए) का विस्तार से विश्लेषण करता है। चरणबद्ध कार्य इस तरह दिखता है:

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

इस दृष्टिकोण के लाभ:

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

विपक्ष:

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

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

• पूरी प्रोजेक्ट टीम जा रही है
• प्रतिभागियों में से एक फैसिलिटेटर (स्क्रैम-मास्टर) की भूमिका निभाता है। वह सुनिश्चित करता है कि बातचीत रचनात्मक तरीके से हो।
• टीम उनके काम करने के तरीकों पर चर्चा करती है। सभी पहलुओं पर विचार किया जाता है: प्रक्रिया, कोडिंग, लक्ष्य निर्धारित करना, आदि। फिर पेशेवरों और विपक्षों पर प्रकाश डाला गया।
• एक सामान्य वोट में, वे परिवर्तनों पर सहमत होते हैं: प्लसस को ठीक करने की आवश्यकता होती है, हटाए गए minuses।
• 3-4 सप्ताह के बाद, प्रक्रिया दोहराती है। टीम परिणामों को देखती है, और यदि हर कोई हर चीज से खुश है, तो काम जारी है।

महत्वपूर्ण शर्तें:

1. किसी भी परिवर्तन और नवाचारों के लिए प्रबंधन का समर्थन।
2. टीम सामंजस्य और सुधार पर ध्यान केंद्रित।

यदि कंपनी की संस्कृति पहल, नवाचार को प्रोत्साहित नहीं करती है, तो पूर्वव्यापी प्रक्रिया को फिर से डिज़ाइन करने का सबसे अच्छा तरीका नहीं है। टीम के सदस्य अपने "दलदल" से आगे नहीं जाएंगे।

दृष्टिकोण के लाभ:

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

विपक्ष:

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

ज्यादातर मामलों में, आप ऊपर वर्णित प्रक्रियाओं को अपनाने और सुधार कर प्राप्त कर सकते हैं। यहां तक ​​कि अगर यह शुरू में स्पष्ट है कि केवल नए विशेषज्ञों / टीमों को आकर्षित करके समय पर परियोजना को पूरा करना वास्तव में संभव है, तो हम दृढ़ता से अनुशंसा करते हैं कि आप ऊपर दिए गए चरणों का प्रयास करें।

यदि, बाधाओं को खत्म करने के बाद, परियोजना प्रबंधक का मानना ​​है कि क्षमता वांछित स्तर तक नहीं पहुंची है, तो आप नई टीमों को जोड़ सकते हैं।

नई टीमों के लिए बुनियादी ढांचा तैयार करना

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

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

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

हमने परियोजना के लिए एक अतिरिक्त टीम को कैसे जोड़ा

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

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

विश्लेषण के बाद, हमने उपरोक्त बिंदुओं को खत्म करने के लिए एक योजना बनाई। बेशक, टीम तुरंत बदलावों से सहमत नहीं थी, लेकिन नेतृत्व के समर्थन और स्पष्ट समय सीमा के विकास के साथ, हम टीम के प्रत्येक सदस्य को मनाने में सक्षम थे।

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

परिणामस्वरूप, निम्नलिखित प्रक्रियाओं को \ अनुकूलित लागू किया गया:

1. हमने उत्पाद टीम के सभी सदस्यों - डेवलपर्स, विश्लेषकों और परीक्षण विशेषज्ञों के बीच संचार का निर्माण किया।
2. उन्होंने अधिक पारदर्शी परीक्षण, दोषों को दूर करने, विवादों को हल करने और बाद में कार्य योजना के लिए महत्वपूर्ण और जटिल कार्यों का दस्तावेजीकरण किया।
3. अनुकूलित विकास प्रक्रियाएं। WorkFlow और GitFlow परियोजना द्वारा अपनाया गया। उन्होंने निरंतर एकीकरण को कॉन्फ़िगर करने और स्वचालित मोड में स्वचालित परीक्षण चलाने में मदद की।
4. हमने टेस्ट बेंचों की असेंबली स्पीड दोगुनी कर दी है।
5. उचित परीक्षण की प्रक्रिया को व्यवस्थित किया। प्रत्येक पुनरावृत्ति के अंत में लागू प्रतिगमन परीक्षण।
6. परिचय योजना की प्रक्रिया का परिचय दिया।
7. लोड परीक्षण का संचालन किया।

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

• 3 महीने के बाद कमीशन।
• फिक्स्ड 70% बग्स
• चार गंभीर सुविधाओं को लागू किया गया
• अनुकूलित और कुछ पृष्ठों को लोड करने की गति 8 गुना बढ़ गई
• पूरे उत्पाद की गुणवत्ता के बारे में सटीक जानकारी प्राप्त की
• बिल्ट रोड मैप Iterations

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

निष्कर्ष

परियोजना के विकास की गति को बढ़ाने के दो मुख्य तरीके हैं: बाधाओं को खत्म करना और उत्पादन क्षमता को बढ़ाना। पहले मामले में, आप विकास गति में 30-40% वृद्धि प्राप्त कर सकते हैं, दूसरे में 70-80%। अतिरिक्त कमांड उत्पादकता में दोगुनी वृद्धि नहीं देते हैं, क्योंकि कई टीमों के बीच बातचीत पर अधिक समय खर्च होता है।

विकास टीमों के विस्तार के लिए प्रमुख सफलता कारक हैं:

• प्रारंभिक कार्य
• स्थापित प्रक्रियाओं
• एक नेता या एक परियोजना टीम का सदस्य जो टीमों की गतिविधियों को बढ़ावा देगा और उनकी देखरेख करेगा,
• सिंगल कमांड कंट्रोल सेंटर।

तीन टीमें वर्तमान में उस परियोजना पर काम कर रही हैं, जिसे हमने पहले वर्णित किया था (एक पुरानी और दो नई)। प्रदर्शन किए गए कार्यों की संख्या 1.9 गुना बढ़ गई।