क्या चुस्त वैज्ञानिक साबित हुआ है?

Question

क्या कोई वैज्ञानिक अध्ययन है जिसने अन्य सॉफ्टवेयर विकास पद्धतियों के लिए चुस्त की तुलना की है? मुझे लगता है कि चुस्त काम करने का एक अच्छा तरीका है, लेकिन इसके लिए कोई वैज्ञानिक आधार है?

मैं this जैसे कुछ ढूंढ रहा हूं, सिवाय इसके कि यह अध्ययन केवल टीडीडी से संबंधित है। सामान्य रूप से चुस्त के बारे में अध्ययन किया गया है?

मैं यह पूछ रहा हूं क्योंकि मैं एक चुस्त उत्साह से मुलाकात की जिसने काम करने के चुस्त तरीके से काम करने के अन्य सभी तरीकों से बेहतर सॉफ्टवेयर तैयार किया। उन्होंने इसे एक तथ्य के रूप में प्रस्तुत किया, जो मुझे नहीं लगता कि यह है।

Answer 1

कुछ जानकारी के लिए this response देखें कि कुछ सॉफ्टवेयर के निर्माण के किसी भी पहलू पर शायद ही कभी कोई अच्छा अनुभवजन्य अध्ययन क्यों न हो।

Answer 2

Laurie Williams from NCSU जोड़ी प्रोग्रामिंग की प्रभावशीलता पर बहुत से रोचक अध्ययन प्रकाशित किए, और फिर चुस्त के अधिक पहलुओं से निपटना शुरू कर दिया।

Answer 3

वैज्ञानिक? खैर, मैं एलिस्टेयर कॉकबर्न काम से बहुत प्रभावित हूं। एलिस्टेयर कॉकबर्न उसे here

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

Answer 4

स्क्रम के कुछ पहलुओं ने अनुभवजन्य साक्ष्य का समर्थन किया है। स्क्रम के विभिन्न हिस्सों के कई अनुभवजन्य अध्ययन किए गए हैं। मैंने जेफ सुथरलैंड (http://jeffsutherland.com/scrum/ स्क्रम के आविष्कारक) को सुना है) उनकी वार्ता में बहुत से विशिष्ट अध्ययन और अवलोकन का उल्लेख करते हैं।

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

Answer 5

मुझे नहीं लगता कि ऐसी चीज को साबित करना संभव है।

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

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

1. व्यक्तिगत प्रोग्रामर की क्षमता।
2. प्रोग्रामर द्वारा समर्पण/प्रयास किया गया।
3. उपकरण के साथ अनुभव।
4. जो भी टीम लीडर के रूप में कार्य कर रहा है की क्षमता (केवल एक पद्धति का पालन करने के लिए पर्याप्त नहीं है। अगर कोई टीम को प्रबंधित करने का तरीका नहीं जानता है, तो पद्धति वास्तव में अच्छी तरह से प्रतिनिधित्व नहीं की जाएगी)।

और शायद कई और कारक हैं।

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

Answer 6

मुझे साबित किया गया है कि झरना की सांख्यिकीय विफलता यानी scientific management सॉफ्टवेयर विकास पर लागू होती है। आंदोलन के रूप में, Agile, इस अनुभवजन्य साक्ष्य का सिर्फ एक जवाब है (उदाहरण के लिए CHAOS रिपोर्ट देखें)।

Answer 7

नहीं, यह वैज्ञानिक रूप से या अन्यथा साबित नहीं हुआ है। "साबित" करने के लिए इसका मतलब है या तो:

• देखने का एक विश्लेषणात्मक दृष्टिकोण से इसकी वैधता प्रदर्शित करने के लिए।
• है कि यह व्यवहार में काम करता है दिखाने के लिए और उसके बाद इसकी वैधता

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

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

तो नहीं, फुर्तीली साबित नहीं हुई है। आस - पास भी नहीं। :-)

Answer 8

यह interview with Linda Rising on InfoQ कुछ हद तक आपके प्रश्न को संबोधित करता है। वह प्लेसबॉस की प्रभावशीलता और दवाओं में हमारी मान्यताओं और सॉफ्टवेयर विकास से संबंधित कैसे हो सकती है, इस बारे में बात करती है। असल में, क्या हम एग्इल समुदाय में हैं, जो हमें "चीनी पिल्ल" देते हैं?

साक्षात्कार अंश

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

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

Answer 9

This paper एग्इल बनाम पारंपरिक तरीकों के निवेश पर निवेश (आरओआई) का विश्लेषण करता है। यह प्रकाशित अध्ययनों से वास्तविक परिणामों पर आधारित है।

सार से:

चंचल तरीके लागत पर लाभ चार गुना अधिक था महंगा पारंपरिक तरीकों की तुलना में , दो गुना कम सस्ती की तुलना में, और सबसे अच्छा चंचल और पारंपरिक तरीके बराबर लागत पर लाभ था।