Development Strategy

From EUDP
Jump to: navigation, search

What

DevelopmentStrategy.png

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

How

The dish

Choice of development strategy.

  • What to develop in which timebox
  • How many timeboxes

Ingredients

  • Artefacts from the 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 a long time to develop. Thus, you must begin with the hardware, but do not postpone the software development
    • The software developers can develop stubs that mimic the hardware until it is 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 the length of each timebox and decide what to develop in each timebox. Also, you should use the diagram on the Realisation Phase to decide on the length of the timeboxes.

Make sure that the strategy ensures that the development team is able to construct a coherent system that - when deployed - adds value to the customer at each deployment.

The blue feature take relatively shorter time to develop but has a high value for the customer whereas the red feature take considerably longer time to develop while not adding as much value as the blue in the figure below.

Customervalue.png

Customer value versus development time

The development strategy can focus on giving the customer a higher experienced value early in the development process as show in the graph below or it can, maybe due to necessary development of base features, give the customer a lower experienced value adding in the early phases.

ExperiencedCustomervalue.png

Different development strategies


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.