Inception phase
The purpose in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.
There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
intended solution [KRO03]:
-
Understand what to build. Determine an overall vision, including the scope of the system and
its boundaries. Identify the stakeholders: who is interested in this system and what are their success
criteria?
-
Identify key system functionality. Decide which requirements are most critical.
-
Determine at least one possible solution. Assess whether the vision is technically
feasible. This may involve identifying a candidate high-level architecture or doing technical prototypes,
or both.
-
Understand the high-level estimate for cost, schedule, and risks associated with the project.
Key considerations
Projects may have one or more iterations in the Inception phase. These are among the reasons for multiple iterations:
-
Project is large, and it is hard to define its scope
-
Unprecedented system
-
Too many stakeholders with competing needs and complex relationships
-
Major technical risks demand the creation of a prototype or proof of concept
There are some commonly observed counterproductive patterns during the Inception phase. Some teams postpone
providing estimates until they analyze the entire domain and have written a large amount of requirements documentation.
This behavior often leads to "analysis paralysis." Another pattern is poor planning of Inception iterations. Avoid such
patterns by planning iterations during Inception in a way that iterations are risk-driven, include early integration
and testing, and produce a product increment that you can demonstrate to stakeholders. By default, have one
(potentially short) iteration in Inception to avoid analysis paralysis.
Construction phase
The purpose in this phase is to complete the development of the system based upon the baselined architecture.
"Agile elaboration" is a potential reordering of some work items to push the technically risky ones to the top of
the stack and then holding an explicit milestone check to ensure that you've proven the architecture during the early
part of the Construction phase.
There are objectives for the Construction phase that help us to have cost-efficient development of a complete
product -- an operational version of your system -- that can be deployed in the user community [KRO03]:
-
Iteratively develop a complete product that is ready to transition to its user community. Describe remaining
requirements, fill in design details, complete the implementation, and test the software. Release the first
operational version (beta) of the system and determine whether users are ready for the application to be deployed.
-
Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development
parallelism between developers or teams of developers by, for example, assigning components that can be developed
independently of one another.
Key considerations
Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
projects:
-
Simple project: One iteration to build the product (to a beta release)
-
More substantial project: One iteration to expose a partial system and one to mature it to beta testing
-
Large project: Three or more iterations, depending upon the size of the project (number of requirements to
implement for a beta release)
Transition phase
The purpose in this phase is to ensure that the software is ready for delivery to users.
There are objectives for the Transition phase that help you to fine-tune functionality, performance, and overall
quality of the beta product from the end of the previous phase [KRO03]:
-
Beta test to validate that user expectations are met. This typically requires some fine-tuning
activities, such as bug-fixing and making enhancements for performance and usability.
-
Achieve stakeholder concurrence that deployment is complete. This may involve various levels
of tests for product acceptance, including formal and informal tests and beta tests.
-
Improve future project performance through lessons learned. Document lessons learned and
improve the process and tool environment for the project.
Key considerations
The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting
business processes.
The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
make the business transition from using the old system to using the new system.
When the Transition phase objectives are met, the project can be closed. For some products, the end of the current
project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation of the same
product.
|