To Dos:
- Planning: User-stories are necessary for analysis. They should be prioritized and each of them will have an incremental development.
- Small releases: First versions will contain the minimum, most useful or necessary set of requirements for the global system.
- Metaphorical system: Each project must have an associated metaphor providing easy criteria to name the following stages of the project.
- Simple design: Because requirements change on a daily basis, or at least they should, simple designs are mandatory.
- Continuous testing: Before implementing any new feature of the system, a corresponding test has to be defined.
- Refactoring: When a new feature is introduced and it has much in common with previous ones, it is highly recommended to eliminate duplicate code; not worrying about the correctness of the new implementation because the tests will assert the correct functioning of the whole system.
- Pair programming: Work in pairs, using just one single computer. This way, one person reviews the other’s code while it is being written.
- Collective code ownership: Anyone can edit any module at any time, and no one has the property of any module.
- Continuous Integration: All changes are entered into the system at least once a day.
- Weeks of 40 hours of work: Developers should go home on time.
- Customer on our place: There should always be a system user accessible by the team members.
- Coding Standards: Everyone must use the same programming style criteria. As such, it wouldn´t be possible to determine who wrote a specific part of the implementation.
Not to Dos:
- Duplicate code fragments.
- Start a new iteration without customer approval.
- The developers work in separate rooms.
- No customer with the team.
- XP is only iterative development + Minimum Documentation + Unit Testing.
- Coding before writing unit tests.
- The customer does not decide.
- No acceptance tests at each iteration.
- Static design.
- Having just one single person from the client working with the team.
- Pair with a partner for a long time.
- Do not integrate the quality assurance team in the project.
- Write design documentation after coding.
- Little modeling.
- Only use pair programming with junior programmers.
- The observer cannot easily see the monitor.
- Team members not knowing XP and its foundations.
- Too long meetings and without clear objectives.
- Not using a dedicated tester.
- The client and the big boss are not aligned.
- The customer who writes the acceptance tests is not the same one that as executes them.
- Too long iterations.
- No time boxed iterations.
- Iteration not ending with a fully integrated baseline.
- Each iteration ending with a delivery to the user.
- Predictive planning.