बीडीडी विनिर्देशों कार्यशालाओं में सफल होने के लिए कैसे?


9

आज हमने स्पेसिफिकेशन वर्कशॉप करके अपनी सॉफ्टवेयर डेवलपमेंट प्रक्रिया में BDD को पेश करने की कोशिश की।

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

कार्यशाला के अंत में कुछ लोग वास्तव में कार्यशाला से नाखुश थे।

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

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

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

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

तो आप कैसे प्रभावी ढंग से है कि काम करने के लिए प्राप्त कर सकते हैं व्यवहार में ?

जवाबों:


4

यदि आप परिदृश्य को विवरण से प्राप्त कर सकते हैं, तो आप कर रहे हैं।

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

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

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

और आप पूछ सकते हैं, "क्या खाता वसूली इस सुविधा का हिस्सा है?"

"यदि आप चाहें तो वे दो विशेषताएं हो सकती हैं।"

"ठीक है, इसलिए हमारे पास बनाने, पढ़ने, अपडेट करने, हटाने के लिए परिदृश्य हैं; यह काफी आसान होना चाहिए। चलिए खाते के पुनर्प्राप्ति के बारे में बात करते हैं। यह बहुत दिलचस्प लगता है।"

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

यदि आपने इसे पहले कभी नहीं किया है या आप अनिश्चित हैं, तो परिदृश्यों के माध्यम से बात करें।

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

एक प्रसंग को देखते हुए
जब कोई घटना होती है
तो एक परिणाम होना चाहिए।

  • क्या कोई अन्य संदर्भ है, जो एक ही घटना के लिए, एक अलग परिणाम उत्पन्न करता है?
  • क्या कोई और नतीजा है जो महत्वपूर्ण भी है?

यदि मेज पर हर कोई ऊब रहा है, तो जिस सुविधा के माध्यम से आप बात कर रहे हैं वह शायद अच्छी तरह से समझा गया है। यह अक्सर कहने के लिए पर्याप्त है, "इसे एक्स की तरह काम करना चाहिए , लेकिन इसके बजाय वाई के साथ ।" डैन नॉर्थ को जिंजर केक पैटर्न कहते हैं; यह चॉकलेट केक के लिए नुस्खा की तरह है, लेकिन चॉकलेट के बजाय अदरक के साथ।

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

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

कभी-कभी BDD काम नहीं करता है।

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

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

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

मैंने Cynefin पर कुछ समय पहले एक ब्लॉग पोस्ट लिखी थी , जो मुझे वास्तव में यह समझने में मदद करता है कि वार्तालाप सबसे प्रभावी कहाँ होगा। यदि आप इसे पढ़ते हैं और चार डोमेन को समझते हैं, तो यहां मेरे द्वारा उपयोग किए जाने वाले नियम हैं:

  • सरल और जटिल सामान (ज्ञात) अक्सर अच्छी तरह से समझा जाता है और आपको परिदृश्यों के बारे में विस्तार से बात करने की आवश्यकता नहीं होती है।

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

  • BDD बीच में (जानने योग्य) ज्ञान के लिए एक तंत्र के रूप में और अन्य दो स्थानों को उजागर करने के लिए अंतरिक्ष में शानदार ढंग से काम करता है। यह एक हथौड़ा नहीं है, और सब कुछ एक कील नहीं है। वास्तव में, यदि आप किसी भी चीज़ पर बातचीत करने में बिताए गए समय पर ध्यान केंद्रित कर सकते हैं, तो यह उन उदाहरणों के बारे में नहीं है जिन्हें आप पा सकते हैं; यह उन उदाहरणों को खोजने के बारे में है जिन्हें आप नहीं कर सकते


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

यह डालने का एक अच्छा तरीका है, हाँ :) इसके अलावा, वार्तालाप का होना उन्हें लिखने से अधिक महत्वपूर्ण है, जो उन्हें स्वचालित करने से अधिक महत्वपूर्ण है।
लूनीवोर

मैंने पाया है "मुझे यकीन नहीं है" काफी आम है। अक्सर किसी को जवाब पता होता है - लेकिन उस व्यक्ति से नहीं जिसे देवता से बात कर रहे हैं। सही व्यक्ति को ट्रैक करने में थोड़ा समय लग सकता है ...
डीएनए

1
@DNA ने इस पोस्ट में अधिक विस्तार से जटिलता का अनुमान लगाया है: lizkeogh.com/2013/07/21/estimating-complexity - नीचे विशेषज्ञता पर नज़र रखने में आसानी वास्तव में मीट्रिक का हिस्सा है।
लूनीवर

5

बैठक की लंबाई आपकी समस्या नहीं है। उन बैठकों के लिए लंबे समय तक जाना ठीक है। लेकिन सभी को आत्मविश्वास से भरपूर होना चाहिए। कि वे आपकी समस्या नहीं थी।

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

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

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

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


3

हमेशा सुनिश्चित करें कि बैठक में हर कोई उस बैठक के विषय के लिए तैयार है!

कभी भी एक साथ कुछ भी "मंथन" करने के लिए एक बैठक का उपयोग न करें। इससे हर किसी का समय बर्बाद होता है।

प्रभावी बैठकों के लिए सामान्य नुस्खा:

  • किसी को चर्चा के लिए तैयार आइटम है
  • सभी प्रतिभागियों को उन वस्तुओं का अध्ययन (सिर्फ पढ़ने के लिए नहीं) की आवश्यकता होती है
  • पहले से टिप्पणियों को इकट्ठा करें और सभी प्रतिभागियों को उनका अध्ययन (केवल पढ़ने के लिए नहीं) करने की आवश्यकता है
  • फैसले लेने के लिए बैठक आयोजित करें

1

शिकायतों के बारे में ...

आइए इनसे शुरू करें:

एक डेवलपर ने महसूस किया कि उसने अपना समय बर्बाद कर दिया क्योंकि उसे व्यवसाय विश्लेषक द्वारा सीधे परिदृश्यों को बाहर करने और उनके साथ समीक्षा करने के लिए इस्तेमाल किया गया था।

जो वह कार्यशाला में कर रहा था। तो यह मेरे लिए एक मूडी और बुरे बहाने की तरह लगता है। मुझे शक है कि इस डेवलपर को या तो (या दोनों) कार्यशाला की छानबीन और इसकी समय-सीमा में कोई कमी नहीं आती है।

व्यापार विश्लेषक ने हमारे परिदृश्य कवरेज के साथ आत्मविश्वास महसूस नहीं किया (एक भावना थी कि हम अन्य महत्वपूर्ण सामानों को याद कर सकते थे)

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

लेकिन इससे भी महत्वपूर्ण बात यह है कि यह कार्यशाला भी समय की बर्बादी थी क्योंकि वह इन सभी परिदृश्यों को स्वयं और कम समय में समझ सकती थी।

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

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

इसके अलावा, अगर पहले से ही डेवलपर को इन परिदृश्यों की समीक्षा करने की आवश्यकता थी, तो मुझे पूरा यकीन है कि कार्यशाला में "मैं अपना सामान अकेले करता हूं और सामान देने की तुलना में आगे-पीछे बहुत तेज और कुशल हूं।" आप, आप इसे अकेले समीक्षा करते हैं और मेरे पास वापस आते हैं और इसे फिर से करते हैं।

सुझाव

  • सकारात्मक रहें और इस बात पर जोर दें कि यदि प्रक्रिया सही है, तो आप इस पर बेहतर होंगे।

  • कार्यशाला को सुव्यवस्थित करने और इसे ट्रैक पर रखने का प्रयास करें।

  • हो सकता है कि "लोन-वुल्फ" विश्लेषण के लिए कुछ जगह दें, कार्यशाला को शुरू करने के लिए हर किसी के साथ कुछ परिदृश्यों को अपने दम पर (इससे भी बेहतर, कार्यशाला से पहले) डिजाइन करें, फिर ट्राइएज और मर्ज करें।

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

Given enough eyeballs, all bugs are shallow.

0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.