चुस्त सॉफ्टवेयर विकास क्या इतना आकर्षक बनाता है?

Question

फुर्तीली सॉफ्टवेयर विकास इन दिनों एक बहुत मजेदार चर्चा बन रहा है।

एक डेवलपर के रूप में, मैं पुनरावृत्त विकास के व्यावहारिक मूल्य को समझता हूं, लेकिन (सबसे अधिक बार) यह सॉफ्टवेयर विकास के लिए एक चुस्त दृष्टिकोण अपनाने के लिए एक डेवलपर्स विकल्प नहीं है। यह एक शीर्ष-डाउन प्रबंधन पसंद है! चाहे वह क्रिस्टल, चुस्त तरीके, डीएसडीएम, रुपये, एक्सपी, स्क्रैम, एफडीडी, टीडीडी हो, आप इसे नाम दें। यह एक डेवलपर विकल्प नहीं है।

वहाँ के सभी प्रबंधकों के लिए, चुस्त विकास करने के लिए चुनने के सबसे बड़े कारण क्या हैं (जब मेरे अनुभव में) अधिकांश प्रबंधकों ने अपने जीवन में कोड का एक टुकड़ा भी नहीं छुआ है!

Comments

इसका एक हिस्सा ऐसा होना चाहिए कि उन्हें नवीनतम तकनीकों और विकास प्रथाओं के साथ "अधिक वरिष्ठ प्रबंधकों और / या ग्राहकों" द्वारा "अप" होने के लिए देखा जा सके।

— ChrisF

मेरे अनुभव में, जब गैर-तकनीकी प्रबंधक "फुर्तीले" के लिए धक्का देते हैं, तो यह आमतौर पर buzzword- अनुपालन द्वारा संचालित होता है, बजाय फुर्तीले विकास के किसी भी लाभ को प्रदान करने की उम्मीद है।

— कार्सन 63000

प्रबंधन से यह अपील करना संभव है कि यह एक सेक्सी नाम है और उनकी शब्दावली में "फुर्तीली" का अर्थ आमतौर पर "कम लोगों के साथ" होता है (देखें "हम एक अधिक चुस्त कंपनी बनना चाहते हैं।" के लिए एक पर्याय के रूप में हम आग लगाना चाहते हैं। आधा कार्यबल ")।

— biziclop

"इन दिनों" कितनी दूर हैं क्योंकि मुझे लगता है कि मैंने कम से कम कुछ वर्षों के लिए एजाइल के बारे में सुना है, जो कि तकनीकी हलकों में एक लंबा समय है?

— जेबी किंग

इसका बड़ा कारण यह है कि प्रबंधक रेंग सकते हैं और कह सकते हैं कि "यह चुस्त होने का हिस्सा है"

— स्टीवन एवर्स

Answer 1

स्थानांतरण आवश्यकताओं, तेजी से वितरण

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

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

वे दोनों की शक्ति चाहते हैं।

Comments

@Pete आप अपने वोटों का उपयोग तब जल्दी से करेंगे ... :)

— निकोल

यह कहने का एक और तरीका है: वास्तव में एक चलते लक्ष्य को गोली मारना और मारना।

— बजर्के फ्रायंड-हैनसेन

Answer 2

निम्नलिखित रुझान

कभी-कभी लोग चीजों को करते हैं, न कि उस चीज की योग्यता के कारण, जो वे (फुर्तीली) हैं, लेकिन केवल इसलिए कि यह लोकप्रिय है और अन्य लोग भी ऐसा करने का प्रयास कर रहे हैं।

"क्या? मैक्रोज़म एजाइल कर रहा है? हम क्यों नहीं हैं? हम धीमे नहीं हैं, हम फुर्तीले हैं, धिक्कार है!"

कुछ लोग एक अच्छा ईश्वरवाद नहीं देते हैं जो वास्तव में चुस्त होता है। यह उनके अस्तित्व को सही ठहराने का एक साधन मात्र है। भेड़, सहकर्मी का दबाव, आदि।

Comments

हाँ, यह एक हजार बार। "कोई सिल्वर बुलेट नहीं है" ... एजाइल / स्क्रैम को छोड़कर, जाहिरा तौर पर, बहुत अधिक प्रबंधकों के अनुसार।

— क्यूरेलसा

"चंचल हमारी सभी समस्याओं का समाधान करेगी।" तो हम अभी भी समस्या क्यों हैं ??

— मार्क कान्लास

Answer 3

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

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

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

उम्मीद है की यह मदद करेगा।

Answer 4

जो चल रहा है, उस पर दृश्यता बढ़ाएँ और उत्पादकता बढ़ाएँ

1. प्रबंधकों को आम तौर पर दृश्यता में दिलचस्पी होती है, विशेष रूप से स्क्रम के साथ। यह उन सेमिनारों में सबसे अधिक इस्तेमाल किया जाने वाला विक्रय बिंदु है जो प्रबंधकों को लक्षित करता है।

2. उच्च उत्पादकता का उपयोग आमतौर पर उन्हें आकर्षित करने के लिए भी किया जाता है क्योंकि यह प्रदर्शित करना आसान है (दृश्यता के लिए धन्यवाद)। कुछ चंचल प्रचारक उन्हें अपने मौजूदा कर्मचारियों से उत्कृष्ट उत्पादकता का वादा करते हैं। "क्या? मैं पहले से ही उन्हें नींबू की तरह दबा रहा हूं और आप मुझे बताएं मैं और भी अधिक प्राप्त कर सकता हूं " ?

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

परिणाम? में कई टीमdistress । उन्होंने सोचा कि चुस्त उनकी सभी समस्याओं को हल कर देगा, लेकिन इसने ठीक इसके विपरीत किया। समस्या कहीं और थी।

मैं इसके खिलाफ सक्रिय रूप से लड़ रहा हूं। इसीलिए कभी-कभी जहाँ pervertedप्रबंधन के द्वारा चुस्त कार्यप्रणाली से अधिक सम्भावना होती है , मेरा सुझाव है कि कंपनी के भीतर इसका उल्लेख न करें।

Answer 5

उस प्रश्न का उत्तर एक पुस्तक भर सकता है।

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

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

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

इसलिए चुस्त अभ्यास भी वास्तविकता को बहुत जल्द स्पष्ट कर देते हैं।

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

Answer 6

अधिकांश प्रबंधकों ने अपने जीवन में कोड का एक टुकड़ा भी नहीं छुआ है!

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

चुस्त विकास करने के लिए चुनने के सबसे बड़े कारण क्या हैं

• विजिबिलिटी या सक्सेस फास्ट / फेल फास्ट - हम 6 महीने से 24 महीने के चक्र के साथ उत्पाद विकास की दुकान हैं। काम कर रहे, परीक्षण सुविधाओं के साथ Iterative विकास ने परियोजना की स्थिति को प्रतिबिंबित करने का एक बेहतर काम किया।
• परिवर्तन - हमारे पर्यावरण में, आवश्यकताओं और समय को तय किया जाता है। लेकिन, बहुत अधिक नियमित आधार पर कारोबार तेजी से बढ़ता है, दिशा में बदलाव के साथ परेशान करता है। निष्क्रिय, दृश्य विकास ने परियोजनाओं को दिशा बदलने में आसान बना दिया।
• पुनरावृत्त विकास के साथ कहानी आधारित आवश्यकताओं ने व्यवसाय के साथ काम करना आसान बना दिया जो हमेशा आवश्यकताओं के तकनीकी पहलुओं को नहीं समझते थे या कुछ विवरणों के व्यापार ड्राइवरों को पूरी तरह से समझते थे। हमारे पिछले प्रयासों में, उच्च स्तरीय विनिर्देश या विपणन आवश्यकता दस्तावेज हमेशा पर्याप्त नहीं थे। अब, जैसा कि परियोजनाएं विकसित होती हैं, कुछ समानांतर बाजार और ग्राहक अनुसंधान हो सकते हैं।
• प्रक्रिया परिवर्तन में कई अन्य विकास विशेषताएँ जैसे TDD, स्वचालित बनाम मैन्युअल परीक्षण, तंग परीक्षण चक्र (हमारे पास अब क्यूसी समूह नहीं है, बस एक क्यूए समूह है), और गुणवत्ता से संबंधित एक उच्च प्रशंसा और प्रयास है (हम एक का उपयोग करते हैं। बहुत अधिक उपकरण और मैट्रिक्स)।

हम इसे अन्य तरीकों से हासिल कर सकते थे, लेकिन चुस्त तरीके और विचारों का लाभ उठाने से हमें काफी मदद मिली।

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

Comments

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

— आरोन मैकिवर

Answer 10

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

Answer 11

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

Answer 12

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

Comments

क्योंकि प्रोग्रामर बिलों का भुगतान नहीं करते हैं, ग्राहक करते हैं और इसलिए वे नियंत्रण में हैं।

— जेफ ओ