एक उपयोगकर्ता कहानी के बारे में कितना विस्तार एक डेवलपर उम्मीद कर सकता है?


15

फुर्तीले विकास का सबसे बड़ा दोष मैंने अनुभव किया है कि लोग मंत्र पर ध्यान केंद्रित नहीं करते हैं कि एक उपयोगकर्ता की कहानी (3-10 आदर्श व्यक्ति दिन) में 1-3 से अधिक वाक्य शामिल नहीं होने चाहिए:

एक ग्राहक के रूप में, मैं मुफ्त-पाठ खोज का उपयोग कर सकता हूं ताकि मैं उन उत्पादों को पा सकूं जिन्हें मैं खोज रहा हूं।

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

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

वास्तविकता यह है कि यदि डेवलपर को ऐसा करने का मौका दिया जाता है, तो ग्राहक के साथ एक साक्षात्कार आवश्यकताओं की एक लंबी सूची लाता है जो ग्राहक के पास कहानी के बारे में है:

  • हमें बूलियन ऑपरेटर्स जैसे AND और OR की जरूरत है।
  • हमें फजी खोज की आवश्यकता है।
  • हमें एकल शब्दों के साथ-साथ वाक्यांश द्वारा भी खोजना होगा।
  • हम ऐसे उत्पाद नहीं खोजना चाहते जो मापदंड X, Y और Z से मिलते हों।
  • हम परिणाम को क्रमबद्ध करना चाहते हैं। ओह, और वैसे, उपयोगकर्ता कॉम्बो बॉक्स में ए, बी, और सी के विकल्प के अनुसार सॉर्ट मानदंड का चयन कर सकता है।

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

लेकिन अक्सर पर्याप्त मैं खुद को इस स्थिति में पाता हूं कि ऐसी जानकारी प्रदान नहीं की जाती है या बहुत घटिया फैशन में है। न तो यह संभव है कि मैं साक्षात्कार करूं, न ही वह व्यक्ति जो साक्षात्कार करने की स्थिति में होगा वह मुझे इसके परिणाम प्रदान करेगा।

कभी-कभी, प्रबंधक यहां तक ​​कि "हम लुसीन खोज चाहते हैं" जैसे तकनीकी विवरणों के साथ आते हैं, लेकिन वे इस बारे में नहीं सोचना चाहते हैं कि क्या वे केवल उत्पाद नाम या उत्पाद विवरण भी ढूंढना चाहते हैं। कभी-कभी मुझे लगता है कि वे सिर्फ आलसी हैं;)

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

आम तौर पर स्वीकृत संख्याओं की कमी के कारण यह बहस करना मुश्किल है। हर कोई जानता है कि एक पुनरावृत्ति कब तक होनी चाहिए। लेकिन कोई भी यह नहीं बता सकता है कि एक कहानी का अनुमान लगाने और विकसित करने के लिए कितनी आवश्यकताएं हैं।

क्या आपके पास कुछ संदर्भ है?


1
क्या यह बिंदु नहीं है कि आप एक मुफ्त-पाठ खोज बनाने के लिए आवश्यक कम से कम काम करते हैं जो काम करता है और फिर आवश्यकतानुसार परिशोधित करता है? (या आपके उत्पाद का मालिक अधिक विशिष्ट होना सीखता है)
टेलस्टाइन

1
@ टेलस्टाइन: ऐसा नहीं है कि ग्राहक अनुमान लगाना चाहता है।
वोल्फगैंग

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

1
हां, मैं "न्यूनतम" के बिंदु से चूक गया। अब मैं समझ गया।
वुल्फगैंग

जवाबों:


8

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

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

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


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

"नंगे- हड्डियों" पर बिंदु के लिए +1। कुछ अस्पष्ट बिंदु हालांकि ...
अशकान ख। नाजरी

@ वुल्फगैंग: "उन निर्णयों के बारे में जो ग्राहक वापस कर देंगे": यह होगा , इससे कोई फर्क नहीं पड़ता कि आप किस पद्धति का उपयोग करते हैं। केवल एजाइल में, यह जल्द ही होता है, इसलिए कम प्रयास बर्बाद होता है।
sleske

6

पहला मुद्दा यह लगता है कि आप उपयोगकर्ता कहानियों पर समय का अनुमान लगाने वाले नहीं हैं। आपको एक कहानी लेने और "कहानी अंक" लागू करने की आवश्यकता है, जो 1 से जानकारी तक जटिलता का एक सामान्य अनुमान है। कहानी के अंक अक्सर 1,2,3,5,8,13,20 जैसे होते हैं ... (प्रत्येक संगठन के अपने नियम होते हैं।) वे आम तौर पर कुछ लागू करते हैं:

1 - आप इसे अपनी नींद में कर सकते हैं और यह शायद ही लागू करने लायक है। 2 - आप इसे समझते हैं, और इसे जल्दी से कम जोखिम के साथ पूरा किया जा सकता है। 3 - आप इसे समझते हैं, लेकिन एक या दो आश्चर्य हो सकता है। 5 - यह एक छोटे से शोध के लिए जा रहा है, और इसमें कुछ कम जोखिम है। 8 - यह एक बड़ा काम है, इसके लिए बहुत सारे शोध की आवश्यकता होती है, और यह स्प्रिंट में फिट नहीं हो सकता है। 13 - यह बहुत बड़ा है, और निश्चित रूप से स्प्रिंट में फिट नहीं होगा। बड़े पैमाने पर जोखिम है। आदि।

आम तौर पर, कोई भी उपयोगकर्ता कहानी जो 8 या उससे ऊपर की होती है, उसे छोटी कहानियों में तोड़ना पड़ता है।

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

आपको वास्तव में केवल समय का आकलन करना चाहिए जब आप कहानी को स्प्रिंट में स्वीकार कर लेते हैं, लेकिन फिर भी, इस पर जोर कम होता है। विचार यह है कि एक बार जब आपकी टीम इंगित करने की प्रक्रिया के लिए अभ्यस्त हो जाती है, तो आप कहानी के बिंदुओं में प्रति रफ आउटपुट को माप सकते हैं, और इस तरह से योजना बना सकते हैं। आप स्प्रिंट की तुलना में कम समय पर योजना बनाना नहीं चाहते हैं। यहाँ विचार यह है कि यदि आप कार्यों को सही ढंग से तोड़ रहे हैं, ताकि कई कहानियाँ स्प्रिंट में फिट हों, और 1-5 स्टोरी पॉइंट रेंज में हों, तो इसका मतलब है कि वे अच्छी तरह से परिभाषित हैं।

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

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

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

यह सिस्टम गेमिंग नहीं है ... यह पूरी तरह से वैध है। यदि आप नहीं जानते कि क्या यह "ए" या "बी" है, तो आप अनुमान लगाते हैं कि किस आधार पर आपके गधे को कवर करने का सबसे बड़ा अनुमान है।


मुझे भी यह आइडिया पसंद आया। लेकिन: 1. यह अभी भी मुझे वह जानकारी नहीं देता जो मुझे विकास के लिए चाहिए, और 2. पीएम या ग्राहक को लगता है कि वे "मूर्ख" हैं और आपके अनुमान को स्वीकार नहीं करेंगे। आखिरकार, यह उनके बजट में फिट होना है। कहानी के अंक मुझे या तो मदद नहीं करते हैं क्योंकि यह मूल रूप से "आदर्श" दिनों के समान है। और क्या आपका मतलब है स्वीकृति मानदंड? हां, मुझे ये पसंद है, लेकिन वास्तव में मैं इतना योग्य नहीं हूं कि किस रूप में आवश्यकताओं को पहुंचाया जाए। यह उनमें से एक राशि है जो मुझे चिंतित है।
वोल्फगैंग

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

ठीक है, मुझे विश्वास है कि "मैं उनसे बात कर रहा हूं" बहुत अच्छा है; ;-) बिंदु, मुझे अक्सर ऐसा करने का मौका नहीं मिलता है और कुछ असहाय परियोजना का नेतृत्व ग्राहक और डेवलपर के बीच सूचना पाइप को रोक रहा है।
वोल्फगैंग

1

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

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

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

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

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


मेरी समस्या यह है कि यह संचार रेखा अक्सर बहुत धीमी और बहुत खराब है। और इस पर मेरा कोई प्रभाव नहीं है।
वुल्फगैंग

प्रारंभिक प्रतिक्रिया के मूल्य को उजागर करने के लिए +1। मुझे लगता है कि यह स्वीकार किए गए उत्तर में नंगे-हड्डी नीति के साथ हाथ में हाथ आता है
अश्कान ख। नाज़री

@ वोल्फगैंग जो एक अलग (और बहुत अधिक कठिन) कहानी है;)
अशोकन ख। नाज़री

1

ग्राहक

मैं उत्पादों की खोज करना चाहता हूं

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

  • उत्पादों के लिए खोजें
  • क्रमबद्ध परिणाम
  • खोज परिणामों को फ़िल्टर करें

डेवलपर ने उत्पाद प्रबंधक से उपयोगकर्ता कहानियां प्राप्त की हैं। मैंने प्रत्येक उपयोगकर्ता कहानी का विश्लेषण किया है और प्रत्येक उपयोगकर्ता कहानी के लिए कार्य की सूची के साथ आया हूं।

  • उत्पादों के लिए खोजें
    1. कार्य 1: डेटाबेस बदलता है
    2. कार्य 2: सर्वर साइड परिवर्तन
    3. टास्क 3: फ्रंट एंड चेंजेस

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

हमारी उपयोगकर्ता कहानियों का विश्लेषण किया जाता है और निम्नलिखित क्रम में परिष्कृत किया जाता है (कुछ भिन्नताओं के साथ):

हेल्प डेस्क -> प्रोडक्ट ओनर -> प्रोडक्ट मैनेजर -> डिपार्टमेंट लीड्स (सीनियर डेवलपर्स, क्यूए लीड्स इत्यादि) -> डेवलपर्स

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

मैं यह नहीं कह रहा हूं कि यह चीजें करने का एक सही तरीका है, लेकिन यह हमारे संगठन के भीतर वास्तव में अच्छी तरह से काम करता है।

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