This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

You have declined cookies. This decision can be reversed.

You have allowed cookies to be placed on your computer. This decision can be reversed.

To Dos

sdPP Element Description

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.
In the sdPP model, a set of “to-dos” is given with recommendations based on the best practices and lessons learned. This “to-dos” list tries to establish the tacit knowledge based on experience about the methodologies, reference frameworks and best practices. A “to-do” is neither an activity nor a part of the workflow (i.e. “work in pairs” cannot be an activity).
Copyright © 2017 Diego Martín. All Rights Reserved.