2013-03-14 10 views
6

[यह "बेहतर है" प्रश्न की तरह गंध करता है, लेकिन यह नहीं है।]यदि आपके पास टीम फाउंडेशन सर्वर 2012 है, तो संस्करणऑन ऑफ़र क्या करता है?

हम संस्करण नियंत्रण और बग ट्रैकिंग (जो बदलने वाला नहीं है) के लिए टीम फाउंडेशन सर्वर 2012 का उपयोग कर रहे हैं। हम Agile में जा रहे हैं, और प्रक्रिया का प्रबंधन करने के लिए VersionOne का उपयोग करने के लिए कहा जा रहा है।

मैंने संस्करणऑन पर कई वेबिनारों में भाग लिया है। मुझे उनकी टीम फाउंडेशन सर्वर एकीकरण कहानी पर स्पष्ट उत्तर नहीं मिल रहा है। मुझे एक महत्वपूर्ण विशेषता नहीं मिल रही है जिसमें टीम फाउंडेशन सर्वर 2012 नहीं है।

मुझे क्या याद आ रही है? क्या मौजूदा एकीकरण कहानियां बेहतर हैं? क्या किसी को इन दोनों उत्पादों के साथ मिलकर काम करने का अनुभव है? क्या किसी को किसी भी नुकसान के बारे में पता है?

- अपडेट -

हम दोनों साथ-पक्ष थोड़ी देर के लिए अब के साथ काम किया है, और मैं हमारे अनुभवों को साझा कर सकते हैं:

  • स्वचालित सिंक्रनाइज़ेशन की स्थापना है (के रूप में उम्मीद) भयानक। डाउनटाइम और स्थायी सामान्य flakiness की उम्मीद है।
  • वी 1 विजुअल स्टूडियो प्लग-इन बेकार के बगल में है। यह आपको IDE के भीतर कुछ अपडेट करने की अनुमति देता है, लेकिन सभी नहीं। यह ठीक से सिंक नहीं करता है। यह संदर्भ प्रदान नहीं करता है। आप किसी भी आइटम को विश्वसनीय रूप से लिंक नहीं कर सकते हैं। यह सिर्फ आगे और आगे Alt-Tabbing से भी बदतर है।
  • वी 1 (टीम रूम, उप-टीमों, चर्चाओं) में उपयोगी और उपयोग की जाने वाली कुछ विशेषताएं टीएफएस 2013 में आ रही हैं और बहुत बेहतर काम करती हैं (विशेष रूप से यदि आप आईएम के लिए Lync का उपयोग करते हैं)।

टीएल, डीआर: वी 1 इसके लिए बहुत अच्छा है, लेकिन यह एक सिलो है। सभी एकीकरण पैचवर्क है। आप एकीकरण के लगभग सभी लाभ खो देते हैं जो टीएफएस ऑफ़र करता है - मुझे गलत मत समझो, टीएफएस में कई, कई, कई, कई मौसा हैं, लेकिन एक कहानी को एक चेकइन में एक जांच के लिए एक दोष से जोड़ने के लिए सक्षम होना एक विशिष्ट निर्माण के लिए आपकी टीम विकी पर दस्तावेज़ सिर्फ उल्लसित रूप से बेहतर है।

- अपडेट -

हम सिर्फ whitebox परीक्षण के लिए कोडित UI का उपयोग शुरू कर दिया है, और यह मूर्खता से शक्तिशाली है। VersionOne के साथ नकल करने के लिए इस बिंदु पर सिर्फ घृणास्पद है।

उत्तर

2

यदि आप टीएफएस 2012 का उपयोग कर रहे हैं तो मैं अब भी सवाल करूँगा कि आपको लगता है कि आपको "फुर्तीले जाने" के लिए एक और टूल की आवश्यकता क्यों है।

मेरा मानना ​​है कि टीएफएस 2012 के नवीनतम अपडेटों में चुस्त कामकाजी समर्थन में सुधार हुआ है, इसलिए यह अभी भी ठीक काम करना चाहिए। आप अपने चुने हुए चुस्त कामकाजी अभ्यास के मामले में स्क्रम या कानबान शैली के लिए जा सकते हैं।

कुछ सवाल अधिक सोचा भड़काने सकता है कि:

  • हम स्क्रम शैली या Kanban जाना चाहते हैं?
  • कौन सा गैर-तकनीकी सह-श्रमिकों को फुर्तीली शैली परियोजना के हिस्से के रूप में भाग लेने की आवश्यकता है?
  • क्या उन्हें सभी को टीएफएस 2012 और/या संस्करणऑन (या उस मामले के लिए कोई अन्य उपकरण) का उपयोग करने की आवश्यकता है?
  • क्या टीएफएस 2012 गैर-तकनीकी टीम के सदस्यों (जो एएलएम टूल्स की परवाह नहीं करते हैं) को बेनकाब करने के लिए ठीक है, या क्या हमें अतिरिक्त टूल को खेलने में लाने की ज़रूरत है?

ईमानदार होने के लिए यदि आप की जरूरत है तो आप शायद चिपचिपा नोट्स पर "चुस्त हो सकते हैं"।

FYI करें: http://blog.countersoft.com/2013/03/basics-of-running-agile-projects/

+0

संक्षिप्त उत्तर: - स्क्रम। जिन परियोजनाओं पर हम काम करते हैं, उनके लिए कानबान काम नहीं करेंगे। - उत्पाद प्रबंधन की एक बड़ी ढेर मदद। - अधिकांश गैर-तकनीक का उपयोग नहीं किया जाएगा। यही वही तरीका है जो चीजें हैं और जिस तरह से वे काम करते हैं। - गैर-देवताओं जो टीमों (लीड्स, क्यूए, इत्यादि) पर होंगी वे वीएस के साथ ठीक हैं; वे एक उपकरण सीख रहे हैं, और परवाह नहीं है कि कौन सा। वैसे भी, पसंद पहले से ही किया जा चुका है - संस्करणऑन नया मानक है। प्रबंधन ने इस पर फैसला किया है (यह एक दिन से Agile पद्धति के लिए कैसे है?)। लिंक के लिए धन्यवाद। मैं शायद नए प्रश्नों का एक गुच्छा शुरू करूंगा जो अधिक विशिष्ट हैं। – Stu

0

मैं दो एक डेमो के लिए एकीकृत। ग्राहक ने संस्करणऑन और TFS को अनिवार्य किया है। मैं जवाब नहीं कर सकते आपने ऐसा क्यों होता है, लेकिन जहां तक ​​कैसे यह उनकी ओपन सोर्स प्रोजेक्ट की जाँच करने के लिए के रूप में:

https://github.com/versionone/V1TFS

बाइनरी यहां हैं:

http://legacy.community.versionone.com/Downloads/Lists/Platform%20Downloads/DispForm.aspx?ID=31

आप मूल रूप से एक एमएसआई चलाता है जो एक वेब सेवा स्थापित करता है जो टीएफएस से घटनाओं के लिए पंजीकृत होता है और आगे चेक-इन या संस्करणऑन को डेटा बनाता है।

फिर आप अपनी चेक-इन नीति इंस्टॉल कर सकते हैं जिसके लिए डेवलपर्स को उपयोगकर्ता-कहानियों को चेक-इन के साथ संबद्ध करने की आवश्यकता होती है।

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

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

+0

पूरी तरह से सहमत हुए। मैं अपने अनुभवों को दर्शाने के लिए सवाल संपादित करने जा रहा हूं। – Stu

1

मुझे यह जवाब कुछ और खोजने के लिए मिलता है और यह एक है जिसे मैं व्यक्तिगत रूप से बहुत जवाब देता हूं, फिर भी मेरा यहां जोड़ रहा हूं और मुझे लगता है कि यह एक और सही जवाब है।

वी 1 एकीकरण डेवलपर्स के लिए उपयोगी है (आप जिस कार्य की आवश्यकता है उसके खिलाफ कोड में जांच सकते हैं)। मैंने दोनों का इस्तेमाल किया है। डेवलपर्स के लिए हो सकता है कि TFS बेहतर (वे सिर्फ कोड में जाँच कल्पना करते हुए) लेकिन अच्छा स्क्रम मास्टर और उत्पाद के मालिक के लिए, *

VersionOne नीचे

TFS ऑनलाइन हाथ * धड़कता है। मुख्य कारण यह है कि वी 1 कहानियों का प्रबंधन और कुशलतापूर्वक प्रबंधन, व्यवस्थित करने, प्राथमिकता देने और रिपोर्टिंग बेहतर तरीके से बेहतर है। जब यह स्क्रम/स्प्रिंट प्रबंधन की बात आती है

TFS ऑनलाइन एक बहुत वांछित किया जाना है।

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

टीएफएस में एक उदाहरण आप अलग-अलग परीक्षणों में स्वीकृति मानदंड को तोड़ नहीं सकते हैं और नियोजन दिवस पर उन्हें समय आवंटित कर सकते हैं जो आपकी स्प्रिंट योजना को फेंकता है। क्या आप इसे टीएफएस के साथ जोड़ सकते हैं? अनुकूलन और अन्य काम के प्रकार से जोड़ने के साथ सुनिश्चित करें, लेकिन यह बट में दर्द है।

वी 1 ने भविष्यवाणी जारी की है, अगले दो हफ्तों में आपकी टीम के लिए क्षमता योजना, ऑफशोर टीमों के लिए बनाई गई पोकर योजना और समग्र रूप से एग्इल विकास के लिए बनाया गया है।

आपके डेवलपर्स को केवल उन कार्यों के खिलाफ कोड जांचना होगा, जो वे कर सकते हैं। आपका स्क्रम मास्टर/उत्पाद स्वामी उपकरण में रहता है और वास्तव में उस उपकरण का उपयोग करना चाहिए जो उनके लिए सबसे अच्छा है।

तो दोनों का उपयोग करें। इसके साथ कुछ भी गलत नहीं है। अपने कोड को स्टोर करने के लिए बस टीएफएस ऑनलाइन का प्रयोग करें। बाकी सब कुछ के लिए वी 1 का प्रयोग करें।

+0

ईमानदार होने के लिए, यदि आप कहानियों के बहुत सारे विभाजन कर रहे हैं तो मैं वास्तव में आपकी प्रक्रिया के बारे में सोचता हूं। वे इतने बड़े क्यों शुरू हुए थे, या वे स्प्रिंट के दौरान क्यों नहीं पूरा हुए? स्वीकृति मानदंड के रूप में, जिस तरह से मैं इसे टीएफएस में करना पसंद करता हूं वह परीक्षण मामलों को स्वीकृति मानदंड _be_ बनाना है। –

+0

मैं अक्सर कहानियों को विभाजित नहीं करता लेकिन ऐसा होता है। कहानी बीए या क्लाइंट द्वारा दर्ज की जाती है और यह महसूस नहीं करती कि यह दो बड़ा है। वे कुछ उदाहरण हैं, रिपोर्टिंग और केवल चीजों को करने की क्षमता कई टीमों में बड़े पैमाने पर परियोजनाओं के लिए कई बैकलॉग प्रबंधित करते समय एक बड़ा अंतर बनाती है। बैकलॉग डेवलपर्स के लिए होना चाहिए, लेकिन क्लाइंट के रूप में क्लाइंट केवल कार्य/परीक्षण को तोड़ने और उन्हें बंद करने के लिए इसका उपयोग कर रहे हैं। आप सही हैं हालांकि इस तरह से निर्मित वास्तविक यूनिट परीक्षण होना अच्छा लगता है। आश्चर्य है कि इसे एकीकृत किया जा सकता है। वैसे भी मेरे विचार। – Mastro

+0

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

संबंधित मुद्दे