118 lines
4.3 KiB
Vue
118 lines
4.3 KiB
Vue
<script setup lang="ts">
|
|
import ProblemSolvingIcon from '@/icons/ProblemSolvingIcon.vue'
|
|
import PullSystemIcon from '@/icons/PullSystemIcon.vue'
|
|
import PushSystemIcon from '@/icons/PushSystemIcon.vue'
|
|
import FeatureItem from '@/modules/pull-system/feature/FeatureItem.vue'
|
|
import FlowControls from '@/modules/pull-system/feature/FlowControls.vue'
|
|
import QualityIssue from '@/modules/pull-system/feature/QualityIssue.vue'
|
|
import { Feature } from '@/modules/pull-system/feature/feature'
|
|
|
|
const feature: Feature = {
|
|
name: 'As a user I can have access to the latest news from the homepage.',
|
|
complexity: 3,
|
|
leadTime: 2,
|
|
qualityIssue: 4,
|
|
status: 'doing',
|
|
step: 2
|
|
}
|
|
</script>
|
|
|
|
<template>
|
|
<div>
|
|
<p>
|
|
The project who has just started, our goal is to make a product as fast as
|
|
you can. With you, you'll have the product team, designers, developers and
|
|
a release team.
|
|
</p>
|
|
<p>
|
|
First things first, what is a feature? A feature is a piece of software
|
|
that enables <em>things</em> for the user. It can be the capability to
|
|
read articles or to share them or even to be able to read one without the
|
|
need for internet connection. In our simulation, a feature will be
|
|
represented as follow:
|
|
</p>
|
|
<FeatureItem :feature="feature" />
|
|
<p>
|
|
It starts with the intention "<code>{{ feature.name }}</code
|
|
>". This is what we'll add to the mobile app.
|
|
</p>
|
|
<p>
|
|
<span class="numeric">({{ feature.complexity }})</span> is the complexity
|
|
of the feature. The more complex a feature is, the more chance we
|
|
introduce a defect.
|
|
</p>
|
|
<p>
|
|
<span class="numeric">{{ feature.leadTime }}d</span> is the number of days
|
|
the teams work on the feature. The goal is to reduce this number and
|
|
deliver as fast as possible.
|
|
</p>
|
|
<p>
|
|
<QualityIssue class="inline" :quality-issue="feature.qualityIssue" />
|
|
are the number of defects the feature had during the flow. For the sake of
|
|
simplicity, we assume teams are capable of detecting every defects and we
|
|
never deliver defects.
|
|
</p>
|
|
<p>
|
|
Okay! We have 20 features to deliver. It takes one day for each team to
|
|
finish their part for each feature.
|
|
</p>
|
|
<!-- [dps] <p>Each day, you can choose between 3 strategies:</p> -->
|
|
<p>Each day, you can choose between 2 strategies:</p>
|
|
<ol>
|
|
<li>
|
|
<PushSystemIcon />
|
|
Push system
|
|
</li>
|
|
<li>
|
|
<PullSystemIcon />
|
|
Pull system
|
|
</li>
|
|
<!-- [dps]
|
|
<li>
|
|
<ProblemSolvingIcon />
|
|
Problem solving
|
|
</li> -->
|
|
</ol>
|
|
<p>
|
|
In this article we'll focus on how these strategies are efficient and what
|
|
are the impact on the quality the teams produce. Let's dive in each
|
|
strategy!
|
|
</p>
|
|
<h3>The push system: start as many features as possible</h3>
|
|
<p>
|
|
By pushing features from the start, we try to maximize the time worked by
|
|
teams on the product. This way, no money is wasted, everyone has everytime
|
|
something to do.
|
|
</p>
|
|
<h3>The pull system: produce features only when the next team needs it</h3>
|
|
<p>
|
|
Now, instead of pushing features, we wait for the next team to be ready.
|
|
It comes from the assumptions that we will never reach the best score ever
|
|
aka "the push system where everything goes right". We know we prefer
|
|
waiting for next team to be ready before doing some extra work than having
|
|
stock of feature pre-baked.
|
|
</p>
|
|
<p>
|
|
To make this happen we first need to setup blue bins: our security stocks
|
|
Blue bins make sure teams can work without any blockers. The next team
|
|
will always have material to transform. Here, we'll have 2 blue bins per
|
|
team.
|
|
</p>
|
|
<!-- [dps]
|
|
<h3>Problem solving: no production, just reflection</h3>
|
|
<p>
|
|
We invest days where we are not productive at all to investigate and
|
|
learning from our mistake. We know that we will never reach the best score
|
|
ever and we know that mistakes will reappear. So we take more time to
|
|
understand and limit rework. The more the team investigate, the more the
|
|
team learn and start to be extremely good at problem solving.
|
|
</p> -->
|
|
</div>
|
|
</template>
|
|
|
|
<style scoped>
|
|
.inline {
|
|
display: inline;
|
|
}
|
|
</style>
|