हमारी विकास प्रक्रिया: विकास के 50 महीने

हमारी कंपनी पहले से ही 6 साल पुरानी है। यह चुस्त के सिद्धांतों पर आधारित था और उन पर बढ़ता गया। हमने पहले दिन से एक्सट्रीम प्रोग्रामिंग का उपयोग किया, बाद में थोड़ा सा स्क्रैम जोड़ा, और अंततः कानबन में स्विच किया। मैं अमूल्य अनुभव साझा करना चाहता हूं और पिछले 4 वर्षों में हमारी विकास प्रक्रिया में हुए बदलावों के बारे में बात करना चाहता हूं।

प्रसंग

संदर्भ बहुत महत्वपूर्ण है क्योंकि यह आपको यह समझने में मदद करता है कि आपके लिए क्या काम कर सकता है और क्या नहीं। हम TargetProcess बना रहे हैं, एक काफी बड़ा वेब अनुप्रयोग। हमारी टीम एक ही कार्यालय भवन में एक ही मंजिल पर है - कोई वितरण बिल्कुल नहीं है और करीब है।

2008	2009	2011	2012
कंपनी का आकार (लोगों में)
15	22	30	40
टीम संरचना
एक पार कार्यात्मक टीम	दो टीमें: कर्नेल (5 डेवलपर्स, स्क्रैम मास्टर, 3 परीक्षक) एकीकरण (3 डेवलपर्स, टीम लीड, परीक्षक)	कुछ मिनी टीमें। हम प्रत्येक बड़ी सुविधा के लिए मिनी टीम बनाते हैं। मिनी-टीम इस सुविधा के कार्यान्वयन के लिए पूरी तरह से जिम्मेदार है।	कई (लेकिन पहले से ही अधिक) मिनी-टीमें
प्रौद्योगिकी के
सी #, ASP.NET, ASP.NET Ajax, NHibernate	C #, ASP.NET, ExtJS , NHibernate	सी #, jQuery , NHibernate, NServiceBus	C #, NHibernate, NServiceBus, 100% जावास्क्रिप्ट फ्रंट-एंड, REST , पायथन

टिप्पणियों

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



प्रौद्योगिकी । सर्वर साइड काफी स्थिर है। यह सभी एक ही .NET स्टैक है। हालांकि इस समय के दौरान हम .NET 2.0 से .NET 4. पर चले गए। हमने पिछले साल प्लगइन्स के लिए एक ESB जोड़ा, जिसने सिस्टम की एक्स्टेंसिबिलिटी और स्केलेबिलिटी में सुधार किया। हम कम और कम खुश हैं कि NHibernate कैसे काम करता है, और हम CQRS की ओर बढ़ रहे हैं। फ्रंट-एंड को स्थिर नहीं कहा जा सकता है। वर्तमान यूआई ASP.NET Ajax, ExtJS और हमारे अपने ढांचे से एक बल्कि दुखी कॉकटेल है। चल रहे प्रयासों का उद्देश्य इस सभी खुशी को एकजुट करना है, ताकि निकट भविष्य में पुराने यूआई को पूरी तरह से एक नया द्वारा बदल दिया जाएगा। क्या अच्छा है, सिस्टम को पुराने और नए इंटरफ़ेस दोनों में उपयोग किया जा सकता है, और इससे मौजूदा उपयोगकर्ताओं के प्रवास को सरल बनाया जाना चाहिए। यहां बताया गया है कि पिछले कुछ वर्षों में प्रौद्योगिकी पर हमारा ध्यान कैसे बदला गया है:

प्रक्रिया है

2008	2009	2011	2012
पुनरावृत्तियों
1 सप्ताह	लेकिन कोई पुनरावृत्तियों नहीं हैं, हम कानबन में चले गए
प्रगति नियंत्रण उपकरण
टास्क बोर्ड , Iteration बर्न डाउन, रिलीज़ बर्न डाउन	कानबन बोर्ड , साइकिल समय	कंबन बोर्ड, साइकिल समय, बोर्ड बनाता है	कनबन बोर्ड, टीम बोर्ड, साइकिल का समय, रसोई में बोर्ड, रोडमैप बनाता है
2008	2009	2011	2012
पुनरावलोकन
हर 2 सप्ताह		हम आवश्यकता होने पर बैठकें करते हैं, कोई अवधि नहीं होती है। वे 3 समस्याओं की सीमा के साथ एक मुद्दा बोर्ड के साथ आए थे। जैसे ही 3 समस्याएं जमा होती हैं, हम एक बैठक करते हैं और उन्हें हल करते हैं। समस्याएँ कोई भी लिख सकता है।	हमारे पास केवल उन लोगों के साथ रुकने वाली बैठकें हैं जो चिंतित हैं। ऐसा अक्सर नहीं होता।
नौकरी का मूल्यांकन
नियोजन पोकर । अंकों में उपयोगकर्ता कहानी का मूल्यांकन करें	लेकिन काम का मूल्यांकन न करें
समय बिताने का हिसाब
सभी कार्यों और बगों के लिए स्पष्ट लेखांकन।		हम रिकॉर्ड नहीं रखते। इससे थक गए।
2008	2009	2011	2012
चर्चा आवश्यकताओं
Iteration योजना की बैठक	उपयोगकर्ता कहानी के लिए "बैठक शुरू करना"। प्रत्येक उपयोगकर्ता कहानी शुरू होने से पहले चर्चा की जाती है। बैठक में एक उत्पाद स्वामी + परीक्षक + डेवलपर्स + डिजाइनर है।
WIP की सीमा
पुनरावृत्तियों	3 उपयोगकर्ता कहानी पर सीमा। काम की प्रगति में अधिक नहीं होना चाहिए।	सीमा के लिए स्कोर किया	प्रति डेवलपर 2 उपयोगकर्ता कहानियां (1 अनुशंसित)। सामान्य तौर पर, मिनी-टीम अपने लिए निर्णय लेती है।
योजना जारी करें
औपचारिक बैठक। आमतौर पर रिलीज 2 महीने तक रहता है	कोई प्लानिंग नहीं है		हम अगले कुछ महीनों के लिए एक उच्च-स्तरीय रोडमैप बना रहे हैं। हर 3 महीने में इसकी समीक्षा की जाती है।
2008	2009	2011	2012
क्रिशिंग यूजर स्टोरीज
उपयोगकर्ता कहानी को साप्ताहिक पुनरावृत्ति में तोड़ना चाहिए	हम विभाजित करने की कोशिश करते हैं, लेकिन किसी तरह यह बहुत अच्छी तरह से काम नहीं करता है	अभी भी बहुत नहीं है ...	थोड़ा बेहतर है, लेकिन अभी भी हमारे लिए अभ्यास करना मुश्किल है
यूजर स्टोरी के लिए Done ( DoD ) की परिभाषा
विनिर्देशन वर्तमान है पारित परीक्षण मामलों का एक सेट इकाई परीक्षण	किकऑफ बैठक विनिर्देशन वर्तमान है पारित परीक्षण मामलों का एक सेट उपयोगकर्ता प्रलेखन डेमो टीम	किकऑफ बैठक विनिर्देशन वर्तमान है पारित परीक्षण मामलों का एक सेट स्वचालित मामलों का सेट उपयोगकर्ता प्रलेखन डेमो टीम	किकऑफ बैठक विनिर्देशन वर्तमान है पारित परीक्षण मामलों का एक सेट स्वचालित मामलों का सेट उपयोगकर्ता प्रलेखन डेमो टीम ग्रीन बिल्ड मानव ग्रंथ प्रदर्शन परीक्षण
2008	2009	2011	2012
बैठक
रिलीज की योजना (टीम) Iteration Planning (कमांड) Iteration डेमो (कमांड) पूर्वव्यापी (टीम) दैनिक (टीम)	उपयोगकर्ता कहानी लॉन्च करें (3-4 लोग) उपयोगकर्ता कहानी डेमो (4+ लोग) पूर्वव्यापी (टीम) दैनिक	उपयोगकर्ता कहानी लॉन्च करें उपयोगकर्ता कहानी डेमो स्टॉप-द-लाइन (टीम) दैनिक	उपयोगकर्ता कहानी लॉन्च करें उपयोगकर्ता कहानी डेमो (परीक्षण से पहले!) स्टॉप-द-लाइन (सही लोग) दैनिक
रोज की बैठक
सुबह 10 बजे भोजन करने में लगभग 10 मिनट लगते हैं	भोजन करते हुए, सुबह 11 बजे, लगभग 15 मिनट लगते हैं
UX
क्या?	wireframes	रेखाचित्र (कई विचार और उपवास), लाइव प्रोटोटाइप, जीवित लोगों पर प्रयोज्य परीक्षण , डिजाइन स्टूडियो	रेखाचित्र, लाइव प्रोटोटाइप, एक कार्य प्रणाली पर प्रयोज्य परीक्षण
शिल्प कौशल
क्या?	कार्यशालाओं	वेतन प्रशिक्षण पर निर्भर करता है मिनी सम्मेलन एक शांत सम्मेलन में भाग लेने के लिए भुगतान किया कार्यशालाओं शुक्रवार का शो प्रति सप्ताह 5 घंटे की स्व-शिक्षा	वेतन प्रशिक्षण पर निर्भर करता है मिनी सम्मेलन एक शांत सम्मेलन में भाग लेने के लिए भुगतान किया स्व-शिक्षा के लिए या प्रति सप्ताह एक व्यक्तिगत परियोजना के लिए 5 घंटे

देख

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

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

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

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

क्रिशिंग यूजर स्टोरीज । मजेदार है, लेकिन हम अभी भी यह नहीं जानते हैं कि यह कैसे करना है। कुचलने का काम मुश्किल है। हां, हमारे पास कुछ सुधार हैं, लेकिन समय-समय पर बड़ी उपयोगकर्ता कहानियां बिना किसी विखंडन के विकास में रिसाव करती हैं। कुचलने में किसी प्रकार की आंतरिक जटिलता प्रतीत होती है।

हो गया परिभाषा । प्रवृत्ति स्पष्ट है - साल-दर-साल DoD अधिक संतृप्त हो जाता है और इसमें अधिक से अधिक चीजें शामिल होती हैं। प्रक्रिया विकसित हो रही है और मैं यह सुनिश्चित करना चाहता हूं कि हर सुविधा पूरी तरह से रिलीज के लिए तैयार हो। हमने हाल ही में DoD में पाठ सत्यापन और प्रदर्शन परीक्षण जोड़े हैं।

दैनिक बैठकें। हमारी समीक्षा के पुराने टाइमर लगभग अपरिवर्तित 4 साल बच गए। लोगों की संख्या में वृद्धि के साथ, हमने बैठक को छोटा और ठोस रखने के लिए हर संभव कोशिश की। सामान्य तौर पर, यह संभव था - 15 लोगों के लिए, बैठक लगभग 15 मिनट तक चलती है।

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

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

शिल्प कौशल। व्यावसायिक कौशल का प्रशिक्षण और विकास करना 4 साल पहले कंपनी की संस्कृति का हिस्सा नहीं था। यह सब 2010 में शुरू हुआ, जब पूरी विकास रणनीति पूरी तरह से संशोधित और बदल गई थी। अब हमारे पास ज्ञान की कुल भावना है । गंभीरता से।

यहाँ बताया गया है कि पिछले कुछ वर्षों में कंपनी के विकास का ध्यान किस तरह बदला गया है:

तकनीकी अभ्यास

2008	2009	2011	2012
स्रोत नियंत्रण और ब्रंच
तोड़फोड़। एक ब्रंच।	गित । प्रत्येक सुविधा या बग फिक्स एक अलग ब्रंच में किया जाता है। विज़ार्ड हमेशा रिलीज़ के लिए तैयार है।		Git। निरंतर डिलीवरी के लिए एक ब्रंच पर लौटे
जोड़ी प्रोग्रामिंग
जोड़ी प्रोग्रामिंग सख्ती से आवश्यक है। डेवलपर्स समस्या को देखने के लिए हर दिन जोड़े बदलते हैं, एक ताजा नज़र के साथ, अनुभवों का आदान-प्रदान करते हैं और वास्तविक सामूहिक कोड स्वामित्व प्राप्त करते हैं	सभी उपयोगकर्ता कहानियों और जटिल बगों के लिए अनिवार्य। कभी-कभी लोग सरल कार्यों पर अकेले काम करते हैं। जोड़ी परिवर्तन रद्द। यह पता चला कि यह फ़ोकस और एनाउंस के साथ हस्तक्षेप करता है	केवल जटिल कार्यों के लिए उपयोग किया जाता है।	पूरी तरह से वैकल्पिक। मिनी-टीम खुद तय करती है कि कैसे काम करना है।
टीडीडी / बीडीडी
टीडीडी की अत्यधिक अनुशंसा की जाती है। प्रत्येक उपयोगकर्ता कहानी के लिए यूनिट परीक्षण कड़ाई से आवश्यक हैं।	सभी नए कोड परीक्षणों में शामिल हैं। जावास्क्रिप्ट की तरफ, हालात बदतर हैं। इसके अलावा BDD का उपयोग करने की कोशिश कर रहा है	जावास्क्रिप्ट की तरफ, सब कुछ ठीक है, हम क्वनेट का उपयोग करते हैं । BDD का विस्तार और विकास हो रहा है	बीडीडी पर स्पष्ट ध्यान दें। हमने अपनी जरूरतों के लिए NBehave को थोड़ा बदल दिया और त्वरित परीक्षण स्क्रिप्टिंग के लिए VS ऐड-इन बनाया
स्वचालित कार्यात्मक परीक्षण
सेलेनियम के लिए कई परीक्षण	सेलेनियम पर कई परीक्षण। हमने परीक्षण लिखने और समर्थन करने के लिए अपना सी # ढांचा बनाया।	कार्यात्मक परीक्षण 20 वर्चुअल सर्वर पर समानांतर में चलते हैं	सेलेनियम वेबड्राइवर की ओर पलायन। लगभग 40 वर्चुअल सर्वर हैं
निरंतर एकीकरण
बहुत सरल है। स्रोत कोड संकलित किया गया है, क्रूज़ कंट्रोल में इकाई परीक्षण लॉन्च किए गए हैं।	हम कई अलग-अलग सेटअपों के साथ क्रूज़ कंट्रोल का उपयोग करते हैं।	जेनकींस पर स्विच किया गया	फिर भी जेनकिंस का उपयोग कर रहे हैं। नया लक्ष्य समय के साथ कंटीन्यूअस डिलीवरी पर स्विच करना है।
टॉगल करने की सुविधा
नेटो			हम फ़ीचर टॉगलिंग का उपयोग करते हैं और निरंतर वितरण की ओर बढ़ते हैं।
टेस्ट कवरेज
ईश्वर जानता है		यूनिट परीक्षणों के साथ 50% कवरेज और कार्यात्मक परीक्षणों के साथ 30% कवरेज	यूनिट परीक्षणों द्वारा 70% कवरेज और कार्यात्मक द्वारा 40% कवरेज

टिप्पणियों

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

जोड़ी प्रोग्रामिंग। यह अभ्यास आवश्यक रूप से पूरी तरह से वैकल्पिक हो गया है। अनिवार्य जोड़ी प्रोग्रामिंग एक बहुत कठिन बात है। आपको पूरे दिन एक जोड़े के रूप में काम करने, संवाद करने, बहस करने, अपनी बात का बचाव करने के लिए मजबूर किया जाता है। इससे ऊर्जा निकलती है। हां, आपको लगता है कि आपने बहुत कुछ किया है, लेकिन कम से कम कई महीनों तक लगातार काम करना आसान नहीं है। अब हम मुख्य रूप से बहुत मुश्किल कामों के लिए जोड़ी प्रोग्रामिंग का उपयोग करते हैं।

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

और इस समय कुछ आँकड़े:

• 5200 यूनिट परीक्षण
• 2500 कार्यात्मक परीक्षण (1700 सेलेनियम और 800 जावास्क्रिप्ट परीक्षण)
• सभी परीक्षण 38 आभासी मशीनों पर चलते हैं
• शॉर्ट असेंबली (इंस्टॉलेशन पैकेज के बिना) में 40 मिनट लगते हैं
• पूर्ण विधानसभा में 1 घंटा लगता है
• 2011 में जीआईटी रिपॉजिटरी में 8400 काम करता है

निष्कर्ष में

यही कारण है कि हम पिछले 4 वर्षों में आए हैं



पुनश्च अगर किसी को पता है कि हैबर को सामान्य रूप से तालिकाओं को कैसे मजबूर करना है - मुझे बताएं।