उपयोगकर्ता कहानियां बहुत ही उच्च स्तर की और वैचारिक हैं, प्रबंधन डेवलपर्स को रिक्त स्थान भरने की उम्मीद करता है


10

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

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

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

आप सभी का स्वागत है।

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


4
अच्छी तरह से मैं कोई एक्सपी विशेषज्ञ नहीं हूं, लेकिन अगर टीम धारणा कर रही है तो वे एक्सपी गलत कर रहे हैं।
सांगो

4
यदि टीम गलत धारणा बना रही है, जिसे अंत उपयोगकर्ताओं के लिए अधिक प्रश्न पूछकर टाला जा सकता है, तो कार्यप्रणाली के गलत तरीके से कुछ गलत हो जाता है।
डॉक ब्राउन

रिक्त स्थान को भरने के लिए ned, लेकिन उन मान्यताओं और जोखिमों के कारण, जब आप जवाब की उम्मीद करते हैं, तो आप उन तारीखों के साथ व्यापार करने वालों / ग्राहकों को वापस जाने की आवश्यकता है ताकि आप परियोजना को ट्रैक पर रख सकें।
tgkprog

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

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

जवाबों:


26

ट्रिक यह है कि वहाँ खाली न रहें। चाल विकास की प्रक्रिया में उन रिक्त स्थान को जल्द से जल्द भरने की है।

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

यह एक डेवलपर की नौकरी का एक बड़ा हिस्सा यह पता लगाने के लिए है कि ग्राहक क्या चाहते हैं, जब वे अक्सर वास्तव में नहीं जानते हैं।

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

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

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


अभी इस उत्तर को आगे नहीं बढ़ा सकते हैं (सीमा तक पहुंच गया है), लेकिन यह बहुतों में से सबसे अच्छा है। इसके अलावा, एक या दो बार पुनरावृति करने के बाद, अधिकांश ग्राहक आपको इसके लिए पसंद करेंगे।
केके

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

7

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

यह मेरे लिए बहुत "XP" ish नहीं लगता है।

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

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


4

संक्षेप में आप निम्नलिखित स्थिति में हैं:

  1. तुम नये हो।
  2. परियोजना (मुझे लगता है कि आपके चल रहे प्रोजेक्ट के बारे में बात कर रहे हैं) में समय की कमी है।
  3. डेवलपर को अपने विवेक पर रिक्त स्थान को भरने की उम्मीद है।
  4. जिस कंपनी में आप काम कर रहे हैं, वह XP का अभ्यास करने का इरादा है। हालाँकि उपयोगकर्ता कहानियों को एक तरह से लागू नहीं किया जाता है जो कि XP ​​कार्यप्रणाली में फिट बैठता है। दूसरी ओर " डेवलपर को अपने विवेक पर रिक्त स्थान भरने की उम्मीद है "।

बिंदु 4 के बारे में सोचें: मेरी राय है कि चुस्त प्रथाओं को एक कंपनी / टीम की जरूरतों और संस्कृति के अनुकूल होना चाहिए (न कि दूसरे तरीके से)। पहचानें कि कंपनी XP कार्यप्रणाली से कहां चिपकी है और कहां विचलित होती है। यह आपकी चिंताओं के लिए रचनात्मक दृष्टिकोण का आधार है।

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

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

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


+1 "चीजों को जटिल करने वाले किसी व्यक्ति" पर ध्यान वापस लाने के लिए।
अशोकन ख। नाज़री

@ ashy_32bit: योग्य नहीं है लेकिन, अगर वह है, जहां आप उत्तरों का फोकस चाहते हैं, तो आपको प्रश्न का फोकस बनाना चाहिए। (यानी, दूसरे पैराग्राफ के अधिकांश को हटा दिया गया)
पीडीआर

3

सच कहूँ तो, उपयोगकर्ता कहानियों में पूरी तरह से विस्तार नहीं होना चाहिए। "मैं चाहता हूं कि सॉफ्टवेयर एक्स को करे, वाई व्यापार की जरूरत को पूरा करने के लिए" पर्याप्त होना चाहिए। आखिरकार, आप व्यवसाय के लोगों को यह नहीं बताना चाहते कि ऐसा कैसे किया जाए - आप सॉफ्टवेयर के विशेषज्ञ हैं और उसमें सर्वोत्तम अभ्यास करते हैं।

उस ने कहा, डेवलपर्स को यह भी पूछने की आवश्यकता है : "आप यह कैसे काम करने की उम्मीद करते हैं?", "क्या होता है जब वह फीचर जेड के साथ बातचीत करता है?"। डेवलपर्स आवश्यकताएं नहीं बनाते हैं, वे कार्यान्वयन करते हैं।

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


2

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

फिर, अपने प्रश्न पूछें और सुनिश्चित करें कि उत्तर कहानी का हिस्सा बन गए हैं।

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


1

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

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

झरना विकास के लिए अंतर, झरना विकास में है, सब कुछ प्रारंभिक आवश्यकताओं के साथ लागू किया जाता है, और अंत में बदल जाता है।


0

ऐसा लगता है कि डेवलपर्स उपयोगकर्ता कहानियों के निर्माण से पूरी तरह से हटा दिए गए हैं। क्या आप उम्मीद करते हैं कि आप उन्हें एक विस्तृत कल्पना की तरह पढ़ पाएंगे और इसे पहली बार बना पाएंगे? यदि आप ऐसा कर सकते हैं, तो आपको XP या किसी अन्य चुस्त कार्यप्रणाली की आवश्यकता नहीं होगी।

किसी को सवाल पूछना चाहिए कि क्या कहानी बहुत अस्पष्ट है। स्वीकृति परीक्षण कहां होता है?

उपयोगकर्ता कहानियां बदलने के लिए होती हैं। आपको इससे निपटने की जरूरत है।


0

हालांकि एक डेवलपर एक कहानी लिख सकता है / विस्तृत आवश्यकताओं को मैंने बहुतों को नहीं देखा है जो इसमें अच्छे हैं। हम मुद्दों को इंगित करने में बेहतर हैं, बेहतर प्रवाह का सुझाव दे रहे हैं, लेकिन पहले से ही लिखित मामले में एक इनपुट के रूप में।

नए और मौजूदा उत्पादों पर काम किया है और दोनों ही मामलों में जहां आवश्यकताएं हैं जहां सिर्फ 5- लाइनें और हमें रिक्त स्थान को भरने और 'समझ' या अधिक विस्तृत दस्तावेज बनाने की उम्मीद थी।

परियोजनाएं बेहतर ढंग से आगे बढ़ीं, हमारे पास हमारी पेशेवर सेवा वाले व्यक्ति थे जिन्होंने इसके साथ मदद की (या एक मामले में एक वीपी जो कूद गया था क्योंकि कोई और उपलब्ध नहीं था)। किसी भी तरह से विकसित करने के लिए समय की बर्बादी (जब तक कोई प्रतिक्रिया वापस नहीं आ रही है और समय सीमा नहीं बदली है)। इसलिए मेरा सुझाव है: अधिक जानकारी के लिए पूछें, और अधिक प्रदान करें, अपनी मान्यताओं और प्रलेखन के लिए समयबद्ध प्रतिक्रिया के लिए पूछें और बताएं कि इसका जोखिम यह है कि x तिथि तक यह जानकारी प्राप्त नहीं होने पर फिर से काम करना और देरी होगी।


0

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

XYZ मेरे लिए अस्पष्ट है। क्या इसका मतलब एबीसी है? या क्या मैं कुछ न कुछ भूल रहा हूं? (मान लें कि XYZ की आवश्यकता है, मान लें कि ABC एक डेवलपर के रूप में मेरी धारणा है)

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

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


0

एक डेवलपर के रूप में,

मुझे पूरी तरह से एक उपयोगकर्ता कहानी की बारीकियों को समझने की जरूरत है,

ताकि मैं आत्मविश्वास से अनुमान लगा सकूं और इसे लागू कर सकूं।

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

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