vault backup: 2025-02-05 14:38:06
This commit is contained in:
@@ -0,0 +1,91 @@
|
||||
---
|
||||
title: Atomic Habits by James Clear
|
||||
created_date: 2024-10-23
|
||||
updated_date: 2024-10-23
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Atomic Habits
|
||||
author: James Clear
|
||||
status: not_started
|
||||
---
|
||||
# Atomic Habits by James Clear
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> **Atomic Habits by James Clear** is about using the power of habits as a system to incrementally become the person you want to be by leveraging the compounding nature of habits. The core idea is to find good habits and make them *obvious, attractive, easy and satisfying*, as well as identifying your bad habits and making them *invisible, unattractive, hard and unsatisfying*. Personally, a key takeaway is to get started doing a habit as soon as possible, by starting smaller than what your end goal is (read 1 page instae, without trying to optimise everything beforehand.
|
||||
|
||||
Missing: Identity, Environment, ...
|
||||
## Cheatsheet
|
||||
### How to create a good habit
|
||||
|
||||
| **The 1st Law** | **Make It Obvious** |
|
||||
| --------------- | -------------------------------------------------------------------------------------- |
|
||||
| 1.1 | Fill out the Habits Scorecard. Write down your current habits to become aware of them. |
|
||||
| 1.2 | Use implementation intentions: "I will [BEHAVIOR] at [TIME] in [LOCATION]." |
|
||||
| 1.3 | Use habit stacking: "After [CURRENT HABIT], I will [NEW HABIT]." |
|
||||
| 1.4 | Design your environment. Make the cues of good habits obvious and visible. |
|
||||
|
||||
|**The 2nd Law**|**Make It Attractive**|
|
||||
|---|---|
|
||||
|2.1|Use temptation bundling. Pair an action you want to do with an action you need to do.|
|
||||
|2.2|Join a culture where your desired behavior is the normal behavior.|
|
||||
|2.3|Create a motivation ritual. Do something you enjoy immediately before a difficult habit.|
|
||||
|
||||
|**The 3rd Law**|**Make It Easy**|
|
||||
|---|---|
|
||||
|3.1|Reduce friction. Decrease the number of steps between you and your good habits.|
|
||||
|3.2|Prime the environment. Prepare your environment to make future actions easier.|
|
||||
|3.3|Master the decisive moment. Optimize the small choices that deliver outsized impact.|
|
||||
|3.4|Use the Two-Minute Rule. Downscale your habits until they can be done in two minutes or less.|
|
||||
|3.5|Automate your habits. Invest in technology and one-time purchases that lock in future behavior.|
|
||||
|
||||
| **The 4th Law** | **Make It Satisfying** |
|
||||
| --------------- | --------------------------------------------------------------------------------------------- |
|
||||
| 4.1 | Use reinforcement. Give yourself an immediate reward when you complete your habit. |
|
||||
| 4.2 | Make "doing nothing" enjoyable. When avoiding a bad habit, design a way to see the benefits. |
|
||||
| 4.3 | Use a habit tracker. Keep track of your habit streak and "don't break the chain." |
|
||||
| 4.4 | Never miss twice. When you forget to do a habit, make sure you get back on track immediately. |
|
||||
|
||||
### How to Break a Bad Habit
|
||||
|
||||
| **Inversion of the 1st Law** | **Make It Invisible** |
|
||||
| ------------------------ | -------------------------------------------------------------------------- |
|
||||
| 1.5 | Reduce exposure. Remove the cues of your bad habits from your environment. |
|
||||
|
||||
| **Inversion of the 2nd Law** | **Make It Unattractive** |
|
||||
| ------------------------ | ------------------------------------------------------------------------- |
|
||||
| 2.4 | Reframe your mindset. Highlight the benefits of avoiding your bad habits. |
|
||||
|
||||
| **Inversion of the 3rd Law** | **Make It Difficult** |
|
||||
| ------------------------ | ----------------------------------------------------------------------------------- |
|
||||
| 3.6 | Increase friction. Increase the number of steps between you and your bad habits. |
|
||||
| 3.7 | Use a commitment device. Restrict your future choices to the ones that benefit you. |
|
||||
|
||||
| **Inversion of the 4th Law** | **Make It Unsatisfying** |
|
||||
| ---------------------------- | ------------------------------------------------------------------------------ |
|
||||
| 4.5 | Get an accountability partner. Ask someone to watch your behavior. |
|
||||
| 4.6 | Create a habit contract. Make the costs of your bad habits public and painful. |
|
||||
|
||||
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
Personally, a key takeaway is to get started doing a habit as soon as possible by starting smaller than what your end goal is (read 1 page, instead of 1 hour). All this without trying to optimise everything beforehand ([[analysis paralysis]]).
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Atomic Habits James Clear
|
||||
-file: "Atomic Habits by James Clear.md"
|
||||
```
|
||||
@@ -0,0 +1,44 @@
|
||||
- Man muss Geld ausgeben um Geld zu verdienen
|
||||
- Kapitalismus ist eng verknüpft mit Spezialisierung, da dadurch mehr produziert werden kann, günstiger angeboten werden kann und somit mehr Geld verdient werden kann. ![[image 14.jpg]]
|
||||
- Die unsichtbare Hand beschreibt den Wettbewerb, den die Unternehmer dazu bringt faire Preise anzubieten, auch wenn sie die Kunden ausnehmen möchten. Sonst laufen die Kunden zu der Konkurrenz.
|
||||
- Die Grenzen des Marktes gemäss [[Adam Smith]], heisst Aufgaben des Staates:
|
||||
- Zinssatz deckeln: sonst gamblen die Leute auf hohe Profite
|
||||
- Kriegsnahe Industrien fördern, um bereit zu sein
|
||||
- Lohnarbeiter schützen, weil sie eine schlechtere Verhandlungsposition haben
|
||||
- Ehrlichkeit der Banken garantieren
|
||||
- Patente garantieren
|
||||
- Neue Industrien schützen
|
||||
- Krankheiten bekämpfen
|
||||
- Volksbildung garantieren und Massstäbe setzen
|
||||
- Für öffentliches Vergnügen sorgen
|
||||
- Hohe Preise (Inflation) und niedrige Löhne sind daselbe —> *Reallohn*
|
||||
- Der Gesellschaft geht es besser wenn die Mehrheit (Arbeitsnehmer) gute Löhne haben
|
||||
- Vorschläge für Gesetzesänderungen immer mit Misstrauen betrachten, da sie oft von Kapitalisten kommen, die durchs Eigeninteresse mehr Profit wollen und die Gesellschaft unterdrücken wollen
|
||||
- Die freie Wirtschaft für Smith war die Wirtschaft in der staatliche Gesetze nicht den Kapitalisten einen Vorteil verschafften —> er wollte die Gesetze entfernen um eine faire freie Wirtschaft aufzubauen. (Also keine staatlich geförderte Monopole, keine Regulierungen, Subventionen, etc die einzelne Profiteure hatte)
|
||||
- Komparativer Kostenvorteil von [[David Ricardo]]:
|
||||
- Internationaler Handel: Fokus auf effiziente Güter: auch wenn ich da ein Produktivitäts Nachteil habe ist dieser geringer und somit profitiere ich
|
||||
- [[Klassische Politische Ökonomie]]
|
||||
|
||||
---
|
||||
Der erste Börsencrash/Flaute war weil die Leute kein Geld hatten um Waren zu kaufen, und somit wurde weniger produziert und weniger Leute angestellt —> ein Teufelskreis
|
||||
|
||||
Man konnte nicht einfach mehr Geld drucken wegen den Goldstandard: das Papiergeld ist an die Menge Gold gekoppelt.
|
||||
|
||||
Geld ist nur dann etwas wert, wenn man vertraut damit etwas anderes kaufen zu können, weil andere Leute auch vertrauen, dass es funktioniert.
|
||||
|
||||
Durch die Mindestreserven (sagen wir mal 20%) bei einer Bank kann Geld mittels Schuldscheinen generiert werden. $1000 in cash wird dann zu $5000 fiktivem Geld, welches im Umlauf ist. Solche Kredite kurbeln die Wirtschaft an.
|
||||
|
||||
Bourgoisie: die Kapitalisten
|
||||
Proletariat: die Arbeiter, die verarmte Masse
|
||||
|
||||
1848 gab es viele Revolutionen, die Idee war, dass das Proletariat stärker wurde und die Kapitalisten ersetzen würde, also das schlussendlich in der Fabrik alle für alle arbeiten würden.
|
||||
|
||||
---
|
||||
Amerika
|
||||
Gutbezahlte Arbeiter, arbeiten besser als schlecht bezahlte, weil sie eine Zukunft sehen, eine Motivation sehen die höher ist als das blosse Existenzminimum.
|
||||
|
||||
Neoklassische Ökonomie: Angebot und Nachfrage
|
||||
|
||||
---
|
||||
**Blase oder Bubble**: Leute kaufen etwas *weil* der Preis steigt. Ihre Käufe treiben den Preis weiter in die Höhe.
|
||||
|
||||
@@ -0,0 +1,279 @@
|
||||
---
|
||||
title: More Effective Agile by Steve McConnell
|
||||
created_date: 2025-01-13
|
||||
updated_date: 2025-01-13
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: More Effective Agile
|
||||
author: Steve McConnell
|
||||
status: not_started
|
||||
---
|
||||
# More Effective Agile by Steve McConnell
|
||||
- **🏷️Tags** : #01-2025 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
|
||||
|
||||
> [!Quote] Inspect, Adapt & Grow
|
||||
> Contents
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
### Thoughts and Ideas
|
||||
- Assign Scrum Master Role to some team member
|
||||
- Team setup: does scrum work with hardware and mixed teams?
|
||||
- Who is product owner?
|
||||
- What roles do we want?
|
||||
|
||||
|
||||
---
|
||||
### What's Really Different About Agile?
|
||||
Main Benefits of Agile vs Sequential:
|
||||
- Short release cycles allow for more timely and less expensive correction of defects and faster feedback loops, meaning you can learn and adapt faster.
|
||||
- End-to-End development in small batches allows for testing and faster feedback loops
|
||||
- Just-in-time planning doesn't waste time creating plans that are then thrown away.
|
||||
- Just-in-time requirements results in less time invested upfront for requirements that might eventually be discarded
|
||||
- Continuous automated testing is very powerful
|
||||
- Frequent, structured collaboration: daily scrum, sprint planning, sprint retrospective
|
||||
- focus on empirical, responsive improvement model allows the team to learn and grow fast.
|
||||
|
||||
### Responding to the Challenges of Complexity and Uncertainty
|
||||
|
||||
#### Cynefin
|
||||
Cynefin means *habitat* or *neighbourhood* in Welsh and they are considered to be clusters of meaning.
|
||||
5 Domains: Complex, Complicated, Chaotic, Obvious, Disorder
|
||||
|
||||
![[Pasted image 20250115111654.png]]
|
||||
|
||||
In the **Obvious domain**, problems are well understood and clear. Example problems are taking an order at a restaurant, filling a car with gasoline, etc. The approach to solving them is *sense, categorize, respond*. There are only miniature problems like detailed if statements with live within this domain in software development, all other problems are not in this domain, which is why we can safely ignore it.
|
||||
|
||||
In the **Complicated Domain** you know the general shape of the problem, what question to ask and how to obtain answers. Multiple correct answers exist and you need to find the relationship between cause and effect. This is often hard, which makes this domain the domain of experts. The approach to solving problems is *sense, analyze, respond*, note the analysis instead of categorizing in the second step. Example problems: prepare a gourmet meal, database query for certain results, prioritize user requirements for version 4.1 of a mature system, etc. A lot of software development falls within this domain, and a sequential linear approach can work.
|
||||
|
||||
In the **Complex Domain** the relationship between cause and effect is not immediately clear, even to experts. You don't know all the questions to ask - finding the right questions is part of the challenge. Experimentation is needed to progress, some amount of failure is part of the process and decisions are often made on the basis of incomplete data. The approach to those problems is *probe, sense, respond*, meaning you can't analyze your way out of problems, but you need to probe and experiment with different solutions to start. Examples are buying a gift for someone who is difficult to shop for, meaning you know you most likely will need to exchange it later; Fixing a bug, which is not found during debugging, but only in production systems; creating software for changing hardware that is evolving. Many software development problems fall into this domain and this is where agile excells.
|
||||
|
||||
In the **Chaotic Domain** there is no discoverable relationship between cause and effect even with extended probing, because it is in constant turbulence. This domain also includes a time pressure element, which other domains lack. The approach to problems in this domain are decisive, action-oriented in order to impose order onto the chaos: *act, sense, respond*. Examples of such problems are: provide natural disaster help, while it is still happening; stopping a food fight in a highschool cafeteria; defining a feature set in a highly political environment with powerful stakeholders; fixing a bug in production by reversing the version, because no probing nor analysis has found the bug. The sizes of the problems are mostly smaller than project size for typical software projects.
|
||||
|
||||
In the **Disorder Domain** you lack clarity which domain applies to your problem. The approach here is to decompose the problem into subelements and assess the domains of each subelement. Remember that each project might have problems in various domains.
|
||||
|
||||
![[Pasted image 20250115111900.png]]
|
||||
As shown in the graph above, it is always better to use an agile approach and maybe sacrifice some efficiency if your problem was only complicated. The other way round could be disastrous and lead to the cancellation of the project.
|
||||
|
||||
#### Succeeding on Complex Projects: OODA
|
||||
![[Pasted image 20250115113740.png]]
|
||||
The origin of OODA was the US military in order to accelerate decision making. It is a method to establish context, formulating a plan, performing work observing results and incorporating learnings into the next cycle.
|
||||
|
||||
**Observe** the current situation, outside information that is relevant and any aspects of the situation that are unfolding (emergent). OODA places a strong emphasis on observation, experience and learning and thus is very empirical.
|
||||
|
||||
**Orient** is where you relate the observations to your situation, meaning you decide how the observations are relevant to you and your current situation and how possible responses look like. This is an opportunity to challenge your assumptions, adjust for cultural and company cultural blind spots, de-biasing data and information. A classical example is the first iPhone, which was technically inferior to many other phones, but solved the user experience problem instead, which turned out to be more important.
|
||||
|
||||
**Decide** is where you make a decision based the observations and the orientation in the previous two steps. The goal is to disrupt the opponents OODA-loop by forcing them to play your game instead of you playing their game.
|
||||
|
||||
**Act** is finally where you implement the decision, after which you start over in the cycle by observing the impact of your actions and learning from them.
|
||||
|
||||
In contrary to sequential development practices, OODA considers uncertainty as opportunity to act and create something new, something you can exploit to gain an advantage over your opponent.
|
||||
|
||||
|
||||
> [!important] Inspect and Adapt
|
||||
> Inspect and Adapt is a useful shorthand for OODA. Agile teams should avoid being idealistic about their practices and instead adjust their practices based on empirical observations about what has been proved to work. Apply Inspect and Adapt to *everything* (plans, designs, code quality, tests, processes, team interactions, organizational interactions, etc), meaning every factor that can make a difference to a team's effectiveness.
|
||||
|
||||
### More effective Agile beginnings: Scrum
|
||||
|
||||
- [ ] Summarize everything until failure mode #todo/b
|
||||
|
||||
The main common failure is not to use SCRUM in its entirety, but only implement certain parts. Scrum is already broken down to the minimum processes, everything you take away in addition will break the system (might not apply to power scrum users, but certainly to beginners).
|
||||
#### Most common Challenges
|
||||
- **Ineffective Product Owner**: Before agile the most common source of failure was poor definition of requirements. Since the product owner is responsible for requirements it comes at no surprise that this is a common challenge. Businesses should treat this role as the highest leverage role for the scrum team and fill it accordingly. With former training business analysts, customer support staff and testers can make excellent POs.
|
||||
- No Product Owner
|
||||
- Only 1-2 teams per product owner
|
||||
- PO doesn't understand the business
|
||||
- PO doesn't understand how to specify software requirements
|
||||
- PO doesn't understand the Development team's technical challenges, thus does not effectively prioritize --> accumulation of technical debt
|
||||
- PO is not co-located with the rest of the Scrum team --> no timely answers to requirement questions
|
||||
- PO is not empowered to make product decisions
|
||||
- PO's agenda differs from the business's: team works towards a different goal than the business
|
||||
- PO does not represent typical users --> for example: PO is a power user of the software
|
||||
- PO refuses to abide by scrum rules --> change requirements mid sprint, or other disruptions
|
||||
- **Insufficient Product Backlog refinement**: the backlog is the developer's food and you never want to starve your development team. The PO's job is to update the backlog continuously and keep it high quality. Split too long stories into 2, write down details of other stories to create nice work packages for the developers,
|
||||
- **Stories Too large**: should be completable within a single sprint. For a team of recommended size (3-9) aim for 6-12 stories per sprint. The maximum story size should consume max half the team for max half the sprint, most stories should be smaller
|
||||
- **Daily Standup not held daily**: Stick to it, no matter what. Focus on the 3 questions: what did you do yesterday, what do you do today, what is blocking progress? Keep it time boxed to 15 minutes --> max 2 minutes or so per person.
|
||||
- **Overly long sprints**: Most sprints are 2 weeks. 3 weeks or longer is too risky because of: planning mistakes, too optimistic commitments, procrastination and so on.
|
||||
- **Emphasis on Horizontal Slices Rather than Vertical Slices**: Vertical slices refer to end-to-end functionality across the technology stack. horizontal slices on the other hand do not produce any demonstrable business-level functionality. Focusing on vertical slices supports better feedback loops and earlier delivery of business value.
|
||||
- **Separate Development Teams and Test Teams**: A common holdover from sequential development. Scrum team needs cross-functional expertise to operate effectively.
|
||||
- **Unclear Definition of Done (DoD)**: When something is marked as done, the team should have confidence that it is actually done, meaning no more work remains for that item in order to add it to the production release.
|
||||
- **Not Driving to a Releasable Level of Quality Each Sprint**: Excessive schedule pressure is that team puts focus on appearance of progress above actual progress. Another example is skipping the testing, in order to get more actual code done (also related to DoD). Successful agile teams drive each story to production level before tackling the next one.
|
||||
- **Retrospectives not held**: when feeling overwhelmed by the amount of work, teams often skip retrospectives. This is a huge mistake! Without it you don't learn from planning and commitment mistakes leading to the same problem over and over again.
|
||||
- **Retrospectives not Implemented in the next sprint**: doing the retrospectives, but not applying the learnings. This means you cannot progress.
|
||||
- **Scrum And**: You don't need more than scrum to start.
|
||||
- **Ineffective Scrum Master**: Scrum master is responsible for avoiding these failure modes.
|
||||
- No scrum master
|
||||
- Scrum Master is supporting too many teams
|
||||
- Dual Scrum Master prioritizes development work over Scrum work
|
||||
- Scrum Master does not understand Scrum well enough to coach the team and project stakeholders
|
||||
|
||||
All points above share that they usually diverge from pure Scrum, meaning they implement "Scrum, but...". Further all attributes demand high discipline practices, meaning if the system is not properly set-up the people tend to drift away from it. The scrum master is responsible for ensuring those practices and the meetings (sprint planning, daily scrum, sprint review and sprint retrospective) provide structural support as well as social support to stick to the scrum.
|
||||
|
||||
|
||||
> [!Tip] Success Factors in Scrum
|
||||
> Each of the failure modes above can be converted into a success factor.
|
||||
|
||||
#### A Successful Sprint
|
||||
A successful sprint will support the main goal of Scum which is maximizing the value of the product:
|
||||
- deliver usable, valuable increment (aggregate functionality) fulfilling DoD.
|
||||
- the sprint's increment increases in value compared to the previous sprint
|
||||
- the Scrum process is improved compared to the previous sprint
|
||||
- Scrum team learns something about itself, its business, its product or its customers
|
||||
- Motivation remains the same or increases with each sprint
|
||||
|
||||
The time allocation per developer should be something like the following (out of 60 hours: 6h project focus for 10 business days. Startups have less overhead and thus more likely 7-8h of project work per day):
|
||||
- *48h* development work, including testing
|
||||
- *2h* daily standups
|
||||
- *3h* product backlog refinement (5%)
|
||||
- *4h* sprint planning
|
||||
- *2h* sprint review
|
||||
- *1h* sprint retrospective
|
||||
|
||||
Summarizing: 80% of the work should go into development and 20% into planning and process improvement.
|
||||
|
||||
#### A Scrum Scorecard
|
||||
![[Pasted image 20250115121640.png]]
|
||||
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------------ |
|
||||
| 0 | Not used |
|
||||
| 2 | used infrequently and ineffectively |
|
||||
| 4 | Used occasionally with mixed effectiveness |
|
||||
| 7 | Used consistently and effectively |
|
||||
| 10 | Optimizing |
|
||||
|
||||
### More effective Agile Team Structure
|
||||
The focus is to have a *cross-functional* team with diverse expertise in different software domains such as front-end, back-end, architecture design, UX design, etc. A typical agile team requires at least the following specializations:
|
||||
- Developers from different layers of the application (front end, back end, etc) and with different expertise (architecture, user experience, security, etc)
|
||||
- Testers from different layers of the application
|
||||
- technical writers
|
||||
- experts in the development process being used (Scrum Master)
|
||||
- Subject Matter Experts (e.g. Industry experts)
|
||||
- Business experts who bring business understanding and ROI to the team (Product Owner)
|
||||
It is difficult to find a full set of skills and remain small (5-9 people), which is why some people might play multiple roles and the organization should help the members to build those skills.
|
||||
|
||||
Beyond skills **Ability and Authority** to make decisions should lie within the team in order for it to implement actual agile
|
||||
|
||||
Treat teams as *black boxes* where you only give inputs and receive outputs. The teams commit to a sprint goal that they will deliver, but the management should not care about how this is delivered. Managers should also not review minute and miniature details and not do micromanagement.
|
||||
### More effective Agile Team Culture
|
||||
Motivate teams through *Autonomy, Mastery, Purpose*. This principle comes from the psychologist Daniel Pink. Motivation always needs to be intrinsic and cannot be forced upon someone.
|
||||
**Autonomy** refers to the ability to direct your own life and work - what you do, when you do it and who you do it with. If a person doesn't believe their organization trusts them, thy won't believe they have real autonomy.
|
||||
**Mastery** refers to the desire to learn and improve, thus to the idea to constantly getting better. This is especially important for technical staff. The opportunity of growth has been a stronger motivator for developers than advancement, recognition, salary, status, level of responsibility and other factors.
|
||||
**Purpose** refers to understanding why what you're working on matters. What is the big picture? How it the thing you're working on more important than yourself? How does it support the company or the world at large?
|
||||
|
||||
Another important point is to consider not only the project in a business perspective, but also consider the team to be part of the project. If the team is energized after the project has finished, they have grown, and will be an asset to the company for future projects. If they are burnt out they won't be of any use after the project. As a company you should grow as well, so take care of your people.
|
||||
|
||||
Developing a business focus means putting every single developer in direct contact with customers. This helps them to see the big picture and will teach them to think through the lens of the customer instead of overly technical. Further it enhances the Purpose pillar of the developers, which increase motivation. Keep in mind that this should become / be a habit, not a one time thing.
|
||||
|
||||
Assigning clear team roles, improves the efficacy of teams.
|
||||
|
||||
### More Effective Distributed Agile Teams
|
||||
One of the key principles of distributed agile teams is to **tighten the feedback loop**, such that problems arise early and can be solved timely and effectively, which in turn allows the team to grow. In fact, a lot of suggestions in the book are about tightening the feedback loops: Product Owners are there to tighten the feedback loop around requirements, cross-functional teams with different skillsets allow for faster decision making, fast automated testing tightens the loop between coding and testing.
|
||||
Geographically distributed teams loosen the feedback loop because of:
|
||||
- non-ideal communication
|
||||
- time difference
|
||||
- larger batches of work before they are being shipped,
|
||||
- differences in languages
|
||||
- differences in culture
|
||||
- development and testing happening at different locations
|
||||
- product ownership and development at different locations
|
||||
- work on shared functionality 50/50
|
||||
|
||||
Once again, the goal is to have self-directed cross-functional teams that have the ability and the authority to make binding decisions locally.
|
||||
|
||||
#### Dos
|
||||
- **routine face-to-face communication (scheduled)**: most of the problems are miscommunication. Plan with visits every 6 weeks
|
||||
- **increase logistical support for distributed teams**: Scheduled meetings: make good meeting habits. Make sure all members have good devices (microphones, headsets, etc) and that a communication tool like slack is used. Consider using remote proxies, meaning someone at the remote office is responsible. Make sure to provide onboarding and training. Mentoring is also important.
|
||||
- **Leverage Autonomy, Mastery and Purpose**: Treat all offices equally, don't use terminology like main office, secondary office; onshore vs offshore, etc. This reduces the Autonomy, Mastery and Purpose of the offshore office. Each site should be able to perform work autonomously and be able to grow autonomously
|
||||
- **Respect Conway's Law**: Technical structure of a system reflects the structure of the human organization that built the system. This is a two-way street, meaning the system also influences the teams.
|
||||
- **Treat Agile teams as black boxes**: Don't focus on how the teams perform the work.
|
||||
- **Maintain high quality**: keeping software close to a releasable state minimizes the discrepancy across distributed teams
|
||||
- **Be aware of cultural differences**: willingness to communicate bad news or answering "no" to questions, response to authority, individual vs team accomplishment, work-hour expectations, work life balance.
|
||||
- **Inspect and Adapt**: regular retrospectives to assess what is working and what is not. Teams must be empowered to make the changes they identify as causes.
|
||||
|
||||
|
||||
> [!Important] Key Principle: Fix the System, Not the Individual
|
||||
> Increased miscommunication leads to errors, meaning people spend more time fixing defects. It is crucial to **decriminalize errors**, such that people embrace them and learn from them. Treat errors as *system errors* and not personnell problems.
|
||||
>
|
||||
> What is it about our system that allowed this error to occur?
|
||||
|
||||
### More Effective Individuals and Interactions
|
||||
|
||||
|
||||
### Enjoy the Fruits of Your Labor
|
||||
The agile mindset is about decriminalising mistakes and develop a Growth Mindset. Use mistakes as learning opportunities, Inspect and Adapt, and gradually become better.
|
||||
The main benefits for your organisation:
|
||||
- teams that stay focused on goals and that are responsive when things change
|
||||
- teams that monitor the effectiveness in order to replace ineffective practices with better ones meaning throughput increases over time
|
||||
- teams that monitor workflows. they will know where the work is and if it's progressing as it should. Increasing visibility and keeping delivery promises with high quality
|
||||
- teams work well with other teams and outside world
|
||||
- constant discoveries, but few disruptive surprises. If they appear you find them early and can react to them
|
||||
- high quality work at all times and identify opportunities for improvement. High motivation
|
||||
|
||||
#### Maturation Phases
|
||||
1. several sprints to learn scrum, learn small increment,
|
||||
2. over time focus shifts to organisations interaction with teams
|
||||
3. iteratively teams are transformed. They deliver quickly and change direction quickly, meaning the organization has strategic opportunities to plan and execute differently and better
|
||||
4. meaning everything gets better and better over time.
|
||||
|
||||
#### Summary of Key principles
|
||||
- **Inspect and Adapt**: Agile is empirical with focus on learning from experience. Meaning the framework should create opportunities to reflect periodically and make adjustments based on experience.
|
||||
- **Start with Scrum**: might not be the final journey, but is the best structured and best supported place to start.
|
||||
- **Build Cross-Functional Teams**: The teams should be self managed, meaning they need to include a full skillset to make well informed decisions that are binding to the organisation.
|
||||
- **Integrate Testers into the Development Team**: Close feedback loop between development and test by having the people work together.
|
||||
- **Motivate Teams Through Autonomy, Mastery, and Purpose**: Motivation factors are inherently supported: Teams work with Autonomy and to become better over time (Mastery). healthy Agile team and motivated Agile team are strongly intertwined.
|
||||
- **Develop a Growth Mindset**: Agile teams have a big steady focus on getting better.
|
||||
- **Develop Business Focus**: Developers should understand the business to fill the gaps in requirements.
|
||||
- **Tighten Feedback Loops**: Don't take any longer to learn lessons than you need to. This supports more rapid progress from Inspect and Adapt and faster imporvements in Effectiveness.
|
||||
- **Fix the System, Not the Individual**: If a developer is not performing look for the system problem that is frustrating the person. Usually it's the system, not the people.
|
||||
- **Increase Team Capacity by Building Individual Capacity**: Team attributes are the combination of individual members attributes and interactions. By strengthening the people, you strengthen the team.
|
||||
- **Keep Projects Small**: They are easier and more often successful. Not all work can be structured like this, but if you can you should do it.
|
||||
- **Keep Sprints Short**: they support a frequent inspect and adapt feedback loop and expose problems quickly before they grow into large problems
|
||||
- **Deliver in Vertical Slices**: Feedback is important and teams get better feedback on their product in vertical slices and thus improve more. This means the business improves more as well.
|
||||
- **Manage Technical Debt**: Focus on Quality. Managing technical debt supports higher team morale, faster progress and higher quality products.
|
||||
- **Support Large Agile Projects Through Architecture**: Good architecture even allows large projects to use agile. Good architecture can make a large project feel smaller
|
||||
- **Minimize the Defect Detection Gap**: The cost of fixing a defect grows with the age of the defect. --> Detecting early and fixing it is cheaper and increases quality.
|
||||
- **Create and Use a Definition of Done**: a good definition of done helps catch incomplete or faulty work early, minimizing the gap between defect insertion and detection.
|
||||
- **Maintain a Releasable Level of Quality**: High quality helps catching additional defects that slip through
|
||||
- **Use Automated Test, Created by the Development Team**: Helps minimizing the defect detection gap. Everyone on the team feels responsible and reinforces that quality is the responsibility of everyone.
|
||||
- **Refine the Product Backlog**: this ensures the team tackles high priority tasks first and doesn't invent new requirements
|
||||
- **Create and Use a Definition of Ready**: make sure requirements are truly ready before the team begins implementing them.
|
||||
- **Automate Repetitive Activities**: You have more benefits when automating repetitive tasks.
|
||||
- **manage to Outcomes, Not Details**: Leave autonomy with the team by communicating desired outcomes, not implementation details.
|
||||
- **Express clear purpose with commander's intent**: this leaves the team a clear ability to make timely, local decisions
|
||||
- **Focus on Throughput, Not Activity**: Busyness is not the objective, valuable work is.
|
||||
- **Model Key Agile Behaviours**: Effective leaders model the behaviours they want to see in others.
|
||||
- **Decriminalize Mistakes**: The goal is to surface mistakes as fast as possible without hesitation from the team so you can learn from them. A mistake you don't learn from penalizes the organisation twice.
|
||||
- **Plan Based on Measured Team Capacity**: Agile is an empirical approach: teams and organisations should plan their work based on their measured past performance.
|
||||
|
||||
---
|
||||
```query
|
||||
More Effective Agile Steve McConnell
|
||||
-file: "More Effective Agile by Steve McConnell.md"
|
||||
```
|
||||
@@ -0,0 +1,275 @@
|
||||
---
|
||||
title: Outlive by Peter Attia
|
||||
created_date: 2024-10-23
|
||||
updated_date: 2024-10-23
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Outlive
|
||||
author: Peter Attia
|
||||
status: read
|
||||
---
|
||||
# Outlive by Peter Attia
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
---
|
||||
## Notes
|
||||
### Medicine 2.0 vs Medicine 3.0
|
||||
Medicine 2.0 is reactive, only reacting to problems once they appear. Medicine 3.0 on the other hand is proactive, trying to do things today in order to delay or prevent problems in the future.
|
||||
![[image 2.jpg]]
|
||||
|
||||
Healthspan is the quality of life.
|
||||
Lifespan is the length of life.
|
||||
|
||||
#### Flaws of Medicine 2.0
|
||||
- helps us live longer with the disease
|
||||
- Looks at each disease separately (especially the four horsemen)
|
||||
- Diabetes is a major risk factor for cancer and Alzheimer‘s
|
||||
- All is related to the biological process of aging
|
||||
#### Goals of Medicine 3.0
|
||||
- look at all diseases at once. What can I do to reduce the risk of all of them significantly?
|
||||
-
|
||||
|
||||
#### The Four Horsemen
|
||||
Cardiovascular Disease
|
||||
Cancer
|
||||
Diabetes
|
||||
Neurodegenerative Disease
|
||||
|
||||
#### Healthspan
|
||||
Three vectors that span a space:
|
||||
1. Cognitive Health
|
||||
2. Physical Health
|
||||
3. Emotional Health
|
||||
|
||||
You can only be healthy if you are healthy in all three of those.
|
||||
|
||||
Maybe the following definition (my own idea)?
|
||||
Health = min(cognitive health, physical health, emotional health)
|
||||
|
||||
#### Objective -> Strategy -> Tactics
|
||||
Tactics are short term and precise plans on how to achieve a simple goal.
|
||||
Strategy on the other hand is the long term plan, without precise implementation to a complex problem.
|
||||
The boxing analogy: strategy: make better, fitter and younger boxer tired by provoking him and enduring minimal damage yourself until you can finish him because you have much more energy left.
|
||||
Tactic: provoke by hitting him in a very simple way ( you don’t hit a champion like that), tire him out by only dodging but not really attacking
|
||||
|
||||
—-
|
||||
Aging is a major risk factor for the four horseman, because your body is not equipped anymore to fight them off.
|
||||
|
||||
—-
|
||||
Our Strategy:
|
||||
- avoid the three pillars of Healthspan decline simultaneously
|
||||
- Focus on improving healthspan, the lifespan benefits are closely related and follow automatically. Also Lifespan is binary: you’re alive or dead, no qualitative measure
|
||||
- Understand the four horseman in detail, to know our strengths to fight against them
|
||||
|
||||
##### Tactics
|
||||
> In Medicine 3.0, our tactics must become interwoven into our daily lives. We eat, breathe, and sleep them - literally. By peter Attila
|
||||
- Exercise
|
||||
- Nutrition
|
||||
- Sleep
|
||||
- Emotional Health
|
||||
- Exogenous Molecules (drugs, hormones and supplements)
|
||||
|
||||
###### Exercise
|
||||
Breakdown because its a very broad term:
|
||||
- Strength
|
||||
- Stability
|
||||
- Aerobic Efficiency
|
||||
- peak Aerobic capacity
|
||||
|
||||
Exercise is the most important tactic: it benefits all pillars of healthspan:
|
||||
|
||||
|
||||
### Datadriven
|
||||
Sources
|
||||
- Observe Centenarians
|
||||
- Animal models (lab mice)
|
||||
- Human Studies of the four horsemen
|
||||
- how do they start?
|
||||
- Progress? What fuels them?
|
||||
- What underlying factors do they share?
|
||||
- What are the treatments used? And how can we infer tactics to do prevention?
|
||||
- We want to know them inside out
|
||||
- Studies of aging (human and animal)
|
||||
- Molecular and mechanistic
|
||||
- Drugs or exercise that fight against it
|
||||
- Mendelian Randomization:
|
||||
- what allels of a gene induce higher risks of a disease
|
||||
#### Centenarians
|
||||
- They shift the aging curve by 1-3 decades, but in the end they still often die of the four horseman. This can be interpreted as being younger at any stage in life.
|
||||
- They mostly are very healthy at ages above 100, scoring well in cognitive tests and daily tasks tests. This means their healthspan is still large
|
||||
- The older you get, the healthier you have been
|
||||
- 20-30% of the longevity might be explained by genes
|
||||
- We try to copy the phenotype despite not having their genotype
|
||||
- Old relatives indicate higher chance of getting old as well
|
||||
- Suffering stage at the end is very short
|
||||
|
||||
##### Genes
|
||||
Most of them do something in cholesterole or glucose metabolism
|
||||
1. APOE
|
||||
2. CETP
|
||||
3. APOC3
|
||||
4. FOXO3 (page 78)
|
||||
|
||||
What centenarians get with their genes we want to achieve otherwise, mostly through training and nutrition.
|
||||
|
||||
### Eat Less, Live Longer?
|
||||
#### Rapamycin
|
||||
- [ ] do research about rapamycin #todo/p
|
||||
|
||||
Also known as:
|
||||
- sirolimus as a coating of arterial stents.
|
||||
- Everolimus: kidney cancer
|
||||
|
||||
Rapamycin tends to slow down cellular growth and division. It works directly on a intracellular protein complex called mTOR (mechanistic Target Of Rapamycin).
|
||||
mTOR can be found nearly across all species of the planet, meaning it is very important, also for us. Rapamycin acts like a switch for mTOR.
|
||||
|
||||
##### mTOR
|
||||
It’s Job is to balance an organism’s need to grow and reproduce against the availability of nutrients. When food is plentiful, mTOR is activated and the cell goes into growth mode (create new proteins and cell division). When the nutrients are scarce mTOR is supressed and the cell goes into a recycling mode, breaking down unused cellular components and cleaning the house
|
||||
|
||||
##### Slowdown of Aging in Mice
|
||||
In 2009 a study was published where rapamycin was used to extend life of mice - 13% for females, 9% for males. And the study was experimentally repeated across the globe by other groups.
|
||||
|
||||
This did not really come as a surprise, because rapmycin has the same effect as eating less (suppressing mTOR). And it had already been shown countless times that eating less results in longer lives for lab animals. The first person to document the process was Alvise Cornaro in the 16th century.
|
||||
|
||||
##### Caloric Restriction (CR)
|
||||
Experiment where one group can eat whatever whenever they want. The CR group gets all the nutrients needed for life, but 20-30% fewer total calories. Good results across the studies (15-45% longer lives and remarkably healthier animals).
|
||||
For us this probably does not apply as a strategy, because it is difficult to do it over a long timespan and you might be more susceptible to infections and other diseases, because you are not in a safe lab environment.
|
||||
|
||||
##### Cellular Aging
|
||||
|
||||
### 10 - Thinking Tactically
|
||||
> Absorb what is useful, discard what is useless, and add what is specifically your own.
|
||||
> - Bruce Lee
|
||||
|
||||
Orientation Questions:
|
||||
1. are you over- or undernourished (calorie count)?
|
||||
2. undermuscled or adequately muscled?
|
||||
3. Metabolically healthy or not?
|
||||
|
||||
What would I say about myself?
|
||||
1. slightly over
|
||||
2. undermuscled (okay VO2 max and endurance)
|
||||
3. I think yes
|
||||
|
||||
|
||||
### 11 - Centenarian Decathlon
|
||||
This chapter helps patients to define their own goals towards building an exercise routine and willpower now by visualizing tasks and passions as a 90 year old.
|
||||
- [ ] #todo/p copy list of examples from book
|
||||
|
||||
- 1 min dead hang
|
||||
### 12 - Training 101
|
||||
|
||||
> It is impossible to produce superior performance unless you do something different from the majority.
|
||||
> - Sir John Templeton
|
||||
|
||||
|
||||
#### Cardio
|
||||
Includes low power endurance (Zone 2) as well as maximal aerobic effort (VO2 max).
|
||||
|
||||
##### Aerobic Efficiency: Zone 2
|
||||
Glucose and fatty acids can be the fuel for our muscles. There are several metabolic pathways for glucose but only microcosms can convert fatty acids into energy.
|
||||
Zonte 2 exercise is mostly done by our slow twitch muscle fibers ( type 1). They are extremely dense with microcomputers and can therefore metabolize fat very well. When the pace increases, more and more type 2 muscle fibers start to join the effort. This are less efficient and more forceful and produce way more lactate because of a different way of producing ATP. When lactate turns into lactic acid you feel the muscle burning.
|
||||
Zone 2 can also be defined by the maximum effort without accumulating lactate.
|
||||
|
||||
##### VO2 Max
|
||||
VO2 max describes the maximum output of our body.
|
||||
|
||||
![[image 9.jpg]]
|
||||
|
||||
|
||||
|
||||
#### Strength
|
||||
Steady decline of muscle mass, muscle strength and muscle speed starting in your thirties. It’s hard to gain muscle when you’re older, but possible to keep it when you already have it.
|
||||
Accidents, diseases and other breaks in training leads rapidly to muscle loss. This is why it’s crucial not to get injured.
|
||||
|
||||
Bone density diminishes on a parallel path to the muscle. We care about this because we want to slow down this decline.
|
||||
Strategy to fight against:
|
||||
1. Optimize nutrition, focusing on protein and total energy needs (see nutrition chapters).
|
||||
2. Heavy loading-bearing activity. Strength training, especially with heavy weights, stimulates the growth of bone-more than impact sports such as running (though running is better than swimming/cycling).
|
||||
Bones respond to mechanical tension and estrogen is the key hormone in mediating the mechanical signal (weight bearing) to a chemical one telling the body to lay down more bone.
|
||||
3. HRT, if indicated.
|
||||
4. Drugs to increase BMD, if indicated.
|
||||
|
||||
Rucking is a sport where you hike with a heavy pack. Helps bone density growth as well as cardiovascular training and strength training for legs and trunk.
|
||||
|
||||
Focus strength training:
|
||||
1. Grip strength
|
||||
2. Concentric and eccentric movement
|
||||
3. Pulling motion ( rows and pull ups)
|
||||
4. Hip-hinging movements (dead lifts)
|
||||
|
||||
#### Stability
|
||||
This is the solid foundation that prevents us from getting injured. Stability makes us bulletproof.
|
||||
|
||||
By sitting in Chairs all the time we forgot the optimal way of moving our bodies. Thats the theory of DNS (Dynamic Neuromuscular Stabilization).
|
||||
|
||||
- www.rehabps.com
|
||||
- Www.posturalrestoration.com
|
||||
|
||||
##### Breathing
|
||||
Breathing is the foundation of stability.
|
||||
- Mr. Stay Puft
|
||||
- Sad Guy
|
||||
- Yogini
|
||||
|
||||
|
||||
### 15 Putting Nutritional Biochemistry into Practice
|
||||
|
||||
#### Macro nutrients
|
||||
##### Alcohol
|
||||
##### Carbohydrates
|
||||
The goal is to keep average glucose below 100 mg/dl with standard deviation of less than 15 mg/dl ( corresponds to HbA1c of 5.1%).
|
||||
##### Protein
|
||||
Its the one macronutrient you shouldn’t ignore. Its the only one where there is a recommendation of 0.8g per kg of body mass. But if you want to maintain muscle you should eat double to triple (1.6-2.2 g/kg). For me with 80 kg this is 120-180 g.
|
||||
Make sure to include all the essential amino acids in your diet, especially leucine, lycine (3-4g per day) and methionine (1g per day). If you want to increase mass, you need 2-3g per serving, four times a day of leucine.
|
||||
|
||||
### Notes and Thoughts
|
||||
- easy biomarker test device to use at home (like theranos?) #idea/startup
|
||||
|
||||
#### Actionpoints
|
||||
- [ ] Healthcheck with biomarker analysis: what is ideal (not normal) #todo/p ⏫
|
||||
- [ ] Understand mendelian randomization #todo/p
|
||||
- [ ] Study the four horseman in detail to understand the biological process underneath #todo/p
|
||||
|
||||
|
||||
|
||||
---
|
||||
### Erste Reaktion
|
||||
Ich habe heute das Buch fertig gelesen. Die letzten Kapitel waren sehr Praxis orientiert. Insgesamt bin ich begeistert davon wie Peter Attia das Buch aufbaut und bin grundsätzlich überzeugt von seiner Herangehensweise ans Gesund leben.
|
||||
Vor allem das er emotionale Gesundheit als gleich wichtig oder sogar als wichtiger betrachtet als körperliche Gesundheit finde ich faszinierend. Logisch übertreibt er gewisse Punkte und Geschichten aus seinem eigenen Leben. Es bringt mich jedoch dazu selber über mein Leben und meinen Zustand zu reflektieren. Wie ist meine emotionale Gesundheit? Ich glaube momentan nicht die beste.
|
||||
|
||||
|
||||
Definition Alter: wenn man in die Zukunft denkt ist man jung, wenn man in der Vergangenheit denkt ist man alt.
|
||||
|
||||
---
|
||||
## Cross References
|
||||
```query
|
||||
Outlive Peter Attia
|
||||
-file: "Outlive by Peter Attia.md"
|
||||
```
|
||||
@@ -0,0 +1,728 @@
|
||||
---
|
||||
title: Software Project Survival Guide by Steve McConnell
|
||||
created_date: 2025-01-07
|
||||
updated_date: 2025-01-07
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Software Project Survival Guide
|
||||
author: Steve McConnell
|
||||
status: not_started
|
||||
---
|
||||
# Software Project Survival Guide by Steve McConnell
|
||||
- **🏷️Tags** : #01-2025 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
- We should define exact goals that are measurable: What does the software need to do? What's its accuracy?
|
||||
---
|
||||
## Clippings
|
||||
### Intro
|
||||
- Software projects fail because of
|
||||
- lack of knowledge of software project conduct
|
||||
- lack of resolve --> indecisiveness, procrastination, low confidence, inconsistency
|
||||
- References
|
||||
- Key Practices of the Capability Maturity Model, Version 1.1 by Software Engineering Institute (SEI)
|
||||
- Recommended Approach to Software Development, Revision 3 by NASA Software Engineering Laboratory (SEL)
|
||||
### The Survival Mindset
|
||||
- The only outcome considered a failure is total collapse
|
||||
- Success: meet cost, schedule and quality goals within engineering tolerances (+- 10% of goal)
|
||||
- **Survival Needs**
|
||||
- Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air)
|
||||
- project not canceled, team not fired, adequate physical working conditions
|
||||
- meeting personal promises for schedule and functionality
|
||||
- Project team must be satisfied that the project can be completed *at all* before it can worry about the schedule or budget
|
||||
- ![[Pasted image 20250107095858.png]]
|
||||
- Individual developers might not prioritise the same needs as the software projects survival needs
|
||||
#### Stakeholders
|
||||
Each group involved in the project must respect the rights of the other parties. And each group's survival needs must be thoroughly satisfied such that they can focus on higher level needs. Usually this is the *Customer* and the *Project Team*:
|
||||
##### Customer's Bill of Rights
|
||||
1. To set objectives for the project and have them followed
|
||||
2. To know how long the software project will take and how much it will cost
|
||||
3. To decide which features are in and which are out of the software
|
||||
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
|
||||
5. To know the project's status clearly and confidently
|
||||
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
|
||||
7. To have ready access to project deliverables throughout the project
|
||||
##### Project Team's Bill of Rights
|
||||
1. To know the project objectives and to clarify priorities.
|
||||
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
|
||||
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
|
||||
4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
|
||||
5. To approve effort and schedule estimates for any work that Team will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
|
||||
6. To have my project's status reported accurately to customers and upper management.
|
||||
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.
|
||||
|
||||
#### Survival Check
|
||||
This tool is a quick check to verify that the essential characteristics for the survival are met. In the book a 👍🏼 or a 💣 is used. We will use a box just like below for every chapter.
|
||||
|
||||
|
||||
> [!question] Survival Check - Survival Training
|
||||
> - 👍🏼 Project team's survival needs are being met
|
||||
> - 👍🏼 The customer and the project team agree to respect each other's software project rights
|
||||
> - 💣 The agreement in principle is not followed in practice
|
||||
|
||||
|
||||
### Software Project Survival Test
|
||||
The idea of the survival test is to check the chances of survival of a project in different stages and to act upon the neglected areas if needed.
|
||||
There is a list of questions that will be answered with 0-3 points, 3 being fully qualified.
|
||||
The questions are separated into the following categories
|
||||
- Requirements
|
||||
- Planning
|
||||
- Project Control
|
||||
- Can progress be tracked and viewed by team members?
|
||||
- defect tracking, source control, project management software
|
||||
- Risk Management
|
||||
- up to date list of risks to the project
|
||||
- Personnel
|
||||
- Do we have all technical expertise?
|
||||
- Are there enough team members and are they committed?
|
||||
-
|
||||
|
||||
Most projects have a score <50.
|
||||
|
||||
| **Score Range** | **Rating** | **Description** |
|
||||
| --------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 90+ | Outstanding | A project with this score is virtually guaranteed to succeed in all respects, meeting its schedule, budget, quality, and other targets. In terms of Chapter 1's project needs hierarchy, such a project is fully "self-actualized." |
|
||||
| 80-89 | Excellent | A project at this level is performing much better than average. Such a project has a high probability of delivering its software close to its schedule, budget, and quality targets. |
|
||||
| 60-79 | Good | A score in this range represents a better-than-average level of software development effectiveness. Such a project stands a fighting chance of meeting either its schedule or its budget target, but it probably won't meet both. |
|
||||
| 40-59 | Fair | This score is typical. A project with this score will likely experience high stress and shaky team dynamics, and the software will ultimately be delivered with less functionality than desired at greater cost and with a longer schedule. This kind of project stands to experience the greatest benefit from applying the plan described in this book. |
|
||||
| < 40 | At Risk | A project with this score has significant weaknesses in the major areas of requirements, planning, project control, risk management, and personnel. The primary concern of a project in this category should be whether it will finish at all. |
|
||||
|
||||
> [!question] Survival Check - Survival Test
|
||||
> - 👍🏼 Project scores at least 60 on the Survival Test
|
||||
> - 👍🏼 The project scores less than 60, but corrective actions are planned to improve its score.
|
||||
> - 💣 The project team doesn't follow through on the planned corrective actions.
|
||||
|
||||
### 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
|
||||
- Think about processes in the upstream period of fixing mistakes at 1/200th of the price.
|
||||
- Rule of thumb: each day spent in processes (e.g. technical review) saves 3-10 days later in the project
|
||||
- Software Development Plan
|
||||
- Project Estimates
|
||||
- Revised Estimates
|
||||
- Quality Assurance Plan
|
||||
- Staged Delivery Plan
|
||||
- Requirements Development
|
||||
- Architecture
|
||||
- Detailed Design
|
||||
|
||||
|
||||
> [!Important]+ Planning Checkpoint Review
|
||||
> Very early in the project (at about 10%) success or failure is determined. This means it can be used as a checkpoint to do a *go/no go* decision about the project. At this point the team should have produced:
|
||||
> - user interface prototype (and shown it to users)
|
||||
> - detailed requirements
|
||||
> - detailed project plan including cost and schedule estimates.
|
||||
>
|
||||
> **Mandatory Documents needed for the checkpoint**:
|
||||
> - Name of project's key decision maker
|
||||
> - Vision statement
|
||||
> - Business case for the software
|
||||
> - preliminary effort and schedule goals
|
||||
> - preliminary effort and schedule estimates
|
||||
> - top 10 risks list
|
||||
> - User interface Style Guide
|
||||
> - Detailed User interface Prototype
|
||||
> - User Manual / Requirements Specification
|
||||
> - Software Quality Assurance Plan
|
||||
> - Detailed Software Development Plan
|
||||
>
|
||||
> **Agenda for the Checkpoint Review**
|
||||
> - Is the original product concept still viable?
|
||||
> - Will it be possible to develop a product that matches the project's vision statement?
|
||||
> - Is the business case for the software still justified when updated, more accurate cost and schedule estimates are considered?
|
||||
> - Can the major risks to the project be surmounted?
|
||||
> - Have users and developers been able to agree on a detailed User Interface Prototype?
|
||||
> - Is the User Manual / Requirements Specification complete and stable enough to support further development work?
|
||||
> - Is the Software Development Plan complete and adequate to support further development work?
|
||||
> - What is the estimated cost of completing the project
|
||||
> - What is the estimated schedule for completing the project?
|
||||
|
||||
Benefits of splitting development into these two funding phases:
|
||||
1. Cancelling one bad project at the stage of 10-20% can fund many other projects
|
||||
2. More reliable funding for the bulk of the project, because it can be better estimated
|
||||
3. Forces project manager to do upstream work in the first 10-20% --> setting the project up for success.
|
||||
#### Risk Management
|
||||
You can hope for the best but should prepare for the worst --> risk management.
|
||||
Typical risks:
|
||||
- failure to plan
|
||||
- failure to follow the plan that has been created
|
||||
- failure to revise the plan when project circumstances change
|
||||
|
||||
Software development is a high-risk activity, which is why it is essential to perform risk managment.
|
||||
|
||||
> [!Quote] By Tom Gilb
|
||||
> If you don't actively attack the risks on a software project, they will actively attack you.
|
||||
|
||||
#### Project Control
|
||||
Without project control every project is *out of control*, which is definitely something we do not want. We do not want to control the people, but rather the project itself:
|
||||
- Choose a software lifecycle model (e.g. staged delivery) to provide a framework
|
||||
- requirements change management --> only update what is necessary
|
||||
- Design and coding standards, to have consistency
|
||||
- write detailed plan of project to align developer's work with goals and to minimize conflicts in between developers
|
||||
#### Project Visibility
|
||||
The visibility is the ability to determine a project's true status, which will give answers to questions like:
|
||||
- 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: each delivery is a syncronizing event because you can compare the estimates with what is delivered and improve your estimation skills.
|
||||
7. Balances Flexibility and Efficiency: It avoids a situation like [[analysis paralysis]], because you can ship a small stage efficiently.
|
||||
##### Cost of Staged Delivery
|
||||
- You need to retest software at every stage
|
||||
- You need to execute merging and other version control tasks
|
||||
- You need to manage different versions
|
||||
- You need to plan the staged deliveries
|
||||
|
||||
Some of those costs are just exposed earlier in the process and would remain hidden (but still exist) otherwise.
|
||||
|
||||
#### Project Phases
|
||||
The phases described above slightly overlap, which is inevitable and desirable.
|
||||
![[Pasted image 20250108155841.png]]
|
||||
|
||||
|
||||
##### Distribution of Effort
|
||||
![[Pasted image 20250108160138.png]]
|
||||
|
||||
![[Pasted image 20250108160308.png]]
|
||||
|
||||
Note that e.g. requirements development requires 12% of the time, but only 6% of the effort, because it is less tangible and requires deeper contemplation such that it is done at a slower pace. This also means that it doesn't produce a lot of code.
|
||||
|
||||
##### Milestones and Deliverables
|
||||
Use lists from book pages 65ff.
|
||||
|
||||
|
||||
> [!question] Survival Check - Successful Project at a Glance
|
||||
> - 👍🏼 Project uses a staged delivery approach
|
||||
> - 👍🏼 Upper management, customer or both track progress by code growth curve
|
||||
> - 👍🏼 Upper management, customer or both track progress by keeping tabs on major milestones and deliverables
|
||||
|
||||
### Hitting a moving target
|
||||
#### Change Control
|
||||
[[Floris]] is no fan of change control, and the book explains why: he could have any changes made at any time before, with change control there is a process which needs to be followed.
|
||||
|
||||
> [!Quote]
|
||||
> People who are used to getting their way can still get their way with systematic change control, but they'll have to do it through a process that emphasizes visible decision making and accountability.
|
||||
|
||||
Change control only works if all parties accept the decision of the change control board.
|
||||
|
||||
> [!question] Survival Check - Change Control
|
||||
> - 👍🏼 The project has a change board.
|
||||
> - 💣 The change board's decisions can be reversed by management, marketing, or the customer.
|
||||
> - 👍🏼 The project has a written, approved Change Control Plan.
|
||||
> - 💣 Project team members aren't given enough time to carry out the plan.
|
||||
> - 💣 Work products aren't actually put under change control.
|
||||
> - 👍🏼 Change Proposals are evaluated by all the project's concerned parties before they are resolved.
|
||||
> - 👍🏼 The change board notifies the project's concerned parties of how each Change Proposal is resolved.
|
||||
> - 👍🏼 The change board has the project team evaluate changes in batches so that the team is not distracted by a constant barrage of change requests.
|
||||
|
||||
|
||||
### Preliminary Planning
|
||||
- Define project vision
|
||||
- identify executive sponsor
|
||||
- set targets
|
||||
- manage risks
|
||||
- map out strategies for using personnel
|
||||
|
||||
This all goes into a **software development plan**.
|
||||
|
||||
#### Project Vision
|
||||
Effective teams have a common vision and thus a clear understanding of the objective. Having a common vision aligns team members to work effectively together and avoiding time-wasting side trips.
|
||||
- Vision builds trust among team members because they know they work towards the same goal
|
||||
- An effective vision can have a motivating effect --> therefore it needs to be elevating
|
||||
- It needs to be achievable within the specified time frame
|
||||
|
||||
The vision should not promise too much (e.g. short schedule, low cost and rich functionality) since developers are realists and feel fooled with impossible goals.
|
||||
##### Deciding What to leave out
|
||||
Statements like creating the world's best of something include too much and therefore not provide much guidance to the development team. A good, exclusive vision statement helps the project team achieve the goal of software minimalism, which is essential for keeping project risk to a manageable level.
|
||||
##### Committing to the vision
|
||||
Formalize through a written vision statement and have it signed by every team member. Then put it under change control! It is the top most guidance element for the team and should be remembered often.
|
||||
#### Executive Sponsorship
|
||||
Make sure that the decision making comes from a single, clear authority (can be a board). Else decisions from different people do not align with each other and interfere and therefore slow down the entire project.
|
||||
|
||||
#### Project Scope Targets
|
||||
This is the envisioned schedule, budget, staffing and feature set to get started with. When development starts and you realize that desired features are not in line with schedule and buget you adjust one or the other.
|
||||
|
||||
|
||||
> [!Quote]
|
||||
> The best organizations plan to reestimate regularly throughout a project and periodically adjust their project plans based on the reestimation.
|
||||
|
||||
Put reestimation points in your plan (just as NASA does, see page 90):
|
||||
|
||||
| Estimation Point | Upper Limit | Lower Limit |
|
||||
|----------------------------------------------|-------------|-------------|
|
||||
| End of requirements definition and specification | x2.0 | x0.50 |
|
||||
| End of requirements analysis | x1.75 | x0.57 |
|
||||
| End of preliminary design | x1.4 | x0.71 |
|
||||
| End of detailed design | x1.25 | x0.80 |
|
||||
| End of implementation | x1.10 | x0.91 |
|
||||
| End of system testing | x1.05 | x0.95 |
|
||||
#### Publicizing Plans and Progress
|
||||
Involve the team in the planning phase, because the people who actually do the work often consider all details. If a plan cannot be followed because of wrong planning, it will not be followed and thus the team runs out-of-control.
|
||||
- [ ] Get the plans reviewed and approved by the developers
|
||||
|
||||
The team needs effective coordination of activities from the project manager, such that efforts are not wasted. Therefore its smart to get the plan approved by the team before the bulk of the work gets started.
|
||||
##### Progress Indicators
|
||||
Once the project started we have the following indicators to show how well we follow the plan. This creates project visibility.
|
||||
- List of tasks completed
|
||||
- Defect statistics
|
||||
- Top 10 Risks List
|
||||
- Percent of schedule used
|
||||
- percent of resources used
|
||||
- project management's status reports to upper management
|
||||
|
||||
- [ ] Create a project intranet homepage (confluence page) with links to planning, tracking, technical work products and project deliverables. Essentially make a dashboard (see page 93)
|
||||
|
||||
#### Risk Management
|
||||
The goal is to trade small amounts of increased overhead for large amounts of risk reduction.
|
||||
In order to commit to risk management:
|
||||
- Describe a risk management approach in writing
|
||||
- Budget funds for risk resolution and risk removal
|
||||
- Use risk assessments to update project plans, else all is for nothing
|
||||
|
||||
Tools for risk management:
|
||||
- Planning for risk management
|
||||
- Assign a risk officer
|
||||
- play devil's advocate during planning meetings and planning reviews
|
||||
- needs to have a bit of the attitude: "It will never work"
|
||||
- senior developer or senior tester
|
||||
- top 10 risk list
|
||||
-
|
||||
- risk-management plan for each risk
|
||||
- create anonymous risk-reporting channel
|
||||
- Bad news are not shared easily --> make it anonymous to facilitate. It is crucial that all team members do communicate this
|
||||
|
||||
> [!Idea] Use Jira / Github Issues for risk Tracking
|
||||
> This makes risks visible. People can discuss risks. You can assign responsibility for risk mitigation
|
||||
|
||||
##### Risk Management Plans
|
||||
Answer the following questions for every risk:
|
||||
- **Why?** Why is a risk-management plan needed for this specific risk? Describe the risk's probability of occurrence, consequences, and severity.
|
||||
- **How?** How will the risk be resolved in general? Describe the general approach to re- solving the risk. List or describe the options that were considered.
|
||||
- **What?** What specific steps will be taken to resolve the risk? List the specific steps and deliverables that will be generated in addressing the risk. Include a description of the conditions under which the risk will be upgraded— for example, if the risk cannot be resolved by a specific date.
|
||||
- **Who?** Who will be responsible for completing each step? List the specific person re- sponsible for completing each step.
|
||||
- **When?** When will each step be completed? List the completion date for each step.
|
||||
- **How much?** How much budget is allocated to the resolution of the risk? List the cost of each step that will be taken to resolve the risk.
|
||||
|
||||
#### Personnel Strategies
|
||||
- evaluate managers based on how well they retain project personnell
|
||||
- professional growth opportunities during the project
|
||||
- after the project team members should feel better about the company, not worse
|
||||
|
||||
|
||||
> [!Quote] Available vs Good
|
||||
> It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.
|
||||
|
||||
Team dynamics and team bond play a more important role than individual developers' capabilities (slightly behind). This means we need to hire someone who fits into the team.
|
||||
|
||||
##### Key Staff-Buildup Questions
|
||||
- Does the project manager have software experience with one or more projects of a similar size?
|
||||
- Does project's senior technical staff have knowledge of the kind of software being built and experience on similar successful projects?
|
||||
- Most teams are comprised of average personnel. Do expectations about the team's productivity match the team members' abilities?
|
||||
- Will the individuals work well together?
|
||||
|
||||
##### Project Team Organization
|
||||
- **Project manager:** orchestrate detailed technical work (development, quality assurance, user documentation). Develops software development plan. Is the team's link to upper management.
|
||||
- **Product manager:** Business level work: marketing, product packaging, end-user documentation, end-user support. In-house projects: work with groups that use the system to define the software, setup training and user support.
|
||||
- **Architect:** Responsible for conceptual integrity at design and implementation level.
|
||||
- **User-interface designer:** responsible for conceptual integrity of software visible to end-user.
|
||||
- **End-user liaison:** interact with end-user throughout the project. Walk them through the prototype, demonstrate new releases, gather user feedback.
|
||||
- **Developer:** detailed design and implementation of software. Responsible for making the software work.
|
||||
- **QA/Testers:** responsible for Quality Assurance and test activities. Create detailed test plans and perform tests. Find all the ways to break the software.
|
||||
- **Tool smith:** Responsible for developing build scripts, maintain versioning system, developing utilities needed by the project.
|
||||
- **Build coordinator:** responsible for maintaining and running the daily build and notifying the developers when something breaks the build.
|
||||
- **Risk officer:** watch for emerging risks and diversion from the development plan.
|
||||
- **End-user documentation specialists:** generate help files, documentation, and instructional materials that end-users will use.
|
||||
|
||||
> [!important] Mixing Roles is Okay except for ...
|
||||
> ... Quality Assurance and Development
|
||||
|
||||
#### Time Accounting
|
||||
Tracking where team members spend their time will help with future planning.
|
||||
|
||||
|
||||
> [!question] Survival Check - Preliminary Planning
|
||||
> - 👍🏼 The project has a clear vision.
|
||||
> - 💣 The vision doesn't provide guidance in deciding what to leave out of the software.
|
||||
> - 👍🏼 The project team has identified an executive sponsor or committee with final authority over projectwide decisions.
|
||||
> - 👍🏼 The project plans and progress compared to the plans are readily available to all project team members and upper management.
|
||||
> - 👍🏼 The project has a risk officer.
|
||||
> - 💣 The risk officer is the project manager.
|
||||
> - 👍🏼 The project has a Top 10 Risks List.
|
||||
> - 💣 The Top 10 Risks List is not kept up to date.
|
||||
> - 👍🏼 The project team develops risk-management plans for each risk on the Top 10 Risks List.
|
||||
> - 👍🏼 The project leaders hire well-qualified people (waiting for qualified people, if necessary), rather than just hiring whoever is available first.
|
||||
> - 👍🏼 Time accounting is begun before requirements development begins.
|
||||
> - 👍🏼 All of the above considerations are formalized in a Software Development Plan.
|
||||
> - 💣 The Software Development Plan isn't placed under change control.
|
||||
> - 💣 The Software Development Plan isn't actually followed by the development team.
|
||||
|
||||
### Requirements Development
|
||||
|
||||
> [!question] Survival Check - Requirements Development
|
||||
> - 👍🏼 The project team identifies a set of key end users who can be trusted to shape the software.
|
||||
> - 👍🏼 The developers create several versions of a basic prototype until they find one that the users are excited about.
|
||||
> - 💣 Prototyping stops while users are still only lukewarm about the prototype.
|
||||
> - 👍🏼 The developers extend the User Interface Prototype to elicit detailed requirements from users.
|
||||
> - 💣 The prototype is not kept broad and shallow, and time is wasted providing deep functionality that will be rewritten for the final software.
|
||||
> - 👍🏼 The project team develops a User Manual/Requirements Specification to use as the detailed requirements specification.
|
||||
> - 👍🏼 The fully developed prototype is baselined and placed under change control.
|
||||
> - 💣 The project team attempts to use the prototype code in the real software.
|
||||
> - 👍🏼 A separate, non-user-interface requirements document is created, reviewed, and placed under change control.
|
||||
|
||||
### Quality Assurance
|
||||
QA matters because it makes development easier and cheaper. If mistakes and defects are detected upstream they are 50-200 times cheaper, which is why a good quality assurance system pays out.
|
||||
Quality is important because the software usually acts as a foundation for business decisions, more software and usually lives longer than you might expect.
|
||||
|
||||
> [!Quote] Quick and Dirty
|
||||
> The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten.
|
||||
|
||||
#### Quality Assurance Plan
|
||||
This document writes down commitments to quality assurance onto paper:
|
||||
- Software quality assurance activities must be planned
|
||||
- The plan for quality assurance must be committed to writing
|
||||
- Quality assurance must beginn in requirements phase or earlier
|
||||
- Development and quality assurance of the same elements cannot be performed by the same person.
|
||||
- Train team members in how to perform quality assurance activities.
|
||||
- Provide adequate funding for quality assurance activities
|
||||
|
||||
Typical Quality assurance activities are:
|
||||
- **defect tracking**: keep record of each defect found, its source, when it was found, when it was resolved, how it was resolved (fixed or not)
|
||||
- **unit testing**: unit refers to subroutine, module, class or even larger programming entity. This is done by developers, or on the git cloud provider automatically
|
||||
- **source-code tracing**: interactive debugging line by line. done by developer.
|
||||
- **technical reviews**: reviews are performed by peers. check all technical work products. Done by developers, QA-team just ensures that they are being held.
|
||||
- **integration testing**: test new code together with existing code / codebase. Done by developer
|
||||
- **system testing**: Test the entire system for the purpose of finding defects. Performed by independent test organization / test engineer
|
||||
|
||||
##### Defect Tracking
|
||||
- document each individual defect
|
||||
- keep statistics: \# open defects, average time requiered to correct a defect, percentage of defects resolved.
|
||||
- track only defects that have been comitted. Beforehand you should just fix them (put them into your personal todos.)
|
||||
- Put defect reports under change control and make it public: automatically in jira / gitlab issues
|
||||
- create a defect report template
|
||||
|
||||
##### Technical Reviews
|
||||
This is an activity that assures quality upstream in the process.
|
||||
- can be: walkthroughs, inspections, code reading
|
||||
- time to talk about code:
|
||||
- juniors can learn from seniors and seniors can fix problems in juniors code
|
||||
- challenge old ways of doing things
|
||||
|
||||
Review pattern:
|
||||
1. **Notification and distribution**: developer informs reviewer that code is ready for review and shares material for review
|
||||
2. **Preparation**: Review happens, aided by checklist of common errors
|
||||
3. **Review Meeting**: talk about the review
|
||||
4. **Review Report**: log statistics of review: amount of defects, time spent for review, meeting, etc, pass or fail
|
||||
5. **Follow-up**: Fix the problems and review again until product passes the review.
|
||||
|
||||
Suggestions
|
||||
- focus on defect detection, do not try to create solutions
|
||||
- start reviews early in the project
|
||||
- keep technical reviews technical and be honest about defects
|
||||
- keep track of what material has been reviewed
|
||||
- record the defects during reviews and list them in the report
|
||||
- Verify that defects found during review are actually fixed (in the follow-up)
|
||||
- make review results public to the project team
|
||||
- schedule time for reviews and errorfixing of found defects
|
||||
|
||||
##### System Testing
|
||||
This is an activity that assures quality downstream in the process, compared to technical reviews.
|
||||
Usually developers cannot wear both the developers' hat as well as the tester's hat: have different people do this.
|
||||
|
||||
- Start system testing as soon as you have the first executable software
|
||||
- Use a requirements traceability matrix to ensure all requirements are covered.
|
||||
- test cases as rows
|
||||
- requirements as columns
|
||||
- every row and column need at least one mark, else they are useless
|
||||
- Automate the testcases. The more critical the software is, the more testers per developers are needed.
|
||||
|
||||
> [!Quote] Testing vs Quality Assurance
|
||||
> Testing is a means of discovering the quality level of a software system, not a means of assuring software quality.
|
||||
|
||||
##### Beta Testing
|
||||
Release of software to a selected group of testers.
|
||||
|
||||
##### Other
|
||||
![[Pasted image 20250110145533.png]]
|
||||
![[Pasted image 20250110145548.png]]
|
||||
|
||||
Have measurable criteria for software releases.
|
||||
|
||||
> [!question] Survival Check
|
||||
> - 👍🏼 Project has a written, approved Quality Assurance Plan.
|
||||
> - 💣 Project isn't following the written plan.
|
||||
> - 👍🏼 Quality assurance is initiated in parallel with requirements work.
|
||||
> - 👍🏼 Defect tracking software is placed online at requirements development time, and defects are tracked from the beginning of the project.
|
||||
> - 👍🏼 Developers review all designs and code before the designs and code are considered "done."
|
||||
> - 💣 No designs or code have failed their reviews, suggesting that reviews are superficial.
|
||||
> - 💣 Developers don't source trace and unit test their own source code prior to submitting it for review, which gives rise to an unwieldy number of defects that have to be tracked from reviews onward.
|
||||
> - 👍🏼 The Quality Assurance Plan calls for an independent quality assurance group.
|
||||
> - 💣 No funding is available for an independent quality assurance group.
|
||||
> - 👍🏼 The Quality Assurance Plan contains measurable criteria that are used to determine whether the software is ready to be released.
|
||||
|
||||
### Architecture
|
||||
|
||||
### Final Preparations
|
||||
The final preparations should be started when architecture design is nearly finished. It includes:
|
||||
- create project estimates
|
||||
- write a staged delivery plan
|
||||
- perform ongoing planning activities
|
||||
|
||||
#### Project Estimates
|
||||
The goal is to estimate effort, cost and schedule. This should be done by the most experienced person doing similar work or an expert estimator.
|
||||
> [!NOTE]- Fibonacci based estimation of effort
|
||||
> [[Martin Albrecht|Martin]] told me about their estimation procedure, where they use fibonacci numbers for estimating efforts of features or user stories. It is difficult to say if something takes 8 or 9 days, but if something takes 1, 2, 3, 5, 8, 13, 21 days is much easier.
|
||||
|
||||
Apart from the obvious activities such as architecture, coding, general planning, user documentation, etc. there are less obvious activities that should be accounted for:
|
||||
- interaction with customers/end users
|
||||
- reviews
|
||||
- fixing problems during reviews
|
||||
- maintaining things like:
|
||||
- revision control systems
|
||||
- daily build scripts
|
||||
- technical training
|
||||
- holidays, vacations and sick days
|
||||
- answering questions from QA and documentation
|
||||
|
||||
Including those less obvious activities is important in order to be more accurate with your time planning. Because if the time plan is really far away from reality, the team stops taking the goal seriously which decreases productivity.
|
||||
Don't plan with the team doing overtime. This can be a reserve if the project falls behind or something similar.
|
||||
Oftentimes with troublesome projects the developers say that the estimates are unrealistic from the start. Lack of buy-in from developers is at best a warning sign that the goals are unachievable. At worst, it indicates an adversarial relationship between developers and management, which comes with many more problems.
|
||||
Redoing the estimation work is crucial. It shows flexibility and will be more accurate the more the team learns about its progress. Further it is important to keep estimates under change control.
|
||||
|
||||
#### Milestone Targets
|
||||
The team should use the estimates from above to put due dates for important milestones such as completing the architecture, completing the stages, and releasing the software.
|
||||
|
||||
#### Staged Delivery Plan
|
||||
The most important functionality is delivered first. The staged delivery approach doesn't reduce the actual development time, but it reduces the development time that is perceived. Every stage that is completed and celebrated makes people feel the success and thus the ultimate goal seems closer. The architecture needs to be build such that staged delivery is possible.
|
||||
Not every stage necessarily needs to be shipped to the customer. Maybe only the 4th stage will be shipped, because the stages before that are too simple. Nonetheless, the simpler stages help in having a good development approach.
|
||||
|
||||
|
||||
> [!question] Survival Check - Final Preparations
|
||||
> - 👍🏼 The project team creates its first estimate after preliminary requirements development is complete.
|
||||
> - 💣 Estimates do not account for normal activities such as holidays, weekends, and vacations.
|
||||
> - 💣 Developers don't believe the estimates are realistic.
|
||||
> - 👍🏼 Estimates are updated after detailed requirements development and again after architectural design.
|
||||
> - 👍🏼 The project has a Staged Delivery Plan that organizes the stages into theme releases.
|
||||
> - 💣 The stages are not defined in detail.
|
||||
> - 👍🏼 The project's risk-management, vision, decision-making, and personnel plans are up-to-date.
|
||||
> - 👍🏼 The project's Software Development Plan is up-to-date and is being followed.
|
||||
|
||||
### Beginning of Stage Planning
|
||||
For each stage a detailed plan is needed. The project team creates an individual stage plans. Each stage includes planning, design, construction, testing and preparation for release. The idea behind the stages is to convert a big risky project into a stage of smaller more manageable projects.
|
||||
|
||||
#### Stage planning overview
|
||||
- requirements updates
|
||||
- detailed design
|
||||
- construction
|
||||
- test case creation
|
||||
- user documentation updates
|
||||
- technical reviews
|
||||
- defect corrections
|
||||
- technical coordination
|
||||
- risk management
|
||||
- project tracking
|
||||
- integration and release
|
||||
- end-of-stage wrap up
|
||||
|
||||
Miniature Milestones are a great way to add visibility to the development process. They should be defined in a way where they can be either *done* or *not done*.
|
||||
When only long-term milestones are used, the developers can easily lose a day here or a week there— people spend time on detours that seem interesting or productive in some vague sense but that fail to move the project forward.
|
||||
|
||||
|
||||
> [!question] Survival Check - Stage Planning
|
||||
> - 👍🏼 Planning is conducted at the beginning of each stage to prepare for that stage's activities.
|
||||
> - 👍🏼 Stage planning includes requirements review, detailed design, coding and code reviews, test case creation, user documentation updates, in-stage defect correction, technical coordination, integration and release, risk management, project tracking, and other important activities.
|
||||
> - 👍🏼 The project team creates a set of miniature milestones to aid in tracking progress throughout the stage.
|
||||
> - 💣 The list of miniature milestones does not include all activities.
|
||||
> - 💣 The project is not actually tracked against the list of miniature milestones.
|
||||
> - 👍🏼 The project manager adopts a hands-on approach to the project.
|
||||
|
||||
### Detailed Design
|
||||
|
||||
|
||||
|
||||
---
|
||||
## Steps towards the Software release
|
||||
1. Define preliminary risks list
|
||||
2. Define requirements
|
||||
3. Create initial project estimate (budget, schedule, staffing, desired feature set).
|
||||
|
||||
|
||||
## Document List
|
||||
- Top 10 Risk List (keeps being updated) including a risk-management plan for each risk
|
||||
- Software Development Plan
|
||||
- Risk management approach
|
||||
- Risk officer and other roles: personnell strategies
|
||||
- Decision making authority
|
||||
- project scope
|
||||
- publicising of plans and progress
|
||||
- time accounting
|
||||
- once finished sign off by project manager, dev team and Q&A team, then place under change control
|
||||
- Quality Assurance Plan
|
||||
- defect report template to be used to report defects (see page 130)
|
||||
- review checklists for different parts
|
||||
- Software architecture plan (less than 100 pages, diagram heavy)
|
||||
- Staged Delivery Plan
|
||||
- Individual stage plans --> add to the software development plan once its finished
|
||||
## Tool list
|
||||
- Anonymous risk-reporting channel
|
||||
- time tracking (helps for future estimating practices)
|
||||
|
||||
## Review List
|
||||
- Review Top 10 Risks every 2 Weeks (see page 97)
|
||||
|
||||
## Checkpoints
|
||||
- reestimate of the schedule and cost
|
||||
- during preliminary requirements development
|
||||
- during detailed requirements development
|
||||
- during architectural design
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Software Project Survival Guide Steve McConnell
|
||||
-file: "Software Project Survival Guide by Steve McConnell.md"
|
||||
```
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Surrounded by Idiots by Thomas Erikson
|
||||
created_date: 2024-10-25
|
||||
updated_date: 2024-10-25
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
- psychology
|
||||
type: book
|
||||
book_name: Surrounded by Idiots
|
||||
author: Thomas Erikson
|
||||
status: started
|
||||
---
|
||||
# Surrounded by Idiots by Thomas Erikson
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
> [!warning]
|
||||
> Apparently there is no scientific background to the claims of the book made by Thomas Erikson. It is based on the [[Personality Tests#DiSC|DiSC]] test, which has its origin in the 1930s and has scientifically not been show accurate. The results have high reliability (consistent results over time) but their validity is questionable.
|
||||
|
||||
Nonetheless, I think there are learnings in the books. The way the different personalities are described is accurate and I did remember several interactions with people while reading it. It is important not to judge people's character through the lens of the colours, but rather using it to strategise the best responses with respect to behaviour. If someone shows red behaviour, we take it as red behaviour and act accordingly - we don't say the person is red. Behaviours can be very environment dependent.
|
||||
A critical comment can be found here: [One of Sweden's biggest scientific bluffs – Vetenskap och Folkbildning](https://www.vof.se/blogg/one-of-swedens-biggest-scientific-bluffs/).
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
|
||||
---
|
||||
```query
|
||||
Surrounded by Idiots Thomas Erikson
|
||||
-file: "Surrounded by Idiots by Thomas Erikson.md"
|
||||
```
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: The 7 Habits of Highly Effective People by Stephen Covey
|
||||
created_date: 2024-11-28
|
||||
updated_date: 2024-11-28
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
- self-help
|
||||
type: book
|
||||
book_name: The 7 Habits of Highly Effective People
|
||||
author: Stephen Covey
|
||||
status: finished
|
||||
---
|
||||
# The 7 Habits of Highly Effective People by Stephen Covey
|
||||
- **🏷️Tags** : #11-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
### Paradigms and Principles
|
||||
Paradigms: what are my maps, my lenses, my ways to see, perceive and interpret the world, the relationships? The better I know them the more I can abstract, experiment, listen to others and thereby getting a larger picture and far more objective view.
|
||||
|
||||
|
||||
Most breakthroughs in science are usually a break with traditional methods and traditional ways of thinking. So called Paradigm Shifts.
|
||||
|
||||
Character Ethics vs Personality Ethics: a paradigm shift which is negative: character ethics is based on principles deeply rooted, whereas personality ethics is based on attitude and behavior.
|
||||
|
||||
Story of the man with the kids in the subway whose mother just died. Small adjustment —> you suddenly feel compassion
|
||||
|
||||
In order to *see* differently, sometimes you need to *be* differently.
|
||||
|
||||
Principles: fairness, integrity, honesty, human dignity, service, quality, excellence, potential, growth, patience, nurturance, encouragement.
|
||||
|
||||
Principles are not practices, which are specific actions or activities and thus change with different circumstances. Principles are deeply rooted and materialize in terms of habits. They are not Values - values are the maps, trying to describe the underlying territory, which are the principles.
|
||||
|
||||
### Private Victory
|
||||
#### Be Proactive
|
||||
Conditioning: it would be easy to say that *genetic, psychic (upbringing) and environmental (current environment ) determinism* shapes our behaviors. It‘s the stimulus / response theory which says we‘re conditioned to respond in a certain way to different stimuli.
|
||||
This lets us create a framework:
|
||||
|
||||
> [!NOTE] Between Stimulus and Response, Man has freedom to choose
|
||||
> Victor Frankl, being tortured in the Nazi’s concentration camps realized that the last human freedom is to choose how different stimuli are going to affect you. Ergo you can choose your response.
|
||||
|
||||
Projecting yourself to be where you want to be helps with choosing the right response today for a future goal.
|
||||
Self-awareness, imagination, conscience (deep inner awareness of what is right and wrong), independent will, are traits that help shape this ability to create a gap in between stimulus and response.
|
||||
|
||||
Being proactive means that as a human being, we are responsible for our own life. Our behavior is a function of our decisions, not our conditions.
|
||||
|
||||
Being proactive requires a paradigm shift: you need to abstract the stimulus and find out how it relates to your life and situation. Then you are free to chose the response.
|
||||
|
||||
Act or be acted upon: you choose if you want to act or be acted upon.
|
||||
|
||||
Language is important to distinguish between proactivism and reactivism. It shows how someone responds to circumstances.
|
||||
|
||||
### Circle of Influence vs. Circle of Concern
|
||||
The circle of Concern: defines what you are concerned about.
|
||||
The circle of influence: is what you can actually influence.
|
||||
Proactive people focus on the circle of influence. What can they influence? Because everything else is not worthwhile to pursue.
|
||||
|
||||
Problems can be of different nature:
|
||||
- direct control: private victories - this is in your realm of possibility
|
||||
- Indirect control: public victories - you need to influence other people for putting indirect control
|
||||
- No control: a proactive person acknowledges this and accepts the problem to be able to live with it
|
||||
|
||||
A proactive person approaches every problem with this distinction
|
||||
|
||||
The story about the distinct CEO that was very commanding reminds me of [[Floris]]. I have been very reactive there, as a proactive person I should have understood Florises inner workings and use them to better communicate. What are Florises weaknesses? How can I complement them? If Floris expects something, how can I fulfill that in his view? How can I present work of the team such that he agrees?
|
||||
What is my circle of influence within OneSec? And what is my circle of concern?
|
||||
|
||||
Focus on being instead of having. Focus on problems that lie within your realm instead of problems out there. Focus on your attitude instead of other people’s weaknesses. Focus on your unconditional love and support for your partner and that will hopefully come back to you, in the end it is all that you can do.
|
||||
|
||||
The consequences of our actions often lie in the circle of concern, but not in the circle of influence. Therefore, we cannot control them and need to accept them when they happened. Bad decisions are mistakes, we cannot change what happened in the past, and thus not change what is in the circle of concern, but rather our attitude to it and learn from the mistakes to not make them the next time around. That is what lies within the circle of influence. Ignoring past mistakes and not to correct it and learn from it makes everything worse, because it is self-deceiving often including lies to one-self and others.
|
||||
|
||||
|
||||
---
|
||||
## Todos
|
||||
- [ ] what are paradigm shifts I have experienced?
|
||||
- [ ] What is my contribution to this world? How do I serve?
|
||||
|
||||
|
||||
## My Stories
|
||||
[[Stefan Fritsche|Dad]] hat auch ein paradigm shift gemscht, als er akzeptiert hat das der Lohnunterschied wegen der Einstufung nicht angepasst wird und er aber sich selber von einer anderen Seite gesehen hat mit Bezug auf Familie, Haus und generelles Wohlsein.
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Utopien für Realisten by Rutger Bregman
|
||||
created_date: 2024-10-27
|
||||
updated_date: 2024-10-27
|
||||
aliases:
|
||||
tags:
|
||||
- book
|
||||
type: book
|
||||
book_name: Utopien für Realisten
|
||||
author: Rutger Bregman
|
||||
status: not_started
|
||||
---
|
||||
|
||||
# Utopien für Realisten by Rutger Bregman
|
||||
- **🏷️Tags** : #10-2024 #book
|
||||
---
|
||||
## Summary
|
||||
|
||||
> [!summary] Summary
|
||||
> 3 Sentences only!
|
||||
> - What are the main ideas?
|
||||
> - If I implemented one idea from this book right now, which one would it be?
|
||||
> - How would I describe the book to someone else?
|
||||
|
||||
---
|
||||
## Ideas and Thoughts
|
||||
|
||||
> [!info]+ Inspiring Questions
|
||||
> - Did you think about other concepts from other books?
|
||||
> - Do the concepts fit to your past, to your memories?
|
||||
> - Can you relive them and reflect them from a different angle?
|
||||
|
||||
|
||||
---
|
||||
## Clippings
|
||||
|
||||
> [!info] Import Clippings from Kindle
|
||||
> Annotate Clippings with thoughts and cross references
|
||||
|
||||
Das problem der Armen ist das sie kein Geld haben, nicht das sie faul oder dumm sind.
|
||||
Das Problem der Obdachlosen ist das sie kein Dach über dem Kopf haben und nicht etwas anderes. Die Lösung für diese Probleme ist den Leuten zu geben was sie brauchen, ohne Bedingungen. Es rechnet sich sogar finanziell, da die Ausgaben die sonst rundherum gebraucht wurden (Polizei, Gericht, Berater, etc) teurer sind als die Leute einfach zu bezahlen.
|
||||
|
||||
Das Hauptproblem der Gesellschaft ist nicht die effektive Armut, sondern die Ungleichheit zwischen den Reichsten und den Ärmsten. Das BIP korreliert nicht mit dem Index gesellschaftlicher Probleme, die Ungleichheit jedoch schon. Auch wenn heute die Ärmsten reicher sind als Könige vor 200 Jahren, so vergleichen sie sich doch mit den Reichsten von heute was einen psychologischen Druck veranlasst. Das führt zu mehr Misstrauen, Statusangst, Mobbing.
|
||||
Es braucht ein bisschen Ungleichheit als Treiber für Arbeitsmotivation und Unternehmertum (wie [[Potential]] in Physik). Zu viel hemmt sogar das Wirtschaftswachstum.
|
||||
|
||||
|
||||
> [!Quote] George Santayana (1863-1952)
|
||||
> Wer sich nicht an die Vergangenheit erinnern kann, ist dazu verurteilt, sie zu wiederholen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Oscar Wilde erklärte, sobald wir das Land des Überflusses erreicht hätten, müssten wir unseren Blick auf den Horizont richten und erneut die Segel setzen: «Fortschritt ist die Verwirklichung von Utopien.» Aber der Horizont bleibt leer. Das Land des Überflusses ist in Nebel gehüllt. Just in dem Moment, in dem wir uns der historischen Aufgabe hätten stellen sollen, diese rei-che, sichere und gesunde Welt mit Sinn zu erfüllen, beerdigten wir stattdessen die Utopie. Und wir haben keinen neuen Traum, durch den wir sie ersetzen könnten, weil wir uns keine bessere Welt als die vorstellen können, in der wir heute leben. Tatsächlich glauben die meisten Menschen in den reichen Ländern, dass es ihren Kindern schlechter gehen wird als ihnen."
|
||||
|
||||
|
||||
|
||||
George Orwell hatte am eigenen Leib erfahren, was es bedeutete, arm zu sein. In seinen Erinnerungen *Erledigt in Paris und London (Down and Out in Paris and London, 1933, deutsch 1978)* schreibt er: "Man dachte, es wäre alles ganz einfach; es ist aussergewöhnlich kompliziert. Man dachte, es wäre schrecklich; es ist nur schmutzig und langweilig"
|
||||
Orwell beschreibt, wie er manchmal den ganzen Tag im Bett lag, weil es nichts gab, für das es sich gelohnt hätte aufzustehen. Das Problem mit der Armut sei, dass sie "die Zukunft auslöscht". Dem Armen bleibe nichts anderes übrig, als im Hier und Jetzt zu überleben. Und Orwell wundert sich darüber, dass manche Leute "einfach annehmen, sie hätten ein Recht darauf dir zu predigen und vorzubeten, nur weil dein Lohn unter einem bestimmten Schnitt gefallen ist".
|
||||
|
||||
---
|
||||
```query
|
||||
Utopien für Realisten Rutger Bregman
|
||||
-file: "Utopien für Realisten by Rutger Bregman.md"
|
||||
```
|
||||
Reference in New Issue
Block a user