स्क्रम - डेवलपर्स स्प्रिंट के बाहर काम कर रहे


12

द स्क्रम टीम

  • 3 एक्स डेवलपर्स
  • 2 एक्स परीक्षक
  • 1 एक्स ऑटोमेशन टेस्ट एनालिस्ट

हम एक बहुआयामी टीम नहीं हैं जिसमें डेवलपर्स परीक्षण नहीं करते हैं और परीक्षक विकसित नहीं होते हैं। मेरा मानना ​​है कि यह मुद्दे का मूल कारण है।

वर्तमान में हम दो सप्ताह के स्प्रिंट करते हैं।

स्प्रिंट की शुरुआत में हर कोई व्यस्त है, डेवलपर्स विकास कार्य पर एक शुरुआत कर रहे हैं और परीक्षक अपनी परीक्षण तैयारी (परीक्षण मामलों को लिखना, आदि) कर रहे हैं।

एक बार जब परीक्षकों ने अपनी तैयारी पूरी कर ली है तो वे अब विकास कार्य पूरा होने की प्रतीक्षा कर रहे हैं या विकास कार्य पूरा हो गया है और डेवलपर्स प्रतिक्रिया / बग का इंतजार कर रहे हैं।

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

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

क्या इसे स्क्रैम में समस्या माना जाता है? क्या इसका कोई हल है? क्या स्क्रम केवल मल्टीफंक्शनल टीमों के साथ काम करता है?

यदि संभव हो तो मैं इसके साथ अन्य लोगों के अनुभव जानना चाहूंगा :)


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

... या शायद आप दो सप्ताह के लिए टीम पर कब्जा रखने के लिए अपने स्प्रिंट में पर्याप्त नहीं डाल रहे हैं।
ब्लरफ्ल

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

3
क्या एक स्प्रिंट के लिए शुरू में जो काम शुरू किया गया था, वह आम तौर पर पर्याप्त गुणवत्ता के साथ पूरा होता है? या क्या आप मूल योजना से आधी-अधूरी कहानियों के साथ भी बचे हैं?
बार्ट वैन इनगेन शेनॉउ

2
आप बस अपनी प्रक्रिया को बनाए रख सकते हैं, लेकिन इसे 'घबराहट' के बजाय 'कानबन' कह सकते हैं, और फिर आपको इस बारे में चिंता करने की ज़रूरत नहीं है कि आपकी प्रक्रिया सही है। / कुछ व्यंग्यात्मक, लेकिन वास्तव में नहीं
एरिक किंग

जवाबों:


16

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

सबसे पहले मैं कुछ चीजों पर ध्यान देना चाहूंगा जो मुझे लगता है कि महत्वपूर्ण हैं:

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

  2. कोई फर्क नहीं पड़ता कि आप कैसे विभाजित करते हैं और पुनरावृत्तियों की व्यवस्था करते हैं, आप वास्तव में हर किसी को हर समय कब्जा नहीं रख सकते हैं और एक एकल बैठक की बैठक के साथ एक टीम है जब तक कि आपकी टीम में विशेषज्ञ काम कर रहे हों। यहां तक ​​कि एक शुद्ध झरने के दृष्टिकोण के साथ, आपको अभी भी "दीवार पर सामान फेंकने" और प्रतिक्रिया की प्रतीक्षा करने की आवश्यकता होगी।

  3. आपको यह भी समस्या है कि अक्सर एक एकल कहानी के लिए एक विकास चरण की आवश्यकता होती है, उसके बाद एक परीक्षण चरण, उसके बाद बग फिक्सिंग चरण, इसके बाद ... यह वास्तव में आपकी टीम को अक्षम बना सकता है - खासकर यदि वे पहले से काम करते हैं , क्योंकि उन्हें संदर्भ स्विच करने की आवश्यकता है।

स्पष्ट रूप से इस स्थिति के लिए एक बहुत ही वास्तविक लागत है: टीम सहयोग नहीं कर रही है। मैं हर बार इसका सामना कर चुका हूं, एक क्यूए टीम शामिल थी, इसलिए मुझे अलग-अलग समाधानों का प्रयोग करने के लिए थोड़ा समय मिला है।

मेरे लिए बहुत अच्छी तरह से काम कर रहे हैं ये दो उपकरण हैं:

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

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

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


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

@Sklivvz ऐसा तब होता है जब QA विभाग होता है। यह हर बार होता है जब QA एक ऐसी भूमिका होती है जो केवल "कुछ खास लोग" ही निभा सकते हैं। "अगले" उच्च-प्राथमिकता वाले कार्य को लेने के लिए निष्क्रिय संसाधन के बजाय, डेवलपर निष्क्रिय हो जाता है, फिर अधिक कार्य चुनता है जबकि QA डेवलपर आउटपुट के प्रति सतत प्रतिक्रिया करता है।
एडविन बक

1
यदि यह ऊपर स्पष्ट नहीं था, तो "अगला उच्च प्राथमिकता वाला कार्य होगा" क्यूए बैकलॉग को कम करना ताकि वस्तुओं को भेज दिया जा सके "बैकलॉग से अगले उच्च प्राथमिकता वाले विकास कार्य नहीं।
एडविन बक

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

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

2

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

हम हमेशा वर्तमान स्प्रिंट में अगले स्प्रिंट काम कर रहे हैं

वाह! स्क्रेम में यह संभव नहीं है। आप नहीं जानते कि बैकलॉग आइटम अगले स्प्रिंट में क्या होगा, यह स्प्रिंट योजना सत्र में अगले स्प्रिंट की शुरुआत में स्थापित किया जाना है।

यह दिलचस्प है कि नए रचनात्मक तरीकों के बारे में जानने के लिए संगठनों ने स्ब्रोट को तोड़फोड़ करने के लिए आविष्कार किया।


3
"वाह! यह तकनीकी रूप से स्क्रम में संभव नहीं है" और ... ... जैसे नए रचनात्मक तरीके संगठनों के लिए समस्या है कि वे स्क्रम को तोड़फोड़ करने के लिए ईजाद करें। वे कहते हैं कि "स्क्रम" करने का एक सही तरीका है। एक सही तरीका होने के लिए, स्क्रैम को अभियोगात्मक होने की आवश्यकता है, अर्थात लोगों के सामने प्रक्रियाएं करें। स्क्रम इसलिए एक चुस्त प्रक्रिया नहीं है अगर स्क्रम करने का एक सही तरीका है।
डेविड अरनो

@ डेविड अरनो यह अच्छा है, आप मूल रूप से किसी भी पद्धति को गैर-चुस्त बता रहे हैं। यहां तक ​​कि चुस्त घोषणापत्र भी। केवल सरासर अप्रत्याशित अराजकता होगी। लेकिन रुकिए .. कौन मुझे अराजक बता रहा है? गंभीर अब: चुस्त एडेगियम "प्रक्रियाओं से पहले लोग" संघर्ष को हल करने के लिए है। अगर किसी को चुनना है, तो उसे वही करना चाहिए जो समझ में आता है, जरूरी नहीं कि नियम क्या कहें। ऐसा लगता है कि ओपी की टीम बिना मुद्दों के स्क्रैम बुक द्वारा जा सकती है। और शायद वे करते हैं, महत्वपूर्ण सवाल यह प्रतीत होता है कि वे कितने पारदर्शी हैं।
मार्टिन माट

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

1

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

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

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

मेरा यह भी सुझाव है कि यह एक प्रबंधन समस्या है। अगर वे व्यस्त रहने के लिए डेवलपर्स पर दबाव डाल रहे हैं तो उन्होंने पूरी तरह से घोटाले को गले नहीं लगाया है। यह एक और बात है कि स्कैम मास्टर मदद कर सकता है। वे यह समझने में मदद करने के लिए प्रबंधन के साथ काम कर सकते हैं कि स्क्रैम कैसे काम करता है ताकि वे सब-ओवर करने के बजाय विकास टीमों को समर्थन और प्रोत्साहित करने में मदद कर सकें।


0

मुझे लगता है कि यहाँ मुख्य समस्या निम्नलिखित है:

अधिकांश डेवलपर्स की राय है कि परीक्षण उनके नीचे है

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

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

डेवलपर्स को व्यस्त रखने का एक और तरीका है कि उन्हें स्प्रिंट में विकसित कार्यात्मकताओं के लिए स्वचालित परीक्षणों को कोडित करने पर काम करना है। फिर उन परीक्षणों का उपयोग प्रतिगमन परीक्षण के लिए किया जा सकता है जो समय-समय पर चलाया जाएगा।

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


मैं कहूंगा कि प्रोग्रामर कोड का परीक्षण कर रहे हैं, वे सिर्फ स्वचालित परीक्षण नहीं बनाते हैं। बड़ा अंतर है।
जेएफओ

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

0

सिद्धांत रूप में, एक SCRUM टीम के सभी सदस्यों के पास समान ज्ञान होना चाहिए, ताकि प्रत्येक सदस्य प्रत्येक कार्य को हर दूसरे सदस्य से ले सके। यदि नहीं, तो आपको ज्ञान का प्रसार करना चाहिए।

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

ज्ञान को फैलाने में प्रबंधन की तुलना में अधिक समय लग सकता है।

मेरे अनुभव के लिए, आप कई काम कर सकते हैं:

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

ये सुझाव 100% SCRUM सिद्धांत नहीं हो सकते हैं, लेकिन सबसे पहले आपको विकास कार्य करना होगा। SCRUM सिर्फ एक टूलबॉक्स है।


0

ऐसा प्रतीत होता है कि आपको टीम में शामिल करने की आवश्यकता है। उसके जैसा:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

अगर मुझे समझ आया कि टेस्ट ऑटोमेशन वालों को कुछ दिन पहले शुरू करना है।

लेकिन मुझे आपकी टीम में एक समस्या है: मुझे डेवलपर्स के साथ एक समस्या है जो अपने स्वयं के कोड का परीक्षण नहीं करता है। यदि परीक्षण लोग कोड की समीक्षा किए बिना परीक्षण तैयार करते हैं तो वे संभवतः केवल ब्लैकबॉक्स परीक्षण कर रहे हैं जो विकसित कार्यक्रम के निर्णय बिंदुओं को ध्यान में नहीं रखते हैं। आप अपने सॉफ़्टवेयर की गुणवत्ता से संतुष्ट हैं?

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