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

Question

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

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

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

तो सवाल वास्तव में निम्नलिखित के लिए नीचे आता है:

1. बिंदु घर को चलाने के लिए मैं किन तर्कों का उपयोग कर सकता हूं कि इस टीम के लिए स्टोरीक्यू का उपयोग करना बेहतर होगा, या बहुत कम से कम बीडीडी पद्धति को अपनाना होगा?
2. क्या आप मुझे किसी भी ऐसे प्रत्यक्ष प्रमाण की ओर संकेत कर सकते हैं जिसका उपयोग मैं अपनी मानक विधि के रूप में BDD को अपनाने के लिए अपने तर्क का समर्थन करने के लिए कर सकता हूं?
3. आप जो तर्क सोच सकते हैं, वह यह सुझाव दे सकता है कि बीडीडी को अपनाने के लिए टीम को प्रोत्साहित करने की मेरी इच्छा त्रुटि में हो सकती है? हां, मैं गलत साबित होने से खुश हूं बशर्ते कि तर्क एक ध्वनि हो।

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

और आप बीडीडी के बारे में अधिक जानने के इच्छुक लोगों के लिए, निम्नलिखित लिंक उपयोगी हो सकते हैं:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

---

_{अधिक विवरणों में रुचि रखने वालों के लिए, हम 4 की एक छोटी सी टीम के बारे में 5 बड़ी परियोजनाओं पर काम कर रहे हैं। BDD के लिए "पायलट ट्रायल" शुरू में लगभग 2 महीने तक चला, इसके बाद लगभग 4 महीने की अवधि हुई। टीम ने स्वीकार किया कि मुझे इस तरह से काम करना जारी रखना चाहिए और अपने स्वयं के परीक्षण करने थे। मुझे बीडीडी-आईएनजी के बारे में 2 साल हो गए हैं क्योंकि परीक्षण समाप्त हो गया है, जबकि अन्य मुद्दे को चकमा देने में बहुत अच्छे हैं। इस मुद्दे पर "टकराव" को मजबूर करने के बजाय, मैं टीम को धीरे-धीरे राजी करने के तरीकों की तलाश कर रहा हूं ताकि अपने सामूहिक बियांड से दूर हो जाऊं और अपना काम करने का समय बना सकूं।}

Comments

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

— PhD

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

— केविन

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

— रॉबिन्स

द्विआधारी निर्णय आरेख? नुथ के TAoCP वॉल्यूम 4 की एक प्रति खरीदें और उन्हें उधार दें।

— पीटर टेलर

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

— एंटोनियो2011 ए

Answer 1

बिंदु घर को चलाने के लिए मैं किन तर्कों का उपयोग कर सकता हूं कि स्टोरीक्यू का उपयोग करना बेहतर होगा, या कम से कम बीडीओ पद्धति को लागू करें?

"ग्राहक इसे चाहता है।"

IMO आप अपने ग्राहकों / डोमेन विशेषज्ञों को BDD को कम से कम विकास टीम को बेचना चाहते हैं।

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

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

दान उत्तर द्वारा एक प्रस्तुति दी गई है कि आप व्यवसाय को बीडीडी कैसे बेच सकते हैं: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

Comments

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

— रॉबिन्स

Answer 2

1. बीडीडी को अपनाने के लिए अनिच्छुक टीम में, कोई "तर्क" नहीं हैं जो आप अपने सहयोगियों को पूर्ण पैमाने पर अपनाने में उपयोग कर सकते हैं।
    
   मुझे लगता है कि आप जो सबसे अच्छा कर सकते हैं, वह उन्हें एक कोशिश ("स्मोक टेस्ट", "ड्राई रन", "पायलट प्रोजेक्ट") देने के लिए मनाने के लिए है - खासकर यदि आप इसे पूरी तरह से स्पष्ट करते हैं कि आप विचार छोड़ देंगे यदि परीक्षण के परिणाम नकारात्मक हैं।
2. उपाख्यान साक्ष्य खोजने के लिए आपका दृष्टिकोण पूरी तरह से आश्वस्त करने के लिए फिट बैठता है कि टीम इसे आज़माए। उस के लिए, मैं बस "व्यवहार प्रेरित विकास सफलता की कहानी" जैसी किसी चीज़ के लिए वेब खोजूंगा और मुझे जो उपयोग करना आसान लगता है उसे चुनूंगा।
3. कुछ दलीलें हैं, मैं सोच सकता हूं कि यह सुझाव दे सकता है कि टीम के प्रयासों को बीडीडी में बदलने की आपकी इच्छा गलत हो सकती है।
    
   इनमें से कोई भी विशेष रूप से रचनात्मक नहीं है, विशेष रूप से एक "परिवर्तन अधिवक्ता" के दृष्टिकोण से, लेकिन दुर्भाग्य से आपको इस तरह की बयानबाजी ( BTDTGTTS ) से निपटने की संभावना होगी :
    
   • आप गारंटी नहीं दे सकते कि कुल मिलाकर टीम उत्पादकता में सुधार होगा
   • आप गारंटी नहीं दे सकते कि BDD को अपनाने में निवेश किए गए प्रयास पर्याप्त ROI देंगे
   • टीम बीडीडी के बिना पर्याप्त रूप से अच्छा कर रही थी, वर्तमान दृष्टिकोण को बदलने का जोखिम उचित नहीं है
   • Google (या Microsoft, या IBM - बस जो भी "सम्माननीय" सॉफ़्टवेयर विक्रेता के नाम से भरें) BDD के बिना ठीक चल रहे हैं, जो "साबित करता है" कि BDD आवश्यक नहीं है
   • गैर-बीडीडी दृष्टिकोणों को तुलनात्मक परीक्षण में उचित मौका नहीं दिया गया था
   • BDD आमतौर पर ठीक हो सकता है लेकिन इसके लिए और उस मॉड्यूल / परियोजना के लिए यह लागू नहीं है

---

मेरे अनुभव के अनुसार, प्रस्तावित परिवर्तन के लिए काउंटर तर्कों को संबोधित करने के लिए कम से कम दर्दनाक तरीका एक प्रस्तावित परिवर्तन के लिए एक सीमित नियंत्रित परीक्षण प्रदर्शन करके था ।

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

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

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

Comments

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

— रॉबिन्स

@ S.Robins दिलचस्प। वह सीमित परीक्षण जिसका आप उल्लेख करते हैं, यह कितने समय तक चला? टीम का कौन सा हिस्सा शामिल था?

— गन्नत

हम 4 की एक छोटी सी टीम है जो लगभग 5 बड़ी परियोजनाओं पर काम कर रही है। "परीक्षण" शुरू में लगभग 2 महीने तक चला, इसके बाद लगभग 4 महीने की अवधि हुई। टीम ने स्वीकार किया कि मुझे इस तरह से काम करना जारी रखना चाहिए और अपने स्वयं के परीक्षण करने थे। मैं लगभग 2 साल से BDD-ing कर रहा हूं, क्योंकि परीक्षण समाप्त हो गया है, जबकि अन्य समस्या को समाप्त करने में बहुत अच्छे हो गए हैं। इस मुद्दे पर "टकराव" के लिए मजबूर करने के बजाय, मैं टीम को धीरे-धीरे राजी करने के तरीके ढूंढूंगा ताकि वे अपने सामूहिक भयों से बाहर निकल सकें और अपना काम कर सकें! ;-)

— रॉबिन्स 6

समझा। यह आपके प्रश्न को और भी रोचक बनाता है। मुझे इसे चबाने के लिए कुछ समय चाहिए; अब तक मैं बस कल्पना नहीं कर सकता कि आगे की प्रगति कैसे संभव होगी ( सूक्ष्म- शक्ति के उपयोग की तरह "अनुचित" दृष्टिकोण के लिए बचाओ)

— gnat

@ S.Robins जबकि मेरा ध्यान है - क्या आपके पास ऐसे मॉड्यूल हैं जो BDD और गैर-BDD भागों को "मिक्स" करते हैं या 100% BDD / 0% BDD मॉड्यूल को अलग करने के लिए है?

— ग्नत

Answer 3

प्रबंधन की भर्ती का समय हो सकता है। यदि आपने एक कोशिश की है और ठोस परिणाम देखे हैं, लेकिन टीम में गड़बड़ी है, तो प्रबंधन को इसमें शामिल होना पड़ सकता है।

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

Comments

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

— केविन

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

— रॉबिंस

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

— बिल लीपर