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:
- Design
- Coding
- Testing
- Build
- 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.