One of things I find myself getting increasingly frustrated with is the definition of done by some people and companies.
For context, I’m speaking about work that is allegedly entirely complete, not necessarily what I expect out of the first sprint on a project. Sorry for stating the obvious, but someone will try to explain to me what the “Definition of Done” is from an agile perspective and I’ll get cranky… 🙂
Just off the top of my head I can think some things I think are important.
- It has to work : I mean actually work! It needs to do what I need it to do, and it needs to do it without falling over every 5 minutes.
- Functional Testing * : It should have some defined functional testing to prove it works. That should preferably be automated, but manual will do. Either way there should be a definition of what has been tested and the known limitations of that testing.
- Load Testing * : Just because it works on your PC with one row in the database, that is no reflection on how it will react in a multi-user system with lots of data.
- Tooling/Automation : There needs to be enough automation and/or tooling to allow the day-to-day operations to happen without having to refer back to the code or run SQL directly on the database to fix things.
- Documentation : There must be some concise and accurate documentation so people know how to use the product, and what operational tasks, if any, need to happen in order to stop the thing falling in a heap after a few days, weeks, months.
- Support : I need to know who to fall back on if I’m stuck.
* These may not be fully transparent to you if it is a 3rd party product, but you will soon know if it is happening when you use the product. 🙂
It’s surprising how many things I encounter on a daily basis that don’t seem to live up to this off-the-cuff list. This is not just internal developments, but work produced by expensive consultancy firms and 3rd party products.
Please, please, please finish the darn stuff before you give it to me!
Cheers
Tim…