Difference between revisions of "Realisation Phase"

From EUDP
Jump to: navigation, search
(Why)
(How)
Line 16: Line 16:
 
'''The dish'''
 
'''The dish'''
  
Realisation Phase.  
+
Realising a complex project is best done in smaller parts.
  
'''Ingredients'''
+
By releasing smaller parts, or bites, of the total project the customer immediately sees progress and can correct any misunderstandings early.
  
*    All documentation, prototypes and other artefacts produced until the beginning  of the phase.  
+
Further, the developers works under a more constant, and typically lower, pressure with a more constant stress level by delivering smaller bites often.
 +
 
 +
For a detailed discussion of timeboxes see below.
  
'''Process'''
 
  
 
[[Image:Realisation.png|300px]]  
 
[[Image:Realisation.png|300px]]  
Line 32: Line 33:
 
'''''Delivering smaller bites of the project'''''
 
'''''Delivering smaller bites of the project'''''
  
Realising a complex project is best done in smaller parts.
 
  
By releasing smaller parts, or bites, of the total project the customer immediately sees progress and can correct any misunderstandings early.
+
'''Ingredients'''
  
Further, the developers works under a more constant, and typically lower, pressure with a more constant stress level by delivering smaller bites often.
+
*    All documentation, prototypes and other artefacts produced until the beginning  of the phase.  
  
For a detailed discussion of timeboxes see below.
+
'''Process'''
 +
 
 +
Realisation of the specifications requires involvement of a number of disciplines.  
  
 
'''''General planning'''''
 
'''''General planning'''''

Revision as of 09:34, 18 December 2012

What

Strategy And PlanningAnalysisDesignImplementationVerificationDeploymentRealisationPhase.png

How

The dish

Realising a complex project is best done in smaller parts.

By releasing smaller parts, or bites, of the total project the customer immediately sees progress and can correct any misunderstandings early.

Further, the developers works under a more constant, and typically lower, pressure with a more constant stress level by delivering smaller bites often.

For a detailed discussion of timeboxes see below.


Realisation.png

The realisation of the specifications into a product

Realisation-bites.png

Delivering smaller bites of the project


Ingredients

  • All documentation, prototypes and other artefacts produced until the beginning of the phase.

Process

Realisation of the specifications requires involvement of a number of disciplines.

General planning

Determine the number and length of the timeboxes.

  • The first one or two timeboxes may be of different length if further planning, analysis or other activities have to be carried out before the actual development can begin.
  • The implementation timeboxes should normally be of same length.
  • Add one last short timebox to cover issues discovered during the last one or two deployments.
  • Estimate the total number of timeboxes.
  • Assign the interruption shield (see below) to a developer if there is no formal project manager in the project. Inform the customer about the interruption shield and the procedure about handling inquiries.

Make a rough selection of which parts will be developed in which timeboxes - the development strategy. From the rough selection, plan the manning of each timebox. Coordinate the plan with the project organisation.

Planning in each timebox

At the beginning of each timebox, review the strategy, i.e. the selected parts that should be developed during the timebox. Often adjustments may be necessary due to knowledge gained during the past timeboxes. Some parts may be postponed and others may be advanced.

Plan the deployment with the customer. Encourage the customer to participate as much as s/he can in the deployment. Write down the deployment plan.

Plan the test scenario(s). Write down the tests that the product has to pass before deployment can be executed.

Review the manning plans and correct accordingly. Remember to coordinate with the rest of the organisation.

Analysis

Do the necessary analysis to gain enough insight and details to design and develop the selected parts. The MW, HW and SW developers work together during the analysis.

Design

Perform the recommended design tasks redesigning the general analysis results into implementable results. MW, HW and SW developers mostly work independently during design.

Implementation

Implement the design.

Verification

Verify the product using the tests written earlier in Verification Planning . Correct as necessary.

Deployment

In cooperation with the customer, deploy the product either at the customers site or in-house depending on the possibilities.

Post deployment

Spend a short time evaluating the just-closed timebox. What went well? Why did it go well? What caused problems? Can they be prevented in the future? And how can they be prevented?

Restart with the next timebox.

Why

Introduction

The Realisation Phase is typically the longest phase in the development. During the realisation, the system-to-be is constructed.

Timeboxes

It is our recommendation that the development is divided into smaller parts - timeboxes - rather than having one long development process covering all the activities. The timeboxes give a number of advantages over the long run such as:

  • The customer experiences stepwise progress in the development rather than one large delivery at the end of the development.
  • The frequent delivery enables the customer to try the system before it is totally implemented. As a result, the developer can get feedback early in the process rather than at the end of the development process.
  • It keeps the developers focus on the development by having the developer deliver to the customer frequently.
  • The developer will experience a number of welldefined tasks including verification planning, analysis, design, test specification and implementation which are repeated frequently. Consequently, focus will be on the quality of delivery in each deployment rather than postponing the verification and test activities until just before delivery of the final product.
  • The project management will, as the customer, experience stepwise identifiable progress in the development rather than progress based on the developer's feedback. In this way, the project management will have more detailed follow-ups available.

The timeboxes should normally be of two to six weeks in length depending of the expected total project length, the number of developers involved, the type of project, etc. As a rule of thumb, the following chart may be used to specify the length of each timebox:

TimeboxLengthSelection.png

Diagram for timebox length selection


It is recommended to have at least one short timebox at the scheduled end of the project to fix any minor bugs or misunderstandings found in the last one or two deployments.


RealisationTimeline.png

Example of timebox distribution

Manning

During the development, the manning of the timeboxes may vary. Hardware, for instance, is typically developed during the first timeboxes leaving the software developers realising their part during the later timeboxes, although the software developers can start working on parts early by writing stubs that simulates the hardware until its ready. The expected size of the effort to develop the software determines when the software developer starts.

Additional analysis and/or planning may often take place during the first one or two timeboxes requiring less manpower.

Planning

At the beginning of each timebox, it is essential to perform the planning thoroughly. The planning should mainly be done by the participating developers, thereby ensuring personal commitment to the plans leading to a high degree of self management. Consequently, less general project management is required.

It is recommended that the planning and specification of the verification is done before the actual implementation. For instance, it is essential that the test specifications are written based on the requirements rather than on what was actually implemented during the realisation.

Interruption Shield

The project management must provide a shield against interruption from the outside. The project team should concentrate on the main issue: developing the selected parts in the timebox. The project management should acknowledge the interruptions, but postpone the handling and decision process until the next planning activity is due.

Only very important interruptions should be allowed when passing through to the developers. Important interruptions could be of financial character introducing major changes for the project economy, or the product under development may not be of relevance to the customer in its current form any more.

If, for instance, a small organisation does not have a formal project management, one of the developers should be assigned the task of being a shield against outside interruptions.

The customer and other external stakeholders should be informed about and accept the practice of shielding the developers during a realisation timebox. If the customer, not knowing the working practice, expects immediate reaction from the developer, he may be disappointed when nothing happens until weeks later.

Customer Involvement

Another issue worth spending some effort on is to inform the customer about the expected involvement in each deployment. The customer should assign enough time to try and test the instalment supplied at each deployment. If the customer does not assign the necessary time to run through the instalment, errors or misunderstandings may arise without being discovered until late in the development process, thus requiring greater effort fixing the problem. Feedback from the customer should be acknowledged, but not handled immediately as noted above in Interruption Shield.

Continue with Strategy and Planning