यह मेरे द्वारा योजनाबद्ध किए जाने से अधिक लंबा हो गया (यह एक टिप्पणी के रूप में शुरू हुआ था), लेकिन मुझे आशा है कि अतिरिक्त लंबाई / विवरण सहायक हैं और आप उन्हें उचित पाते हैं।
Agile CRUD ऐप्स के लिए विशिष्ट नहीं है
फुर्तीले साहित्य का अधिकांश भाग CRUD प्रकार के व्यावसायिक अनुप्रयोगों के लिए पक्षपाती प्रतीत होता है, जहाँ उपयोगकर्ता इस बात से अवगत है कि पर्दे के पीछे क्या चल रहा है। (यह ठीक है क्योंकि ज्यादातर लिखा जा रहा कोड शायद इसी वर्ग का है।)
मुझे लगता है कि यह इसलिए है क्योंकि इस प्रकार के आसान-से-सरल उदाहरणों को बनाना आसान है, वास्तव में नहीं क्योंकि कार्यप्रणाली का उद्देश्य उन प्रकार के सिस्टमों से है। यदि आप एक आसान-से-आसान अनुसरण करने वाला उदाहरण नहीं बनाते हैं, तो आप जोखिम उठाते हुए पाठक को उस उदाहरण को समझने की कोशिश कर रहे हैं जब आपकी बात चुस्त अवधारणाओं के बारे में पाठक को पढ़ाने वाली थी।
उपयोगकर्ता कहानियां! = आवश्यकताएँ
इस प्रकार के अनुप्रयोग के लिए उपयोगकर्ता की कहानियों (आवश्यकताओं) और विकास कार्यों के बीच का संबंध ज्यादातर सीधा होता है: बस उपयोगकर्ता कहानी को कुछ कार्यों में विभाजित करें।
एक उपयोगकर्ता कहानी एक आवश्यकता के समान नहीं है। यह सच है कि आवश्यकता 'उच्च-स्तर ’के आधार पर कुछ ओवरलैप हो सकती है, लेकिन आमतौर पर यह समान नहीं है। मुझे यह आभास होता है कि आप एक ही नुकसान में चल रहे हैं, मेरे कई पूर्व प्रबंधक गिर गए: उपयोगकर्ता कहानियों के बारे में "आवश्यकताओं" के समानार्थक शब्द के रूप में, जो कि एसवीएन उपयोगकर्ताओं द्वारा गिट पर संक्रमण करने की कोशिश के समान है, लेकिन रखें एसवीएन के संदर्भ में सोच। (वे तब शुरू की खराब धारणाओं के कारण समस्याओं में भाग जाते हैं।)
IMHO, आवश्यकताओं और उपयोगकर्ता कहानियों के बीच एक महत्वपूर्ण अंतर यह है कि आवश्यकताओं को विस्तार से निर्दिष्ट किया गया है, कि कुछ सिस्टम घटकों को कैसे व्यवहार करना चाहिए; वे विनिर्देश हैं जिनमें इनपुट, आउटपुट, मान्यताओं / पूर्व-स्थितियां, उठाए गए संभावित अपवाद आदि शामिल हैं। वे इस बात पर ध्यान केंद्रित करते हैं कि सिस्टम क्या करता है।
OTOH, उपयोगकर्ता कहानियां सिस्टम घटकों के लिए एक विस्तृत व्यवहार विनिर्देश बनाने की कोशिश किए बिना अंतिम-उपयोगकर्ता के लिए अपेक्षित परिणाम पर ध्यान केंद्रित करती हैं। वे अपेक्षित उपयोगकर्ता अनुभव पर ध्यान केंद्रित करते हैं ।
मैं जो भी करता था, और यह मेरी टीम द्वारा अपनाई गई एक प्रथा थी, उपयोगकर्ता की कहानियों को कार्यों में तोड़ देना था। आपके कार्य उतने ही विशिष्ट या अस्पष्ट हो सकते हैं जितने कि आप चाहते थे / होने के लिए उनकी आवश्यकता थी, लेकिन वे वास्तविक प्रगति के लिए आपके प्रगति के संकेतक थे जो कहानी को एक किए गए राज्य की ओर ले जाने के लिए किए गए थे।
उदाहरण
मैं मोटे तौर पर एक अमेरिकी को याद करता हूं जो मैंने वर्षों पहले काम किया था जहां उपयोगकर्ताओं को परीक्षण मामलों को स्वयं-असाइन करने की आवश्यकता थी ताकि टीम में हर कोई इस बात से अवगत हो कि वे किस टीसीएस पर काम कर रहे थे ताकि वे नकल किए गए प्रयासों से बच सकें; यूआई एक (एन आंतरिक) वेब अनुप्रयोग था। उपयोगकर्ता ने केवल एक बटन देखा, लेकिन कहानी को कई कार्यों में विभाजित किया गया था जिसमें कुछ तकनीकी कार्यान्वयन विवरण शामिल थे, आदि।
उपयोगकर्ता की दृश्यता
लेकिन एक अन्य प्रकार का अनुप्रयोग है जहां अधिकांश कोड को जटिल प्रसंस्करण से निपटना पड़ता है जो उपयोगकर्ता को सीधे दिखाई नहीं देता है।
क्या किसी तरह से इसे उपयोगकर्ता को दिखाई देना संभव है?
जीपीएस पर विचार करें। जब आप अपनी बारी याद कर लेते हैं, तो आपको वास्तविक मार्ग पुन: गणना प्रक्रिया दिखाई नहीं देगी, लेकिन उपयोगकर्ता को कुछ उपयोगी प्रतिक्रिया (उदाहरण के लिए "पुनर्गणना ...") प्राप्त होती है।
कंपाइलर चेतावनी या त्रुटियों को प्रदर्शित कर सकते हैं, या उपयोगकर्ताओं के लिए GUI में नई सेटिंग्स / विकल्प शामिल करके देख सकते हैं कि कुछ नया जोड़ा गया है। मुझे लगता है कि संकलक के लिए उपयोगकर्ता प्रोग्रामर होंगे, है ना? क्या उन्हें नए मानक के लिए समर्थन नहीं मिला है?
एक नए मानक का समर्थन करते समय संभवतः फीचर स्तर पर होगा और उपयोगकर्ता कहानियों में टूटने की आवश्यकता होगी, क्या आपने सुनिश्चित किया है कि, कम से कम कुछ मामलों में, आप कहानियों का उपयोग करने की कोशिश नहीं कर रहे हैं जब आपको इसके बजाय सुविधाओं का उपयोग करना चाहिए। ?
कार में छवि विश्लेषण को इस तरह से चित्रित किया जा सकता है जिससे उपयोगकर्ता को पता चल सके कि कार दुर्घटना में समाप्त होने की संभावना कम हो गई है। उदाहरण के लिए:
एक सेल्फ-ड्राइविंग कार में एक यात्री के रूप में, मुझे वाहन की संभावना की आवश्यकता होती है, जिससे किसी अपरिचित वस्तु के दुर्घटनाग्रस्त होने की संभावना शून्य के करीब हो सकती है, ताकि मैं अधिक सुरक्षित यात्रा कर सकूं।
यह यूएस एक उच्च-स्तर पर कब्जा कर लेता है, ऐसी चीजें जिन्हें आपको सामान्य रूप से कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं के संयोजन का उपयोग करके निर्दिष्ट करना होगा-सुरक्षा, सुरक्षा, आदि।
हालांकि, एक आवश्यकता प्रणाली के बारे में अधिक हो सकती है; उदाहरण के लिए:
abcघटक में फ़ंक्शन के Aपास सहिष्णुता दहलीज का मूल्य छवि तुलना एल्गोरिदम में कम होना चाहिए ताकि धीरे-धीरे चलती वस्तुओं का बेहतर पता लगाया जा सके।
मेरे लिए, यह आसानी से उपर्युक्त उल्लिखित उपयोगकर्ता कहानी के तहत एक कार्य होगा , जिसका शीर्षक कुछ इस तरह है: फ़ंक्शन में सहनशीलता में कमीA.abc और फिर इसमें अन्य प्रासंगिक विवरण शामिल करें।
फ्लुइड सिमुलेशन सिस्टम के लिए, आपके पास एक प्रगति बार भी हो सकता है जो सिस्टम द्वारा किए जा रहे बैकग्राउंड कार्यों के बारे में फीडबैक प्रदान करता है, अगर यह समझ में आता है। (किसी चीज़ के उपयोगकर्ता को सूचित करने का हमेशा एक तरीका होता है, हालाँकि आप स्पैम होने से बचना चाहते हैं।)
मैं उन विशेष डोमेन के बारे में पर्याप्त नहीं जानता जिनके बारे में आपने बेहतर और / या अधिक यथार्थवादी उदाहरणों के साथ आने का उल्लेख किया है, लेकिन अगर यहां एक टेक-ऑफ है, तो आप कुछ अलग दिखाई देने वाले उपयोगकर्ता फीडबैक प्रदान करने के लिए विभिन्न तरीकों का उपयोग कर सकते हैं सिस्टम हो सकता है, अर्थात अदृश्य चीजों को थोड़ा और दृश्य बनाने के तरीके हो सकते हैं। (यहां तक कि अगर यह रिलीज नोट्स का एक सेट लिखने के लिए उबालता है, जो दस्तावेजों को बताता है कि सिस्टम का प्रदर्शन अब आपके प्रयासों के कारण कितना तेज है, आदि)
कहानियों और कार्यों के बीच संबंध
यहां कार्यों और उपयोगकर्ता कहानियों से संबंधित वास्तव में मुश्किल हो सकती है।
हमारा दृष्टिकोण उपयोगकर्ता कहानियों को इस बात पर ध्यान केंद्रित करने के लिए था कि अनुरोध क्या था, इसे क्यों बनाया गया था, और अमेरिका को "किया" पर विचार करने के लिए किन चीजों को सही होना चाहिए । " कैसे हमेशा अमेरिका के बाहर छोड़ दिया और डेवलपर (ओं) को छोड़ दिया गया था।
डेवलपर उन कार्यों के एक सेट में अमेरिका में वर्णित समस्या को तोड़ देगा, जिन पर वे काम करेंगे।
मैं इसे ऐसे व्यक्ति के रूप में कह रहा हूं, जिसने अधिकांश भाग के लिए, बैक-एंड सर्वर-साइड प्रोग्रामिंग किया, जो संभवतः "अदृश्य" के रूप में है जैसा कि आप अंत-उपयोगकर्ता के लिए प्राप्त कर सकते हैं।
इस पर निर्भर करते हुए कि मुझे क्या करने की आवश्यकता है, मैं कभी-कभी AJAX का उपयोग एक सरल "लोडिंग ..." एनीमेशन / gif दिखाने के लिए करता हूं ताकि उपयोगकर्ता को पता चले कि उन्हें गलत इंप्रेशन प्राप्त किए बिना कुछ और पूरा करने के लिए थोड़ा इंतजार करना होगा। कभी-कभी यह इतना सरल था। इसके लिए एक कार्य उपयुक्त होगा।
विभिन्न प्रतिमान, अभ्यास और अनुभव
क्या इस मुद्दे को दूर करने की तकनीकें हैं या यह केवल कुछ है जिसे हमें स्वीकार करना है और इसे सर्वश्रेष्ठ बनाना है?
प्रतिमान बदलाव को स्वीकार करने से परे, अभ्यास और अर्जित अनुभव, शायद कहने के लिए बहुत अधिक नहीं है। मैंने अक्सर लोगों को प्रक्रिया के माध्यम से शॉर्टकट लेने की कोशिश करते देखा। मैं इसके खिलाफ सलाह दूंगा, खासकर यदि आप शुरू कर रहे हैं। जैसा कि आप अधिक अनुभव प्राप्त करते हैं, आप कुछ लचीलेपन की अनुमति दे सकते हैं, लेकिन खुद को कम आंकने से बचें।
आपके पूर्व के शब्दों को देखते हुए, आप अभी भी कहानियों के बारे में सोच रहे हैं जैसे कि वे "नामांकित आवश्यकताओं" थे, जो मुझे लगता है कि एक गलत धारणा है। मुझे लगता है कि यह एक है लक्षण चंचल और गैर चंचल दृष्टिकोण के बीच मूलभूत अंतर के बारे में एक गहरी जारी होने की।
दूसरे, मुझे लगता है कि आपको स्वीकार करना चाहिए कि फुर्तीली झरने की तुलना में एक प्रतिमान बदलाव है , जिसका अर्थ है कि, जबकि प्रक्रिया में समान लक्ष्य हैं, वे इसके बारे में बहुत अलग तरीके से जाते हैं। (एसवीएन बनाम गिट के बारे में सोचो, अगर वह मदद करता है।)
आवश्यकताओं और उपयोगकर्ता कहानियों के बीच वैचारिक मतभेदों की अपनी वर्तमान समझ में सुधार करने की कोशिश करें और स्वीकार करें कि वे एक ही चीज नहीं हैं।
अपने स्प्रिंट से सीखना - पूर्वव्यापी
जो मैं पर्याप्त तनाव नहीं कर सकता , वह स्प्रिंट मास्टर और डेवलपर्स के बीच प्रत्येक स्प्रिंट के अंत में पूर्वव्यापी है । यही कारण है कि वह जगह है जहां वे चीजें हैं जो "अच्छी तरह से चला गया" या एक ईमानदार / पारदर्शी तरीके से "अच्छी तरह से जाना नहीं था", और क्या चर्चा है साध्य परिवर्तन को संबोधित करने के लिए अगले स्प्रिंट के लिए लागू किया जाएगा "अच्छी तरह से जाना नहीं था" अंक ।
इसने हमें एक-दूसरे के अनुभवों से अनुकूलन करने और यहां तक कि सीखने की अनुमति दी, और इससे पहले कि हम इसे जानते हैं, हमने अपनी टीम के वेग की सामान्य स्थिरता द्वारा मापा के रूप में काफी सुधार किया था।