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:

  • Agile Modeling.
  • Establish and reiterate the same vision about the project among all team members.
  • Product Sheets: Marketers and requirements promote the early creation of product data sheets containing future budgets, comparisons, etc... to help clarify the physical limit, vision and definition of high-level requirements.
  • Track requirements in iterations.
  • Involve customer and product requirements.
  • Make brainstorming and / or brainwriting.
  • The development should be done in a common room, so it is necessary airy room with room for all members of the development team.
  • Within that room desks should be close to encourage open communication.
  • It must have white boards where you can draw freehand diagrams and models.
  • It must have a digital camera to film it drawn on whiteboards.
  • You should have a computer with two projectors (for which you need a dual graphics card).
  • All project support tools (wikis, server, etc...) Should be ready before the first iteration.
  • It should give a priority to each risk.
  • Use developments centered architecture (beginning and focus on it).
  • Use developments based on use cases.
  • Do not lose sight of the end system or intermediate milestones.
  • Having several development cycles for each production version.
  • Encourage customer relations.
  • Encourage self-directed teams.
  • The ideal speed is one that can be maintained indefinitely.
  • Simplicity is important.

Not to Dos:

  • Be clear about the difference between cascade development and iterative development, and not try to superimpose both types of development.
  • During the iteration changes can not by stakeholders.
  • Do not "fix" what is not broken, ie if the code works, do not waste time trying to improve it.
  • The dates for completion of each iteration can not be changed, are fixed.
  • Do not excessively enhance the process, believe in him and his immutability.
  • Do not create an excessive amount of documentation
  • Do not dispose of prototypes.
  • Do not set the time-boxes too big or small.
  • Do not put little emphasis on feedback.
  • Do not allow the estimation is made by sources outside the project.
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.