फुर्तीली टेकडिर भूमिका - टेट्रिस गेम

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

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

आप समझते हैं कि कुछ अजीब हो रहा है, कि परियोजना "बीमार" है, कि आप शायद इससे बच सकते थे, यदि आप पहले से जानते थे ...

हम यह समझने की कोशिश करेंगे कि अब कौन "चेहरे को पीटता है" और अगली परियोजना के लिए हमारे पास कौन आता है - इस तरह के पतन से बचने के लिए।



पुराना प्रोजेक्ट

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

प्लानपॉकर एक समस्या की पहचान करता है - सहकर्मी यह समझने की कोशिश कर रहे हैं कि इस मॉड्यूल के लिए HOW MUCH TIME TO ADD FEATURE का मूल्यांकन करने के लिए यह या उस मॉड्यूल को कैसे संरचित किया गया है, लेकिन - सब कुछ इतना उलझा हुआ है कि हम डरावने से समझते हैं कि इसे पर्याप्त मूल्यांकन देने के लिए कई सप्ताह ... okoda। और फिर से लिखना / हार्ड रिफैक्टर - यह अधिक नहीं तो महीनों लगेंगे।

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

एक व्यवस्थित दृष्टिकोण चाहिए। किससे निर्देश लें, किससे सहमत हों?

नई परियोजना

लेकिन यह ProductOwner शुरुआती के लिए एक वास्तविक आश्चर्य हो सकता है! एक नई परियोजना - जो विघटित होने लगी है।

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

लक्षण 1: तकनीकी बैकलॉग बढ़ने लगा

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

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

- हमने चर्चा की ... हमने एक मॉड्यूल लिखा, ORM लाइब्रेरी का उपयोग किया - लेकिन यह हमें शोभा नहीं देता, यह बहुत जटिल है, हम सीधे डेटाबेस को प्रश्न लिखना चाहते हैं (2 महीने व्यतीत हो गए थे)
- हमने विरासत की वस्तु पदानुक्रम को जटिल कर दिया है, शैतान समझ नहीं पाएगा। फिर से लिखना (एक नई परियोजना !, कलश देना) आवश्यक है।

लक्षण 2: अस्थिर स्प्रिंट

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

लक्षण 3: "ब्रेक"

सब कुछ घड़ी की तरह चला गया। लेकिन यहां उन्होंने सिस्टम में परीक्षण डेटा लोड किया और ... यह नीचे चला गया। यह पता चला है कि सभी प्रोग्रामर यह नहीं समझते हैं कि कोड को डेटा की मात्रा के लगभग "स्वतंत्र रूप से" काम करना चाहिए, आप तालिका से सभी रिकॉर्ड का चयन नहीं कर सकते हैं और कोड में उन्हें संसाधित कर सकते हैं, सैकड़ों मेगाबाइट को मेमोरी में बदल सकते हैं, आदि।

अक्सर, सिस्टम को यह सिखाने के लिए कि डेटा की अपेक्षित मात्रा के साथ कैसे काम किया जाए, यह एक गंभीर पुनर्लेखन लेगा जिसमें महीनों (!) लग सकते हैं। और फिर टेस्ट, टेस्ट ...

लक्षण 4: स्वतंत्रता का मैट्रिक्स

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

लेकिन जब सिस्टम / वेबसाइट बड़ी हो जाती है, तो ... लोग गुम होने लगते हैं। जीवन से एक सरल उदाहरण:

PO: सहकर्मियों, आपको अतिरिक्त छूट एप्लिकेशन एल्गोरिथ्म के लिए समर्थन जोड़ने की आवश्यकता है ...। हमारा अनुमान है।

डेवलपर्स: ऐसा करने के लिए, आपको यहां लाइब्रेरी को ठीक करना होगा, वहां आउटपुट टेम्पलेट को ठीक करना होगा। शायद (!) सब कुछ।

तो यहाँ है। सुविधाओं की शुरूआत के बाद यह पता चला है ... कई भुगतान प्रणालियां बह गई हैं। इसके अलावा, ग्राहकों ने तुरंत इसके बारे में सीखा और "सकारात्मक" प्रतिक्रिया की।

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

स्वचालित परीक्षण ... हाँ, वे कोड का परीक्षण करते हैं, और फिर भी, यदि आप उन्हें तुरंत और LITERALLY लिखते हैं। और वे जटिल व्यावसायिक आवश्यकताओं, एल्गोरिदम के बीच निर्भरता का परीक्षण कैसे करते हैं? हमें अन्य उपकरणों की आवश्यकता है, पहले से ही विश्लेषकों के लिए।

शिकायत करना एक कपटी दुश्मन है

ऐसा लगता है कि यह परियोजना जितनी बड़ी है, उतनी ही बेकाबू और लॉन्च की गई - डेवलपर्स के लिए, ProductOwner के लिए और ग्राहक के लिए दोनों बन जाती है।

काशी बड़ी हो रही है।

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

कौन चेहरे को हराए?

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

Agile का उपयोग करने वाली कंपनी में IMHO, एक मजबूत तकनीकी निदेशक होना चाहिए, जिसमें उसकी रीढ़ की हड्डी में प्रयुक्त कार्यप्रणाली और उपकरणों का BALANCE महसूस हो। विकास प्रक्रियाओं पर किताबें पढ़ने से भाग में मदद मिलेगी - यह वह वृत्ति है जिसकी आवश्यकता है।

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

टेकडिर के प्रमुख कार्य

इसलिए हमने देखा कि चुस्त विकास में, टेकडिर को लगातार टेट्रिस में जीतना चाहिए - चाहे कितनी भी परियोजनाएं ऊपर से नीचे जाएं, उत्पादन संतुलित होना चाहिए और जटिलता बंद नहीं होनी चाहिए। हमेशा ओ (1) और अच्छे मूड ;-):

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

- परियोजनाओं का कोड "खराब नहीं होता है" - तकनीकी विशेषज्ञ द्वारा सिखाए गए डेवलपर्स ने गंध की भावना विकसित की और तकनीकी बैकलॉग में खराब कोड को साफ करने का कार्य निर्धारित किया।

- बड़ी मात्रा में डेटा के लिए कोड तैयार है - डेवलपर्स योग्य हैं, समझें कि वे क्या लिखते हैं। फिर भी, टेकडियर ने परियोजना तत्परता चेकलिस्ट में अनिवार्य लोड परीक्षण निर्धारित किया है।

- या तो यूनिट और अन्य प्रकार के ऑटोटेस्ट का तुरंत उपयोग किया जाता है, या उनका उपयोग परियोजना के जटिल भागों के लिए किया जाता है। यहां आप कभी-कभी कई तरह के कंटीन्यूअस इंटरग्रेशन फास्ट कर सकते हैं।

- परियोजना को अनिवार्य रूप से मॉड्यूल में विभाजित किया गया है और वे एक-दूसरे से जितना संभव हो उतना स्वतंत्र हैं - इसलिए, एक मॉड्यूल में बदलाव से बाकी सिस्टम पर कोई असर नहीं पड़ेगा।

- तकनीकी दस्तावेज़ीकरण या तो स्वचालित टूल (जैसे phpdoc) का उपयोग करके बनाए रखा जाता है, या एक व्यावसायिक प्रक्रिया कॉन्फ़िगर की जाती है और परिवर्तन प्रलेखन विभाग में जाते हैं।

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

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

यदि ऐसा कोई व्यक्ति नहीं पाया जा सकता है - एक बात यह है कि विनिमेय कर्मचारियों के साथ एक जटिल मेगा-औपचारिक प्रक्रिया का निर्माण करना है। यह शायद अधिक महंगा और लंबा होगा।

परिणाम

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

अन्यथा, आप फुर्तीले घोड़े एजाइल को दुखी नहीं कर पाएंगे।