चुस्त, टीएफएस ऑनलाइन जैसे सख्त प्रबंधन ढांचे का उपयोग करके योजनाबद्ध और आवंटित किए गए प्रोजेक्ट की शुरुआत में बुनियादी ढांचे के कार्य कैसे होते हैं?

Question

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

जब मैं काम की योजना देख रहा था, मुझे लगा कि वहाँ कुछ गायब है। बस चीजों को स्थापित करने में प्रारंभिक परिव्यय होने वाला है जिसमें हम कार्यक्षमता को बढ़ा सकते हैं। चीजें जो सभी उपयोगकर्ता कहानियों की हैं, न कि किसी विशेष उपयोगकर्ता की कहानी की।

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

इस विशेष एप्लिकेशन से एक और प्रासंगिक उदाहरण खराब विरासत कोड के एक ब्लॉक को फिर से लिखना और लेना है जो इस ऐप के कार्यों के लिए उपयोगी है। फिर, यह उपयोगकर्ता के लिए कोई तत्काल परिणाम नहीं है, लेकिन यह आवश्यक काम है। उपयोगकर्ता कहानियों पर केंद्रित एक परियोजना योजना में इस काम की योजना "लाइव" कहां है?

मैंने देखा है कि लोग इसे "एक डेवलपर के रूप में, मैं चाहता हूं ..." लिखकर लोगों को हल कर रहा हूं, लेकिन जैसा कि कहीं और चर्चा की गई है यह एक उपयोगकर्ता कहानी नहीं है । यह एक डेवलपर है।

मैं टीएफएस ऑनलाइन जैसे सख्त प्रबंधन ढांचे का उपयोग करके मुझे (और अन्य) योजनाओं की योजना बनाने में मदद करने के लिए, इसका एक ठोस जवाब मांग रहा हूं। ये "हितधारक कहानियां" या अन्य अस्पष्ट मेटा-समाधान बनाने के लिए फ़ंक्शन का जवाब नहीं देते हैं, जो योजना बैठक में बुनियादी कार्यों के लिए एक स्क्रैम टीम कैसे खाता है?

Comments

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

— रॉबर्ट हार्वे

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

— mmathis

@ मैमथिस मैंने उस प्रश्न को देखा, और यह समान और प्रासंगिक है। हालाँकि, वास्तव में कोई भी उत्तर इस प्रश्न का उत्तर नहीं देता है। विशेष रूप से तब, जब आप टीएफएस जैसे मौजूदा ढांचे के भीतर इसे करने के तरीके पर ध्यान केंद्रित करते हैं।

— बॉब तेव

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

— बॉब तिवारी

आप सिस्टम उपयोगकर्ताओं को धोखा दे सकते हैं, और iteration0, या आप केक को अलग तरह से काट सकते हैं। पहला फ़ीचर कुछ यूज़र फंक्शनलिटी देता है और इसे काम करने के लिए जो इन्फ्रास्ट्रक्चर चाहिए होता है। फिर सुविधा 2 जिसके परिणामस्वरूप कुछ और बुनियादी ढाँचे सामने आते हैं, इस तरह से आप बुनियादी ढांचे की स्थापना के लिए समय बर्बाद नहीं करते हैं जिसकी आपको आवश्यकता नहीं है। यदि आप अब चिल्ला रहे हैं, लेकिन इसका मतलब है कि मुझे फिर से योजना बनाने की आवश्यकता है, तो आप चुस्त नहीं हैं।

— ctrl-alt-delor

Answer 1

मैं अन्य उत्तरों को पसंद करता हूं जो कहते हैं कि आप "टूलिंग" कोड को Iteration 0. में डाल सकते हैं। हालाँकि, कभी-कभी, इस प्रकार के उपकरण प्रोजेक्ट शुरू होने के बाद सामने आते हैं। शायद Iteration 3 में आपको एहसास होता है कि आगे जाने वाली विभिन्न कहानियों पर एक सामान्यीकृत XML पार्सर विजेट का उपयोग किया जाना चाहिए।

उस मामले में, पहली आंतरिक कहानी जो इन आंतरिक वास्तुशिल्प टुकड़ों पर निर्भर करती है, वह वह है जिससे वे संबंधित हैं । यदि आप कहानी # 345 पर काम करने वाले हैं, और यह आपके XML पार्सर पर निर्भर करेगा, इससे पहले कि इसे 'किया' के रूप में गिना जा सके, तो उस कहानी को पूरा करने के लिए आपके पुन: प्रयोज्य पार्सर को कार्य के रूप में संलग्न किया जाएगा।

मेरी टीम ने उपरोक्त दृष्टिकोण का उपयोग किया है और यह हमारे लिए ठीक काम कर रहा है।

Comments

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

— जे एस

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

— रोबी डी

Answer 2

यदि यह बुनियादी ढाँचा है तो इसे आमतौर पर Iteration Zero में डाल दिया जाता है। Iteration शून्य क्या है? यह आम तौर पर वास्तविक पुनरावृत्तियों शुरू होने से पहले किकऑफ और नियोजन के बीच का समय है।

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

इसलिए, यह कार्य पुनरावृति में किया जाएगा। 1 पुनरावृत्ति शुरू होने तक, पहले से ही एक नया प्रोजेक्ट शेल होगा जो एक संकलन बिल्ड स्क्रिप्ट होगा, और तैनात करेगा। अब, उपयोगकर्ता की कोई भी कार्यक्षमता नहीं होगी, लेकिन यह जाने के लिए तैयार है।

मैं अब भी इस काम को ट्रैक करूंगा और इसे 0 काम के हिस्से के रूप में प्लान करूंगा।

रिफैक्टिंग एक तकनीकी कहानी की तरह लगती है जो किसी भी यात्रा में जा सकती है।

Comments

+1 क्योंकि हम इसका भी उपयोग करते हैं, लेकिन वास्तव में इंटरएक्शन ज़ीरो नया Iteration One है। यह सिर्फ एक पुनरावृत्ति है कि व्यापार हितधारक वास्तव में परवाह नहीं करता है, लेकिन हितधारक की परवाह करने वाली चीजों को प्राप्त करना आवश्यक है।

— ग्रेग बरगद्ट

आपके पास 0 से अधिक की बोली हो सकती है, लेकिन यह नहीं कहा जा सकता है कि आप दिन से मूल्य वितरित करना शुरू नहीं कर सकते। 1. आपको कोड काटने के लिए एक बिल्ड सर्वर, स्वचालित तैनाती और स्रोत कोड भंडार की आवश्यकता नहीं है - यह बाद में हो सकता है (या समांतर में भी)।

— रोबी डे

Answer 3

आधारभूत संरचना पर निर्भर करता है।

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

यदि बुनियादी ढांचा आपकी टीम द्वारा प्रबंधित किया जा रहा है, और केवल एक बार सेट अप किया जाता है, तो आप पुनरावृति 0 तकनीक का उपयोग कर सकते हैं जो जॉन द्वारा वर्णित है।

यदि अवसंरचना का सेटअप कई पुनरावृत्तियों को ले जाएगा (जैसे कि शायद आप अपने बिल्ड सर्वर को अभी सेट करते हैं, लेकिन क्यूए और प्रीप्रोड सर्वर को थोड़ी देर बाद बनाया जाएगा) तो उनके बिल्डआउट को अप्रभावी PBI के रूप में प्रबंधित किया जा सकता है। कार्यात्मक PBI में इन पर कुछ निर्भरताएँ हो सकती हैं, जिन्हें आप "पूर्ववर्ती" लिंक का उपयोग करके TFS में संहिताबद्ध कर सकते हैं।

और निश्चित रूप से आप उपरोक्त सभी को मिला सकते हैं और मेल कर सकते हैं। उदाहरण के लिए, आप एक निरंतर बिल्ड सर्वर के बिना बहुत कुछ नहीं कर सकते हैं, इसलिए आप इसे पुनरावृत्ति में डाल सकते हैं। इस बीच आपके प्रीप्रोड सर्वर को पुनरावृत्तियों 2 और 3 के कार्यों के रूप में परिभाषित किया जा सकता है, और वे आपके डीबीए टीम पर बाहरी निर्भरता हो सकते हैं ( जो फुर्तीले नहीं हैं) जो आपके डेटा सेंटर में आपको DB इंस्टेंसेस आवंटित करेंगे। या हो सकता है कि आपको कुछ खास फीचर्स के लिए एसएसएल सीट्स जारी होने का इंतजार करना पड़े; वे पुनरावृत्ति 4 में जा सकते हैं, और कोई भी कार्यात्मक वस्तु जो उन सेर्ट्स पर भरोसा करती है, उन्हें पूर्ववर्ती / उत्तराधिकारी संबंध से जोड़ा जाना चाहिए।

सभी मामलों में, याद रखें:

1. हमेशा स्पष्ट स्वीकृति मानदंड को परिभाषित करें। हार्डवेयर लोगों में एक सर्वर को खड़ा करने और इसे कॉल करने की प्रवृत्ति होती है जब इसे बिल्कुल भी मान्य नहीं किया जाता है।
2. आपकी टीम के पुनरावृत्ति किकऑफ़ के दौरान, टीम को किसी भी PBI या कार्य आइटम के लिए निर्भरता और उनकी उपलब्धता की जांच करने की आवश्यकता होगी।

Comments

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

— रोबी डी