Skip to content

Fix image path in overview.md #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
paravozz wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix image path in overview.md #31

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions content/en/building/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ This chapter will therefore guide you through how to manage and measure what we

There is a wealth of information online about the [Software Development Lifecycle](https://en.wikipedia.org/wiki/Systems_development_life_cycle). Consequently, there is some variation in terms of the various steps of the lifecycle. We do not take an opinionated approach on this; for pragmatic reasons, we will use these high-level steps in the rest of of this chapter:

<img src="img/sflc.svg" class="mx-auto" style="min-height: 2rem;"/>
<img src="/img/sflc.svg" class="mx-auto" style="min-height: 2rem;"/>

### Existing frameworks: DORA Metrics

Expand Down Expand Up @@ -58,4 +58,4 @@ Not suprisingly, the signals we favor display opposite features compared to the

- **It focuses on inputs**, in the form of bottlenecks, slow-downs and other inefficiencies at every step of the SDLC. This type of metric is more specific and actionable, and usually harder to misuse or "game". It also clearly puts the focus on improving the developer experience as opposed to measuring individual performance.
- **Its definition is simple to understand**. For someone with "average context" about the situation at hand, it should be easy to intuitively understand how the metric is defined and what may cause it to move in different directions. Again, it optimizes for actionability and it reduces the potential for "interpretation battles".
- **It supports drill-downs**. The metric should be easy to aggregate at various resolutions (team, department, organization) and it should support multiple ways to filter or group (e.g. by repository, by service, etc.). This is critical in terms of making it easy to debug problems and iterate on solutions.
- **It supports drill-downs**. The metric should be easy to aggregate at various resolutions (team, department, organization) and it should support multiple ways to filter or group (e.g. by repository, by service, etc.). This is critical in terms of making it easy to debug problems and iterate on solutions.