Difference between revisions of "Development Strategy"

From EUDP
Jump to: navigation, search
(How)
(How)
Line 31: Line 31:
 
Considering these aspects, you must find out how long each timebox shall be and decide what to develop in each timebox. Also use the diagram on [[RealisationPhase]] to decide on the length of the timeboxes.
 
Considering these aspects, you must find out how long each timebox shall be and decide what to develop in each timebox. Also use the diagram on [[RealisationPhase]] to decide on the length of the timeboxes.
  
 +
Ensure that the strategy ensures that the development team construct a coherent system, that when deployed adds value to the customer at every deployment.
  
 
The strategy also includes problematics concerning bus, memory, power supply, interfaces, protocols, etc.
 
The strategy also includes problematics concerning bus, memory, power supply, interfaces, protocols, etc.

Revision as of 08:37, 21 October 2014

What

DevelopmentStrategy.png

Decide the direction for the project. Strategy is the long term overall plan for what is to be developed at what time.

How

The dish

To decide the development strategy.

  • What to develop in which timebox.
  • How many timeboxes.

Ingredients

  • Artefacts from Launch Phase
  • Artefacts developed in previous timeboxes

Process

To find the best development strategy, you must consider the following aspects:

  • Find a central part in the system-to-be. This must be developed in order to keep all developers busy
    • Hardware is often a central part and usually takes quite long time to develop, hence it must be started first, but do not postpone software development
    • The software developers can develop stubs that mimics the hardware until it becomes ready for them to use
  • Find the parts which will take the longest time to develop. These parts must be developed soon enough to complete the project according to schedule
  • Select the parts with the highest risk impact (see Risk Management), and plan the implementation of these parts early in the development process

Considering these aspects, you must find out how long each timebox shall be and decide what to develop in each timebox. Also use the diagram on RealisationPhase to decide on the length of the timeboxes.

Ensure that the strategy ensures that the development team construct a coherent system, that when deployed adds value to the customer at every deployment.

The strategy also includes problematics concerning bus, memory, power supply, interfaces, protocols, etc.

  • The use of uniform busses, e.g. I2C, RS232, etc. This sets higher hardware standards if more circuits need special features
  • The use of uniform power supply voltages, which makes a simpler power supply
  • The memory management is important in order to make it possible to develop the software
  • Usage of standardised protocols eliminates many errors in the protocol specification it self


In every timebox, some errors are made

  • Make an error list and classify the errors
  • Decide and plan when errors shall be handled with


If new ideas are found, these must be considered

  • Decide if they should be implemented or not?
    • If the new ideas will be implemented, it must be in according with the project plan
    • If the project will be behind schedule, then it must be accepted by the costumer


For every timebox reconsider the strategy

  • Is the strategy consistent with the experience so far?
  • Does some parts of the strategy have to be reorganised in order to enable critical part(s) to be developed earlier in the project
  • Has new ideas and errors changed the order of implementation

Why

In order to make the best and most economic design, it is important to find the best development strategy. With a wrong strategy, the project will take longer and cost more money. Some developers may not be able to work if some parts are not developed/implemented in time. In order to save time and money it is, therefore, essential to spend some time finding the best strategy and order of development.

It is also important regularly to examine the strategy and reconsider if it still is the optimal way of implementing the parts that eventually will be the final product. We recommend this to be done at every start of a new timebox, because it is a convenient time to take the broad overlook of the remaining project.

During development things may change or the developers discover issues so a reorganisation of the strategy becomes necessary. As long as the final deadline can be kept there is no problem in reorganising the strategy. Note the reason in the process documentation and perform the reorganisation. If the deadline has to be moved this can only be done in cooperation with the customer.

Example

DevelopmentStrategyPlan.png

An incomplete development strategy

Verification Planning is the next important step.