An Extreme Programming Scenario


To see how a typical extreme programming scenario might look from a programmer's view, the following is a generic procedure taken from www.linuxdevcenter.com/pub/a/linux/2001/05/04/xp_intro.html. (By the way, this is the only reference to Linux in this book, so the subtle hint here is that extreme programming seems to serve the open source community best at this time.)

  1. The customer lists the features that the software must provide.

  2. Programmers break the features into standalone tasks and estimate the work needed to complete each task.

  3. The customer chooses the most important tasks that can be completed by the next release.

  4. Programmers choose tasks, and work in pairs.

  5. Programmers write unit tests.

  6. Programmers add features to pass unit tests.

  7. Programmers fix features/tests as necessary, until all tests pass.

  8. Programmers integrate code.

  9. Programmers produce a released version.

  10. [The] customer runs acceptance tests.

  11. [The] version goes into production.

  12. Programmers update their estimates based on the amount of work they've done in the release cycle.

This is just an example, but it should give you an idea of the workflow if you are a developer in an extreme programming environment.



The Build Master(c) Microsoft's Software Configuration Management Best Practices
The Build Master: Microsofts Software Configuration Management Best Practices
ISBN: 0321332059
EAN: 2147483647
Year: 2006
Pages: 186

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