क्या फुर्तीले जलप्रपात की दक्षता / प्रभावशीलता पर कोई अध्ययन है [बंद]

Question

बैठक में दूसरे दिन दावा किया गया कि झरने की तुलना में फुर्तीले विकास के समय में केवल 60% कुशल थे। मैं इस दावे को मान्य या खंडन नहीं कर रहा हूँ। मुझे यह पता लगाने में दिलचस्प है कि क्या 2 कार्यप्रणाली की तुलना में कोई अध्ययन किया गया है।

क्या वहाँ कोई अध्ययन दोनों की तुलना कर रहे हैं?

Comments

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

— थॉमस ओवेन्स

दावे का स्रोत पूछें।

— मार्टिन यॉर्क

वैसे यदि मूल व्यक्ति के पास स्रोत है तो इसमें अन्य अध्ययनों के लिंक शामिल हो सकते हैं।

— मार्टिन यॉर्क

@ क्या यह आपकी जगह क्यों नहीं थी? यह कौन कह रहा था? यदि यह एक बाहरी विक्रेता था, तो आपके साथ काम करने से पहले उनकी परियोजना प्रबंधन क्षमता को समझने का एक अच्छा अवसर क्या है।

— थॉमस ओवेन्स

@ कोच: डगलस एडम्स का I refuse to prove that Agile is more efficient,कहना है कि .... भगवान कहते हैं,for proof denies faith, and without faith Agile is nothing.

— मैथुन १६'१४

Answer 1

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

यह पुस्तक स्वयं कई शोध अध्ययनों का सार प्रस्तुत करती है, जिसमें कई फुर्तीले भी शामिल हैं। एक खंड डायना, टी।; द्वारा "क्या दो प्रमुखों से बेहतर है? पेयर प्रोग्रामिंग की प्रभावशीलता पर" सहित शोध को संक्षेप में प्रस्तुत करता है ; अरिशोलम, ई।; Sjøberg, DIK; हेने, जेई; शुल, एफ।; और " फुर्तीली सॉफ्टवेयर विकास के अनुभवजन्य अध्ययन: एक व्यवस्थित समीक्षा " टॉर डायबे और टॉर्गीर डिंगोरियर द्वारा।

सामान्य समझ यह है कि अधिकांश चुस्त प्रथाएं फायदेमंद होती हैं, लेकिन यह है कि जोड़ी प्रोग्रामिंग और टीडीडी और अन्य फुर्तीले किरायेदारों के प्रभाव उतने मजबूत नहीं हैं जितना कोई उम्मीद कर सकता है। वहाँ भी एक परेशान फुटनोट है कि TDD वास्तव में कुछ नशे की लत हो सकता है *।

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

---

* यह जरूरी नहीं कि मेरी राय है!

Comments

कोई मौका जो आप कुछ उद्धरण और संदर्भ जोड़ सकते हैं? यह मेरी सफारी बुकशेल्फ स्लॉट में से एक के योग्य है या नहीं, यह जानने में मदद मिल सकती है। * 8 ')

— मार्क बूथ

कोना संस्करण भी :) धन्यवाद आप इसे बाहर आज रात की जाँच करेगा।

— सोयलेन्टग्रे

जोड़ा गया। मुझे पता है अगर यह तुम मन में था। यदि कोई इस पोस्ट को संपादित करना चाहता है और पुस्तक के पाठ को प्रसारित करना चाहता है, तो उसका भी स्वागत किया जाएगा।

— काइल हॉजसन

धन्यवाद काइल, लेकिन मुझे लगता है कि एक सारांश बेहतर होता कि स्क्रीन ग्रैब जैसा दिखता। उदाहरण के लिए, बिना अधिक संदर्भ के वे जो बात कर रहे हैं, उसे प्राप्त करना थोड़ा मुश्किल है, उन्हें प्रयास से क्या मतलब है ? क्या हम प्रति प्रोजेक्ट डेवलपर घंटे के बारे में बात कर रहे हैं?

— मार्क बूथ

पुस्तक प्रश्न का उत्तर देती है जैसा कि मुझे यह पूछना चाहिए था हालांकि मुझे लगता है कि यह बहुत व्यापक था। लिंक के लिए आपको धन्यवाद।

— सोयालेंटग्रे

Answer 2

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

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

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

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

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

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

---

मैंने जो पढ़ा है, उसके आधार पर मुझे आपके सहकर्मियों के आकलन से असहमत होना पड़ेगा। मुझे यकीन है कि आप कुछ मामले का अध्ययन कर सकते हैं जहां एक चुस्त परियोजना 60% कम कुशल थी, जो एक समान योजना-संचालित परियोजना की तुलना में कुछ प्रदर्शन मीट्रिक के संबंध में थी। हालांकि, ऐसे अध्ययन भी हैं जो बताते हैं कि चुस्त उपज 80% कम प्रयास, 50% कम समय, और उत्पाद के साथ उच्च ग्राहक संतुष्टि है।

Answer 3

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

उल्लिखित विधियों में से किसी की प्रभावशीलता विश्लेषकों पर अत्यधिक निर्भर करती है।

जब आपको एक बेहतरीन उत्पाद का मालिक मिल गया है, तो उदाहरण के लिए SCRUM निश्चित रूप से एक खराब कल्पना के साथ एक झरना दृष्टिकोण से तेज है।

खराब उत्पाद के मालिक के साथ फुर्तीली निश्चित रूप से एक महान विनिर्देशन के साथ झरना से धीमी है।

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

कोई कह सकता है कि फुर्तीली कार्यप्रणाली जोखिम को कम करती है, जबकि झरना, भले ही यह कभी-कभी तेज हो, काफी मौद्रिक जुआ हो सकता है।

Answer 4

फुर्तीले विकास के समय में केवल 60% कुशल थे

सच।

लेकिन, यह एक लंगड़ा माप है।

फुर्तीली विधियां आमतौर पर वास्तविक मूल्य को जल्द ही वितरित करती हैं।

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

आगे की।

आप "विकास के समय" को "विकास और परीक्षण समय" से अलग माप सकते हैं।

एजाइल में आमतौर पर परीक्षण शामिल होता है। तो यह धीमी लगती है।

झरने के विकास को सफाई से परीक्षण से अलग किया जा सकता है। इसलिए कोड जल्द ही "परीक्षण के लिए तैयार" है। लेकिन बहुत बाद तक "किया" नहीं गया।

इसलिए। वे पूरी तरह से सही हैं। उन्होंने क्या मापा।

Comments

मुझे नहीं पता कि यह हमेशा सच है - यह इस बात पर निर्भर करता है कि आप दक्षता को कैसे (किस स्तर पर) मापते हैं। अगर मुझे एक प्रोजेक्ट के माध्यम से झरना लगता है, जिसमें मुझे 2 साल लगते हैं, तो मैंने सिर्फ दो साल बिताए सब कुछ विकसित करने में। लेकिन अगर मैं एक पुनरावृत्त / वृद्धिशील दृष्टिकोण का उपयोग करता हूं, तो मैं सीख सकता हूं कि मेरी आवश्यकताओं के केवल 40% को लागू करने की आवश्यकता है और 15 महीनों में उत्पाद बैकलॉग के 40% को लागू करने के बाद परियोजना सफलतापूर्वक समाप्त हो जाती है। यह एक अलग परियोजना पर 9 महीने का विकास समय है। मेरे लिए, यह दक्षता में वृद्धि है - मैं न केवल एक ग्राहक की सभी व्यावसायिक जरूरतों को पूरा करता हूं, बल्कि पहले से ही एक दूसरे का समर्थन कर रहा हूं।

— थॉमस ओवेन्स

"आप जो मापते हैं वह आपको मिलता है" का एक और मामला। गलत बात को मापें और इससे मदद नहीं मिलती।

— मार्टिन यॉर्क

मेरे अनुभव में चुस्त तरीके निश्चित रूप से धीमे होते हैं जब आपके पास वास्तव में अच्छा विकल्प होता है। लेकिन जब आपका चश्मा बेकार हो जाता है (जो अक्सर होता है), तो चुस्त तरीके से परियोजना को बचाते हैं। जब आपके उत्पाद का मालिक बेकार हो जाता है तब चुस्त / SCRUM बेकार हो जाता है। तो यह बहुत अधिक समान है। यदि आपको कोई ऐसा व्यक्ति मिला है जो वास्तव में अच्छे उत्पाद की कल्पना कर सकता है, तो दोनों दृष्टिकोण समान रूप से तेज़ हैं। यह विश्लेषकों की तुलना में कार्यप्रणाली पर कम निर्भर है।

— फाल्कन

मूल दावे पर फिर से विचार करना वास्तव में सवाल का जवाब नहीं देता है। क्या आपके पास कोई सबूत है, जो उपाख्यान के अलावा है, कि अभिकथन सही है?

— मार्क बूथ

आप जो मापते हैं, वही आपको मिलता है।

— स्कॉट