उपयोगकर्ता की कहानियां और आवश्यक चीज़ों पर बहुत सी बातचीत और क्या फ्लाफ है।
बहुत सी बातचीत।
आर्किटेक्चर पर बहुत पीछे और पीछे भी। स्क्रम के लिए एक स्थिर, सिद्ध वास्तुकला की आवश्यकता होती है। हालांकि, हमेशा उन्नयन और संवर्द्धन होते हैं। बैकलॉग के साथ फिट कैसे होते हैं? उत्पाद मालिक, प्रौद्योगिकी लोगों और (कुछ हद तक) उपयोगकर्ताओं/खरीदारों के बीच यह बहुत राजनीतिक जॉकी है।
निहित रूप से गैर-रैखिक प्रक्रिया।
यह क्रिस्टलाइजेशन की तरह है। आपके पास समाधान है, आप कहानियां लिखना शुरू करते हैं, आपके पास एक तकनीकी दृष्टि है, आपके पास कुछ कौशल और अनुभव के साथ एक टीम है।
इनमें से कोई भी विशेषता बैकलॉग में क्या है और किस क्रम में निर्णय लेने के लिए "न्यूक्लियस" के रूप में कार्य कर सकती है। आखिरकार, कुछ न्यूक्लियस बन जाता है और मिश्रण क्रिस्टलाइज होता है। कभी-कभी लागत या अनुसूची या जोखिम अस्वीकार्य होते हैं, इसलिए आप इसे वापस गर्म करते हैं, एक और नाभिक पाते हैं और देखते हैं कि यह उस नए नाभिक के आसपास स्वीकार्य रूप से क्रिस्टलाइज करता है या नहीं।
प्रत्येक स्प्रिंट के बाद पुनरावृत्ति होती है, वैसे भी, इसे कम रैखिक बनाते हैं।
संपादित करें। "स्थिर साबित वास्तुकला"।
प्रश्न: नया आर्किटेक्चर सीखने के लिए कौन भुगतान करता है?
उत्तर: हा हा। कोई अच्छा जवाब नहीं है। इसलिए सावधान रहें कि आपके पास विकास की दौड़ चलने के दौरान आप कितनी वास्तुकला सीख रहे हैं।
यदि आपके पास एक आर्किटेक्चर नहीं है जो (ए) काम करता है, और (बी) टीम पर लगभग सभी लोगों द्वारा व्यक्त किया जा सकता है, तो आप उस वास्तुकला को इकट्ठा करने में समय बिताने जा रहे हैं।
आर्किटेक्चर बनाने का समय और लागत आपके पहले स्प्रिंट में क्या करती है?
आपको पहली स्प्रिंट में आर्किटेक्चर विकास को शामिल करना होगा, चीजों में देरी होगी।
मान लें कि आप एक लैंप स्टैक को लागू करने का निर्णय लेते हैं। आप नहीं जानते कि PHP, पर्ल या पायथन को यूनिक्स करना है या नहीं। तो आप एक चुनते हैं। पायथन की तरह। और आप चार सप्ताह में पहली स्प्रिंट का वादा करते हैं। तो आप kabillion add-one मॉड्यूल और ढांचे के साथ संघर्ष में 3 सप्ताह तक काम करते हैं। 3 सप्ताह के बाद, आपको लगता है कि आपके पास एक तकनीकी तकनीक ढेर है, लेकिन आपके पास वादा किया गया स्प्रिंट नहीं है।
क्या आप देरी करते हैं?यदि ऐसा है, तो हर कोई पूछता है कि क्या आपको गति तेज है और अन्य सभी स्पिंट्स के लिए समय दोगुनी हो जाती है।
क्या आप कुछ भी नहीं देते? यदि हां, तो अगर आपके पास बुनियादी ढांचे को छोड़कर अंत में कुछ भी नहीं है तो स्पिंट्स का क्या मतलब है?
आप प्रबंधनीय टुकड़ों में बुनियादी ढांचे को बदल सकते हैं, संशोधित और बढ़ा सकते हैं। लेकिन एक ताजा वास्तुकला बनाने के लिए, टुकड़ों को साबित करें, हर किसी को प्रशिक्षित करें और सर्वोत्तम प्रथाओं को विकसित करने में समय लगता है। बहुत ज़्यादा उसका। और उस समय नहीं - वास्तव में - वितरित उत्पाद बनाने के स्प्रिंट समय के रूप में चार्ज किया जाना चाहिए। वह ओवरहेड टाइम है।
संपादित करें। टूलींग।
नियम 1. Agile प्रक्रियाएं कई जटिल उपकरण और प्रक्रियाओं का उपयोग नहीं करती हैं। यही कारण है कि मैंने कहा कि प्रक्रिया बहुत "वार्ता" है। जो भी आपको उत्पादक बनाता है।
नियम 2. इसे सोचने पर मत सोचो। बस कर दो।
अधिकांश लोग कहते हैं - सबसे मजबूत संभव तरीके से - 5 "x8" पेपर कार्ड का उपयोग करें और उन्हें दीवार पर चिपकाएं। गंभीरता से। कोई उपकरण नहीं बस साधारण पेपर, मार्कर, टेप और खाली दीवार की जगह।
इस पढ़ें: http://www.agilemodeling.com/artifacts/userStory.htm
आप उपयोगकर्ता कथाएँ (और महाकाव्यों - कहानियां हैं कि विघटित किया जा करने के लिए) को इकट्ठा करने के लिए स्प्रेडशीट का उपयोग कर सकते हैं। आप जटिलता (कहानी बिंदु), लागत, प्राथमिकता और रिलीज के लिए कॉलम जोड़ सकते हैं, और परियोजना प्रबंधन के लिए इसका उपयोग कर सकते हैं।
हम उपयोग के मामलों (उपयोगकर्ता कहानियों नहीं) का उपयोग करते हैं लेकिन टूलींग एक जैसी है। एक उपयोग का मामला है - एक तरह से - सामने की जानकारी के साथ एक उपयोगकर्ता कहानी। लेकिन उपयोग केस का नाम सारांशित कर सकता है कि एक अभिनेता एक प्रणाली के साथ कैसे बातचीत करता है; बातचीत को आमतौर पर स्पष्ट, सरल संज्ञाओं और क्रिया के साथ संक्षेप में सारांशित किया जा सकता है, जो उपयोगकर्ता की कहानी की तरह बहुत अधिक है।
स्प्रेडशीट आसान लगती है क्योंकि आप प्रत्येक स्प्रिंट के अंत में पंक्तियों को पुनर्व्यवस्थित कर सकते हैं। आप यह सुनिश्चित करने के लिए सरल गणना और रकम कर सकते हैं कि प्रत्येक सुविधा का कितना खर्च आएगा और जब वे आएंगे।
मैं स्प्रेडशीट का उपयोग नहीं करता क्योंकि - जीयूआई ग्लिट्जनेस के बावजूद - मुझे थोड़ा सा बोझिल लगता है। मुझे एक स्प्रेडशीट निकालने वाला लिखना आवश्यक लगेगा जो बैकॉग को ओपन ऑफिस ऑर्ग फ़ाइल से रीस्ट्रक्चरर्डटेक्स्ट (आरएसटी) में बदल देगा। मैं आरएसटी - सादा पाठ मार्कअप पसंद करता हूं - स्प्रेडशीट्स पर।
यह सभी लंबी बातचीत है। हर बातचीत के परिणामस्वरूप सब कुछ बदल जाता है। यह एक Agile विधि का मुद्दा है। त्वरित स्प्रिंट अगले स्प्रिंट की दिशा में वार्ता के बाद।
हमारा बैकलॉग एक बड़ा आरएसटी दस्तावेज़ है। हम Sphinx का उपयोग करके हमारे सभी दस्तावेज प्रकाशित करते हैं और आरएसटी मार्कअप में बैकलॉग लिखने, मामलों, वास्तुकला, डिजाइन इत्यादि का उपयोग करना बहुत आसान है।
हमारे स्पिंट्स केवल एक बड़े दस्तावेज़ पेड़ के अनुभाग हैं। वे अनुमानित समापन तिथि, और स्थिति (प्रक्रिया में, जारी) जैसी व्यक्तिपरक चीजों के लिए कुछ विशेष उद्देश्य के व्याख्या किए गए टेक्स्ट फ़ील्ड से सजाए गए हैं।
मैं इस प्रश्न को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह प्रोग्रामिंग के बारे में नहीं है। –