MSDN Utopia : TFS

Accessing TFS 2010 from VS2008

Salva Patuel — Fri, 24 Jul 2009 12:20:00 GMT

In order to access the new Team Foundation Server 2010 from your current Team Explorer 2008 you will need to install the Visual Studio 2008 Service Pack 1. Several customers were complaining that even with the service pack installed they couldn't manage to connect.

The problem is the order of the installation. For many customers, the orders was:

1) Visual Studio SP1
2) Team Explorer 2008

but if you have installed Team Explorer 2008 after the SP1 the changes are not in place. In order to sort out this just reinstall the SP1 and it will work.

MSF Agile planning - The storyboard without TFS

Salva Patuel — Fri, 27 Apr 2007 11:55:00 GMT

Not all our customers will have a TFS implementation ready to go when we try to implement some agile procedures. This has limited some consultants that have been trained to implement MSF agile using our tool only.

The good news is that there are some pragmatic ways to organize tasks and keep the communication open between the teams. A good approach is using a storyboard, writing down the different tasks in story cards that can be sticked to the whiteboard.

Storyboard in action

The idea is to identify the tasks and distribute the across the iterations. One way to do it is to divide the whiteboard in frames, using different areas to place the tasks assigned to the different iterations. The tasks should be considered as if they were standard agile tasks; the amount of information is up to the project governor discretion. A way to share the goals that the team are trying to achieve on the iteration can be displayed at the top of the list with a different card colour; this can help to move tasks to other iterations if they are not aligned with the iteration goal.

Storyboard sample

Each task needs to be specific, with mini subtasks if necessary. If the task ends to generic it is recommended to split it in different tasks. Another key area to consider is the duration of each one, as a big different in the estimated time can push the iteration beyond the planned timeframe. Don’t try to define all your iterations in advance, if you have ideas or “good to have” features, put them into a “future iterations” list, no matter how crazy they are. Once the project starts to deliver value you can review the future iterations section to accommodate them in the next iterations.

In order to track the status of the project, another section is recommended. This section will have the name of the developers (or teams if the project is big enough) with the tasks assigned to it/them. These tasks should be removed from the iterations list with the starting time tracked. This type of exercise allows everybody to see which features are under development and which ones are still missing from the current iteration. Once the developer or team finished the tasks it should go to the completed list with the goals attached, marking each of the goals achieved on the completion list.

Work in progress and competition sample

This storyboard methodology helps to track the tasks without using TFS and has a real visual impact on the team and managers.

MSF Agile and service packs management

Salva Patuel — Tue, 10 Apr 2007 18:02:00 GMT

Not a while ago, a customer asked me about how to incorporate the service packs and hot fixes to the agile development process, this triggered an interesting debate about the importance of a QA and release manager.

The UAT environment always must reflect the live environment, this means that the automatic updates should be off (or downloads without installing them), otherwise hot fixes and service packs will alter the test environment.

Every change in the environment should go through a new iteration, this sometimes causes confusion when developers thinks that the agile iteration will be only followed if a change in the code is introduced. This is not correct, Agile is not about development only, is about a product life cycle that includes the environment where the software will run.

A change on the environment will trigger a new iteration, where the product manager needs to approve (and justify) the change. This can be a security fix that affects the production environment. The iteration will not trigger an automatic change on the code (unless specified by the update) but the code will be included on the new iteration.

At this stage we have a new build ready to install. The QA manager should install the service packs or hot fixes on the UAT environment and install the build. The entire test must be executed on this new environment and the QA team will raise any problem detected as a normal iteration. Once the QA manager signs off the build under the new environment this will be hand over to the release manager for the production environment upgrade.

At the end of this iteration a new build has been generated with the upgrade notes attached, this will help in the future to track down the context where the software has been tested.

This post should help you to understand that the MSF Agile is a full life cycle methodology that can be extended to all the areas that affects the software, including infrastructure.