How to convince management that CI & Test is a good thing?

From CitconWiki
Revision as of 02:54, 28 July 2007 by Redsofa (talk | contribs) (New page: == Resistance == 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 pr...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Resistance

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

Some suggestions.

  • Just do it.
  • Testinfect 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.


Why

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.