स्प्रिंट के बीच क्या होता है?


11

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

  • यह आमतौर पर कितना समय लगता है?
  • क्या पूरी टीम शामिल होनी चाहिए?
  • डेवलपर्स के अगले स्प्रिंट आइटम पर काम शुरू करने से पहले इसे सख्ती से खत्म करना पड़ता है?
  • क्या यह तब होता है जब कोड की समीक्षा और परीक्षण होता है?

तीन डेवलपर्स हैं, लगभग 1 सीसीडी तक। तो स्प्रिंट वास्तव में बहुत कम हैं।


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

13
What happens between sprints?लैन पार्टियां, जाहिर है ...
yannis

सप्ताहांत, उम्मीद है।
13

जवाबों:


13

मैं एक प्रोजेक्ट पर काम कर रहा हूं जो कि स्कोरम मॉडल का अनुसरण करता है।

यह स्पष्ट करने के लिए: आपके प्रबंधकों ने शायद आपको स्क्रैम के बारे में बताया था, लेकिन आप जो प्रदर्शन करते हैं वह स्क्रैम नहीं है।

आमतौर पर इसमें कितना समय लगता है?

स्प्रिंट समीक्षा बैठक + स्प्रिंट पूर्वव्यापी बैठक वर्तमान स्प्रिंट समाप्त होती है। छोटे स्प्रिंट में उन्हें 30 मिनट के बीच कुछ लेना चाहिए - 1 घंटे एक साथ। अगले कार्य दिवस में स्प्रिंट प्लानिंग मीटिंग 1 और 2 का प्रदर्शन करके एक नया स्प्रिंट शुरू होता है। टीम के आकार और स्प्रिंट की लंबाई के आधार पर इन मीटिंग में 2 - 4 घंटे लगते हैं।

क्या पूरी टीम को शामिल होना चाहिए?

पूरी टीम को पिछले उत्तर में उल्लिखित बैठकों में शामिल होना चाहिए।

डेवलपर्स के अगले स्प्रिंट आइटम पर काम शुरू करने से पहले क्या इसे सख्ती से खत्म करना होगा?

हां, क्योंकि जब तक समीक्षा बैठक नहीं होती है, तब तक आप यह नहीं जानते हैं कि ग्राहक पिछले स्प्रिंट के परिणाम को स्वीकार करता है या नहीं और आपको नहीं पता है कि योजना की बैठकों में उपयोगकर्ताओं की कहानियां क्या होंगी।

क्या यह तब होता है जब कोड की समीक्षा और परीक्षण होता है?

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

मुख्य मानसिक बदलाव क्यूए के साथ है। कई डेवलपर्स सोचते हैं कि क्यूए उस कोड को मान्य करने के लिए है और वह काम करता है जो उसे करना चाहिए था। निश्चित रूप से नहीं। वह डेवलपर काम है।

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

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

मेरे अनुभव में यह वह जगह है जहां ज्यादातर कंपनियां चुस्त होकर चलती हैं।


"नहीं। कोड की समीक्षा और परीक्षण स्प्रिंट का हिस्सा है।" - अच्छा, यही मैं पूछ रहा था। :)
स्टीव बेनेट

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

@BryanOakley: मैं सहमत हूं। मैंने अपने उत्तर के उस हिस्से को केवल उन विकास कार्यों के सबसेट के लिए लक्षित किया जहाँ स्वचालित परीक्षण संभव हैं।
लादिस्लाव मृंका

1
यह प्रश्न का उत्तर देने में विफल रहता है।
एडवर्ड एंडरसन

8

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

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


ठीक है, तो आपका क्यूए स्प्रिंट के अंदर होता है। कब होती है तैनाती? क्या आप प्रतीक्षा करते हैं जब तक कि सभी देवों ने अपने सभी काम QA'ed नहीं कर लिए हों, तब एक व्यक्ति को तैनात करता है?
स्टीव बेनेट

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

0

... और अनुमान कब है? योजना?

कहानियों को स्प्रिंट के बीच कोई समय नहीं होना चाहिए।

और मुझे नहीं पता कि आप किस तरह के परीक्षण की बात कर रहे हैं, लेकिन डेवलपर्स इकाई और एकीकरण परीक्षण करेंगे, इससे ज्यादा कुछ नहीं।

मैं स्प्रिंट के बीच कभी-कभी 2 ओ 3 दिन के साथ एक परियोजना में काम कर रहा था और यह सही लगता है। अब मैं एक ऐसी परियोजना पर काम कर रहा हूं, जहां कोई समय नहीं है और इसके सभी फजी हैं। स्प्रिंट का अंतिम समय हमारे पास उत्पादन परिनियोजन है और यह मेरे अंतिम स्प्रिंट दिन का कुछ समय लेता है।


सही मायने में, देव आम तौर पर स्वीकृति परीक्षण नहीं लिखते हैं, लेकिन वे समय-समय पर कर सकते हैं। गुणवत्ता पूरी टीम की जिम्मेदारी है। भले ही वहाँ (उम्मीद है!) परीक्षण विशेषज्ञ हैं, डेवलपर्स को थोड़ा पिच करना चाहिए। कहने के लिए कि वे इकाई और एकीकरण परीक्षणों की तुलना में "अधिक कुछ नहीं करते हैं" सही नहीं है SCRUM।
ब्रायन ओकले
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.