Difference between revisions of "SSA Overarching Thoughts"
From Agile Systems Engineering Wiki
(Created page with "==Some structure to our thoughts== *We were talking at different levels **Doing agile for different reasons (different whys) **Applying it to different levels of system (diffe...") |
(→Alignment) |
||
Line 31: | Line 31: | ||
==Alignment== | ==Alignment== | ||
*Some elements align, some don’t | *Some elements align, some don’t | ||
− | *See grids | + | *See grids below |
{|class="wikitable" | {|class="wikitable" | ||
|- | |- |
Latest revision as of 22:22, 13 October 2014
Contents |
[edit] Some structure to our thoughts
- We were talking at different levels
- Doing agile for different reasons (different whys)
- Applying it to different levels of system (different whats)
- Using different underpinning approaches (different hows)
- Some elements line up, some don’t
[edit] Different whys
- The SE process is time-consuming and boring, we want to start building stuff immediately
- I need to deliver something within my length of tour – and agile is the only possible was to get something!
- The system’s environment will change after we deploy the solution, we need to keep updating the system to remain effective
- The customer and users are unable to define the requirements up front as their understanding of what they need will change as we develop the system
- Getting something out there early Deliver a new product using SE with the non value added and time-consuming elements removed is better than waiting the for perfect solution late
- Because it is the next ‘silver bullet’ we need to be doing
[edit] Different whats
- What is the system of interest?
- The ‘user interface’ / mission software
- All the software
- A subsystem
- The product system
- The operational capability
[edit] Different hows
- Ignore the formal SE process, it’s just useless bureaucracy
- Selectively ‘value engineer’/tailor the SE process to focus effort on the greatest value adding elements of SE
- Buy of the shelf kit
- Split the development into different stages and develop each stage within a fixed timebox, progressively integrate each stage as they are developed, confirm it works prior to final acceptance
- Split the development into different stages, develop, deploy and evaluate each stage within a fixed timebox
- Split technology development and product development.
- Develop a high-level ‘integration architecture’
- Develop sub-systems/technologies as stand alone workstreams
- Launch products at defined points driven by marketing/planners. At a fixed pointy prior to product release selecting the most mature/relevant technology available. Undertake system integration, manufacture and launch.
[edit] Alignment
- Some elements align, some don’t
- See grids below
The ‘user interface’ / mission software | All the software | A subsystem | The product system | The operational capability | |
---|---|---|---|---|---|
The SE process is time-consuming and boring, we want to start building stuff immediately | Supports | Supports | Supports | Supports | Supports |
I need to deliver something within my length of tour – and agile is the only possible was to get something! | Supports | Supports | Supports | Supports | Supports |
The system’s environment will change after we deploy the solution, we need to keep updating the system to remain effective | Doesn’t support | Doesn’t support | Doesn’t support | Supports | Supports |
The customer and users are unable to define the requirements up front as their understanding of what they need will change as we develop the system | Supports? | Doesn’t support | Doesn’t support | Supports | Supports |
Getting something out there early Deliver a new product using SE with the non value added and time-consuming elements removed is better than waiting the for perfect solution late | Supports? | Doesn’t support | Doesn’t support | Supports | Supports |
Because it is the next ‘silver bullet’ we need to be doing | Supports | Supports | Supports | Supports | Supports |
The SE process is time-consuming and boring, we want to start building stuff immediately | I need to deliver something within my length of tour – and agile is the only possible was to get something! | The system’s environment will change after we deploy the solution, we need to keep updating the system to remain effective | The customer and users are unable to define the requirements up front as their understanding of what they need will change as we develop the system | Getting something out there early Deliver a new product using SE with the non value added and time-consuming elements removed is better than waiting the for perfect solution late | Because it is the next ‘silver bullet’ we need to be doing | |
---|---|---|---|---|---|---|
Ignore the formal SE process, it’s just useless bureaucracy | Supports | Supports | Doesn’t support | Doesn’t support | Doesn’t support | Supports |
Selectively ‘value engineer’/tailor the SE process to focus effort on the greatest value adding elements of SE | Supports | Supports | Doesn’t support | Doesn’t support | Supports | Supports |
Buy of the shelf kit | Supports | Supports | Doesn’t support | Doesn’t support | Supports | Supports |
Split the development into different stages and develop each stage within a fixed timebox, progressively integrate each stage as they are developed, confirm it works prior to final acceptance | Doesn’t support | Doesn’t support? | Doesn’t support | Supports | Doesn’t support | Supports |
Split the development into different stages, develop, deploy and evaluate each stage within a fixed timebox | Supports? | Supports | Supports | Supports | Supports | Supports |
Split technology development and product development | Doesn’t support | Doesn’t support? | Supports | Supports | Supports | Supports |