SpecDD Principles

SpecDD is created based on a foundation and a set of principles derived from that foundation.  The foundation is not meant to be modified. The principles are the best practice guidelines, and are used as the skeleton to create the detailed framework.  The principles are more flexible.

 

The foundation of SpecDD

  • SpecDD enhances but does not replace traditional development: projects should be managed based on the project needs. 
  • Development should be balanced with documentation and process management.
  • The primary purpose of being agile is to be able to quickly respond to change and to minimize the cost of change.  SpecDD systematically creates a model where requirements are quantified, change happens at the concept level, any coding and QA testing change must follow the requirement changes.
  • Good development is the result of both defined and empirical processes where the important development factors are equal: people, interactions, process, workflow, working software and documentation.
  • The primary goals of a development methodology are to better assure both short term and long term project success.
  • Principles are created to achieve such goals above in a more disciplined and scientific way.   SpecDD provides guideline and rules for other contributors to modify its principles.
  •  

 

Working software and improving product design

  • A development iteration has two deliverables: working software and an ever-improving product design.
  • Deliver working software frequently. (2-4 weeks are recommended for each iteration.)
  •  

  • Quantified designs are the only standard for driving development, design, and QA testing.  Working software is the primary measure of progress.
  • Continuous attention to technical excellence and good design enhances agility and quality
  • Simplicity and consistency:  working software can be interpreted to be a set of specifications already developed. The remaining work of a project can be represented as set of specifications already created, needing to be improved, or to be created.

 

Welcome change and document management

  • We welcome changing requirements, even late in the iteration
  • Change should be made at the requirement level first
  • The driving factors of change are customers, product owners, and the working software itself
  • Change can result in development work for future iterations as well as the current iteration

 

People, interactions, tools, and process management

  • Effective communications via face to face meeting and embracing specifications as a standard that drives development, planning, and QA testing work.
  • Build project around motivated individuals.  Trust them and also support them with automation tools, and standardized workflow rules
  • Well managed teams help to optimize development processes and increase quality
  • Sustainable development comes form the optimal organization of people, interactions, process, workflow, and effective tools
  • Workflow, and daily practices enhance teamwork
  • Development tools help to make mature and repeatable processes and help to improve work efficiency

 

When should you modify SpecDD Principles?

    SpecDD is built on a belief that a development methodology needs to be open for change for its principles the framework details.  Changing the principles should be controlled and should following the SpecDD governing foundation.

    The following are the guidelines to modify SpecDD principles:

  • If modifying the principles helps companies to better and more effectively and more scientifically manage their development process.
  • If modifying the principles helps to better achieve development results without losing the principle that development is agile, yet balanced with design and conceptual level documentation.
  • If modifying the principles helps companies to better promote or unify agile development practices with waterfall and iterative development needs
  • If modifying the principles better fit development culture of a team and their local environment