Work item customization requirements (or possibly security) would be my driving force as well, but I find this more the exception than the rule, depending upon how siloed the organization is of course. But I don't want to take this discussion too far afield. _________________________ Dave Zimmerman Current Client direct dial: 612-667-6841 mobile: 651-246-2378 [email protected]<mailto:[email protected]> http://www.intertech.com/ Instructors Who Consult. | Consultants Who Teach.™
Come join us at the vstsMN User Group (http://vstsmn.net) ________________________________ From: [email protected] [[email protected]] On Behalf Of Ewald Hofman [[email protected]] Sent: Monday, October 19, 2009 4:58 AM To: ozTFS Subject: RE: TFS Practices A customer of me did also little team projects, but regrets this decision now and they created per system / application / project a team project now. This is also driven by the fact that multiple teams have different customization needs. So my rule of thump is to give each development team its own team project. However in your case I would have one team project for all tools and utility applications, because you don't have any benefit of creating multiple ones Sent from my mobile phone. ________________________________ Van: Dave Zimmerman <[email protected]> Verzonden: maandag 19 oktober 2009 8:46 Aan: ozTFS <[email protected]> Onderwerp: RE: TFS Practices As a rule we typically recommend very few team projects for most organizations so this never really comes up. Yes, all the bug tracking is in one team project, but the team filters by area and iteration. Separate sites/bugs/reports for every project can be too isolated to a fault, e.g, no way to have project plans span team projects, and end up copying all sorts of documents from SharePoint site to SharePoint site. == Just my 2 cents worth. _______________ Dave Zimmerman Intertech<http://www.intertech.com/> :: [email protected]<mailto:[email protected]> :: 651.994.8558 x36 :: 651.246.2378 (mobile) Instructors Who Consult / Consultants Who Teach Come join us at the vstsMN User Group (http://vstsmn.net) Or stay connected on Facebook<http://www.facebook.com/home.php#/group.php?sid=bbb0ff375c0782fe55c7fafd0d879a5b&gid=38452984276> and LinkedIn<http://www.linkedin.com/groups?home=&gid=1681947&trk=anet_ug_hm>, be an Intertech Facebook Fan<http://www.facebook.com/home.php?#/pages/Intertech/227130205696?ref=nf>, follow us on Twitter<http://twitter.intertech.com/> From: [email protected] [mailto:[email protected]] On Behalf Of Alastair Waddell Sent: Sunday, October 18, 2009 6:36 PM To: ozTFS Subject: TFS Practices Hey All, Just looking for other peoples ideas as to how you structure you projects… If you have some small applications that don’t really fit the requirements for a full blown project then do you just create a “Stuff I need in Source Control” project and add the source code for each of these applications, or do you create a project for each of these applications Eg I have created some installer projects for installing the Reporting Services Printer client (2005 and 2008) and these don’t really have the need for bug tracking etc…but do want then under source control Alastair
_______________________________________________ oztfs mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/oztfs
