नुकसान स्क्रैम - धब्बेदार फ्रेम

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

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

चलो चलते हैं।

लचीला और "कठिन"

लचीले विकास के तरीके (फुर्तीली) हैं, जैसे कि एक-दो दिनों में स्क्रम, सरल और बोधगम्य। और "कठोर", वजनदार हैं, जिन्हें कई महीनों के विसर्जन की आवश्यकता होती है, जैसे कि आरयूपी।

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

क्यों डरते हो? पागल दाढ़ी वाले विशेषज्ञ प्रक्रियाओं, कलाकृतियों, आवश्यकताओं के ट्रैसेबिलिटी मैट्रिक्स के बारे में बात करते हैं - और हम एक शर्ट में हैं, नंगे पांव, बस ... हम 3 स्प्रिंट के लिए किसी भी इंटरनेट परियोजना का कार्यक्रम करेंगे! हुर्रे, कामरेड, जीत के लिए।

इसलिए, लचीली कार्यप्रणाली द्वारा प्रस्तुत "सरलीकरण" बहुत ही सशर्त और कपटी है। एक तरफ "आराम", आपको दूसरी तरफ खुद को फैलाना होगा।

हम एजाइल का उपयोग करते हैं, लेकिन क्या आप एक्सपी प्रथाओं को भूल गए हैं?

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

परियोजनाओं को जल्दी से एक कचरे के डिब्बे में बदल दिया गया और तुरंत पूर्ण जीवन शुरू किए बिना मरने के लिए तुरंत नर्सिंग होम भेजा गया।

यह रक्त और पसीने द्वारा विकसित कठिन एक्सपी अभ्यास है, अराजकता में जीवित रहने की प्रथाएं जो केवल स्थिति को संतुलित कर सकती हैं और एक सफल विकास प्रक्रिया को लक्ष्य तक पहुंचा सकती हैं!

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

आइए कठोर वास्तविकता की वास्तविक दुनिया में टीम की भर्ती के साथ शुरू करें।

एचआर जोखिम

PHP / MySQL वेब डेवलपमेंट प्रोजेक्ट में विशिष्ट भूमिकाओं पर विचार करें।

PHP प्रोग्रामर

सामान्य तकनीकी शिक्षा और लागू गणित की बुनियादी बातों के ज्ञान के अलावा, एक कर्मचारी को प्रौद्योगिकी / प्रोग्रामिंग भाषा के बारे में विस्तार से समझने की जरूरत है, न कि Google में किसी भी अवसर पर चढ़ाई करने की।

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

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

केवल एक ही रास्ता है - अपने दम पर पढ़ाने के लिए, एक जानकार सिद्धांत को संलग्न करने के लिए और परियोजनाओं के डेवलपर में कठोर, प्रमाणन के लिए ज़ेंड भेजें।

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

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

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

एसक्यूएल विशेषज्ञ

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

इसलिए, कभी-कभी वे एक SQL विशेषज्ञ की विशेष भूमिका पर जोर देते हैं, जो एक विश्लेषक, एक वास्तुकार या एक सिस्टम प्रशासक हो सकता है - यदि केवल वह संबंधपरक सिद्धांत और विशिष्ट DBMS को समझता है।

मेकअप आदमी

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

काम की गुणवत्ता को नियंत्रित करने के लिए, आप सिद्धांत रूप में, वेब मानकों (w3c) के अनुपालन के लिए जाँच के स्वचालित साधनों का उपयोग कर सकते हैं और विभिन्न ब्राउज़रों में नेत्रहीन जाँच कर सकते हैं।

सॉफ्टवेयर विकास के सिद्धांत और कठिन अभ्यास पर कई वेटी किताबें पढ़ने के बाद, एक टाइपसेट, प्रोग्रामर बन सकता है, लेकिन यह दुर्लभ है।

विश्लेषक

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

वास्तुकार

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

टेस्टर

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

सिस्टम व्यवस्थापक

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

अब हम टीम में भूमिकाओं के बारे में प्राप्त व्यावहारिक ज्ञान को स्क्रम / एक्सपी में घोषित तकनीकों पर लागू करते हैं और एक कार्यशील समाधान प्राप्त करने का प्रयास करते हैं।

परियोजना टीमों में क्रॉस-कार्यक्षमता एक मिथक है

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

गुणवत्ता नियंत्रण - जिम्मेदारी का पदानुक्रम

यदि विशेषज्ञ अनुभवहीन है, तो उसे और अधिक अनुभवी का पालन करना आवश्यक है। मैं एक साथ (एक्सपी अभ्यास) दो अनुभवहीन लोगों को रोपण की सलाह नहीं देता - वे इसे 2 गुना बदतर बना देंगे।

यह पता चलता है कि प्रत्येक भूमिका के प्रतिनिधियों की निगरानी, ​​"वरिष्ठ संरक्षक" द्वारा की जानी चाहिए। यह एक कार्यात्मक प्रबंधक (विभाग प्रमुख) या एक वरिष्ठ विशेषज्ञ (लीड डेवलपर / विश्लेषक / sysadmin) हो सकता है जिसके पास आवश्यक क्षमता है और काम की गुणवत्ता की निगरानी के लिए सीधे जिम्मेदार है।

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

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

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