प्रोग्रामर, मैनेजर, एमवीसी और स्वीकृति मानदंड

मैंने गौर किया। किसी भी ग्राहक के साथ काम करना वेब एप्लिकेशन के समान है। लेख दिखाता है कि आप प्रक्रियाओं को बेहतर बनाने के लिए इस ज्ञान का उपयोग कैसे कर सकते हैं।

नियंत्रक कौन है, और कटौती के तहत मॉडल कौन है।

यह लेख मानता है कि पाठक जानता है कि एमवीसी क्या है ।

एक मॉडल का निर्माण करते समय, मैं सरलीकरण को जानबूझकर करने के लिए जाता हूं।

1. रिश्ते में सभी भागीदार जिम्मेदार लोग हैं और एक परिणाम प्राप्त करना चाहते हैं।
2. एक विशिष्ट कस्टम विकास पर विचार करें।

पात्र

ग्राहक - एक व्यक्ति जो एक उत्पाद या परियोजना का आदेश देता है। यह बाहरी और आंतरिक दोनों हो सकते हैं।

कंपनी (ठेकेदार) - ग्राहक के साथ संविदात्मक संबंध के लिए पार्टी।

प्रबंधक - एक व्यक्ति जो ग्राहक और अंतिम निष्पादक (प्रोग्रामर) के साथ बातचीत करता है। यह एक इनपुट के रूप में ग्राहक से कार्यों को स्वीकार करता है, इन कार्यों को ठेकेदार को ट्रांसलेट करता है और ग्राहक को परिणाम देता है।

अंतिम निष्पादक एक प्रोग्रामर है जो कार्य को कार्यान्वित करता है। आदर्श रूप में, केवल प्रबंधक के साथ संवाद करता है।

प्रक्रिया

कस्टम विकास प्रक्रिया कुछ इस तरह दिखती है:

1. ग्राहक कंपनी के लिए कार्य निर्धारित करता है।
2. राउटर के रूप में कार्य करने वाली कंपनी, प्रबंधक के लिए कार्य करती है।
3. प्रबंधक ग्राहक के साथ विवरण को स्पष्ट करता है।
4. प्रबंधक प्रोग्रामर को कार्य सेट करता है।
5. प्रोग्रामर कार्य करता है और पूर्ण किए गए कार्य को स्थानांतरित करता है।
6. प्रबंधक कमियों की पहचान करता है और चरण 4 पर लौटता है।
7. यदि कोई कमी नहीं है, तो प्रबंधक ग्राहक को कार्य स्थानांतरित करता है।
8. ग्राहक कमियों की पहचान करता है और पैराग्राफ 3 पर लौटता है।
9. यदि कोई कमी नहीं है, तो ग्राहक काम के लिए भुगतान करता है।

कंपनी के लिए सबसे प्यारा बिंदु पैराग्राफ 9 है। लेकिन इसके लिए रास्ता आमतौर पर लंबा और कांटेदार होता है।

ऐसी प्रक्रिया की समस्या

पहली नज़र में, इस प्रक्रिया में सब कुछ सही है और सुधार करने के लिए कुछ भी नहीं है। हालाँकि, ऐसा नहीं है। हम समस्याओं को उजागर करते हैं।

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

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

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

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

ऐसी अवांछनीय घटनाओं से बचने के लिए क्या करें?

संगति

आइए ग्राहक के साथ काम करने की सरलीकृत योजना देखें:

एक अनुभवी डेवलपर MVC के साथ एक पूर्ण मैच देखेगा:

संस्थाओं की तुलना करना बहुत सरल है।

• ग्राहक = उपयोगकर्ता
• प्रबंधक = नियंत्रक
• कलाकार = मॉडल
• कार्य परिणाम = देखें
• कंपनी = संपूर्ण आवेदन

महज एक संयोग? मुझे ऐसा नहीं लगता। यदि सहभागिता योजनाएँ मेल खाती हैं, तो आप उन दृष्टिकोणों को लागू करने का प्रयास कर सकते हैं जो हम विकास में कस्टम विकास के प्रबंधन की प्रक्रिया में उपयोग करते हैं।

ठीक करने के लिए पहला कदम

जब हम विकसित हो रहे हैं तो हमारे पास क्या उपकरण हैं?

हम आवेदन परतों को परिभाषित करते हैं। हम परतों के बीच बातचीत अनुबंधों को परिभाषित करते हैं और एप्लिकेशन को मॉड्यूल में तोड़ते हैं। आइए इन साधनों को यहां लागू करने का प्रयास करें।

समूहों

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

ग्राहक को कार्य पारित करने की प्रक्रिया में, प्रोग्रामर जो कार्य करता है, उसमें शामिल नहीं होना चाहिए। कभी नहीं। कभी नहीं।

सड़न

बड़े कार्यों को छोटे में विभाजित करने की आवश्यकता है। एक छोटा कार्य अधिकतम दो दिनों के लिए एक कार्य है।

टी

हर कोई अभिव्यक्ति जानता है: एक स्पष्ट टीके के बिना - एचजेड का परिणाम।

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

किसी भी सामान्य कंपनी में, TK कार्य के लिए एक अनिवार्य तत्व है। सच है, यह केवल बड़े कार्यों पर लागू होता है।

ऐसा लगता है कि TK प्रोग्रामिंग के संदर्भ में एक अनुबंध के समान है। मैं टीके के साथ क्या समस्याएँ देखता हूँ:

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

यहां देखा जा सकता है कि टीके स्पष्ट रूप से पर्याप्त नहीं है। सवाल यह है कि क्या किया जाए?

स्वीकृति मानदंड

विकास अभ्यास में, परीक्षण स्थान पर गर्व करता है। गुणवत्ता विकास के लिए टेस्ट ने उनकी आवश्यकता को साबित किया है।

क्या हम अपने अभ्यास में परीक्षण लागू कर सकते हैं? हां, और इसलिए हम सब कुछ परीक्षण कर रहे हैं और यहां तक ​​कि प्रक्रिया के विवरण में भी, एक चौकस पाठक कहेगा। हां, लेकिन नहीं। मैं अन्य परीक्षण के बारे में थोड़ी बात कर रहा हूं।

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

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

सही ढंग से तैयार स्वीकृति मानदंड के साथ, प्रोग्रामर के पास ToR में कोई विसंगतियां नहीं हो सकती हैं और यहां तक ​​कि वास्तव में उसे क्या करना चाहिए, इस पर भी संदेह है।

एक छोटे से कार्य के लिए, टीके नहीं हो सकता है, लेकिन स्वीकृति मानदंड मौजूद होना चाहिए। स्वीकृति मानदंड कार्यान्वयन से पहले लिखे गए परीक्षणों के समान हैं। क्या यह आपको कुछ याद दिलाता है?

स्वीकृति मानदंड का वर्णन करने के लिए, आप Gherkin भाषा का उपयोग कर सकते हैं जो BDD प्रदान करता है। इसे शुरू करने में आसान बनाने के लिए, आप उन्हें सामान्य रूसी भाषा में वर्णन कर सकते हैं।

आपत्तियों

मैं प्रबंधकों से एक सवाल की उम्मीद करता हूं:

स्वीकृति मानदंडों के विकास में अतिरिक्त समय लगता है। कहां से लाएं?

स्वीकृति मानदंड विकसित करने का समय निकाले बिना, आप इन लागतों को सभी चरणों में फैला रहे हैं। और बहुत से लोग समय बिताते हैं: प्रबंधक, प्रोग्रामर, परीक्षक, ग्राहक।

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

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

मैं आपको यह आश्वस्त करने का साहस करता हूं कि स्वीकृति मानदंड का विकास हाथों से भुगतान करता है।

परिणाम

टीके के साथ स्वीकृति मानदंडों की शुरूआत के बाद प्रक्रिया कैसे बदलती है?

प्रोग्रामर अपना काम स्वीकृति मानदंडों के अनुसार करता है। प्रबंधक काम लेता है। फिर ग्राहक वही करता है। और उसके पास इस कार्य के लिए भुगतान न करने का कोई कारण नहीं है।

क्या यह हमेशा बिना किसी गड़बड़ के काम करेगा? मुझे लगता है कि नहीं। सबसे पहले, ग्राहक के साथ विकास, स्वीकृति मानदंडों के निर्माण और उनके समझौते में समस्याएं होंगी। और यह प्रोग्रामर और ग्राहक के साथ दोहराया पुनरावृत्तियों का कारण होगा। लेकिन उनकी संख्या कम से कम है।

आप इस बारे में क्या सोचते हैं?