implementation planning
- define goals
- practically done with requirement analysis
- conduct research
- partially done at the requirement elicitation phase
- map out risks
- schedule milestones
- assign responsibilities and tasks
- allocate resources
based on What is an implementation plan? 6 steps to create one (Asana, 2024)
conduct research
- during the requirement analysis some data was already collected
- regarding functional and non-functional requirements
- interviews, questionnaires, telemetry, etc.
- some research may be needed to select the tools and frameworks during
the implementation
- do some experiments with different libraries
learning could be a task
- you may need to work a technology / framework / language that you are not familiar with
- or you just have to learn a new codebase
- calculate with learning during the planning
experiments
- sometimes the task requires a step that you don’t want to implement
(again) but use an existing framework instead
- e.g., crop a profile picture to a standard size, while keeping the face in focus
- then you may want to search for a suitable framework and do some research about how to use it
fail fast
~ indirect proof, proof of contradiction
- the requirements are known
- try to eliminate candidates as soon as possible
- unmaintained
- cannot handle certain file formats
- target language / version is not supported
- then move on the next one
- document findings (~ decision records)
https://en.wikipedia.org/wiki/Fail_fast_(business)
minimal workable example
- when you have a promising candidate, write code to try it out in practice
- start new project
(for every candidate / experiment)- simple, clean
- no interference, side effects
- eliminate unknown variables
- document research findings (~ decision records)
Stackoverflow guideline on How to create a Minimal, Reproducible Example
identify risks
a risk is a possibility that something bad can happen
- there is risk inherent with building any piece of software
- whether you’re building a completely new greenfield project,
- or adding a new feature to an existing codebase
- other parts cease to work
- the new feature alienate users
- data loss
based on riskstorming.com | CC BY 4.0
prioritize risks
- often difficult to prioritise which risks you should take care of
- one way to do this is to map risks to a matrix
- where you evaluate
- the probability: how likely is it that the risk will happen?
- and the impact: what is the negative impact if the risk does occur?
from riskstorming.com | CC BY 4.0
risk register
- a risk register is a document used as a risk management tool
- contains all identified risks with additional information
- e.g., nature of the risk, probability, impact, reference and owner, mitigation measures
- it can be displayed as a table or as a scatterplot
source Wikipedia (Wikipedia contributors, 2024b)
Rust-GCC example
common columns in table-based risk registers:
category, name, responsible, probability, impact, mitigation, action by,
action when
| Risk | Impact (1-3) |
Likelihood (0-10) |
Risk (I * L) |
Mitigation |
|---|---|---|---|---|
| Rust Language Changes | 2 | 7 | 14 | Target a specific Rustc version |
| Missing GCC 13 upstream window | 1 | 6 | 6 | Merge in GCC 14 and be proactive about reviews |
source: Rust-GCC / Reporting
risk storming
- visual and collaborative risk identification technique
- created by Simon Brown
- author of C4 model
- motivation: often only one person evaluated risks
- ~ four eyes see more than two
- risk evaluation should be collaborative activity
this chapter is based on riskstorming.com | CC BY 4.0
steps of risk storming
- draw some software architecture diagrams
- to show what you’re planning to build, at different levels of abstraction
- ideally C4
- identify the risks individually
- gather people in front of the diagrams,
- ask them to identify what they personally perceive to be risky
- write a summary of each risk on a separate sticky note,
- colour coded to represent low, medium, and high priority risks
- timebox this exercise (e.g. 10 minutes),
- do it in silence
from riskstorming.com | CC BY 4.0
steps of risk storming
- converge the risks on the diagrams
- ask everyone to place their sticky notes onto the diagrams,
- sticking them in close to the area where the risk has been identified
- review and summarise the risks
- review and summarise the output,
- especially focusing on risks that only one person identified,
- or risks where multiple people disgree on the priority
from riskstorming.com | CC BY 4.0
mitigating risks
- risks are identified
- and prioritized
- come up with mitigation strategies
- either to prevent the risks from happening
- or to take corrective action if the risk does occur
- focus on the highest priority ones first
from riskstorming.com | CC BY 4.0
mitigation strategies
- education
- train the team,
- or hire new team members in areas where you lack experience
- writing code
- create prototypes, proofs of concept, walking skeletons, etc. to mitigate technical risks by proving that something does or doesn’t work
- re-work
- change software architecture to remove or reduce the
probability/impact of identified risks
- e.g. removing single points of failure,
- upon change you should re-run the risk-storming process
- change software architecture to remove or reduce the
probability/impact of identified risks
from riskstorming.com | CC BY 4.0
walking skeleton
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
– Alistair Cockburn
it is a pattern intended to kick-start test driven development (later in the course)
via wiki.c2.com
risk storming example
schedule milestones
- visualize project milestones
- Gantt chart
- keep the entire team posted
- pay attention to holidays
- multiple countries in the case of an international team
- things won’t go as planned, so
- add safety margin (wiggle room)
- e.g., an extra week before deadline for fixing bugs
ninety–ninety rule
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
– Tom Cargill, Bell Labs
source: (Bentley, 1985)
assign responsibilities and tasks
- every task you want to make done should have exactly one person
responsible
- no assignee – no one will do it
- more than one – “I though the other one was doing it”
- define area of responsibility
- a task (as in scrum) should have definition of done, which specifies it
- everyone needs to know what other people are responsible for
- scrum/kanban board can visualize it
- issue/ticket trackers can also work
at the end of a sprint planning, every task in the sprint backlog should have an assignee
source: (Paquet, 2019)
dependencies
allocate resources
- resource is anything that is available with limits
- money, time, personnel, equipment, etc.
man-month
Man-month is a hypothetical unit of work representing the work done by one person in one month.
– Fred Brooks: The Mythical Man-Month (Brooks, 1974)
estimating time requirement of a task
- scrum (and agile in general) does not say anything about how to estimate (time)
- story points are often used instead
- (relative) unit of effort required to fully implement a product backlog item
- e.g., 1–5,
- Fibonacci: 1, 2, 3, 5, 8, 13…
- powers of 2: 1, 2, 4, 8, 16, 32…
“Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time (Radigan, n.d.).”
planning poker
- is a consensus-based, gamified technique for estimation (in agile)
- product owner reads the user story
- members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud
- estimates are then discussed and high and low estimates are explained
- repeat until estimates converge
- by hiding the figures, the group can avoid the cognitive bias of
anchoring
- where the first number spoken aloud sets a precedent for subsequent estimates
zero: done | tiny: ½ | easy: 1, 2, 3 | medium: 5, 8, 13 | large: 20, 40 | very large: 100 | ∞: huge
optional cards
- ? means unsure
- ☕ means “I need a break”
source: (Wikipedia contributors, 2024a)
estimation is guessing
- many developers do not like to estimate
- seemingly simple task can turn out to be difficult
- some difficulties are hard to foresee
- bad architectural decision
- “Architecture is the decisions that you wish you could get right early in a project.” – Ralph Johnson
- make educated guesses instead
- measure
- burn down charts, cumulative flow diagram
- infer from previous tasks
- measure
Brooks’s law
Adding manpower to a late software project makes it later.
Assigning more programmers to a project running behind schedule will make it even later. This is because the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever-increasing quantity of available time (Wikipedia contributors, 2024c).
Furthermore, in many cases the new programmer cannot just learn about the project on their own, but someone should mentor them. This may be considered as a part of the communication overhead, it is an important aspect.
references
Asana, T. (2024). What is an implementation plan? 6 steps to create one. https://asana.com/resources/implementation-plan .
Bentley, J. (1985). Programmimg pearls. Commun. ACM, 28(9), 896–901. https://doi.org/10.1145/4284.315122
Brooks, F. P. (1974). The mythical man-month. Datamation, 20(12), 44–52.
Grams, C. (2019). How much time do developers spend actually writing code? https://blog.tidelift.com/how-much-time-do-developers-spend-actually-writing-code .
Paquet, P. (2019). When everyone is responsible, no one is responsible. https://medium.com/@philippelyp/when-everyone-is-responsible-no-one-is-responsible-73e9a179237f .
Radigan, D. (n.d.). Story points and estimation. https://www.atlassian.com/agile/project-management/estimation .
Wikipedia contributors. (2024a). Planning poker — Wikipedia, the free encyclopedia. https://en.wikipedia.org/w/index.php?title=Planning_poker&oldid=1243064642.
Wikipedia contributors. (2024b). Risk register — Wikipedia, the free encyclopedia. https://en.wikipedia.org/w/index.php?title=Risk_register&oldid=1245973868.
Wikipedia contributors. (2024c). The mythical man-month — Wikipedia, the free encyclopedia. https://en.wikipedia.org/w/index.php?title=The_Mythical_Man-Month&oldid=1233664045 .