Change Authorization

The developer on the agile project is authorized to change the source code in two cases:

  1. To implement an agreed-upon feature for the current iteration.

  2. To improve the simplicity (readability and maintainability) of the source code.

Agile development teams work hardas a matter of principle and through peer pressureto develop only what the customer has requested for the current iteration, and to keep the design simple. They also are working in short iterations, and so they have less time in which to gold-plate their design. These factors together have the effect that very few gratuitous features get put into the code, which reduce the worries surrounding development change control.

Agile teams are typically authorized to make small refactoring changes at any time without prior management approval, provided that the code complies with team-defined coding conventions and continues to pass all the same tests as before. ( Refactoring is revising the code structure without changing its functionality.)

Development change control is often informal. The source-code control system marks the changes, and may perform change notification automatically upon check-in or check-out . Changes are announced by e-mail between developers, or word-of-mouth when teams sit together. This works because of the small amount of goldplating, the short iterations, the close contact between developers and good testing habits.



Configuration Management Principles and Practice
Configuration Management Principles and Practice
ISBN: 0321117662
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net