A software development process that is flexible, responsive to changing requirements and risk managed.
The demands on software developers in the 21st Century make it necessary to be both responsive to change while minimising the risks inherent in change. They must endeavouring to maintain a consistent approach whilst keeping up with current best practice.
Until recently many internet projects have been green field. As we move forward towards the next generation of internet projects they will be more like traditional software projects a mixture of green field development and legacy systems integration.
The 'green-field' nature of allows improvements to be made to the development processes based on modern flexible best practices. Iterative development is particularly suitable for these projects.
This process is best applied at development team level. This proposal will not effect the existing development platform, which will continue to utilise the existing development processes.
In the traditional 'waterfall' or 'big bang' development processes, all phases of the process are big including the risk. Iterative development processes seek to reduce the granularity of each phase of the project with requirements being tightly functional-boxed and time-boxed and delivered at production quality. These phases are iterated repeatedly to address the full functional requirements.
Iterative development mitigates risk by addressing the largest risk factors first in the earliest iterations. It recognises that process owners have constantly changing needs - requirements risk. Iteration allows constant review and makes a project responsive to changing requirements. It recognises that technology may be untested or evolving or unselected - Technology risk. Iteration allows constant review of technology risks, and makes a project responsive to changing technologies. It recognises that the development team will be learning both new technology and business processes during the project - skills risks. These combined risks result in a financial and political risk to the project. A highly iterative process can addresses a small subset of the requirements within each time-boxed iteration. These are identified, analysed, designed, implement, tested and delivered at production quality. The obligation to produce production quality artifact of a subset of the project requirements on a reference platform is important. It leads to rapid feedback and presents an early opportunity to adapt the project design and allows an early mitigation of risk.
The main features that drive an Iterative Development Processes are: - Requirements are Functionally-boxed as usecases. - Continuous involvement of domain expertise. - Time-box each iteration. - Test early, Test often. - Deliver early, Deliver often. - Each iteration is production quality artifact.
The early identification of technology and skill risks allows the high risk issues to be prioritised and addressed early in the project. These issues are addressed early and the risk mitigated, making progress easier to quantify and demonstrate. Political risk and financial risks are therefore mitigated.
All project participants gain an early understanding of the end-to-end development process, the project objectives, business workflow, the technology and the solution.
The early appearance of a production quality system allows stakeholders to evaluate progress, and provide feedback from operational systems. The project can adapt to problems and responding to feedback is an incremental change.
The early identification of system boundaries aids the of development of project architecture, which is subject to early reassessment. The architecture evolves quickly based on knowledge obtained from early iterations and can be subject to incremental improvement.
Continuous involvement of business domain experts and project sponsors allows for the continuous review and prioritisation of usecases. The highest priority usecases are addressed first. Usecases can be rescheduled to suit evolving or changing business needs. Expectations are constantly managed because progress is made very visible from the regular review of the production quality releases.
An iteration covers the full development cycle with limited sub-set of the requirements. It can be considered a micro-project. All iterations will include all activities of the full process though the balance between the various development activities will shift as project progresses.
Iterations are Usecase driven. A usecase is goal centred business scenario. The projects requirements are specified in usecases, project task planning is in usecases, the architectural model is enhanced by each usecase, and programmers produce modules based on usecases.
As iterations progress, integration of the various iterations into the project architecture is continuous, there is no no need for big project integration phase at the end of the project.
Each iteration is completed within the scheduled time-box. If an iteration is in danger of slipping, and/or time limited resources becomes a problem, risk analysis is used to assess which usecases should be be dealt as a priority and which are deferred to the next iteration.
The project plan is constantly adjusted to reflect both the evolving requirements and iteration contents.
Each Iteration is composed of four key activities. Inception, Elaboration, Construction and Transition. These activities are centred on the traditional skill competencies of a development team of Management, Analysis, Programming, Deployment.
The duration of an iteration time-box is typically fixed within a project but varies between projects based on the several factors, such as capability maturity, the complexity of the requirements, the amount of ceremony and the size of the development team and organisations culture. A single developer project with straightforward requirements may time-box in one week iterations. A large team with complex requirements will usually have long time-boxes, i.e. one month. The time-box duration should be determined during Inception.
Ceremony is how formalised a project or process is, does it require detailed project plan's ? Does it require formal documentation output ? Does it require formalised meetings ? The amount of ceremony required is not a factor of iterative development processes. Some Iterative processes like RUP are high-ceremony and produce a lot of written documentation, others such as Agile are notable for there lack of ceremony, and produce very little.
The amount of ceremony is governed by the organisations culture and the project management requirements. Some project require high ceremony others will require less. The amount of ceremony required for a project is determined during the first stage, Inception based on the management reporting and tracking required.
The objective of producing a production quality artifact at the end of each iteration means that continuous testing is an important element of iterative development processes. Complete unit, integration, regression and system testing is required during each iteration to ensure production Quality.