क्या मैं प्रक्रिया सुधार कार्यों के लिए "उपयोगकर्ता कहानियां" का उपयोग कर सकता हूं?

Question

वर्तमान में हम अपने विकास कार्य को ट्रैक करने के लिए JIRA का उपयोग करते हैं। मेरा प्रबंधन गैर-सॉफ्टवेयर विकास संबंधी कार्यों सहित "उपयोगकर्ता कहानियां" के रूप में सब कुछ प्रारूपित और वर्गीकृत करना चाहता है। उदाहरण के लिए:

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

स्वीकृति मानदंड: 1. पूरी तरह से स्वचालित परीक्षणों के लिए 50 मौजूदा मैनुअल परीक्षणों में कनवर्ट करें। 2 टेस्ट 1 घंटे से कम समय में निष्पादित होने चाहिए "

मैं समुदाय से एक समझ प्राप्त करना चाहता हूं यदि यह काम के लिए "उपयोगकर्ता कहानियों" का उपयोग करने के लिए समझ में आता है जो सॉफ्टवेयर विकास प्रक्रिया का समर्थन करता है, प्रोग्रामर द्वारा नहीं किया जाता है, और सीधे वितरण कोड में परिणाम नहीं करता है। या इसे अलग तरह से संभाला / वर्गीकृत किया जाना चाहिए (उदाहरण के लिए, JIRA में)?

6/7/2011 अपडेट किया गया - "उपयोगकर्ता कहानी" शब्द पर ध्यान केंद्रित करने के लिए रीफ़्रैस्ड प्रश्न।

Comments

आपके विचारों के लिए सभी को धन्यवाद - टिप्पणी आते रहें! ऊपर सिर्फ एक [अति] सरल उदाहरण है क्योंकि मेरे पास अभी तक हमारी प्रबंधन टीम द्वारा लिखित नहीं है। लेकिन चर्चा के आधार पर, वे प्रक्रिया में सुधार करने में सक्षम होना चाहते हैं जैसे "तिमाही के अंत तक स्वचालित परीक्षणों में 100 (या कुछ प्रतिशत) मैन्युअल परीक्षण", आदि। वे यह सब JIRA में रखना चाहते हैं और इन्हें श्रेणीबद्ध करते हैं। "उपयोगकर्ता कहानियों" के रूप में "कार्यों" या कुछ और के विपरीत।

— डेन सी।

Answer 1

हाँ

कोई भी हितधारक, कोई भी सुविधा जो प्रणाली को बेहतर बनाती है

[शुद्धतावादी को शुरू करने दो!]

Comments

+1 बस स्पष्ट होना चाहिए कि हितधारक कौन हैं, अर्थात देव, प्रबंधक, आदि [फ्लैमवार्स शुरू होने दें!]

— माइकल के

मैं एक शुद्धतावादी हूं, और मैं इस उत्तर का अनुमोदन करता हूं।

— टॉम एंडरसन

मैं सहमत नहीं लेकिन downvote नहीं होगा क्योंकि मैं अपने साहस :) सराहना

— maple_shaft

एक लंबा घुमावदार संस्करण देने जा रहा था, लेकिन यह सब कहता है! "अनुचर" और "3 साल में इस चीज़ पर काम करने वाले लोग" विचार करने के लिए वैध हितधारक हैं!

— अल बिगलान

Answer 2

"मेरा प्रबंधन गैर-सॉफ़्टवेयर विकास संबंधी कार्यों सहित, सब कुछ के लिए एजाइल का उपयोग करना चाहता है।"

इसका मतलब हर फीचर के लिए यूजर स्टोरी लिखना नहीं है।

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

उपयोगकर्ता कहानियां! = चंचल।

उपयोगकर्ता कहानियां आवश्यकताओं को इकट्ठा करने और समझने का एक तरीका है। यदि आप चाहते हैं तो उनका उपयोग पूरी तरह से झरने के तरीके से किया जा सकता है। कुछ लोग ऐसा करते हैं।

फुर्तीली परियोजनाओं को प्रबंधित करने का एक तरीका है। आप फुर्तीले प्रोजेक्ट में यूजर स्टोरीज का उपयोग कर सकते हैं या नहीं।

उपयोगकर्ता कहानियां तकनीकी ऋण और आंतरिक कार्यों का प्रबंधन करने के लिए - फिर से - फुर्तीली होने के साथ कोई लेना-देना नहीं है।

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

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

यदि वास्तविक हितधारकों को उनकी कहानियां नहीं मिलती हैं, तो व्यवसाय वास्तव में पीड़ित होता है।

Comments

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

— दान सी।

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

— 22

अच्छी बात। मैंने प्रश्न को फिर से परिभाषित किया और अधिक संदर्भ प्रदान किया।

— दान सी।

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

— बाबा Kososhi

Answer 3

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

उस नोट पर, सॉफ्टवेयर है:

1. definable
2. परीक्षण योग्य

प्रक्रिया सुधार खुले अंत में होते हैं, और आमतौर पर व्यक्तिपरक होते हैं।

स्वीकृति मानदंड: 1. परीक्षण में सुधार 1 (x / y द्वारा)

आप परीक्षण में सुधार कैसे मापेंगे? उसके लिए कोई निश्चित अनुबंध नहीं है।

और एक असंबंधित नोट पर मैंने SINCERELY HOPE दिया कि आपका उदाहरण ऊपर दिया गया है,

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

... बस एक उदाहरण है, क्योंकि इसमें बहुत कुछ गलत है जिसे मैं वर्णन करना भी शुरू नहीं कर सकता।

Comments

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

— अल बिगलान

Answer 4

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

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

Answer 5

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

Answer 6

जब आप आंतरिक "उपयोगकर्ता कहानियों" को वास्तविक उपयोगकर्ता कहानियों के साथ मिश्रण में डालते हैं तो आपके पास एक गहरा मुद्दा है।

कृपया "हितधारक" की कई परिभाषाओं को फिर से पढ़ें जैसे आप पा सकते हैं।

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

उन्हें बहुत, बहुत ध्यान से पढ़ें ताकि आप मुर्गियों और सूअरों के बीच अंतर देख सकें।

आंतरिक "उपयोगकर्ता कहानियां" मुर्गियों द्वारा लिखी जाती हैं।

वास्तविक उपयोगकर्ता कहानियाँ सूअरों द्वारा लिखी गई हैं।

आपकी "चिकन-उन्मुख" उपयोगकर्ता कहानियां बहुत महत्वपूर्ण नहीं हैं। कोई फर्क नहीं पड़ता कि प्रबंधन उन्हें कितना ट्रैक करना चाहता है क्योंकि वे वास्तविक मूल्य के साथ वास्तविक उपयोगकर्ता कहानियां थीं, वे वास्तविक उपयोगकर्ता कहानियां नहीं हैं और वे उसी तरह मूल्य नहीं बनाते हैं।

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

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

यदि QA परीक्षण में सुधार नहीं दिखाता है, तो कोई भी व्यवसाय से बाहर नहीं जाता है। पैसा नहीं खोया है।

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

आंतरिक ("मुर्गी") और वास्तविक ("सुअर") हितधारकों को नहीं।

Answer 7

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

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

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