If your using TFS then you should get power tools. The version for TFS 2010 are out…
http://blogs.msdn.com/bharry/archive/2009/12/01/tfs-2010-power-tools-are-available.aspx
Also the best practice analyzer is out to make sure your server side is all good…
One of the new (and awesome) features of TFS 2010 is that you can create deep and complex relationships among work items of various types. This is needed to create rich project tracking and reporting. There isnt a TFS 2010 for Dummies book out yet and I needed a simple way to explain this. Pretty pictures to the rescue!
Here is a visual of how the work items are related. It can be complicated but it is this relationship structure that empowers the whole system. The work items under a user story (children) are either test cases or tasks. Tasks are for when someone needs to do something. Test cases are for things to validate for that user story to be functionally complete. As the tasks are completed, code is being written and functions start to work in the application. When all of the child tasks of a user story are completed, then the user story is code complete… meaning it can be tested. At this stage a tester will look at all of the child test cases of a user story and start to try them in the QA environment. As they find issues the will create bugs which are related to the test case (and associated user story). When all of the test cases are complete with no bugs and all of the tasks are complete it means a user story is complete (and should be working). Also notice there can be another dimension beyond parent and child, that of predecessor and successor. This is used when one task needs to be completed before another can start. An example of this is that a web page’s UI needs to be designed before it can be built. This is useful to determine the calendar date of when a user story will be complete. You can export all of this data to Excel and MS Project if you like.
A couple concepts that are not represented in this diagram code check-ins and builds. As code is checked into TFS it is associated with development tasks. Check-ins are rolled up into builds. Therefore you can garner all sorts of interesting data; bugs in a build, completed user stories in a build, work completed in a build…
Out of the box TFS ships the Task work item with two fields to support classification, Area and Iteration. It’s pretty obvious what Iteration is for (time), but Area can be a bit confusing. In my experience the issue stems from the fact that multiple user types use the TFS system. So you will get a different answer as to what an Area is based on the type of person you are talking with. People on the product & business side tends to think of areas as functional areas of the system (users, commerce, partners, advertising…); however people on the technical side tend to think of areas as the technical component (public website, database, api, mobile application…). Ive seen examples where companies just combined the two concepts into the Area hierarchy; this doesn’t really do anyone any good. The issue here is that these are really two different concepts with each task actually being associated with both concepts. Example; you can have commerce functionality in both the public website and the database. The solution is really quite easy, but nobody really does it… create a new work item field.
Customizing Work Item Types on Team Foundation Server
Field Definition
<FIELD name=”Component” refname=”TadlockEnterprises.TFS.Apollo.WorkItemFields.Component” type=”String” reportable=”dimension” >
<HELPTEXT>The techincal component.</HELPTEXT>
<ALLOWEDVALUES expanditems=”true”>
<LISTITEM value=”Public Website” />
<LISTITEM value=”Admin Website” />
<LISTITEM value=”API” />
<LISTITEM value=”Database” />
<LISTITEM value=”Foundation” />
<LISTITEM value=”Model” />
</ALLOWEDVALUES>
</FIELD>
Form Definition
<Group Label=”Classification”>
<Column PercentWidth=”100″>
<Control FieldName=”System.AreaPath” Type=”WorkItemClassificationControl” Label=”&Area:” LabelPosition=”Left” />
<Control FieldName=”TadlockEnterprises.TFS.Apollo.WorkItemFields.Component” Type=”FieldControl” Label=”&Component:” LabelPosition=”Left” />
<Control FieldName=”System.IterationPath” Type=”WorkItemClassificationControl” Label=”&Iteration:” LabelPosition=”Left” />
</Column>
</Group>
In the TFS configurations I setup for my clients I have the Area field represent the business concept (because the hierarchy makes more sense here) and create a new flat field for the technical component (Component). I then add this field right next to the Area and Iteration fields in the UI. This Component field is also useful in the Bug work item.
All of this works pretty well. My only complaint with this is that you cant create custom work item fields that use the TreePath type, so you cant make the Component field a hierarchy. I’m sure there is some technical reason why this is the case, but Microsoft should just fix it.
This is a great resources for questions about automated testing within TFS 2010.
Jim Lamb has a great write up on how to build custom workflow activities for TeamBuild for TFS 2010. Given that some key activities are missing out of the box in beta two, it’s very likely you will find yourself writing a few of your own.
Funny, I was just wondering about something this morning… then I check the latest tech news and sure enough there is an article similar to what I was thinking! So here it is… Cloud/grid computing is all the rage these days. In the current model you put your entire application in the cloud and run it from there. This is good for some things like web servers and databases, but not great for other things. Applications that don’t fit well into the current cloud model tend to be very rich UI focused applications; for example most of the applications you run on your desktop/laptop. However there is a subset of those desktop applications that at time require intense processing power, much more that your little desktop/laptop can provide. Examples of this include compiling code (VS.NET), transcoding audio/video, crazy Excel spreadsheets… What you really want is a local application experience but use the power of the cloud for the intense processing tasks. Imagine this; you are using VS.NET and TFS for a large enterprises system with several applications and databases. When you click rebuild all, it automatically puts your changes into a shelveset on the server, kicks off a server build (which leverages a huge CPU farm of build servers), then when done copies the outputs to your local machine. This would be great for huge systems! At Spot Runner it took 5+ minutes to rebuild the entire solution on the local developer machines. We had the choice of either upgrading 100 engineer’s systems to be more powerful (expensive) or leaving it be and paying the cost in developer productivity (more expensive). This would have solved both problems by giving faster rebuild times and allowing us to maximize the usage of our cap-ex server expenditure by centralizing it. There really isn’t anything stopping this from becoming reality. I could see a model both where the computing-cloud is internal to the corporate network or an external cloud (Amazon, Microsoft, Google…). I have to imagine these companies are already working on this. If you know anything about this, let me know!
http://techflash.com/seattle/2009/11/microsoft_juicing_up_excel.html