vault backup: 2025-03-23 16:50:29
This commit is contained in:
@@ -225,6 +225,84 @@ Once again, the goal is to have self-directed cross-functional teams that have t
|
||||
|
||||
### More Effective Individuals and Interactions
|
||||
|
||||
Productivity differs up to a factor of 10 between individuals of similar level of experience. Also teams in the same industries see the same factor.
|
||||
|
||||
There is a tension between new learning and application of prior learning.
|
||||
|
||||
- [ ] #todo/b Look at PDL (Professional Development Ladder)
|
||||
|
||||
Emotional intelligence is key. People with a lot of it perform much better
|
||||
|
||||
Meetings should be kept effective:
|
||||
- Clear purpose
|
||||
- What decision / deliverable
|
||||
- Schedule shorter rather than longet
|
||||
- Only people who are necessary
|
||||
|
||||
### More effective Agile Projects
|
||||
- Keep Projects small: much higher successrate when team remains below 20 people (but project needs to be defined accordingly, e.g. you cannot build an airplane with 2 people)
|
||||
- The larger the project, the lower the per-person productivity. ![[image 16.jpg]]
|
||||
- keep Sprints short: 1-3 weeks max. Requirements can only be changed for the next sprint. Increase team accountability. Increase responsiveness. Expose risks early. Encourage automation. Offer frequent sense of accomplishment.
|
||||
- Velocity based planning
|
||||
- Vertical slices: tighter feedback loops, delivers higher business value
|
||||
- Manage technical Debt: technical debt can be an asset but can quickly evolve into a liability. ![[image 17.jpg]]
|
||||
- can be intentional (shirt-term / long-term)
|
||||
- unintentional (bad faith)
|
||||
- Unintentional but planner well and used proper software development practices (good faith)
|
||||
- Legacy
|
||||
- Summary: ![[image 18.jpg]]
|
||||
|
||||
### More effective large agile projects
|
||||
I only skimmed this chapter because it doesn’t apply to us for now. But a few core ideas:
|
||||
- Support large teams through architecture: design a good architecture upfront in order to be able to split the large project into sub units , where normal small agile teams can execute whatever is needed in an agile manner.
|
||||
- loose coupling, modularity
|
||||
- Avoid monolithic databases
|
||||
- Use queues: this makes it very modular because the thing can be processed later (microseconds later). It avoids the very rigid unflexible way of coding. Think of it as seams: there is a lot of interaction within a process, but very little across a boundary. You can take this too far if you have too many
|
||||
- design by contract
|
||||
- Typical architecture is microservices: its very well compatible with agile.
|
||||
-
|
||||
- Most common problems:
|
||||
- requirements
|
||||
- Architecture
|
||||
- Configuration management / version management
|
||||
- QA/Test
|
||||
- Project Management
|
||||
- Process
|
||||
|
||||
### More effective Agile Quality
|
||||
|
||||
> If you can‘t find the time to do it right, where will you find the time to do it over?
|
||||
|
||||
- Minimize the Defect Detection Gap: we need effective quality assurance to detect defects early on
|
||||
- Unit testing
|
||||
- Static analysis
|
||||
- Code reviews (if performed in a timely way)
|
||||
- Continuous integration
|
||||
- Create and use a Definition of Done (DoD) (p. 157ff)
|
||||
- Completion criteria for: design, code, test, documentation and other work related to implementation of a requirement.
|
||||
- State very clearly to avoid ambiguity: its true or false.
|
||||
|
||||
### More effective Agile Testing
|
||||
|
||||
- Increase emphasis on testing by devs.
|
||||
- Increase front loading (test immediately after function creation)
|
||||
- Increase Test automation
|
||||
|
||||
- automated tests, written by developers:
|
||||
- Api tests, unit tests, integration tests, acceptance tests, UI layer tests, support for mocking, random inputs and data, simulations
|
||||
- Devs should be able to run tests locally within minutes
|
||||
- Team should be able to run complete test suite fot a complete test pass within hours. Incl. all unit tests, user level tests
|
||||
- Devs need to take primary responsibility for testing their own code
|
||||
- Signs are if they close items towards the end of sprint (prio to code than to test)
|
||||
- Code coverage of at least 70% (except for safety critical systems). Its
|
||||
- Monitor static code metrics: depth of decision nesting, file size, folder size, magic numbers, embedded SQL, comments, adherence to coding guidelines
|
||||
- Use coding guidelines for test code as well
|
||||
- Maintenance of test suite is important as well
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 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.
|
||||
|
||||
Reference in New Issue
Block a user