फुर्तीली सॉफ्टवेयर डेवलपमेंट का भविष्य

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

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

यह सभी के लिए स्पष्ट है कि फुर्तीली मुख्यधारा बन जाती है और बहुत जल्द ही एक पूर्व निर्धारित जीवन के साथ व्यक्तिगत मास्टोडोन झरने पर काम करेंगे। चंचल ने रेस जीती। Microsoft TFS में चुस्त समर्थन में सुधार कर रहा है और कई उत्पादों पर पुनरावृत्त विकास का उपयोग कर रहा है। आईबीएम ने एजाइल जैज प्लेटफॉर्म लॉन्च किया यहां तक ​​कि एसएपी भी चुस्त है (मैं इसे देखना चाहूंगा)

और यहां ड्यूश बैंक के सीआईओ वोल्फगैंग गैटनर का एक उद्धरण है

“हमें आगे बढ़ना चाहिए। पारंपरिक तरीके पर्याप्त तेज़ नहीं हैं। वे बहुत जटिल हैं और नवाचार में बाधा डालते हैं। यह स्पष्ट रूप से स्पष्ट है। ”

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

कम से कम अमेज़ॅन सर्वरों के हालिया पतन को लें, जो कई दिनों तक चला। हमारा सर्वर लगभग एक सप्ताह से पड़ा हुआ है! Skype समय-समय पर दुर्घटनाग्रस्त हो जाता है (विशेषकर Microsoft द्वारा इसे खरीदने के बाद)। हर किसी को यह काम करने के लिए एक डफ के साथ नाच याद है।

कभी-कभी, आईओएस के साथ समस्याएं पैदा होती हैं। उदाहरण के लिए, अगले अपडेट के बाद मेरे फोन ने स्टैंडबाय मोड में जाने से इंकार कर दिया और 8 घंटे में बैटरी को उतारा, रैंडम क्लिक और कॉल का उल्लेख नहीं किया। यह बहुत कष्टप्रद था। मैं लगभग एक महीने के लिए तय करने के लिए इंतजार कर रहा हूँ!

सही काम करो

चलो सॉफ्टवेयर विकास की तीन मूलभूत समस्याओं से गुजरते हैं। मुख्य कार्य सही काम करना है ।

आपका क्या मतलब है? यह आवश्यक है, विशिष्ट समस्याओं को हल करना और इन समस्याओं को हल करना अच्छा है। बाजार पर कई हजार परियोजना प्रबंधन उपकरण हैं। उनमें से कितने वास्तव में अच्छे हैं? 10? 20? शायद ही 20 से अधिक।

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

हमारे उद्योग के पहले कार्यों में से एक सही सॉफ्टवेयर बनाना सीखना है। पहली रिलीज के साथ लोगों के दिलों में उतरना जरूरी है।

चीजें सही करें

दूसरा काम क्या है? दूसरा काम चीजों को सही तरीके से करना है ।

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

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

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



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

कुटिल रूप से लिखे गए सॉफ़्टवेयर जीवन की नई वास्तविकताओं को विकसित करने और बदलने के लिए बेहद मुश्किल है। ऐसे सॉफ्टवेयर का विकास महंगा और धीमा है।

एक समय में, हमने जल्दी से टारगेटप्रोसेस लिखा। चूंकि यह काम के बाद और सप्ताहांत पर लिखा गया था, इसलिए मुख्य कार्य यह विचार करना था कि यह कितना व्यवहार्य था। यूनिट परीक्षण कुछ कम थे। आर्किटेक्चर कमजोर था। उदाहरण के लिए, O / R ढांचे को असफल रूप से चुना गया था। स्केलेबिलिटी और प्रदर्शन के बारे में किसी ने नहीं सोचा था। लेकिन मुख्य कार्य प्राप्त किया गया था - अवधारणा ने इसकी व्यवहार्यता साबित कर दी है। नतीजतन, सब कुछ खरोंच से फिर से लिखना पड़ा और इसमें 8 महीने का पूरा समय लगा। परिणामस्वरूप, TargetProcess 2.0 दिखाई दिया। यह अच्छा था या बुरा? एक तरफ, हमें लगता है कि 8 महीने खो गए हैं। दूसरी ओर, हमने अवधारणा की जाँच की और यह सुनिश्चित किया कि यह काम करे।

गति

हम तीसरी समस्या - गति की ओर आसानी से बढ़ रहे हैं।

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

उद्योग में ड्यूक नुकेम फॉरएवर जैसे अपने प्रसिद्ध दीर्घकालिक निर्माण हैं।

यह 1996 में शुरू हुआ और 2011 में पूरा हुआ। कई समय सीमा के बाद, डेवलपर्स ने सार्वजनिक मूल्यांकन करना बंद कर दिया, लेकिन बस इतना कहा कि खेल "जब यह तैयार होगा" जारी किया जाएगा। दुर्भाग्य से, ड्यूक नुकेम फॉरएवर कभी भी गेमर्स की अपेक्षाओं को पूरा करने में सक्षम नहीं था। गेम्सपोट ने खेल को 3.5 का स्कोर दिया। खेल उबाऊ, अपरंपरागत और पुराना था।

कैसा धीमा देश है! - रानी ने कहा। - अच्छा, यहाँ,
तुम्हें पता है, तुम बस के रूप में तेजी से चलाने के लिए उसी पर रहना है
जगह! यदि आप दूसरी जगह जाना चाहते हैं, तो आपको कम से कम दो बार तेज दौड़ने की आवश्यकता है।

वास्तव में, हमें तेजी से दौड़ने की जरूरत है ताकि दूसरों से पीछे न रहें। यदि हम पहले बनना चाहते हैं, तो हमें अधिक तेज, तेज दौड़ना चाहिए।

किसी भी सॉफ्टवेयर विकास प्रक्रिया को इन तीन मुद्दों पर ध्यान केंद्रित करना चाहिए, और सामान्य तौर पर किसी भी अच्छी प्रक्रिया का नारा है:

सही काम सही और तेजी से करें



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

यदि हम जल्दी से सही उत्पाद बनाते हैं, लेकिन गलत तरीके से , हम उत्पाद विकास की समस्याओं का सामना करेंगे। या तो हम प्रॉपर और बैसाखी डालेंगे और 10 साल में उत्पाद को दफन कर देंगे, या इसे खरोंच से फिर से लिखेंगे, जो महंगा है।

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

आदर्श रूप में, हमें केंद्र पर पहुंचना चाहिए।

फुर्तीले विकास का भविष्य

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



हमें यह सीखने की जरूरत है कि किसी भी पैमाने पर सही और सही काम कैसे किया जाए।

यह नींव है।

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

शुरुआत करते हैं गति से। गति दो चीजों से निर्धारित होती है: विशेषज्ञता और त्वरित प्रतिक्रिया।

प्रतिक्रिया

प्रतिक्रिया महत्वपूर्ण क्यों है?

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

प्रतिक्रिया मौलिक रूप से आपको 2 चीजें सीखने की अनुमति देती है। क्या हमने वही किया है जो हमें चाहिए। क्या हमने सही किया। हम इसे जल्द से जल्द जानना चाहते हैं। आदर्श रूप से, किसी कार्य को पूरा करने के तुरंत बाद। कैसे जल्दी से जल्दी पता लगाया जाए कि हम सही काम कर रहे हैं? दो समाधान: रेखाचित्र और प्रोटोटाइप, त्वरित डिलीवरी।

स्केचिंग समाधान

स्केच आवश्यकताओं का पता लगाने का एक शक्तिशाली साधन है। लेकिन स्केच को संकीर्ण रूप से नहीं समझा जाना चाहिए। एक स्केच एक वास्तविक प्रणाली का अनुकरण करने का एक त्वरित तरीका है। कभी-कभी एक फ्रीहैंड स्केच पर्याप्त है।



और कभी-कभी बहुत सरल मॉडल नहीं बनाना आवश्यक होता है।

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

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

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

बिल बक्सटन, स्केचिंग यूजर एक्सपीरियंस

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

निरंतर वितरण

फीडबैक को तेज करने का दूसरा तरीका तेजी से वितरण है। प्रत्येक कमिट के बाद डिलीवर करना एक सुपर-रेडिकल विचार है जो सीमा तक प्रतिक्रिया को कम करता है।



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

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

जांच

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

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

लोगों के पास विशेषज्ञता और समस्या सुलझाने के कौशल हैं। यही विकास और सुधार की जरूरत है।

डोमेन ज्ञान

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

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

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

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

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

शिल्प कौशल

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

तेजी से जाने का एकमात्र तरीका सही जाना है।

चाचा बोब मार्टिन

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

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

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

समस्या हल करना

शायद समस्याओं को हल करना किसी भी व्यक्ति का मुख्य कौशल है। यदि यह है, तो आप जिस कंपनी में काम करते हैं, वहां विकास प्रक्रिया में आसानी से अपने स्वयं के अंतराल और अंतराल को भर सकते हैं।

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



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

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

अनुभवी प्रशिक्षक नई प्रथाओं को पूर्वव्यापी बनाने की कोशिश करते हैं, लेकिन वे हमेशा सफल नहीं होते हैं। अक्सर वे स्वयं समस्या हल करने में विशेषज्ञ नहीं होते हैं, अक्सर टीम के लिए अपने ज्ञान को स्थानांतरित करना संभव नहीं होता है।

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

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

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

स्केल

स्केल चुस्त प्रक्रियाओं के लिए एक गंभीर परीक्षा है। मूल रूप से, स्केलेबिलिटी की समस्या कंपनी को समग्र और वितरित टीमों के रूप में चिंतित करती है।

एक पूरे के रूप में कंपनी

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

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

चंचल एक पारंपरिक कंपनी के होमियोस्टैसिस को बाधित करना चाहता है और सतह पर सभी पानी के नीचे की धाराओं, छिपी हुई खामियों और हर चीज को लाता है जो सामान्य परिस्थितियों में पानी में नहीं डूबता है।



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

हाल ही में, यूएक्स टीमें और विकास टीम सक्रिय रूप से जुड़ रही हैं। गंभीर प्रगति है।

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

वितरित टीमें

लंबे समय से चुस्त समस्या वैश्वीकरण है। इंटरनेट के विकास से वितरित टीमों का उदय हुआ है। दुनिया भर के दर्जनों देशों में कार्यालय हैं, जिनमें सैकड़ों लोगों के काम को सिंक्रनाइज़ करना है। चूँकि चंचल का जन्म सह-स्थित टीमों के स्तर पर हुआ था, इसलिए शुरू में उन्हें वितरित टीमों के साथ गंभीर समस्याएँ थीं। निरंतर संचार और कम प्रतिक्रिया मुश्किल है जब एक OUNER उत्पाद सुबह 9 बजे उठता है, और डेवलपर्स नींद से 4 बजे काम करते हैं।

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

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

निष्कर्ष

सॉफ्टवेयर विकास उद्योग का मुख्य कार्य केंद्र को प्राप्त करना है। सही काम सही और तेजी से करना सीखना।



मुझे यकीन है कि यह संभव है। ऐसा करने के लिए, यह आवश्यक है (प्राथमिकता के घटते क्रम में):

• नवीन सोच और प्रणालीगत सोच विकसित करने के लिए TRIZ जैसी समस्या को सुलझाने वाली तकनीकों का अध्ययन करना
• सभी तरीकों से प्रतिक्रिया समय कम करें
• विषय क्षेत्र का अध्ययन करें
• एक संपूर्ण कंपनी में और वितरित टीमों के लिए फुर्तीली मानसिकता को कैसे मापें

PS हाँ, मुझे पता है कि लेख बहुत अच्छा है। लेकिन उसके टुकड़े करने के लिए मुझे बात नहीं दिखती।