स्क्रम को समझना

Question

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

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

और जब हम विकास करते हैं, तो हम कैसे सुनिश्चित कर सकते हैं कि हम टेस्ट केस तैयार करने और कार्यक्षमता देने के लिए प्रतीक्षा करने के अलावा परीक्षण टीम को व्यस्त रखते हैं?

यह एक प्रश्न उठाता है अगर हमें स्प्रिंट के पहले 3 दिनों के भीतर पहला कार्य/सुविधा प्रदान करने की आवश्यकता होती है, ताकि परीक्षक उस टुकड़े का परीक्षण करने के लिए अपने परीक्षण मामलों के साथ तैयार हो सकें।

मुझे स्क्रैम प्रक्रिया को अनुकूलित करने में सहायता के लिए अपने क्लाइंट को शिक्षित करने की भी आवश्यकता है।

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

Answer 1

एक आदर्श स्क्रम टीम में, परीक्षकों और डेवलपर्स की हिस्सा हैं टीम और परीक्षण विकास के समानांतर में होने चाहिए, चरणों, अतिव्यापी अनुक्रमिक (क्रमिक रूप से काम करने नहीं हैं अंदर एक स्प्रिंट एक रोधी है पैटर्न Scrumerfall के रूप में जाना जाता है)। और वैसे, यहां व्यक्त की गई कुछ राय के विपरीत, एक अंतिम स्क्रम कार्यान्वयन कहानियों को पूरा करता है ताकि परीक्षण - आईएसटी, यूएटी - स्प्रिंट के दौरान किया जाना चाहिए।

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

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

मैं यह नहीं कह रहा कि यह आसान है, लेकिन परिपक्व (यानी दुबला) स्क्रम कार्यान्वयन और परिपक्व स्क्रम टीमें कर रही हैं।

मैं हेनरिक निबर्ग द्वारा Scrum And XP from the Trenches पढ़ने का सुझाव देता हूं, यह बहुत अच्छी व्यावहारिक मार्गदर्शिका है।

_{के रूप में मैरी Poppendieck लिखते हैं, परीक्षकों के काम दोषों (आवश्यक) को रोकने के लिए, दोष (अपशिष्ट) को खोजने के लिए नहीं होना चाहिए।}

Answer 2

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

Answer 3

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

यह केवल अंत में, एक बार आप टीम के वेग निर्धारित किया है (यानी। कितने कहानियों एक यथोचित एक स्प्रिंट में पूरा कर सकते हैं) है कि आप बड़ी परियोजनाओं

के लिए दिनांक और चीजों का आकलन

Answer 4

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

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

Answer 5

आप निश्चित रूप से स्प्रिंट की पहली छमाही और दूसरी छमाही में सभी परीक्षण में सभी विकास करने के लिए नहीं करना चाहती। यह सिर्फ एक छोटा झरना है।

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

उत्पाद मालिक वितरण के शीर्ष पर है, तो मैं क्या हम को तैनात करने के संबंध में कोई मुद्दा नहीं की उम्मीद है।

मैं देख सकता हूँ कि पास्कल परिपक्व स्प्रिंट टीमों + डन की परिभाषा के बारे में लिखें। और उत्तेजना हमेशा स्प्रिंट के अंत तक पहुंचने के तुरंत बाद 'वितरण पर ध्यान केंद्रित करती है'। हालांकि - मुझे यकीन नहीं है कि दुनिया में बहुत सी टीम वास्तव में ऐसा कर रही हैं? हम कम से कम अभी तक नहीं हैं :)

Answer 9

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

मैं आप के रूप में के दौरान आप कर सकते हैं के रूप में छोटे कार्यों में खड़ी कहानियों काट करने के लिए सुझाव है कि कैसे स्प्रिंट नियोजन बैठक का हिस्सा है। कार्यों को छोटे इकाइयों के रूप में तोड़ने की सिफारिश की गई ताकि वे एक या दो दिन में पूरा हो सकें।

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

और याद रखें कि गुणवत्ता पूरी टीम की ज़िम्मेदारी है इसलिए समर्पित व्यक्ति द्वारा परीक्षण किए जाने की चिंता न करें।