स्क्रम - एक स्प्रिंट के दौरान टीम के सदस्य किसके साथ व्यस्त हैं


33

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

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

मैंने इसे संभालने के लिए 2 दृष्टिकोण देखे हैं, लेकिन दोनों में से कोई भी समस्या को ठीक से हल नहीं करता है।

1) टीम के सदस्यों को यह तय करने दें कि जब भी वे कार्यों से बाहर हों तो क्या करें।

विपक्ष:

  • यदि वे जो करते हैं, वह पूरी तरह से नियोजित नहीं होता है (यानी प्रमुख रीफैक्टरिंग, नए परीक्षण ढांचे पर स्विच करना), तो उनका काम बेकार हो सकता है या आधे रास्ते में अटक सकता है।
  • दूसरी ओर, इस तरह के काम की योजना बनाने में काफी समय लग सकता है, और ग्राहक को टीम के समय को किसी ऐसी चीज पर देखने में निराशा हो सकती है जो तत्काल मूल्य नहीं ला सकती है
  • इस तरह के कार्यों का आमतौर पर अच्छी तरह से अनुमान नहीं लगाया जा सकता है, इसलिए असंबद्ध श्रमिकों के लिए YouTube बिल्लियों को देखने के लिए अपना समय व्यतीत करना काफी आसान है, इसके बिना यह स्कैम बोर्ड या कहीं और परिलक्षित होता है

2) केवल विकास के लिए स्प्रिंट में कमरा बनाएं, और स्प्रिंट समाप्त होने के बाद परीक्षण शुरू करें (जब डेवलपर्स अगले स्प्रिंट से सुविधाओं पर काम करना शुरू करते हैं)

विपक्ष:

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

तो मेरा सवाल यह है: डेवलपर्स और परीक्षकों के बीच स्प्रिंट के दौरान काम को सही तरीके से कैसे वितरित किया जाए ताकि कोई भी काम के साथ अतिभारित न हो या किसी भी बिंदु पर कार्यों के बिना समाप्त हो जाए? क्या ऊपर वर्णित दृष्टिकोणों को सुधारने के तरीके हैं? या कोई बेहतर दृष्टिकोण हैं?



1
@holdenmcgrohen अनुमान कैसे लगाए जाते हैं - नियोजन पोकर या कुछ और?
रॉबी डी

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

1
@holdenmcgrohen, हम अपनी परियोजना में भी इसी तरह के मुद्दे का सामना करते हैं। हमने स्प्रिंट के हिस्से के रूप में स्ट्रेच कहानियों ('नहीं होना चाहिए ') को जोड़ना शुरू कर दिया है और केवल तभी उठाया जाता है जब डेवलपर्स कार्यों से बाहर होते हैं। अब यह दृष्टिकोण अगले स्प्रिंट के शुरुआती दिनों में परीक्षक की व्यस्त रखने में हमारी मदद करता है।
user6005214

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

जवाबों:


49

स्प्रिंट की शुरुआत में अभी तक परीक्षण करने के लिए कुछ भी नहीं है

वास्तव में? आपको मान्य करने की कोई आवश्यकता नहीं है? आपके ग्राहक के साथ होने वाली कोई चर्चा नहीं? मूल्यांकन करने के लिए कोई तार-फ्रेम नहीं? कोई भी परीक्षण के बारे में सोचने की योजना नहीं है?

स्प्रिंट के अंत में आम तौर पर विकसित / तय करने के लिए कुछ भी नहीं है या बहुत कम बचा है

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

मुझे पता है कि कुछ लोग बहुत धार्मिक हैं जो 'SCRUM' नहीं है। मैं इस बारे में कम परवाह नहीं कर सकता। लेकिन मुझे लगता है कि आपके यहाँ दो मुद्दे हैं:

  1. एक 'पारंपरिक' QA विभाग जो कोड का परीक्षण करता है, एक बार डेवलपर्स द्वारा ग्राहकों और डेवलपर्स के साथ काम करने के बजाय यह सुनिश्चित किया जाता है कि आप सही चीज़ का निर्माण कर रहे हैं और साथ ही साथ इसे सही भी बना रहे हैं। लिसा क्रिस्पिन द्वारा चुस्त परीक्षण quadrants पर एक नज़र डालें । सर्वश्रेष्ठ परीक्षक सॉफ्टवेयर विकास जीवनचक्र के हर चरण में शामिल होते हैं और सर्वश्रेष्ठ डेवलपर्स अपने स्वयं के परीक्षण लिखते हैं।

  2. 1 सप्ताह / 2 सप्ताह के SCRUM समय-सारिणी के बहुत करीब से चिपकाने की कोशिश कर रहा है, बिना प्राथमिकता के और आकार के बैकलॉग को उन कार्यों में विभाजित किया गया है जो एक ही स्प्रिंट के भीतर कम समय के भीतर पूरा करने के लिए काफी आसान हैं । अगर आपके पास यह होता तो हमेशा साथ काम करने के लिए और अधिक होता। हो सकता है कि इस स्प्रिंट में आपके द्वारा काम किया गया आखिरी फीचर इस स्प्रिंट के रिलीज में न आए, लेकिन यह हमेशा अगले एक में जा सकता है।

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

टिप्पणियों में @Cort Ammon द्वारा लाया गया एक अतिरिक्त बिंदु। फुर्तीला घोषणापत्र अनुबंध वार्ता पर ग्राहक सहयोग के बारे में बात करता है। आप कहते हैं कि:

ग्राहक उस चीज पर समय बर्बाद करने के लिए निराश हो सकता है जो तत्काल मूल्य नहीं लाती है

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

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

संक्षेप में, मैं एक स्प्रिंट की शुरुआत और अंत में लोगों को अधिक कुशल होने की कोशिश करने के बारे में बहुत अधिक चिंता नहीं करूंगा, बल्कि इसे टीम के भीतर एक व्यापक मुद्दे के लक्षण के रूप में देखूंगा। क्या आपने eXtreme प्रोग्रामिंग (XP) के बारे में सुना है । मैं कहता हूँ कि XP ​​से सिद्धांतों को यहाँ लागू करने के लिए संचार और सम्मान कर रहे हैं:

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

हाँ, हाँ और हाँ। हर तरह से जवाब पर हाजिर।
डेविड अर्नो

अच्छा जवाब - आखिरी पैराग्राफ काम की जरूरत है। कुछ टोम की ओर इशारा करने के बजाय यहां बिंदुओं को उठाएं और समझाएं।
रॉबी डी

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

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

@Encaitar ग्रेट सामान +1
रोबी डी

20

पहला बिंदु यह है कि स्क्रम सभी टीम के अनुकूलन के बारे में है , प्रत्येक व्यक्ति के बारे में नहीं। यदि टीम उत्पादक और कुशल है, तो यह बहुत मायने नहीं रखता है कि कोई व्यक्ति कार्य के प्रारंभ या अंत में निष्क्रिय है।

हालाँकि, मैं जिस भी टीम में हूँ, वहाँ हमेशा बहुत काम होता है। मुझे अपनी विशिष्ट चिंताओं के बारे में बताएं:

स्प्रिंट की शुरुआत में अभी तक परीक्षण करने के लिए कुछ भी नहीं है,

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

स्प्रिंट के अंत में आम तौर पर विकसित / तय करने के लिए कुछ भी नहीं है या बहुत कम बचा है

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

मैंने इसे संभालने के लिए 2 दृष्टिकोण देखे हैं ... 1) टीम के सदस्यों को यह तय करने दें कि जब भी वे काम से बाहर हों तो क्या करें।

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

केवल विकास के लिए स्प्रिंट में जगह बनाएं,

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

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

लक्ष्य एक टीम लक्ष्य है, लेकिन आप ऐसा लिख ​​रहे हैं जैसे कि प्रत्येक व्यक्ति का व्यक्तिगत लक्ष्य ("मेरे कार्य समाप्त करें") हों। यदि किसी के पास करने के लिए कुछ नहीं है, तो वे देख सकते हैं कि वर्तमान में क्या काम किया जा रहा है और मदद करने की पेशकश करते हैं। या, वे अगले कार्य या कहानी को ले सकते हैं और उस पर काम शुरू कर सकते हैं।


1
+1। चंचल प्रक्रियाओं को सुस्त बनाने की आवश्यकता होती है। किसी सिस्टम को ऑप्टिमाइज़ करने के लिए, आपको अक्सर सबप्रोसेस को डी-ऑप्टिमाइज़ करना पड़ता है। इस मामले में, आपने इसे "टीम को अनुकूलित करने" के साथ सबसे अच्छा कहा। और कुछ भी उपयोग की गिरावट का एक लक्षण है।
कोडगोमेन

अपने कैरियर की शुरुआत में, मुझे कुछ कंपनियों के सामने उम्मीद थी कि वे सभी पीएचपी, जावा, सी #, डेस्कटॉप ऐप्स (वीबी), क्यूए (स्वचालित, मैनुअल), फ़ोटोशॉप, सीएसएस और इतने पर काम करने की उम्मीद करेंगे। उस समय के उद्योग ने उन कंपनियों को विशेषज्ञता मूल्य के कारण कम पेशेवर माना। मुझे आश्चर्य है कि अगर उसी पैटर्न को एजाइल के तहत स्वीकृति (यहां तक ​​कि आवश्यकता बन जाती है)।
kuldeep.kamboj

1

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

अगला, आपको स्प्रिंट को भरना चाहिए। स्प्रिंट के अंत में कोई खाली समय नहीं होना चाहिए यदि अनुमान अच्छे हैं, हालांकि निश्चित रूप से अनुमान एक काली कला है, इसलिए यह शायद ही कभी भरता है

यदि किसी डेवलपर के पास स्प्रिंट के अंत में खाली समय है, तो इस समय को यह सुनिश्चित करने के लिए ट्रैक किया जाना चाहिए कि यह मूल्य जोड़ रहा है (एक नया ढांचा सीखना, विश्लेषण करना, आगे का परीक्षण आदि)।

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


8
स्क्रम गाइड पढ़ें । शायद आपको वह बिट मिल जाएगा जहां यह कहता है कि विकास टीम को परीक्षकों और डेवलपर्स में विभाजित करना ठीक है (संकेत, आप नहीं करेंगे)।
नाथन कूपर

3
दस्तावेज़ में यह नहीं कहा गया है कि आपके पास विशेष टीम के सदस्य हैं जिनके पास विशेषज्ञ हैं, लेकिन आपको "मुर्गियों" की तरह व्यवहार करने के लिए एक समूह को विभाजित करने की आवश्यकता नहीं है।
नाथन कूपर

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

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

2
@CodeGnome बिल्कुल सही है, और एक बिंदु पर छूता है जिसे मैं हमेशा ऊपर लाता हूं : एजाइल एक दर्शन है, स्क्रैम उस दर्शन का कार्यान्वयन है। दोनों एक ही चीज नहीं हैं, और अलग-अलग नियमों का पालन करते हैं। (हां, स्क्रम पहले आया था, लेकिन बाद में एक फुर्तीला कार्यान्वयन हो गया था)

-2

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

SCRUM तरीका यह होगा कि आप अपनी टीम को क्रियात्मक होने में सक्षम बनाएं । आपके परीक्षकों के पास परीक्षण-स्वचालन के लिए कौशल होना चाहिए, वैसे भी यह कम जटिल चीजों में से कुछ को कोड करने के लिए एक छोटा कदम है।


6
टी-आकार के लोग एक चीज हैं, परीक्षकों को कोड लिखना (जब तक कि हम परीक्षण स्वचालन के लिए बात नहीं कर रहे हैं) काफी भिन्न है।
रॉबी डी

2
यह सिर्फ यह मानता है कि स्प्रिंट में केवल टेस्टर्स डाउनटाइम है? देवों का भी अधोगति है।
maple_shaft

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