Difference between revisions of "Development Strategy"
(New page: == What == To find the development strategy. What to develop in which timebox. How many timeboxes. == How == '''The dish''' To find the development strategy. * What to develop...) |
(→How) |
||
| (24 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
== What == | == What == | ||
| − | + | [[Image:DevelopmentStrategy.png|300 px]] | |
| + | |||
| + | Choosing the direction of the project. Strategy is the long-term overall plan for what is to be developed at what time. | ||
== How == | == How == | ||
| Line 8: | Line 9: | ||
'''The dish''' | '''The dish''' | ||
| − | + | Choice of development strategy. | |
| − | * What to develop in which timebox | + | * What to develop in which timebox |
| − | * How many timeboxes | + | * How many timeboxes |
'''Ingredients''' | '''Ingredients''' | ||
| − | * | + | * Artefacts from the [[Launch Phase]] |
| − | + | * Artefacts developed in previous timeboxes | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
'''Process''' | '''Process''' | ||
| Line 32: | Line 23: | ||
To find the best development strategy, you must consider the following aspects: | 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 | + | * Find a central part in the system-to-be. This must be developed in order to keep all developers busy |
| − | * Find the parts which will take the longest time to develop. These parts must be developed soon enough to complete the project | + | ** 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 |
| − | * Select the parts with the highest risk impact, and plan the implementation of these parts early in the development process | + | ** 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. | |
| + | |||
| + | [[Image:Customervalue.png | 200px]] | ||
| + | |||
| + | '''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. | ||
| + | |||
| + | [[image:ExperiencedCustomervalue.png|600px]] | ||
| + | |||
| + | '''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 == | == 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 == | == Example == | ||
| + | |||
| + | [[Image:DevelopmentStrategyPlan.png|600px]] | ||
| + | |||
| + | '''An incomplete development strategy''' | ||
| + | |||
| + | [[Verification Planning]] is the next important step. | ||
Latest revision as of 13:30, 10 December 2015
What
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.
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.
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
An incomplete development strategy
Verification Planning is the next important step.
