एक छोटी सी टीम में सफल कानबन।

उन पदों की समीक्षा करने के बाद, जिनमें हेबर-उपयोगकर्ता उत्पादन में लचीली कार्यप्रणाली के कार्यान्वयन और कार्यान्वयन की प्रक्रियाओं का वर्णन करते हैं, मैंने अपने स्वयं के विकास के अनुभव को कंबन पद्धति पर एक छोटी उत्पाद टीम में साझा करने का निर्णय लिया।

जब तक हमारे पास एक नई प्रक्रिया संगठन प्रणाली का प्रयास करने की इच्छा थी, तब तक हम एक अच्छी तरह से स्थापित टीम थे, जो सफल स्क्रम विकास का नेतृत्व कर रही थी।

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

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

विश्लेषण का परिणाम हमारी भविष्य की प्रक्रिया का एक मानचित्र था। प्रक्रिया के प्रत्येक चरण में कानबन बोर्ड पर अपना एक स्तंभ होता है, और प्रत्येक चरण (पुल को छोड़कर) में दो स्तंभ होते हैं: प्रगति और पूर्ण।



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

पुल

पुल एक बफर है जिसमें उत्पाद स्वामी (पीओ) बैकलॉग से नए कार्यों को जोड़ता है। बफर में कार्यों की संख्या की सीमा होती है। बोर्ड में, कार्यों को प्राथमिकता के क्रम में रखा गया है। पीओ किसी भी समय कार्य की प्राथमिकता को बदल सकता है या कार्य को दूसरे के साथ पूरी तरह से बदल सकता है।

के विश्लेषण

जब पूरी तरह से मुक्त डेवलपर विकास प्रक्रिया में दिखाई देता है, तो वह पुल से सर्वोच्च प्राथमिकता वाला कार्य लेता है और कार्य को विश्लेषण की स्थिति में स्थानांतरित करता है।

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

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

डिज़ाइन

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

डिज़ाइन

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

समीक्षा

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

परीक्षण

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

तैनाती

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

सत्यापन

सफलतापूर्वक तैनात सुविधा सत्यापन के अधीन है - एकीकरण और प्रतिगमन परीक्षण किया जाता है।

प्रतिबंध

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

रिफंड

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

परिणाम

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

उपयोगिता

प्रक्रियाओं
कंबन (विकास)
कानबन ने सॉफ्टवेयर डेवलपमेंट के लिए आवेदन किया: एजाइल से लीन तक
लीन सॉफ्टवेयर इंजीनियरिंग
उपकरण
कानबन बोर्डों की समीक्षा