vault backup: 2025-01-07 12:32:04

This commit is contained in:
2025-01-07 12:32:04 +01:00
parent 14441bc1de
commit 1b8e503f63
10 changed files with 82 additions and 4 deletions

View File

@@ -111,6 +111,80 @@ Most projects have a score <50.
### Survival Concepts
> [!Quote]
> An investment made in process at the beginning of the project produces large returns later in the project
Processes are important because they make the development more productive and resistant in the long term. Example processes are:
- formally write down requirements
- use a procedure to control additions and changes to the requirements
- Do reviews of all requirements, designs and source code
- Develop a written *Quality Assurance Plan*, including a *test plan*, *review plan* and a *defect tracking plan*.
- Create an *implementation plan* that defines in which order the components are developed.
- Automated source code control (e.g. git)
- Revise Cost and schedule after each milestone
If teams do not invest in process at the beginning of the project, the amount of time spent for process and thrashing (i.e. unproductive time) will increase (see Figure 3-3).
![[Pasted image 20250107114628.png]]
On the contrary, teams which establish processes in the beginning (overhead) will spend less and less time on thrashing and processes as the project moves on.
![[Pasted image 20250107114616.png]]
> [!Quote] Overhead of a cancelled Project
> If you think that attention to process is needless overhead, consider that the overhead of a canceled project is 100 percent.
> [!warning] Opposite Views
> - Processes limit developer's creativity
> - --> Set up an environment where creativity is still possible.
> - Developers feel best in environments where they are the most productive.
> - Research shows that in regulated environments people feel more productive.
#### Upstream and Downstream
Upstream contains all early work of a project, such as requirements definition and architecture design. Downstream refers to later parts such as construction and system testing.
Defects cost more (50-200 times more), the earlier in the project they are inserted as illustrated in the figure below.
![[Pasted image 20250107120429.png]]
Please note that the cost grows exponentially, which multiplies the effect.
> [!Quote]
> Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture.
Remember that just because no code is being written in the beginning that doesn't mean it is delaying the real work, but rather it is laying the groundwork for the project's success.
Erring on the side of too much process is marginally more expensive, versus erring on too little process can be way more expensive (50-200x) in the long run. This is because of the *cone of uncertainty*, which illustrates that upstream decisions affect downstream decisions, but not vice-versa.
![[Pasted image 20250107121222.png]]
> [!Quote]
> Early in the project you can have firm cost and schedule targets or afirmfeature set, but not both.
> [!question] Survival Check - Survival Test
> - 👍🏼 Project leadership understands the critical role of well-defined processes and supports them.
> - 👍🏼 The project's processes are generally oriented toward detecting as many problems upstream as possible.
> - 👍🏼 Project leadership recognises that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses.
### Survival Skills
Software projects are inherently complex and therefore need to be planned, controlled and made sure that the progress is visible, people are supported to do the project's work.
The risks should be tracked and constantly redeveloped.
#### Planning
#### Risk Management
#### Project Control
#### Project Visibility
#### Peopleware
#### User Involvement
#### Product Minimalism
#### Focus on Shipping Software
---
```query
Software Project Survival Guide Steve McConnell