From f8abdeb4ad06afb65eef6d5192e78a3bba430438 Mon Sep 17 00:00:00 2001 From: Julien Calixte Date: Thu, 10 Apr 2025 22:26:48 +0200 Subject: [PATCH] article: better introduction --- src/modules/pull-system/FlowArticle.vue | 68 ++++++++++++------------- 1 file changed, 33 insertions(+), 35 deletions(-) diff --git a/src/modules/pull-system/FlowArticle.vue b/src/modules/pull-system/FlowArticle.vue index 3f9ddfc..15d2ab2 100644 --- a/src/modules/pull-system/FlowArticle.vue +++ b/src/modules/pull-system/FlowArticle.vue @@ -121,55 +121,50 @@ const createdAt = new Date('2025-01-08').toLocaleDateString(undefined, { coding, and ensuring the product goes live.

- First, what is a feature? A feature is a software component that - provides a functionality for the user. Examples include the ability to - read articles, share content, or use the app offline. In our simulation, - a feature is represented as follows: + First, let's take a moment to define the most important element: the + feature. A feature is a software component that provides a functionality + for the user like the ability to read articles, share content, or use + the app offline. In our simulation, a feature is represented as follows:

Each feature starts with an intention: "{{ feature.name }}". This defines what we will add to the mobile app. + >". "{{ feature.leadTime }}d" indicates the + number of days teams work on the feature. The goal is to minimize this + number and deliver features as quickly as possible. "" shows the number of defects found in the feature during its workflow + (For simplicity, we assume teams can identify all defects, and no + defective features are delivered). Any defect must be reworked by the team that caused it.

+

It takes one day to each team to complete their part.

-

- {{ feature.leadTime }}d indicates the - number of days teams work on the feature. The goal is to minimize this - number and deliver features as quickly as possible. -

-

- - shows the number of defects found in the feature during its workflow. - For simplicity, we assume teams can identify all defects, and no - defective features are delivered. Any defect must be reworked by the - team that caused it. -

-

- Okay! We have 20 features to deliver. Each team takes one day to - complete their part for a feature. -

-

Every day, you can choose between two strategies:

-
    -
  1. Push system
    2. -
  2. Pull system
    3. -

- In this article, we’ll examine how these strategies affect efficiency - and quality. Let’s explore each one! + Okay! We have 20 features to deliver and every day, you can choose + between two strategies:

-

The Push System: Start as Many Features as Possible

+

+ 1. The Push System: Start as Many Features as + Possible +

In the push system, we aim to maximize the time teams spend working on the product. This ensures no downtime, as everyone always has tasks to complete.

-

The Pull System: Produce Features When the Next Team Needs Them

+

+ 2. The Pull System: Produce Features When the Next + Team Needs Them +

Instead of pushing features forward, the pull system waits until the next team is ready. This approach acknowledges that the ideal "push @@ -177,9 +172,9 @@ const createdAt = new Date('2025-01-08').toLocaleDateString(undefined, { readiness, we avoid creating a backlog of pre-prepared features.

- To implement this, we introduce "blue bins" as safety stock. These bins - ensure teams always have work ready to process without delays but we - stop whenever blue bins are full. + We introduce "blue bins" as safety stocks: these bins ensure teams + always have work ready to process without delays + but teams stop whenever blue bins are full.

+
+

All set? Let's make this app!

+

- Well, what do you think? Not so simple... What are the insights from - these strategies? Here are some observations: + Well, what do you think? Not so obvious... What can we say? Here are + some observations: