How to convince management that CI & Test is a good thing?
Revision as of 01:56, 28 July 2007 by 18.104.22.168
Here is a list of arguments we hear from management, if we try to introduce CI and/or Test.
- CI is out of scope, so why do you create this?
- The build is not the problem, only the environment (e.g. DB, LDAP,...), and you can't test this.
- Why should we build continuous, we have a build every night.
- If we change the current process, we introduce new unknown risk to the project.
- What is the value in knowing early that the build is broken?
- We don't need that, because our developers don't create these errors / brake the build.
- We don't have a problem now, why should we change something?
What to do
- Just do it.
- Test infect your team (back door approach).
- Educate management what agile, CI, automated Tests, ... is about.
- Do not let management decide how we are developing. The contract should have a measurable end functionality.
- CI can maybe be bundled with automated test / TDD
- You can't sell this without trust.
- Management will only be willing to change something, if there is a crisis (so your goal could be to create the crisis!?)
- You can't sell this, if there is no measurement about the current development process.
I guess the value of CI and Test is clearer in some of the other sessions, but here is a small list.
- Faster, predictable product.
- No milestones, but continuous information.
- Increase speed to change code, i.e. time to market is shorter.