Getting to Done with VS2010

Getting to Done with VS2010

Posted by Simon Reindl | April 23, 2010 | Best Practice, Scrum, Visual Studio 2010

One of the most critical aspects of any project is when have you got to done. This is one of the central principles of Scrum, as it is the contract between the team that is going to produce something, and the Product Owner who is going to take delivery of it. In waterfall projects, it is just as critical. Due to the focus on the Big Design Up Front, it is costly in terms of time and effort to revisit a phase once it is “done”.

The thing is that there as many definitions of done as there are folk on the project, so it is vital to get the agreed definition visible – so everyone knows what they are committed to delivering.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint-Exupery

At the highest level, any software solution should consist of:

  1. Design
  2. Coding
  3. Testing
  4. Build
  5. Documentation

OK, so nothing profound there – however what is the benchmark standard for each of these, and how can I use VS to let the team now when we are done?

 

Design

The great thing about VS2010 is that it speaks UML. When this is tied in with the slick WPF interface, being able to move through many different views, zooming in and out allows you to get a solid understanding of your app quickly. A great summary is at Somasegar’s weblog. All of these are great, and the bonus is that the gated check in is here with Team Build. The purpose of a gated check in is to prevent code that is going to break either the build or the design. In this way the integrity of the design is maintained. The code that is checked in is automatically turned in to a shelve set, and depending on the what level of validation you want (where you set the bar) controls what gets fully checked in. The neat feature is that if your architecture says that the UI talks to the business tier, and not directly to the database, code that doesn’t comply never gets in to the branch. That will save a heap of rewriting!

Coding

2010 is better than the previous version by a long way. The killer feature – Multi-Screen support, followed on by:

  • enhanced refactoring
  • intellitrace (oh wow … unfortunately only in Ultimate edition)
  • support for the all the Dubs (WCF, WPF, WF)
  • enhanced intellisense in XAML
  • all the Database GDR2 magic
  • SharePoint templates
  • Multi Framework targeting
  • Code Analysis
  • Code Metrics

All these features makes it a more straight forward proposition to write, compile, fix and refactor the code base. The guidance from the code analysis and metrics should be included in the done definition – what is the minimum level that you will accept in to promoting up the stack to live?

Testing

The major addition in 2010 is the Test and Lab manager. There is a much improved web testing that can be used to create performance and load tests. The key thing in my view is the lab management to help manage the VM estate so that the range of tests can be run against a known server state.

The testing tiers should be cumulative:

Level Testing
One Integration Tests
Functional Tests
Build Verification Test / Smoke Test
Two all of the above and
Unit Tests
Regression Tests
Three All of the above and
Performance Tests
Security Tests
Documentation Tests

As many of these as possible should be automated so that they can be included in the build cycle. The sooner you know it is broke – the sooner you can fix it

Build

The big change in the build for 2010 is that it is now based on Windows Workflow. MSBuild can still be used, however the default templates are WF. The best practice is to create a custom build process template and share it across your projects.

The bad news is that the WiX integration was dropped, more on that in a later post.

Aaron has a great summary of the way build works: http://blogs.msdn.com/aaronhallberg/

Documentation

Sandcastle is a great tool for generating well formatted documentation based on the xml comments in the code. It can be integrated in to the build, you just have to write decent comments! There is a codeplex project to help get the best out of sandcastle.

Suggested “Done”

A basic definition of Done would be:

  • User Stories in as work items
  • Design completed
    • Class diagrams
    • Sequence diagrams
  • Code written
  • Code Compiles
  • Code passes code analysis (agreed exceptions)
  • Code passes metric gates
  • All tests that have been written pass
  • Code coverage meets agreed level (this is an “it depends” answer, if you have inherited a huge code base, it is a big ask to get to 80% coverage!)
  • Smoke Test passes
  • Build and packing completed (you are going to ship this, aren’t you)
  • Documentation written

This is a very basic definition of done, the more detailed the definition will depend on where your team is at.

Martin Kulov has compiled this list of links to features in VS2010,  along with the http://www.teamsystemwidgets.com/ for the collection of extensions for TFS.

Related Blogs

Posted by richard | March 15, 2017
Create a Professional Scrum process
Visual Studio Team Services' customization capabilities are to a point now where I can write this blog post ... as a rebuttal to any earlier post of my own. Since...
Posted by richard | August 15, 2016
Ordering the Product Backlog by ROI
The Scrum Guide says that the Product Owner is the sole person responsible for managing the Product Backlog and that Product Backlog management includes ordering items in the Product Backlog...
Posted by richard | June 13, 2016
Stakeholder Traceroute
I'm always amazed at how difficult and even impossible it can be for stakeholders to get their ideas into some product backlogs. I've started asking teams to run a stakeholder...