हम विकास के लिए एक स्क्रम प्रक्रिया का उपयोग शुरू कर रहे हैं। हमारे पास अब उपयोगकर्ता कहानियों का अच्छा ढेर है। मैं सोच रहा हूं कि, एक बार जब उपयोगकर्ता की कहानी पूरी हो जाती है, परीक्षण और तैनात किया जाता है तो क्या आप इसके साथ कुछ और करते हैं? हम अभी छोटे सूचकांक कार्ड का उपयोग कर रहे हैं, मुझे लगता है कि उन्हें कूड़ेदान में टॉस करना ठीक होगा।पूर्ण उपयोगकर्ता कहानियां - त्यागें? पुरालेख?
यदि आप उन्हें रखते हैं, तो आप बाद में उनके साथ क्या करते हैं?
भविष्य की परियोजनाओं पर संदर्भ के लिए उन्हें संग्रहीत करें। जब आप कहानी बिंदुओं का अनुमान लगाना चाहते हैं तो वे उपयोगी होंगे। अक्सर कई बार, परियोजनाओं में समान ध्वनि कहानियां होती हैं।
कचरा एक उचित जगह की तरह लग सकता है।
उन्हें रखें (उन्हें संग्रहित करें) ताकि भविष्य में किसी चीज़ पर कोई विवाद या तर्क हो, तो आपके पास इसका संदर्भ है, और स्वयं को कवर कर सकता है।
विवाद? मैं कहूंगा कि यदि सिस्टम पीओ की तरह काम नहीं करता है तो यह चाहता है कि यह एक नई उपयोगकर्ता कहानी लिखने का समय हो (या शायद यह एक बग फाइल करें यदि यह ऐसा है)। एक स्वीकृत उपयोगकर्ता स्टोरी कार्ड पर जो लिखा गया है वह सिर्फ अप्रासंगिक है। – PEZ
किसी भी चुस्त प्रक्रिया के लिए सटीक विपरीत दर्शन की तरह लगता है। आप सुनिश्चित हैं कि आप झरना प्रक्रिया से आवश्यकताओं के दस्तावेजों के बारे में बात नहीं कर रहे हैं? – madlep
मैं कहूंगा कि यह परिदृश्य में यथार्थवादी है जहां आप पागल-झरने वाली कंपनी के लिए चुस्त हो रहे हैं और किसी भी परेशानी की समस्याओं को हल करने में मदद के लिए। – Donnelle
पीईजेड लगभग सही है। उन्हें कचरे के बजाय कार्ड रीसायकल करें। :)
वास्तव में उन्हें रखने में कोई बात नहीं है। यदि आपको परिवर्तनों के इतिहास की आवश्यकता है तो आप इसे अपने एससीएम और टेस्ट स्क्रिप्ट से प्राप्त कर सकते हैं।
उम - उन्हें रखें और उन्हें प्रोजेक्ट फ़ाइल में रखें। सभी मामलों में सीवाईए। आप कभी नहीं जानते कि कोई ग्राहक वापस कब आएगा और आपको पूछेगा "यह इस तरह क्यों है?", या "किसने फैसला किया कि यह कैसा था?"। फिर आप उपयोगकर्ता की कहानी खींच सकते हैं और बैकअप ले सकते हैं।
हमेशा इस तरह की सब कुछ तब तक रखें जब तक वारंटी अवधि आपके सॉफ़्टवेयर पर समाप्त नहीं हो जाती ... जब तक कि आप उस स्थिति में नहीं रहना चाहते जहां आपको वास्तव में कुछ बदलाव करने के लिए कहा जा सकता है।
उन्हें रखने के लिए एक और वोट। मुझे पता है कि यह एक गंदे शब्द है, लेकिन उपयोगकर्ता कहानियां आपके प्रलेखन का हिस्सा हैं, और एक महत्वपूर्ण उद्देश्य प्रदान करते हैं।
अब से तीन साल जब आप (या उत्तराधिकारी) सिस्टम में परिवर्तन कर रहे हैं, तो ऐतिहासिक दस्तावेजों को यह जानने में मदद मिलती है कि आपने काम करने के तरीके क्यों किए।
स्थिति में बदलाव होने पर यह भी मदद करता है और आपको उपयोगकर्ता की कहानियों पर वापस जाने में सक्षम होने के लिए फिर से लिखना होगा कि एप्लिकेशन संतुष्ट करता है और निर्धारित करता है कि वही कहानियां नए संस्करण पर लागू होती हैं या नहीं।
पूर्ण उपयोगकर्ता कहानियां अनिवार्य रूप से आपके प्रोजेक्ट के लिए अंतिम विनिर्देश हैं। यदि आपने औपचारिक आवश्यकता दस्तावेज या विनिर्देश के साथ शुरुआत की है, तो उस दस्तावेज़ के साथ अपनी पूर्ण उपयोगकर्ता कहानियों की तुलना करके सीखने के लिए कई सबक हैं। यदि आपके पास प्रारंभिक दस्तावेज़ नहीं है, तो आपकी पूर्ण उपयोगकर्ता कहानियां आपके प्रोजेक्ट की कार्यक्षमता को दस्तावेज करती हैं। किसी भी मामले में, मुझे लगता है कि भविष्य के संदर्भ के लिए उन पर लटका देना बहुत महत्वपूर्ण है, चाहे परियोजना पोस्ट-मॉर्टम में या बाद की परियोजनाओं का आकलन और योजना बनाते समय।
मुझे लगता है कि हम कभी नहीं जानते कि भविष्य में क्या उपयोगी होगा, इसलिए मेरी सिफारिश उन्हें टैग करना और उन्हें फाइल करना है। यदि आप भौतिक कार्ड का उपयोग कर रहे हैं, तो उन्हें स्कैन करें, फिर छवि फ़ाइल में टैग जोड़ने के समान कुछ आसान करें। सामान्य थ्रेड ढूंढने के लिए या अपनी सामग्री का पता लगाने और पुनः उपयोग करने के लिए बाद में टैग क्लाउड को देखकर कल्पना करें।
सभी चीजों के साथ स्क्रम, हालांकि, अगर यह बहुत अधिक समय लेना शुरू कर देता है, तो शायद यह आपके प्रयास के लायक नहीं है। इसे पागल प्रक्रिया न बनाएं, बस इसे जल्दी से फ़ाइल करें और इसे भूल जाएं।
चीयर्स, रीव्स
मैं आमतौर पर एक रबर बैंड और सामने एक नया कार्ड वेग और अनुमानित अंक बताते हुए में उपयोगकर्ता कथाएँ (और कार्यों) की कीमत प्रत्येक पुनरावृत्तियों लपेट दें। हालांकि, मैंने कभी भी उनके लिए कोई उपयोग नहीं किया है, जबकि नॉस्टलजिक रीसाइजिंग को छोड़कर। तो उन्हें संग्रह के लिए रखें जो मैं कहूंगा: -9
उन पर रुको!
मैं आवश्यकताएं लिखता हूं (कोड के बजाए), लेकिन मुझे अक्सर पुरानी उपयोगकर्ता कहानियां और स्वीकृति परीक्षण (मेरा और अन्य ') पढ़ना पड़ता है।
पुरानी कहानियों की समीक्षा करना मुझे पहिया को पुनर्निर्मित करने के बजाय जटिल अवधारणाओं के लिए स्पष्ट वाक्यांश खोजने में मदद कर सकता है। वे कभी-कभी विवरण के लिए एक उपयोगी अनुस्मारक के रूप में कार्य करते हैं जो मैं अन्यथा दस्तावेज़ को भूल सकता हूं। दूसरों द्वारा लिखी गई कहानियां मुझे उन सुविधाओं पर तेज़ी से आने में मदद करती हैं जिनमें मैं शामिल नहीं था, और शायद नए कर्मचारियों के लिए एक अच्छा सीखने वाला टूल होगा।
मैं आगे बढ़ सकता हूं, लेकिन मुझे इसे इस तरह से रखने दें:
कहानियों को रखने और उन्हें जरूरी नहीं, या कहानियों की आवश्यकता है और उन्हें नहीं होने की अधिक संभावनाएं हैं?
अनुभव और कर्मियों के परिवर्तन के साथ एक टीम का वेग बदलता है। पुराने अनुमान वास्तव में उपयोगी नहीं हैं। – ewalshe
मेरा उत्तर अपेक्षाकृत स्थिर टीम के संदर्भ में है। – moffdub
+1: अनुभव-आधारित अनुमान। यह आपका बेसलाइन डेटा है। लागू करने के लिए मूल कहानी और अंतिम लागत। –