टीम फाउंडेशन सर्वर, किसी भी परिष्कृत उपकरण की तरह, कुछ संगठनात्मक संचालन दृष्टिकोण की आवश्यकता है। इसके अलावा, यह टीम के लिए पसंद की स्वतंत्रता प्रदान करने के लिए बनाया गया था, या, जैसा कि ब्रायन हैरी ने अपने एक नोट में, "आपकी प्रक्रिया, हमारी प्रक्रिया, या कोई प्रक्रिया नहीं" पेश करने के लिए किया था। भाग में, यह स्वतंत्रता एक बुरा मजाक खेल सकती है जब यह टीम को लगता है कि टीएफएस का उपयोग केवल अपनी क्षमताओं की बहुत कम सीमा में किया जाता है। यह नोट व्यवहार्य एएलएम वातावरण को तैनात करने के लिए कुछ दिशानिर्देश प्रदान करेगा।
लक्ष्य निर्धारित करें
टीएफएस का मुख्य "क्रेडो" सॉफ्टवेयर के विकास और आंशिक संचालन से जुड़ी सभी संगठनात्मक प्रक्रियाओं में पूर्वानुमानशीलता को बढ़ाना है। इस संदर्भ में भविष्यवाणी का शाब्दिक अर्थ है एक चीज -
किसी भी समय, टीएफएस टूल का उपयोग करके, आप देख सकते हैं कि चीजें कैसे चल रही हैं और निष्कर्ष निकालना है । आपके पास कितनी त्रुटियां हैं, क्या आवश्यकताएं अभी तक बंद नहीं हुई हैं, और इसी तरह। इस जानकारी की विश्वसनीयता सीधे स्रोत डेटा पर निर्भर करती है - इस तरह के अधिक डेटा को टीएफएस द्वारा एकत्र किया जाएगा, बेहतर आप बाद के निर्णय ले सकते हैं। टीएफएस को एक डेटाबेस के रूप में प्रस्तुत करना बहुत सही है, जिसमें विभिन्न स्रोतों से जानकारी लगातार आ रही है। कहीं स्वत: मोड में, कहीं आवश्यकता है कि लोग इस जानकारी को स्वयं योगदान करें। यह समझा जाना चाहिए कि आप जितनी अधिक जानकारी एकत्र करेंगे, उसमें उतने ही अधिक तालमेल और रिश्ते होंगे।
इससे यह निम्नानुसार है कि टीएफएस के सफल कार्यान्वयन के लिए मुख्य कारक मुख्य रूप से रिपोर्टिंग सेवा और OLAP, उनकी सूचना सामग्री और बाद की कार्रवाइयों के साथ इन रिपोर्टों के आधार पर निष्कर्ष निकालने की क्षमता के आधार पर कार्यात्मक रिपोर्ट है। दूसरे शब्दों में, यदि आप रिपोर्टिंग सेवाओं का उपयोग नहीं करते हैं, तो Excel का उपयोग करते हुए OLAP क्यूब्स और
संकेतक की
सूची को नहीं समझते हैं
जो TFS विश्लेषण के लिए प्रदान करता है , तो आप माइक्रोस्कोप के साथ नाखूनों में हथौड़ा करते हैं।
रिपोर्ट की गुणवत्ता में सुधार
ऊपर निर्धारित लक्ष्य के आधार पर, आप अधिक विस्तार से समझ सकते हैं कि टीएफएस घटकों को अधिक तीव्रता से कैसे संचालित किया जाए, और इस ऑपरेशन के स्तर को और बढ़ाने के लिए क्या कदम उठाए जाने की आवश्यकता है।
रिपोर्ट में दिखाई देने वाले डेटा को एक सूची में वर्गीकृत किया जा सकता है, जो टीआरए ऑपरेशन ऑपरेटर के क्रमिक सुधार के चरणों का प्रतिनिधित्व कर सकता है:
- आपकी परियोजनाओं पर दिखाई देने वाली सभी कार्य वस्तुओं के बारे में जानकारी। इस डेटा में कार्यों, आवश्यकताओं, त्रुटियों के बारे में जानकारी शामिल है, और TFS इन कार्य मदों के लिए फ़ील्ड परिवर्तनों का एक पूरा इतिहास संग्रहीत करता है। इस जानकारी के आधार पर, आप समझ सकते हैं कि आपकी वर्तमान चुनौतियाँ क्या हैं। इस बिंदु पर, आप समय को ट्रैक करने और टीम को डाउनलोड करने के लिए शेड्यूल कर पाएंगे। यह मत भूलो कि इस डेटा की गुणवत्ता सीधे लोगों पर निर्भर करती है। और इस स्तर पर, टीएफएस में प्रश्नों के साथ काम करना सीखना आवश्यक है, काम की वस्तुओं को बदलने के लिए तंत्र की व्याख्या करें, और एक्सेल जैसे एकीकृत उपकरण का उपयोग करें।
- प्रोजेक्ट स्रोत फ़ाइलों में परिवर्तन के बारे में जानकारी। स्रोत कोड की लाइनों के सभी अतिरिक्त, परिवर्तन, विलोपन। किसने, कब और किस आधार पर यह या उस ऑपरेशन को अंजाम दिया। यह ध्यान रखना महत्वपूर्ण है कि चूंकि TFS आपको त्रुटियों, कार्यों और अन्य कार्य वस्तुओं के साथ स्रोत कोड में परिवर्तन (लिंक) करने की अनुमति देता है। पहले से ही इस स्तर पर आप देख सकते हैं कि किसी विशेष आवश्यकता के कार्यान्वयन या त्रुटि को ठीक करने के लिए कोड की कितनी लाइनें हैं। इस जानकारी के निर्माण में किसी व्यक्ति की भागीदारी को नोट करना भी महत्वपूर्ण है, जो प्रोग्रामर को उनके द्वारा किए जाने वाले कार्यों के साथ कोड में परिवर्तनों के संघों के महत्व को समझाता है।
- विधानसभा की जानकारी। टीएफएस में एक बहुत ही लचीला प्रोजेक्ट बिल्ड पर्यावरण शामिल है। जैसे ही आप स्वचालित असेंबली स्थापित करते हैं, काम की वस्तुओं और कोड में बदलाव से संबंधित जानकारी का एक लिंक होगा, जो तदनुसार आपको किसी विशेष बिल्ड में परिवर्तनों के स्तर और पैमाने को समझने का अवसर देगा। इस स्तर पर, निरंतर एकीकरण ("निरंतर एकीकरण") के तंत्र शामिल हैं, जो हमें दीर्घकालिक स्तर पर पूर्वानुमान बनाने के लिए परियोजना की प्रगति को उच्च स्तर पर समझने की अनुमति देते हैं।
- परीक्षणों द्वारा परीक्षण और कोड कवरेज के बारे में जानकारी। आपके उत्पाद की गुणवत्ता सुनिश्चित करने के लिए परीक्षण एक बहुत ही महत्वपूर्ण तंत्र है। टेस्ट को आवश्यकताओं, कोड परिवर्तन, और बिल्ड से जोड़ा जा सकता है। जैसे ही इन तंत्रों को चालू किया जाता है, आपको तुरंत अपने वर्तमान निर्माण की क्षमता का मूल्यांकन करने और मैनुअल परीक्षण के लिए न देने का अवसर मिलेगा, क्योंकि यह आवश्यक स्वचालित परीक्षणों को पारित नहीं करता है, जिससे परीक्षकों से भार कम हो जाता है। इसके अलावा, आपको परीक्षण गुणवत्ता के स्तर (कोड कवरेज के लिए धन्यवाद) के बारे में जानकारी प्राप्त होगी।
इन सभी घटकों को लागू करने का प्रयास करना और रिपोर्ट में पूरी जानकारी तुरंत प्राप्त करना आवश्यक नहीं है। आपकी परियोजनाओं के विन्यास में चरणबद्ध चक्रीय परिवर्तन और सुचारू संगठनात्मक परिवर्तन काफी संभव हैं। गलतियों से डरो मत, एक नियम के रूप में, वे केवल टीएफएस के साथ व्यावहारिक अनुभव की कमी से जुड़े हुए हैं और जल्दी से पकड़ लेते हैं।
नमूना TFS सुधार योजना
आपकी ALM प्रक्रिया में TFS क्षमताओं के क्रमिक, पुनरावृत्त समावेश को छोटे चक्रों ("Kaizen" जैसी कुछ) में विभाजित किया जा सकता है, जिनमें से प्रत्येक में आप धीरे-धीरे फ़ंक्शन कनेक्ट करते हैं और रिपोर्ट का उपयोग करके उनके प्रदर्शन की जांच करते हैं:
सप्ताह 1:
- कार्य आइटम की स्थिति पर आधे घंटे की कार्यशाला का संचालन करें और अनुरोधों के साथ काम करें
- परियोजना क्षेत्रों (क्षेत्र) की एक सूची विकसित करें
- कार्य के साथ कार्य की अनुसूची में क्षेत्र क्षेत्र में अनिवार्य भरना
- पहली स्वचालित निर्माण प्रणाली बनाएँ
- जाँचें कि रिपोर्ट में निर्माण में पूर्ण कार्यों के संदर्भ में परिवर्तन के बारे में जानकारी शामिल है
सप्ताह 2:
- काम की वस्तुओं (मास्टर / बाल) को जोड़ने पर आधे घंटे की कार्यशाला आयोजित करना
- परियोजना पुनरावृत्तियों (Iterations) की एक सूची विकसित करें
- आवश्यकताओं के अधीन काम करने के लिए नियमों में शामिल करने के लिए नियोजित और खर्च किए गए घंटों के क्षेत्र में अनिवार्य भरने की आवश्यकता होती है
- विनियमन और एक परस्पर कोड के साथ कार्यों और आवश्यकताओं का एक अनिवार्य संघ में परिचय
- जांचें कि क्या रिपोर्ट में आवश्यकताओं के अनुसार कोड परिवर्तन की जानकारी शामिल है। हम KPI को शुरू करते हैं - संघों के बिना कोड में परिवर्तन की संख्या और हमें टीम से इस सूचक में कमी की आवश्यकता होती है।
सप्ताह 3:
- डेढ़ घंटे का कोड कवरेज कार्यशाला आयोजित करें
- परीक्षणों की एक प्रारंभिक सूची बनाएं, 2-3 परीक्षण तैयार करें
- आवश्यकताओं के साथ कार्य अनुसूची में शामिल करने के लिए इस आवश्यकता के लिए एक मैनुअल परीक्षण का अनिवार्य निर्माण
- सक्षम परीक्षण सबसिस्टम के साथ एक नई बिल्ड परिभाषा बनाएँ
- जाँचें कि रिपोर्ट में परीक्षण के स्तर और कोड के प्रतिशत कवरेज के बारे में जानकारी शामिल है
इस प्रकार, प्रत्येक छोटे स्तर पर, एक निश्चित परिणाम प्राप्त होता है, जो टीम के लिए स्पष्ट है।
प्रक्रिया परिवर्तन और TFS विन्यास
TFS एक लचीला और बहुमुखी उपकरण है। पैकेज में दो प्रक्रिया टेम्पलेट (एजाइल और सीएमएमआई) शामिल हैं, इसके अलावा, आप अन्य प्रक्रिया टेम्पलेट स्थापित कर सकते हैं। कई टीमों को इन टेम्पलेट्स को परिष्कृत करने के लिए लुभाया जाता है, क्योंकि, उनकी राय में, टीएफएस में कार्यान्वयन इस संगठन में अपनाई गई प्रथाओं का अनुपालन नहीं करता है। यह एक पूरी तरह से स्वीकार्य स्थिति है, लेकिन चरम पर मत जाओ, उदाहरण के लिए, काम के तत्वों के संक्रमण की स्थितियों और नींव को पूरी तरह से फिर से परिभाषित करना। एक नियम के रूप में, यह बहुत दुखद परिणाम की ओर ले जाता है अगर आपको एएलएम ऑटोमेशन सिस्टम के साथ गंभीर काम का कोई अनुभव नहीं था।
सामान्य तौर पर, यह बहुत अच्छी तरह से हो सकता है कि आप जिन प्रथाओं का उपयोग करते हैं, वे पूरी तरह से प्रक्रियाओं के कार्यान्वयन के वर्तमान संस्करण में फिट होते हैं और आपके पास बस कोई शब्दावली विसंगतियां हैं। किसी भी मामले में, लागत के रूप में नियोजित परिवर्तनों का मूल्यांकन करने का प्रयास करें: जो आसान है, बैठक में काम के एक नए संगठन पर सहमत हों या टीएफएस में बदलाव करें।
निष्कर्ष
यदि आप क्रमिक सुधार दृष्टिकोण का उपयोग करते हैं तो ALM को स्वचालित करना उतना मुश्किल नहीं हो सकता है। इस तथ्य के कारण कि टीएफएस एक एकीकृत परिसर है जो विभिन्न घटकों से जानकारी एकत्र करता है। जितना अधिक डेटा आप इकट्ठा करने का प्रबंधन करते हैं, उतनी ही प्रभावी रूप से आप परियोजनाओं पर वर्तमान स्थिति को समझ सकते हैं, और इसलिए अधिक कुशलता से सॉफ्टवेयर विकास प्रक्रियाओं का प्रबंधन कर सकते हैं। आप
MSDN दस्तावेज़ से अनुप्रयोग जीवनचक्र प्रबंधन के बारे में अधिक जान सकते हैं और
फ़ोरम में चर्चा कर सकते हैं।