प्रोसेस टेम्प्लेट
जो लोग पहले से ही अपने काम में टीएफएस का उपयोग करते हैं, वे जानते हैं कि टीम के काम को व्यवस्थित करने के लिए, दो प्रक्रिया टेम्पलेट का उपयोग किया जा सकता है - एमएसएफ एजाइल और एमएसएफ सीएमएमआई। तकनीकी रूप से, ये टेम्प्लेट फ़ाइलों का एक सेट है जो प्रक्रिया कार्य आइटम, दस्तावेज़, रिपोर्ट, सुरक्षा सेटिंग्स और इसी तरह का वर्णन करते हैं। इसके अलावा, TFS आपको इन टेम्प्लेट को अनुकूलित करने की अनुमति देता है, उन्हें कुछ गुणों के साथ पूरक करता है जो इस कमांड के लिए विशिष्ट हैं। इस तरह के संशोधनों को विज़ुअल स्टूडियो पावर टूल्स का उपयोग करके आसानी से किया जाता है। बाजार में समुदाय और वाणिज्यिक कंपनियों द्वारा विकसित कई अतिरिक्त प्रक्रिया टेम्पलेट हैं।
स्क्रेम प्रोसेस टेम्प्लेट
यह टेम्प्लेट Microsoft विशेषज्ञों द्वारा Scrum.Org के विशेषज्ञों की प्रत्यक्ष भागीदारी के साथ विकसित किया गया था। मानक एमएसएफ एजाइल और एमएसएफ सीएमएमआई की तरह, इसमें मुख्य रूप से कार्य आइटम का एक सेट होता है जो टीम के काम को व्यवस्थित करने के लिए डिज़ाइन किया जाता है:
Productuct बैकलॉग आइटम (PBI): संपूर्ण सॉफ़्टवेयर उत्पाद के लिए ट्रैक आवश्यकताएँ।
बग: विकास के दौरान एक बग मिला। यह ध्यान दिया जाना चाहिए कि उत्पाद बैकलॉग आइटम और बग लागत अनुमानों और योजना के संदर्भ में आवश्यकताओं की सूची के लगभग बराबर तत्व हैं। इसलिए खेतों के लगभग समान सेट। एक छोटी सी टिप्पणी। एमएसएफ एजाइल और एमएसएफ सीएमएमआई टेम्पलेट्स के विपरीत, टीएफएस एक गलत निर्माण के आधार पर बग नहीं बनाता है।
कार्य: कार्य। यह आइटम आपको उत्पाद बैकलॉग आइटम के लिए आवश्यक स्तर का विवरण दर्ज करने की अनुमति देता है। स्वाभाविक रूप से, कार्यों को स्वयं उप-मुखौटे में विभाजित किया जा सकता है।
स्प्रिंट: यह कार्य आइटम स्प्रिंट तिथियों, लक्ष्यों, और पूर्वव्यापी को पकड़ता है। स्प्रिंट को एक अलग कार्य आइटम में अलग करना MSF एजाइल और MSF CMMI टेम्पलेट से स्क्रैम टेम्पलेट को अलग करता है। उनमें, स्प्रिंट को केवल पुनरावृत्ति पदानुक्रम के तंत्र द्वारा इंगित किया जाता है, लेकिन दुर्भाग्य से इसका उपयोग करके स्प्रिंट की शुरुआत और समाप्ति तिथियों को इंगित करना संभव नहीं है।
प्रभाव: समस्याएं, जोखिम और वे सभी जो टीम के काम को प्रभावित कर सकते हैं, लेकिन सीधे विकसित उत्पाद के गुणों से संबंधित नहीं हैं।
टेस्ट केस: पीबीआई के लिए परीक्षण का विवरण। आमतौर पर, परीक्षण सीधे एक विशिष्ट PBI से जुड़े होते हैं। यह कार्य आइटम (अन्य साझा चरणों में) सीधे स्क्रैम में परिभाषित नहीं किया गया है, लेकिन टीएफएस बुनियादी ढांचे के लिए सही ढंग से काम करना आवश्यक है।
साझा किए गए चरण: कई टेस्ट केस के बीच साझा किए गए परीक्षण चरण।
काम का संगठन
वास्तव में इस प्रक्रिया को स्क्रेम मैनुअल में अच्छी तरह से वर्णित किया गया है और नीचे दिए गए चरणों का एक बहुत ही संक्षिप्त उदाहरण है:
1) एक परियोजना टीम बनाई गई है, और न्यूनतम आवश्यक दस्तावेज तैयार किए गए हैं (विजन, स्कोप)
2) एक प्राथमिक पीबीआई सूची उत्पन्न होती है और जहां संभव हो, प्राथमिकताएं सौंपी जाती हैं। एक नियम के रूप में, एनालिटिक्स का यह चरण लंबा नहीं है।
3) प्रारंभिक PBI सूची के आधार पर, प्लानिंग पोकर का उपयोग करके पहला मूल्यांकन (एफ़ोर्ट फील्ड) किया जाता है। यह मत भूलो कि ये अमूर्त इकाइयां हैं, हालांकि आप घंटों में योजना बना सकते हैं।
एक। वे PBI जो स्पष्ट नहीं हैं (अनन्तता के स्तर का मूल्यांकन या बहुत अधिक लागत) अतिरिक्त विश्लेषण के लिए भेजे जाते हैं।
4) पहला स्प्रिंट उत्पाद बैकलॉग के पूर्ण सेट से PBI की प्राथमिकताओं और महत्व के आधार पर बनता है, और यह पहले से ही स्पष्ट है कि इसे कैसे लागू किया जाए।
5) पीबीआई जो स्प्रिंट में मिला है, डेवलपर्स द्वारा टास्क लेवल (टास्क) में विस्तृत किया गया है जहां आवश्यक है। यहां आप समय दर्ज कर सकते हैं। कार्य में एक शेष कार्य क्षेत्र है।
एक। दो या तीन स्प्रिंट के बाद, आप पहले से ही लागतों में विशिष्टता की उम्मीद कर सकते हैं और योजना क्षितिज को स्पष्ट कर सकते हैं।
6) निर्दिष्ट परीक्षण मामले के आधार पर कमिटेड राज्य में PBI की जाँच की जाती है।
7) अनिवार्य रूप से होने वाली त्रुटियों को बग का उपयोग करके तय किया जाना चाहिए, जो उत्पाद बैकलॉग में भी आते हैं।
8) पूर्ण स्थिति के साथ PBI के करीब पूर्ण
9) अगले स्प्रिंट की योजना बनाई गई है, प्रक्रिया पीपी के साथ दोहराती है। 5।
उत्पाद बैकलॉग और स्प्रिंट में PBI / कीड़े / टास्क सूचियों के साथ छेड़छाड़ मानक क्वेरी का उपयोग करके की जाती है जो पहले से ही स्प्रिंट 1 के लिए टेम्पलेट में परिभाषित हैं।
तदनुसार, पहले स्प्रिंट के अंत के बाद, आपको वर्तमान स्प्रिंट के लिए "स्प्रिंट बैकलॉग" अनुरोध को बदलना नहीं भूलना चाहिए:
स्क्रेम वर्क आइटम स्टेट्स
MSF फुर्तीली और MSF CMMI टेम्प्लेट पहले से स्थापित TFS ARC दृष्टिकोण (Active-> हल-> बंद) का उपयोग करते हैं जो स्क्रम शर्तों के अनुरूप नहीं है।
- यह टेम्पलेट अन्य राज्य नामों का उपयोग करता है:
- PBI, बग: नया-> स्वीकृत-> प्रतिबद्ध-> संपन्न
- कार्य: करने के लिए- प्रगति में-> हो गया
- प्रतिबाधा: खुला-> बंद
मुझे याद दिलाएं कि आप MSDN वेबसाइट पर और अधिक विस्तार से सभी वर्क आइटम के वर्कफ़्लो के साथ खुद को परिचित कर सकते हैं, और टीम फाउंडेशन सर्वर वेब एसेस और प्रोसेस एडिटर का उपयोग कर सकते हैं।
उदाहरण के लिए, मैं बग वर्क आइटम (जो कि सबसे अधिक जटिल है) के विक्रम प्रवाह संपादक से स्क्रीनशॉट लेता हूं:
घोटाले की रिपोर्ट
स्वाभाविक रूप से, लगभग सभी फ़ील्ड जो स्कैम वर्क आइटम में परिभाषित किए गए हैं, टीम फाउंडेशन सर्वर एनालिटिक्स सिस्टम में आते हैं और आपको कई महत्वपूर्ण रिपोर्ट बनाने की अनुमति देते हैं, जो बाद में यह समझना संभव बनाते हैं कि परियोजना पर चीजें कैसे चल रही हैं।
स्प्रिंट / रिलीज़ बरंडाउन - दो रिपोर्ट जो परियोजना और शेष पर शेष काम की मात्रा का आकलन करने का अवसर प्रदान करती हैं।
रिलीज बरंडाउन: स्प्रिंट से स्प्रिंट तक, एफर्ट इकाइयों में अनुमानित कार्यों की कुल मात्रा घटनी चाहिए। अप्रत्यक्ष रूप से इस ग्राफ के माध्यम से, आप टीम के प्रदर्शन का मूल्यांकन भी कर सकते हैं।
स्प्रिंट बरंडाउन: हर दिन, टीम स्प्रिंट के हिस्से के रूप में कई PBI को बंद कर देती है।
वेग रिपोर्ट: प्रत्येक स्प्रिंट पर खर्च किए गए प्रयास। यह रिपोर्ट रिलीज़ बर्नडाउन के साथ प्रतिध्वनित होती है। ग्राफ स्प्रिंट में टीम के प्रदर्शन का औसत आंकड़ा (35) भी दिखाता है। आदर्श रूप से (और एक अजेय टीम के लिए), जितने अधिक स्प्रिंट थे, यह आंकड़ा उतना ही सटीक था, और अधिक सटीक रूप से एक परियोजना की अंतिम तिथि की भविष्यवाणी कर सकता है।
समय के साथ सफलता का निर्माण, सारांश रिपोर्ट बनाएँ: मंच और परीक्षण द्वारा परियोजना विधानसभाओं की स्थिति दिखाएँ। आपको प्रगति, परिवर्तन की सीमा को समझने और उत्पाद की गुणवत्ता का मूल्यांकन करने की अनुमति देता है।
उत्पाद की गुणवत्ता की सामान्य स्थिति का आकलन करने के लिए, साथ ही परीक्षणों से संबंधित संगठनात्मक मुद्दों को हल करने के लिए परीक्षण रिपोर्ट तैयार की जाती है। इन रिपोर्टों में प्रस्तुत जानकारी के आधार पर, आप समझ सकते हैं कि तारीख से तारीख तक कितने परीक्षण सही परिणाम के साथ, कितने गलत परिणाम के साथ, कितने अभी तक लॉन्च नहीं हुए हैं, और कितने परीक्षण अवरुद्ध हैं।
टेस्ट केस रेडीनेस रिपोर्ट आपको परीक्षणों के साथ काम को व्यवस्थित करने की अनुमति देती है, जिसमें दिखाया गया है कि कितने परीक्षण निष्पादन के लिए तैयार हैं और कितने अभी भी विवरण के चरण में हैं। आदर्श रूप में, इस रिपोर्ट को इस तरह एक चित्र बनाना चाहिए:
निष्कर्ष
स्क्रम प्रक्रिया टेम्पलेट टीम फाउंडेशन सर्वर के लिए सबसे सरल प्रक्रिया टेम्पलेट्स में से एक है, जो फिर भी आपको टीम वर्क के आयोजन के बुनियादी मुद्दों को हल करने की अनुमति देता है। इसके अलावा, स्क्रैम का लेकोनिज़्म आपको नई या मौजूदा टीमों में इस दृष्टिकोण को जल्दी से लागू करने की अनुमति देता है और काफी कम समय में एक दृश्य परिणाम प्राप्त करता है। जो, मैं विश्वास करना चाहता हूं, बेहतर सॉफ्टवेयर और सटीक योजना के विकास में शामिल होगा।