एक विधायक के रूप में कार्यप्रणाली: विधानसभा निर्देश

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



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

कार्य

कुछ साल पहले, मैं एक बार फिर स्क्रैच से भुगतान प्रणाली बनाने के लिए एक परियोजना में आया था। परियोजना की शुरुआत में कुछ भी नहीं था: कोई डेवलपर्स नहीं, कोई प्रक्रिया नहीं, कोई निर्माण नहीं। अगर कुछ भी नहीं है तो काम कहाँ से शुरू करें? तुरंत कुछ का परिचय अजीब और यहां तक ​​कि बेवकूफ भी है। इसलिए, पहला कदम यह समझना है कि तकनीक से वास्तव में क्या आवश्यक है।

केंट बेक, SCRUM पर अपनी पुस्तक के अंत में लिखा है:

सभी तरीके डर पर आधारित हैं। आप अपनी आदतों को विकसित करने की कोशिश कर रहे हैं जो आपके डर को वास्तविकता बनने से रोकने में आपकी मदद करेगा।

इसलिए, पहली बात यह है कि व्यवसाय से यह पता लगाना है कि यह किससे डरता है ।

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

अलग-अलग आशंकाएं अलग-अलग कार्यप्रणाली को जन्म देती हैं। अधिक भुगतान के डर से सस्ते डेवलपर्स को काम पर रखने की ओर जाता है जो बदलने में आसान हैं - यह SCRUM है। औपचारिक दस्तावेजों के एक समूह के साथ त्रुटि का डर GOSTs या RUP को जाता है।

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

आशंकाओं के अलावा, व्यवसाय के पास प्रक्रियाओं को अनुकूलित करने के लिए क्या उद्देश्य हैं:

• तेजी से;
• सस्ते;
• उम्मीद के मुताबिक,
• एक नियंत्रित तरीके से;
• गुणवत्ता;
• स्केलेबल;
• haypovo।

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

आमतौर पर एक व्यवसाय एक ही बार में सब कुछ चाहता है । आवश्यकताओं को एकत्रित करते समय, "रोगी हमेशा झूठ बोलता है" के पालन का पालन करें। जब कोई व्यवसाय सब कुछ चाहता है, तो वह झूठ बोलता है। समझने की कोशिश करें कि व्यवसाय वास्तव में क्या चाहता है और उसे उसे बेचने की कोशिश करें। यह टीम लीडर के लिए कौशल का सबसे मानक सेट नहीं है। लेकिन अगर आप नहीं जानते कि किसी व्यवसाय की वास्तविक आवश्यकताओं का पता कैसे लगाया जाए, तो आपको एक ऐसे व्यक्ति को खोजने की जरूरत है जो कर सकता है।

व्यवसाय की इच्छाओं के अतिरिक्त, आपको महत्वपूर्ण सीमाओं का पता लगाने की आवश्यकता है।

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

यह आवश्यक सीमाएँ हैं जो भेद करती हैं, उदाहरण के लिए, समय और सामग्री प्रक्रियाओं से FixPrice प्रक्रियाएं।

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

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

हम एक परियोजना शुरू करने के लिए एक पद्धति का निर्माण कर रहे हैं

लेकिन एक तकनीक क्या है? हम सामान्य रूप से क्या बनाना चाहते हैं? सवालों के जवाब में बिंदुओं के एक समूह के साथ एलिस्टेयर काउबर की एक सुंदर तस्वीर है।



पहली जगह में इस तस्वीर से तीन चीजें हमारे लिए महत्वपूर्ण हैं: लोग - जो करते हैं; प्रक्रियाएं - वे कैसे करते हैं; और कलाकृतियों - क्या किया जाना चाहिए। हमारे पास अभी तक लोग और प्रक्रियाएँ नहीं हैं, इसलिए हमें यह पता लगाना होगा कि हमें किन कलाकृतियों की ज़रूरत है।

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

कलाकृतियों का चयन

हम डर लेते हैं और समझते हैं कि कौन सी कलाकृतियां घबराती हैं।

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

हम प्रक्रियाएँ बनाते हैं

हम विकास की शुरुआत में हैं, इसलिए जटिल औपचारिक प्रक्रियाओं को बनाने का कोई समय और कारण नहीं है। इसलिए हम सभी प्रक्रियाओं को सरल बनाते हैं और संचार की सुविधा पर ध्यान केंद्रित करते हैं ।

नतीजतन, वास्तव में दो प्रक्रियाएं हैं: एक बड़े कार्य का पता लगाने के लिए - एक समाधान के बारे में सोचने के लिए, और जो पूरा हो गया है उसकी जांच करें । ये प्रक्रियाएं लंबी, अनुसंधान और एक दूसरे के साथ थोड़ा जुड़ी हुई हैं, जो उचित विकास प्रथाओं की ओर ले जाती हैं।

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

---

रिट्रीट: काम पर रखने के बारे में

काम पर रखने के दौरान, वे आमतौर पर मानक नौकरी विवरण और उम्मीदवार स्तरों के सामान्य उन्नयन को देखते हैं, टीम में भूमिकाओं का लगभग समान नक्शा बनाते हैं:



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

संकटमोचन । यह एक ऐसा व्यक्ति है जो 2 दिनों के लिए दस्तावेज और परीक्षणों के बिना किसी प्रकार के बग के साथ विरासत कोड में गोता लगा सकता है, और वाक्यांश के साथ उभर सकता है: "इस पंक्ति में, + के साथ बदलें - और यह काम करेगा।"

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

इंटीग्रेटर। यह एक ऐसा व्यक्ति है जो कई अलग-अलग घटकों, पुस्तकालयों, मॉड्यूल से कुछ अभिन्न बनाना जानता है। वह अब XML प्रोग्रामर नहीं है, लेकिन जो आंतरिक संरचना को समझता है। यह एक अत्यंत दुर्लभ कौशल है, जो आमतौर पर वास्तविक विकास में मांग में बहुत अधिक है।

गुरु: फ्रेमवर्क, सुरक्षा, डेटाबेस, DevOps । गुरु के बारे में सब कुछ स्पष्ट है - ये वे लोग हैं जिनसे प्रासंगिक विषयों पर प्रश्न पूछे जा सकते हैं।

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

यदि आपके विशिष्ट प्रोजेक्ट के लिए भूमिका मानचित्र में कुछ भूमिका नहीं भरी गई है, तो टीम को इसे पूरा करना होगा।

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

उम्मीदवार का स्तर जितना अधिक होगा, साक्षात्कार उतना ही कम होगा।

आपको किन अन्य लोगों की आवश्यकता है?

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

आलोचक - मुझे सबसे पहले मेरे आलोचक की जरूरत है। यह वह व्यक्ति है जो मेरे फैसलों की आलोचना करेगा। आलोचना के बिना, मुझे डर है कि मैं कुछ बकवास कर रहा हूं। जब वे मेरी आलोचना करते हैं, तो मुझे तर्कों के बारे में गंभीरता से सोचना होगा, और यह पता चलेगा कि यह पूरी तरह से बकवास नहीं है।

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

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

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

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

सामाजिक भूमिकाएं भी भरी हुई थीं (और कुछ आलोचक भी थे)।

---

अभ्यास

इसलिए, हमने आवश्यक कलाकृतियों का पता लगाया, यह पता लगाया कि लोगों को क्या चाहिए और क्या प्रक्रिया की आवश्यकता है। क्या हुआ, हम वास्तव में विकास को कैसे व्यवस्थित करते हैं:

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

जब लोग समान के बारे में बात करते हैं, तो बहुत औपचारिक तरीके से नहीं, वे अक्सर कहते हैं: " हमारे पास एक चुस्त है।"

हमें क्लासिक भी मिला "हमारे पास एजाइल है।" लेकिन मुझे स्पष्ट रूप से समझ में आया कि इस तरह की तकनीक और यह "फुर्तीली" क्यों थी, और कुछ अधिक विशिष्ट और जटिल नहीं थी। और मैं (और व्यवसाय), यह तकनीक काफी उपयुक्त थी।

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

---

पाचन: काउबर्न मैट्रिक्स

1980 में, एलिस्टेयर काउबर्न ने परियोजना की जटिलता का एक मैट्रिक्स आकर्षित किया।


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

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

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

हमारे पास एक भुगतान प्रणाली है, जिसका अर्थ है कि एक चुटकी में हम कुछ उपयोगकर्ता पैसे खो देंगे। यह, ज़ाहिर है, अप्रिय है, लेकिन जटिलता में तेज वृद्धि नहीं करता है।

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


हमारे पास लगभग 20 लोगों की एक टीम है, इसलिए हम E30 वर्ग में आते हैं। यह बुरा है, क्योंकि इस वर्ग में तकनीक का एक अच्छा उदाहरण पूर्ण विकसित तर्कसंगत एकीकृत प्रक्रिया होगी - औपचारिक प्रक्रियाएं, कई दस्तावेज, स्पष्ट कथन। 20-30 लोग इसका सामना नहीं कर सकते। आपको 50 किराए पर लेना होगा, और कठिनाई स्नोबॉल की तरह बढ़ेगी। ऐसी कार्यप्रणाली में समान प्रणाली आमतौर पर सैकड़ों या अधिक लोगों द्वारा लिखी जाती हैं।

क्या करें? मुसीबत? नहीं, पूरी परियोजना समान रूप से महत्वपूर्ण नहीं है । हमारे पास केवल कुछ महत्वपूर्ण टुकड़े हैं।

• मनी लॉन्ड्रिंग चेक - जिसके लिए सेंट्रल बैंक ने सिर पर कड़ी चोट की।
• बैंक कार्ड के साथ काम करना - जिसके लिए विश्व भुगतान प्रणाली ने सिर पर कड़ी मेहनत की।
• व्यक्तिगत डेटा का भंडारण - इसके लिए, राज्य ने सिर पर कड़ी मेहनत की।

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

लेकिन ऐसे हिस्से कम हैं। इसलिए, इस परियोजना के लिए काउबर्न मैट्रिक्स निम्नानुसार है।


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

एक बड़ी जटिल परियोजना अपने विभिन्न घटकों के लिए प्रथाओं के विभिन्न सेटों का उपयोग कर सकती है।

यह माइक्रोसर्विस आर्किटेक्चर के बड़े फायदों में से एक है - एक तस्वीर को प्रिस्क्राइब करने की क्षमता जिसमें विभिन्न सेवाएँ अलग-अलग तकनीकों के लिए नहीं, बल्कि एक ही तकनीक के भीतर अलग-अलग प्रथाओं का जवाब देती हैं। उसी समय, महत्वपूर्ण चीजें सामान्य रहती हैं: योजना, कलाकृतियां, बातचीत के लिए एक सामान्य दृष्टिकोण।

---

संक्षेप में देना

हमें कार्यप्रणाली के लिए आवश्यकताओं का पता चला: लक्ष्य और सीमाएं। मूल तत्वों की पहचान की : प्रक्रियाएं, कलाकृतियां और लोग। उन्होंने प्रथाओं का वर्णन किया : प्रक्रियाओं को कैसे लागू किया जाए, कलाकृतियों के लिए आवश्यकताएं, किस तरह के लोगों की आवश्यकता है।

यह एक क्लासिक इंजीनियरिंग डिजाइन योजना है: हमारे पास आवश्यकताएं हैं, फिर हमने वास्तुकला को निर्दिष्ट किया, और फिर इसे क्रमादेशित किया।

डिजाइनिंग के तरीके एक इंजीनियरिंग अभ्यास है, एक इंजीनियरिंग प्रक्रिया है जो एक मॉड्यूल प्रोग्रामिंग से अलग नहीं है।

स्टेज वन प्रैक्टिस

सिद्धांत से वास्तविकता तक विचलित करने के लिए थोड़ा अभ्यास।

"क्यों?" का अधिकार

यह मेरा पसंदीदा अभ्यास है।

प्रत्येक कर्मचारी को किसी भी कार्य के बारे में पूछने का अधिकार है: यह क्यों करते हैं, यह इस तरह से क्यों करते हैं, और इसकी आवश्यकता किसे है?

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

तीन को सामान्य न करें

, . , , .


— , , . — — , . , , .

IDE Driven Development

JetBrains — ! , IDE.

, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .

, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .

. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .

, — , . : , ,

, : . . .

• . , , .
• . , , , , - .
• . 3 -, , , , . , .
• . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .

.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .

— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?

Planning poker . « » — . , , . Planning poker , .

. :

• ;
• product owner ;
• ;
• .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?

, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

• ;
• ;
• .

.

: , , .

Jira , « » ? - -? ?


, , . , junior product manager — , , , .

, — . . , . — !


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

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

कार्यप्रणाली को कैसे बदलना है और परियोजना को नहीं मारना है

इसलिए, 9 महीनों में हमने 3 विधियाँ बदलीं: "हमारे पास फुर्तीली", एक दिन की SCRUM और कानबन। कैसे सुनिश्चित करें कि आप संसाधनों को नहीं खोते हैं? एक ही समय में कार्यप्रणाली को कैसे बदलना है, और परियोजना को नहीं मारना है?

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

मुख्य बात यह है कि कब बदलना है।

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

यदि आपने सोचा कि "कैसे।" यदि आप समझते हैं कि आप बिंदु A से बिंदु B तक कैसे आएंगे, तो बदल दें। जब तक आप साथ आते हैं - कोई ज़रूरत नहीं है।

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

ट्रेनिंग

हम पहले से शुरू करते हैं। एक छोटी टीम के लिए, शिफ्ट से एक महीने पहले तैयारी शुरू हो जाती है।

हम उपयोगकर्ता कहानियां आकर्षित करते हैं। एप्लिकेशन डिज़ाइन में समान दृष्टिकोण। आवश्यकताओं का वर्णन करते समय आप उपयोगकर्ता कहानियों का उपयोग करते हैं, मुझे आशा है?

उदाहरण के लिए:

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

इस तरह, अपनी सभी मुख्य गतिविधियों से गुजरें जो आपकी कार्यप्रणाली के भीतर उत्पन्न होती हैं और उपयोगकर्ता कहानियां लिखती हैं।

प्रबंधक योजना की प्रभावशीलता को कैसे देख सकता है? एक शीर्ष प्रबंधक कैसे समझता है कि सब कुछ ठीक है? उपयोगकर्ता कहानियां लिखें, फिर विवरण जोड़ें: उपयोगकर्ताओं के लिए और शीर्ष प्रबंधकों के लिए एक डैशबोर्ड बनाएं - स्वीकृति मानदंड पास, सब कुछ ठीक है।

जब आपके पास पहले से ही उपयोगकर्ता कहानियां हैं, तो आप उन्हें प्रथाओं में बदलना शुरू कर सकते हैं।

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

कलाकृतियों और संचार को कम करें । यदि उनमें से बहुत सारे हैं - प्रत्येक उपयोगकर्ता स्टोरी अपनी कलाकृतियों और संचार का सुझाव देती है - इसके साथ कुछ करने की आवश्यकता है।

अड़चनें देखो । जब इस तरह की कहानी का नक्शा होता है, तो आप इसके साथ कुछ करना शुरू कर सकते हैं।

उपकरण चुनना

उपकरण सुविधाओं की पहचान करता है । एक लोकप्रिय राय है कि उपकरण महत्वपूर्ण नहीं हैं, या कोई भी उपकरण उपयुक्त है - यह बकवास है।

यदि उपकरण उपयोग करने के लिए असुविधाजनक है, तो उनका उपयोग नहीं किया जाएगा।

इसके अलावा, विक्रेता हमेशा झूठ बोलते हैं। यदि वे कहते हैं कि उनका उपकरण "1, 2 और 3" कर सकता है, तो सबसे अधिक संभावना है कि वे "1", "2" कभी-कभी और "3" ऐसा नहीं कर सकते, लेकिन यह बहुत बुरा है। सब कुछ जांचना सुनिश्चित करें।

हम सक्रिय रूप से चर्चा कर रहे हैं

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

इस स्तर पर, लोग अन्य तकनीकों की शुरूआत से नकारात्मक पिछले अनुभव दिखा सकते हैं।

- आह, बकवास! हमारे पास पहले से ही यह था और इसमें से कुछ भी नहीं आया।

इससे बचने के लिए, लोगों के दर्द को इकट्ठा करें, पूछें कि क्या गलत है। सटीक रूप से रिकॉर्ड करें और प्रदर्शित करें कि आपने क्या रिकॉर्ड किया है - इसलिए व्यक्ति समझ जाएगा कि उन्होंने उसे सुना है।

नकारात्मक अनुभवों को न दोहराएं । रेट्रोस्पेक्टिव नहीं गया? अब यह एक "शुक्रवार का केक" है। सुबह 7 बजे स्टैंडअप नहीं गया? अब यह "चार्जिंग" है। एक ही प्रथाओं को अलग-अलग नाम देना ताकि लोग अपने पिछले नकारात्मक अनुभवों को उनके साथ न जोड़ें।

दुर्भाग्य से, कोई सार्वभौमिक समाधान नहीं हैं। अपनी स्थिति पर निर्माण करें।

की शुरूआत

आईटी प्रबंधन में मुख्य मूल्य सम्मान है।

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

हम संक्रमण के साथ मदद करते हैं । यदि हम एक नई प्रथा शुरू करते हैं, तो हम एक व्यक्ति के बगल में बैठते हैं और उसे नई प्रणाली को समझने में मदद करते हैं। हम पहले से निर्देश तैयार करते हैं।

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

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

KISS। इसे सरल बनाएं, कम से कम शुरुआत में। ओवरकम्प्लीट न करें।

समर्थन

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

निष्कर्ष

परियोजनाएं अलग हैं, लोग भी - हर किसी को पूरी तरह से अलग तकनीकों की आवश्यकता है ! सभी खुश परिवार समान रूप से खुश हैं, सभी दुखी हैं - अपने तरीके से। परियोजनाओं के साथ एक ही - दो समान नहीं हैं।

तकनीक बनाना एक इंजीनियरिंग कार्य है। बिल्कुल प्रोग्रामिंग और डिजाइनिंग सिस्टम मॉड्यूल के समान है। आप इसे कैसे देख सकते हैं आप जानते हैं कि इंजीनियरिंग समस्याओं को अच्छी तरह से कैसे हल किया जाए - इसलिए इस नए अभ्यास में अपने सभी ज्ञान का उपयोग करें।

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

मेरी व्यक्तिगत अभिव्यक्ति

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

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

ऐसा होता है कि कुछ प्रथाओं को लागू करना मुश्किल है, क्योंकि उन्हें समझना मुश्किल है। कभी-कभी अभ्यास को बदलना आसान होता है, शायद यह आपके कार्यों या आपके लोगों के अनुरूप नहीं होता है। अंतिम उपाय के रूप में - लोगों को बदलें, लेकिन यह अभ्यास बदलने की तुलना में अधिक महंगा है।

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

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

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

तीनों सिद्धांत दुनिया की मेरी निजी तस्वीर हैं। यदि आपके पास अन्य निर्धारितियां हैं, तो आपको तकनीकों के निर्माण के लिए संभवतः एक अलग पद्धति की आवश्यकता होगी।

TeamLead Conf program Committee में , हम पुराने लेगो से भी अधिक परिचित हैं, इसलिए हम उस प्रोग्राम में क्यूब्स का चयन करते हैं, जहाँ से आप स्वयं उन प्रक्रियाओं का निर्माण कर सकते हैं जो आपको सूट करती हैं। सेंट पीटर्सबर्ग में शरद सम्मेलन के लिए, 15 भागों का एक सेट पहले से ही इकट्ठा किया गया है, लेकिन हम अभी भी रिपोर्टों के लिए आवेदन स्वीकार कर रहे हैं - लिखें ।