vault backup: 2025-01-08 15:43:38
This commit is contained in:
1
.obsidian/plugins/text-extractor/cache/398fb71276dcc57b25f3b7ef3eb1cae9.json
vendored
Normal file
1
.obsidian/plugins/text-extractor/cache/398fb71276dcc57b25f3b7ef3eb1cae9.json
vendored
Normal file
@@ -0,0 +1 @@
|
||||
{"path":"Attachments/Pasted image 20250108151953.png","text":"‘ % \\ÿ\\\\ » \\ Discovery N \\ \\‘*\\\\\\.\\ NN S e \\A N_ D Development SN \\ NN \\:\\ Focus \\\\\\ N N \\\\ N SSN \\ÿ_\\ \\\\\\\\ \\\\‘\\%\\\\ _\\\\‘ ._\\» , \\-.\\‘ . \\\\\\\\‘ N ) -\\\\\\ x SS S ASSS T ÉSSSX PS Schedule FIGURF 5-1 Conceptual phases ofa software project. The kind of work performed during each phase of the project vanes, but each kind of work occurs to some extent throughout the project.","libVersion":"0.3.2","langs":"deu+eng+fra"}
|
||||
2
.obsidian/workspace.json
vendored
2
.obsidian/workspace.json
vendored
@@ -544,6 +544,7 @@
|
||||
"lastOpenFiles": [
|
||||
"0 Journal/Meetings/Vidit Update - 8.1.24.md",
|
||||
"5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md",
|
||||
"Attachments/Pasted image 20250108151953.png",
|
||||
"Attachments/Pasted image 20250108110043.png",
|
||||
"Temporary/Vidit Update - 8.1.24.md",
|
||||
"2 Personal/Lists/Business Ideas.md",
|
||||
@@ -577,7 +578,6 @@
|
||||
"5 Media/0 Books/Surrounded by Idiots by Thomas Erikson.sync-conflict-20241025-131108-LIUMLEB.md",
|
||||
"Attachments/Pasted image 20241118160705.png",
|
||||
"Attachments/Pasted image 20241118143053.png",
|
||||
"Attachments/Pasted image 20241118142001.png",
|
||||
"Attachments/Gym-Rings-UK.pdf",
|
||||
"99 Work/Jobhunt/Applications",
|
||||
"99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Robotics/Sensors",
|
||||
|
||||
@@ -235,21 +235,79 @@ The visibility is the ability to determine a project's true status, which will g
|
||||
- Is the project on track to achieve goals?
|
||||
- Are we within 10% of budget and schedule or only within 50%?
|
||||
|
||||
Good visibility does not come automatically, you have to plan for it!
|
||||
|
||||
Activities that help achieve visibility:
|
||||
- Vision Statement
|
||||
- Hold a planning checkpoint review after 10% of the project
|
||||
- Regularly compare actual performance against planned performance to check if plan is working and adapt if necessary.
|
||||
- Use binary milestones: they are either done or not done
|
||||
- Drive the project to a releasable state periodically to show project's true condition
|
||||
- revise estimates after each phase to improve planning with more information
|
||||
#### Peopleware
|
||||
The development team needs to be on board in order for the project to succeed. Guidelines to consider the human aspect in software development:
|
||||
- Align Developers' Interest with Work Assignments:
|
||||
- Make work *interesting*
|
||||
- Make *possible goals*: developers usually are realistic and are demotivated by goals that are out of reach
|
||||
- Show developers that you sincerely appreciate them
|
||||
- don't use cheerleading campaigns, impossible challenges or monetary rewards
|
||||
- Provide Thinking-oriented office space
|
||||
- the process is one of continuous discovery and invention --> create atmosphere which is supportive.
|
||||
- Space where developers can concentrate
|
||||
- Avoid open work bays
|
||||
- allows deep concentration
|
||||
- install soda machine or hang out zone for when they don't need to concentrate to foster communication and inspirational discussions.
|
||||
|
||||
#### User Involvement
|
||||
Don't assume you know what the user wants! Marketers want too many features such that the essential features cannot be found anymore, Developers create technical features that user's don't care about.
|
||||
- Ask users what they want, show them what they intend to build and ask how they like it. Then listen carefully until you fully understand the stated and unstated elements of the users' reponses
|
||||
- Identifying who the user is might be difficult
|
||||
- user needs to be open to mock-ups (very crude prototype)
|
||||
- Adopt easy features and changes immediately and implement larger more complicated changes later on.
|
||||
|
||||
User involvement saves time because it eliminates a large source of requirement changes: features that no-one needs.
|
||||
|
||||
#### Product Minimalism
|
||||
Focus on simplicity. Simple solutions are always better than complicated ones.
|
||||
- Focus on taking away components of the software to make it simpler, rather than adding elements to make it more complex.
|
||||
|
||||
#### Focus on Shipping Software
|
||||
A company makes money by *shipping* software *not by developing* it!
|
||||
|
||||
|
||||
> [!question] Survival Check - Survival Skills
|
||||
> - 👍🏼 Project Team creates a detailed written plan, designed to eliminate potentially costly problems early in the project.
|
||||
> - 👍🏼 Project emphasizes the importance of upstream work holding a *Planning checkpoint review* to make a go / nogo decision when the project is about 10 percent complete.
|
||||
> - 👍🏼 Project practices active risk management
|
||||
> - 👍🏼 project plan emphasizes visibility and control
|
||||
> - 👍🏼 project plan involves real users early and throughout the journey
|
||||
> - 👍🏼 project is conducted in a productive environment
|
||||
> - 👍🏼 project plan calls for a simple-to-complex approach rather than the reverse.
|
||||
|
||||
### Successful Project at a Glance
|
||||
- source code tends to grow in a S-shaped curve where most of the code is written in the middle third of the project.
|
||||
- Staged delivery: ship important functionality fist
|
||||
- keep tabs on clearly defined milestones and deliverables
|
||||
|
||||
#### Intellectual Phases
|
||||
Different phases of a project have different characteristics. They need to overlap somehow, but we don't want them to overlap too much either.
|
||||
![[Pasted image 20250108151953.png]]
|
||||
|
||||
#### Project Flow
|
||||
Staged delivery!
|
||||
We want to ship staged versions of the software continuously in order to deliver something that works and improve upon it (ideally with more user feedback).
|
||||
Each stage is released after detailed design, coding, debugging and thorough testing.
|
||||
##### Benefits of Staged Delivery
|
||||
1. Critical functionality is available earlier:
|
||||
Because it is usually in the first deliverables.
|
||||
2. Risks are reduced early:
|
||||
at each stage we have the integration of the different parts which means that different parts of the software are continuously brought onto the same page. You also create tangible signs of progress at frequent intervals.
|
||||
3. Problems become evident early:
|
||||
You get frequent progress reports which show critical problems that can be addressed early. You will also see if the development team struggles, if they miss the deadline for the first deliverables.
|
||||
4. Status-reporting overhead is reduced:
|
||||
Shipped and working software is a more accurate status report than a paper report.
|
||||
5. Makes More Options Available: you have releasable software at all times, meaning if you want to release something is is much less work than if you don't
|
||||
6. Reduces possibility of estimation error
|
||||
---
|
||||
```query
|
||||
Software Project Survival Guide Steve McConnell
|
||||
|
||||
BIN
Attachments/Pasted image 20250108151953.png
Normal file
BIN
Attachments/Pasted image 20250108151953.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 615 KiB |
Reference in New Issue
Block a user