स्क्रम - आप सभी 'अन्य' सामान कहां करते हैं?

Question

स्क्रम के साथ, उपयोगकर्ता कहानियों और इन स्टेमिंग कार्यों आदि का प्रिंसिपल है जो एक तैयार उत्पाद के आसपास घूमता है - जो ठीक है।

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

तो, यह कहां होता है?

Answer 1

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

Answer 2

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

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

Answer 3

असल में, यह प्रत्येक सुविधा के भीतर होता है, जो कि किया जाने से आसान कहा जाता है लेकिन शायद फुर्ती वृद्धिशील सॉफ्टवेयर विकास का पूरा बिंदु है।

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

Answer 4

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

दूसरी ओर, आप पाएंगे कि कुछ गैर-कार्यात्मक आवश्यकताएं हैं जो आप मूल रूप से विश्वास करते हैं महत्वपूर्ण हैं, लेकिन कोई प्रभाव नहीं पड़ सकता है। कभी-कभी, कभी-कभी, डेवलपर्स की प्रवृत्ति गलत होती है :)

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

Answer 5

मैं सहायक सुविधाओं को पहली सुविधा में बनाना चाहता हूं जिसके लिए इसकी आवश्यकता है ।

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

आशा है कि मदद करता है!