Assignment Table
The table shows correlation between principles and project phase or project review.
The "X" label means that the principle may be applied in the corresponding project phase.
| Nr. | Project phase/event | Plan | TestCreation Review | Code contribution | Test | Release Review | Retrospective |
| Principle | Opening | Development | Closure | ||||
| 1 | Continuous Integration | X | X | ||||
| 2 | Continuous Testing | X | X | ||||
| 3 | Milestones first | X | X | X | X | ||
| 4 | Plan is alive | X | X | X | X | X | |
| 5 | End Game | X | X | X | |||
| 6 | Retrospective | X | |||||
| 7 | Live Betas | X | |||||
| 8 | Consume your own output | X | X | ||||
| 9 | Community Involving | X | X | X | X | X | |
| 10 | New & noteworthy | X | X | ||||
| 11 | Dynamic team | X | X | ||||
| 12 | Component centric | X | X | ||||
| 13 | API First | X | X | ||||
| 14 | Build to last | X | |||||
| 15 | Always have a client | X | |||||
- Continuous Integration is used mostly in development period (code contribution and bug fixing) of the project life cycle, so the state of the project is kept consistent and up-to-date.
- Continuous Testing may be applied in development phase. Using of this principle means a well considered approach in developing of self-tested valid code.
- Milestones first. Definition of milestones starts in the plan phase. Therefore it affects the implementation and test phases. A review about achievement level of milestone should be made in retrospective.
- Plan is alive. Keeping the plan up-to-date is important in all phases. As good as possible the plan should be followed in the development phase, but if necessary the plan must be altered. The final version of the plan is available at the release review.
- End Game is the closing stage of the development phase. Everything closable in given time should be closed and nothing new is allowed to start. On time release review is purpose of all End Game activities.
- Retrospective. Application of this principle means an additional phase “Retrospective” at the end of the development cycle. In this phase the team analyses went wrong and what was good to improve the approach in the next iteration.
- Live Betas in more an iteration in-between principle. Every new release (small or big) should be offered to community (or user) to use and test it as well as provide feedback.
- Consume your own output: if possible use own written frameworks in the development, even as milestone or nightly builds.
- Community Involving should be applied in all phases: in development with bug reports and feature suggestions, in release review as community event and in retrospective with analyse of user interaction.
- New & noteworthy announces of project events like new version or creation of new projects in the community to attract attention and wake interest.
- Dynamic team principle is applied in the development phase. The team is responsible for all parts of the task: design, implementation, test and integration into main project stream.
- Component centric principle can be applied in development and in plan phases. Components must be identified and plan for there implementation should be created.
- API First lies near to component centric principle. Designing of API and creation of plan for implementation belongs to opening period and modification of API in the development phase.
- Build to last: Use short iteration with continuous quality analysis in the retrospective phase to keep the complexity under control and maintain high quality level.
- Always have a client. All implemented features and functionalities must be requested by someone. This principle is used mostly in the development phase to reduce the complexity.
Assignment Schema
The image shows main association between principles.
