Team Foundation Server…it’s more platform than product!


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 :)

 


Comments (7)

  1. Rob Caron says:

    David Lempher’s recent blog post (Team Foundation Server…it’s more platform than product!) reminded…

  2. Dave, great post about a fantastic product.  But have you looked at the pricing for TFS?  Given that TFS is currently not included in the MS partner program (AFAIK) RRP for TFS is approx $5900 + approx $1000 per seat?  For a smallish dev teams (ie around 6-10 seats) this pricing is ridiculous for the functionality.  We recently decided to go with Gemini and SourceSafe as a much cheaper (approx $280 US with no per seat cost).  Yes we loose a bit of functionality, but definitely not enough to warrent the extra cost.

    The other significant point is that because we don’t have a per seat cost we can expose our Gemini interface to everyone else in the org, as well as customers (if we so desired).

  3. Mitch Denny says:

    Partnership pays. We are a Microsoft Gold Certified Partner with competencies in Custom Development as such we get a whole bunch of Team Developer licenses with a Standard Server license for Team Foundation Server.

    Mind you – getting access to that entitlement out of the partner program can be so big a challenge that its easier to drop the dosh :)

    Something needs to be done about the delivery of TFS across the various channels actually.

  4. Dylan Smith on Database Unit Testing – Not quite there yet…

    David L. on Team Foundation Server…it’s…