क्या "तकनीकी उपयोगकर्ता कहानियां" स्करम में अनुमत हैं?

Question

क्या स्क्रैम में तकनीकी उपयोगकर्ता कहानियों की अनुमति है? यदि हां, तो स्क्रैम में तकनीकी उपयोगकर्ता कहानियां लिखने के लिए मानक टेम्पलेट क्या है? क्या यह वही है As a <user> I want to do <task> so that I can <goal>??

मैंने कुछ ब्लॉगों में पढ़ा है कि जैसे-ए-डेवलपर- इज़ नॉट -ए-यूज़र-स्टोरी , लेकिन मैंने यह भी पढ़ा है कि स्क्रैम इन को अनिवार्य नहीं करता है। वहाँ कुछ ब्लॉगों, जहां उन्हें साझा किया है उपयोगकर्ता के रूप में प्रणाली के साथ उपयोगकर्ता कहानियों , अपनी तरह as a <user who is not end user> i want to <system functionality> so that <some techinical thing>। तो कौन सा मानक है?

उदाहरण के लिए, उपयोगकर्ता कहानियां हैं:

एक समीक्षक के रूप में मैं किसी भी होटल / भोजन की तस्वीरें अपलोड करना चाहता हूं ताकि अन्य उपयोगकर्ता उन्हें देख सकें और उन्हें पसंद कर सकें

एक उपयोगकर्ता के रूप में मैं फोटो टिप्पणियां जोड़ना चाहता हूं ताकि मैं अपने दृष्टिकोण को बेहतर ढंग से समझा सकूं

अब इन दोनों उपयोगकर्ता कहानियों के लिए, एक बड़ी तकनीकी वस्तु है - छवि को सहेजना और पुनर्प्राप्त करना

तो क्या मैं निम्नलिखित विवरण के साथ एक तकनीकी कहानी जोड़ सकता हूं, जिसका नाम "छवि भंडारण और पुनर्प्राप्ति तंत्र" है?

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

Comments

"छवि भंडारण और पुनर्प्राप्ति तंत्र" एक तकनीकी कहानी नहीं होनी चाहिए, लेकिन आपकी पहली उपयोगकर्ता कहानी से जुड़ा एक डेवलपर कार्य ।

— गुरिल्ला

Answer 1

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

उदाहरण के लिए, छवियों को सहेजने और पुनर्प्राप्त करने के लिए आपकी कहानी आसानी से दो नियमित उपयोगकर्ता-कहानियों के रूप में लिखी जा सकती है

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

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

Comments

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

— जेएफओ

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

— पबरानिस

क्या ऐसा कोई मामला होगा जहां उपयोगकर्ता कहानी लागू नहीं होती है? उदाहरण के लिए, उपयोगकर्ता कहानियों के उदाहरण क्या हैं जो हम देखेंगे, अगर आपको एक आर्टिफिशियल इंटेलिजेंट बनाने के लिए कहा जाता है: अल्फा जीओ, और अंतिम लक्ष्य मानव को जीओ में हरा देना है? कौन उपयोगकर्ता होगा जो मैं उम्मीदों / स्वीकृति मानदंडों को परिभाषित करने के लिए साक्षात्कार कर सकता हूं?

— रॉय ली

Answer 2

प्रश्न, आपके विशेष उदाहरण को देखते हुए, यह होगा कि एक डेवलपर छवियों को संग्रहीत करने और पुनर्प्राप्त करने के लिए एक तंत्र क्यों विकसित करना चाहता है ताकि उपयोगकर्ता जहां भी आवश्यकता हो / छवियों को देख सकें, जब तक कि उपयोगकर्ता छवियों को जोड़ना या देखना न चाहे?

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

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

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

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

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

उन वातावरणों में, महत्वपूर्ण डेवलपर कहानियों को परिभाषित करना अच्छा हो सकता है। यह दृश्यता बढ़ाता है, विश्वास बढ़ाता है, और डेवलपर्स और प्रबंधन को समान रूप से व्यवसाय के लिए ऐसे कार्यों के मूल्य के बारे में सोचने और तदनुसार प्राथमिकता देता है।

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

लेकिन मेरी वृत्ति कहती है कि यदि आप व्यवसाय के लिए इस विकास के मूल्य पर विचार कर रहे थे, तो आपने इसे डेवलपर कहानी बनाने की कोशिश भी नहीं की होगी। यह अंत उपयोगकर्ता के लिए अच्छा है या यह नहीं है। यदि ऐसा नहीं है, तो व्यवसाय के लिए कोई मूल्य नहीं है।

Comments

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

— रॉय ली

Answer 3

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

एक उदाहरण के रूप में, एक नए एप्लिकेशन में डिस्कनेक्ट, यदि हमें तकनीकी कहानियों को जोड़ने की अनुमति नहीं है, तो यह है कि मैं स्प्रिंट डेटाबेस मॉडल बनाने और मेरे डेटा मॉडलर के अनुमोदन के लिए इंतजार करने की शुरुआत के बाद एक सप्ताह के लिए गुनगुनाऊंगा। उन्हें, मॉडलर w / iterate और जब dba को स्क्रिप्ट भेजें और उन्हें db ऑब्जेक्ट बनाने के लिए प्रतीक्षा करें। इस बीच, मैं एक नया कोड प्रोजेक्ट, कुछ आधार ORM कार्यक्षमता और मेरा स्रोत नियंत्रण लेआउट बनाऊंगा और जब सब कहा जाएगा और किया जाएगा तो मेरे पास एक खाली लैंडिंग पृष्ठ बनाने और तैनात करने का समय होगा।

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

यदि ऐसा करने के लिए एक बेहतर सर्वोत्तम अभ्यास है तो मैं सभी कानों के पास हूं।

Comments

हालांकि कई संगठनों में एक मुद्दा, 100% उपयोग गिरावट एक आम शिथिलता है। ASIDE: तकनीकी ऋण एक ज्ञात चिंता है जिसमें आवश्यक कार्य शामिल हैं जो जानबूझकर देरी से किए जाते हैं।

— एलन लरीमर

Answer 4

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

मैं अब अपने साबुनबॉक्स से उतर जाऊंगा, लेकिन अगर आप सवाल करते हैं कि क्या नीचे वास्तव में 'घबराहट' है, तो कृपया (फिर से) ऊपर पढ़ें।

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

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

Comments

बकवास, मैंने देखा कि यह एक पुराना सवाल था ...

— जिमीजैम

नहीं, यह एक अच्छा जवाब है। कुडोस!

— हनीले

teams should not be too hung up on what scrum allowsसमस्याग्रस्त है। यह एक प्रमुख कारण है कि स्क्रैम ढांचे को गलत समझा जाता है। कार्गो के दोष जो व्यवहार में सही नहीं हैं, चल रहे अज्ञान के माध्यम से समाप्त हो जाते हैं।

— एलन लरीमर

@AlanLarimer घबराहट से ज्यादा फुर्तीली है। चुस्त की बात यह है कि टीमों के लिए काम करने वाली प्रक्रियाओं का निर्माण करना है। मैं इस बात से सहमत होता हूं कि जब समस्याग्रस्त नहीं है तो कुछ घोटाले को कॉल करना लेकिन मैं इस धारणा को खारिज करता हूं कि घोटाले परियोजना प्रबंधन प्रक्रियाओं का शिखर है।

— जिम्मीजाम्स

सहमत है कि चुस्त दर्शन उत्पाद के लिए अनुकूली दृष्टिकोण को बढ़ावा देता है (परियोजना पर, जैसा कि स्क्रम केंद्रित है) विकास और यह कि कोई चांदी की गोली नहीं है। कोई भी इस Q & A में एक शिखर की स्थिति का दावा नहीं करता है । जब टीमें / orgs / groups स्क्रम फ्रेमवर्क चुनते हैं और इसके उपयोग के बारे में प्रश्न रखते हैं, तो यह उजागर करना कि यह एक ऐसा फ्रेमवर्क है जो समर्थन करता है (क्योंकि यह एक आधार था) फुर्तीला दर्शन कई बारीकियों को निर्धारित नहीं करने के माध्यम से महत्वपूर्ण है। इस तरह के लचीलेपन और अन्य लोगों में मूल्य का एहसास, कार्गो के दोषों से बचने और ढांचे और प्रक्रिया के मुद्दों के बीच अंतर की पहचान करने के लिए महत्वपूर्ण है।

— एलन लरीमर

Answer 5

उपरोक्त सभी उत्तर स्क्रम फ्रेमवर्क के लिए आधिकारिक स्रोत दस्तावेज़ को संदर्भित करने में विफल रहते हैं: स्क्रम गाइड ।

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

ध्यान उत्पादन मूल्य पर होना चाहिए। कभी-कभी वह मूल्य तकनीकी कार्यों से आता है, जैसे कि बुनियादी ढांचे का उन्नयन। उन वस्तुओं को बाहर न करें!

शब्द उपयोगकर्ता कहानी कभी भी स्क्रम गाइड में दिखाई नहीं देती है क्योंकि

यह एक ढांचा है जिसके भीतर आप विभिन्न प्रक्रियाओं और तकनीकों को नियोजित कर सकते हैं।

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

वर्टिकल स्लाइसिंग को समझना और उपयोग करना उत्पाद बैकलॉग आइटम्स (PBI) के आकार को कम करने के लिए मददगार होगा। टुकड़ा करने की क्रिया है कि एक विचार करें बचाने और पुन: प्राप्त में आइटम को बचाने और पुनः प्राप्त आइटम रों ।