Team Foundation Server...it's more platform than product!

  • Article

So (there’s that word again!) most of us are pretty convinced that Team Foundation Server is a pretty solid SDLC product, but I thought I would list some of the elements that appeals to non-devs.

Integration: To me, integration has the ability to be more than just connecting to other systems. It’s the opportunity for the SDLC to become part of the bigger business process. The opportunities are many, for example, motioning data from TFS through to billing or invoicing systems can create new productivity chains, or feeding information from external customer systems into TFS creates new collaboration points.

Visibility: Being able to track the progress of a solution in development is only one direction of visibility, the other is retrospectivity. The ability to extract post-implementation data for SPI (Software Process Improvement) reviews or IP distillation is fundamental; the ability for the platform to be instrumented and mined is key to reviewing what was done, and improving the process going forward.

Traceability/Accountability: Traceability is all about following a particular interaction through a series of steps, and being able to identify the key players at each step. Accountability to me is about being able to lay claim to a particular action, or being able to understand why someone performed an action. For example, tracing a defect from a particular release back through the build process, through the source code control system, through to the change set commit, through to the work item is very important. Also knowing who created and assigned the work item, who changed the code, who released the build and who tested and found the defect is gold too. The other aspect that is important is not to focus on management by exception. Yes it’s cool to know who has the worst unit testing record, and to sufficiently chastise that person, but it’s also important to be able to regularly reward quality, which again is very achievable in TFS. You could easily create a web part for the project portal that finds the top 5 developers based on unit test quality and work rate (how many work items closed and released) and have them on the front page of the portal.

Aggregation: Again, aggregating lifecycle data is invaluable. Being able to aggregate data from projects, across a portfolio, or across a team is very powerful. Some of the key aggregation points in TFS for me are:

  • Project Data: Build quality, overall bugs, work rate.
  • Portfolio Data: Total hours spent, Work Completed/Work to be done ratio.
  • Resource Data: Assigned to projects (as in, how many projects the developer is assigned to), overall work spread (over all the projects, what is the spread of metrics such as defects, failed unit tests, etc. This is important to understand if a developer is experiencing issues in a particular project team, or is consistent across all projects), Release rate (how often does the developer have work released).

Tooling: The ability to extend and customise a SDLC tool using the skills and experience already present in the development team is fundamental to efficient SPI. If you need to hire external consultants to change or update your tools, then you’re not going to get the best result. Ideally, SPI should be an internal investment in idle times for the project team. Following a PIR, the project team should spend a period of time refining their internal process, then build appropriate tools and extensions to the SDLC toolset to support this in future projects. Again, TFS supports tooling both on the server tier and the client tier, so being able to extend and integrate TFS and VSTS is critical to tooling the process.

Anyhoo, thought I’d spew some stuff forth, enjoy :)