We’re in the middle of the “finishing” phase of three v1 projects right now, and since my software lifecycle on this blog is sorely missing any comment on finishing, I thought I should share a few thoughts.
Firstly, what is finishing? Its what used to be called QA or testing, where the developers hand over to the test team and then retrospectively update the specification to match what’s been built.
I’m not that fond of the QA at the end of a project approach. If you look at risk based testing, then you identify risks up front and work throughout all stages of the project to mitigate the risks. When you get to the end of the project, there shouldn’t be that much QA left to do – just finishing. We all know that the last 5% of a project takes far longer than 5% of the time and this is a really important time where hundreds of small decisions are made.
The other thing I’m not fond of is this tension between QA being at the end of the cycle so there’s always time pressure, but also the idea that developers should hand over completed bug-free code. I tried that once and all it meant was that I had to go through the entire QA process myself (which I’m really bad at) – just to hand it over to be QA’ed again.
Finishing is about shipping working software. Its when the feature development is complete (or when you hit the 80/90% mark in your cycle or budget) and when developers, testers, BAs and everyone else involved start to focus on shipping instead of building. There will be bugs to fix, there will be missing functionality to build, there will be enhancements, there will be style changes, there will be a lot going on and its not all QA. The goal is to turn a feature-complete project into a quality shippable project and it doesn’t rest on the shoulders of the test team while the developers move onto the next project.
So, finishing is actually quite fun, I just wish we stopped setting up our projects to converge like this!
[...] another way, finishing is better than [...]