l e a n - IPA · 開発: TDD + CI (with Contract Tests) b. リファクタリング: コードをきれいに、シンプルに保つ c. 手戻りの防止: テストフレームワークで全体をテストする

l e a n software development

www.poppendieck.com Mary Poppendieck [email protected] [email protected]

Faulty Assumptions

How Lean Software Development Reduces Risk



間違った想定

リーンソフトウェア開発がリスクを減らすやり方

スライド翻訳: 原田騎郎・川口恭伸

l e a n

Assumptions

Assumption: an unstated belief about how the world is, or will become.

At the heart of most disasters we find faulty assumptions in design or operation.

Assumptions made are risks accepted and taken. When assumptions are tied to other assumptions, risks quickly magnify.

April 12 Copyright©2012 Poppendieck.LLC 3

Robert Charette, Challenging the Fundamental Notions of Software Development

http://www.itmpi.org/assets/base/images/itmpi/privaterooms/robertcharette/ChallengingtheFundamentalNotions.pdf

It is not what you know that can hurt you.

It is what you know that is not so. Will Rodgers

Examine Your Assumptions

l e a n

想定を検査しよう

想定

想定(思い込み): 世界のあり方について確かめていないが信じていること

ほとんどの大災害の主たる要因には、デザインや運用についての間違った想定がある

想定されると、それに含まれるリスクを受け入れ、リスクをとったことになる。思い込みが他の思い込みとつながると、リスクは急速に増大する。


Robert Charette, Challenging the Fundamental Notions of Software Development

http://www.itmpi.org/assets/base/images/itmpi/privaterooms/robertcharette/ChallengingtheFundamentalNotions.pdf

あなたを傷つけることを知っているものではない。あなたを傷つけないと知っているものである。

Will Rodgers

l e a n

TPS: Just-in-Time Flow

Faulty Assumption:

Maximum machine productivity = maximum overall productivity

April 12 5 Copyright©2008 Poppendieck.LLC

Faulty Assumption:

Maximum individual productivity = maximum overall productivity

l e a n

TPS: ジャストインタイムの流れ

誤った想定: 機械の生産性最大 =

全体生産性最大

April 12 6 Copyright©2008 Poppendieck.LLC

誤った想定: 個人の生産性最大 =

全体生産性最大

l e a n April 12 7 Cop

yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Assumption:

Early Specification Reduces Waste

Features and Functions Used in a Typical System

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always

7%

Often

13%

Sometimes

16% Rarely

19%

Never 45%

Rarely or Never

Used: 64%

Often or Always

Used: 20%

l e a n April 12 8 Copyright©2006 Poppendieck.LLC

想定: 早く仕様を固めればムダを減らせる

一般的なシステムにおけるフィーチャーや機能の使用頻度

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

いつも使う

7%

よく使う

13%

ときどき 16%

めったに使わない 19%

まったく使わない

45%

めったに使わない、全く使わない: 64%

いつも使う、よく使う: 20%


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Lean Principle:

Eliminate Waste

Waste is making the wrong thing or making the thing wrong.

Features that will not be used are waste, even if customers asked for them!

In any system where technology or market conditions change, an early detailed specification significantly increases waste.

The Biggest opportunity for increasing Software Development Productivity: Write Less Code!

Cost

Time


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

リーンの原則: ムダをなくす

間違ったモノを作るムダ、作る方法を間違えるムダ

使われないフィーチャーはムダ。顧客が要求したにしても！

どんなシステムでも技術動向、市場動向が変化すれば、早すぎる詳細化仕様はムダを大きく増やす

Tソフトウェア開発における生産性向上の最大の機会: 書くコードを減らせ!

Cost

Time

l e a n

TPS: Single Digit Set-up

Manufacturing

Faulty Assumption: Die changed have a huge overhead

Don’t change dies very often

TPS: Economics requires frequent die change

One Digit Exchange of Die

Software Development

Faulty Assumption: Releases have a huge overhead

Don’t release very often

Lean: Economics requires many frequent releases

Continuous Delivery

March, 2003 11 Cop

yrig

nt©

200

3

Pop

pen

diec

k.L

LC

l e a n

TPS: シングル段取り

製造業

誤った想定: 金型交換のオーバーヘッドは大きい

しょっちゅう金型を換えるな

TPS: 経済的状況により、金型を換えざるを得ない

シングル段取り(10分未満で金型交換完了)

ソフトウェア開発

誤った想定: リリースのオーバーヘッドは大きい

しょっちゅうリリースするな

リーン: 経済的状況により、しょっちゅうリリースせざ

るを得ない

継続的デリバリー

March, 2003 12

Copyrignt©2003 Poppendieck.LLC


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Assumption: The Job of

Testing is to Find Defects

The job of testing is to prevent defects

If you are focused on finding defects

– you are not focused on preventing them.

A quality process builds quality into the code

If you routinely find defects during verification

– your process is defective.

Defects are not caused by developers

Defects are caused by a system which allows defects.

– Defects are a management problem. --- W. Edwards Deming


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

想定: テストの仕事は、不良を見つけることだ

テストの仕事は、不良を防止することだ不良の発見に集中してしまうと、

– 不良の防止に注意を払わなくなる

品質プロセスは、品質をコードの中に作り込む検証中にしょっちゅう不良が見つかるなら、

– プロセスが壊れている

不良の原因は開発者ではない不良の原因は、不良を許すシステムにある

– 不良はマネジメントの問題である --- W. Edwards Deming

l e a n

Lean Principle:

Build Quality In

How good are you? When in your release cycle do you try to freeze code and test the system?

What percent of the release cycle remains for this “hardening”?

Typical: 30%

Sometimes: 50%

Top Companies: <10%

Release Cycle

Every software development process ever invented has had the same primary goal – find and fix defects as early in the development process as possible. If you are finding defects at the end of the development process – your process is not working for you.


l e a n

リーンの原則:

品質を作り込む

どれくらいうまく使えている? リリースサイクルの中で、コードをフリーズしてテストを始めるのはいつ？リリースサイクルの中で、コードフリーズ後の「堅牢化」作業が締める割合は？

普通: 30%

時々: 50%

トップ企業: <10%

リリースサイクル

これまでに考案されたソフトウェア開発プロセスには、すべからく共通のゴールを持っている。不良はなるべく早く発見し修正することだ。開発プロセスの最後で不良が見つかるなら、そのプロセスは適切に使われていない。


l e a n

Total Cycle Time

Assumption: Releases are

Painful! Avoid Releases!

Is Your Release Cycle greater than six months?

Quick & Dirty Value Stream Map:


Release Cycle Release Cycle

Harden Design UAT Develop Need a Feature

Release Cycle

Total Cycle Time Value-Added Time

Average Start End Start

Need a Feature

How can a one week feature

take over a year to deliver?

l e a n

Total Cycle Time

想定: リリースは辛い! リリースを避けよう!

リリースサイクルが６ヶ月以上？

バリューストリームマップはこんな感じ:


リリースサイクルリリースサイクル

堅牢化設計受け入れテスト開発フィーチャー

要求

リリースサイクル

トータルサイクルタイム付加価値時間

Average Start End Start

フィーチャー要求

開発に１週間しかかからないフィーチャーのリリースに、半年以上かかるの？

l e a n

Lean Principle:

Learn Constantly

For Each Business Capability:

1. Design a. Specify: Discuss and agree on

examples of intended behavior.

b. Automate: Put the examples into a regression framework (eg. cucumber).

2. Implement a. Develop: TDD + CI (with Contract Tests)

b. Refactor: Clean up the code to keep it simple.

c. Regression: End-to-End testing with regression framework.

3. Validate a. Test: Exploratory Testing, Performance Testing, Canary Releasing

b. Measure Value: A/B Experiments, Cohort Metrics, Interviews, etc.

4. Learn April 12 Copyright©2012 Poppendieck.LLC 19

Iter

ate

l e a n

リーン原則: 常に学ぶ

各ビジネス価値について: 1. デザイン

a. 明確化: 引き出したい行動の具体的な例について議論し、合意する。

b. 自動化: その例をテストフレームワーク (cucumberなど)に入れる

2. 実装 a. 開発: TDD + CI (with Contract Tests) b. リファクタリング: コードをきれいに、シンプルに保つ c. 手戻りの防止: テストフレームワークで全体をテストする

3. 確認 a. テスト: 探索的テスト, パフォーマンステスト, カナリアリリース b. 価値を実測する: A/B テスト, コホート分析, インタビュー, etc.

4. 学習


繰り

返す

TDD: Test Driven Development CI: Continuous Integration

l e a n

Rep

orts

Met

adat

a

Rep

orts

Met

adat

a

BIN

AR

IS

Continuous Delivery

Testers

Self-Service Deployments

Source

Code & Tests

UAT Stage Configure Environment

Deploy Binaries

Smoke Test

Manual Testing

Rep

orts

Met

adat

a

Capacity Stage Configure Environment

Deploy Binaries

Smoke Test

Run Capacity Tests

Operations Push-Button

Releases

Testers

Production Configure Environment

Deploy Binaries

Smoke Test

Acceptance Stage Configure Environment

Deploy Binaries

Smoke Test

Run Acceptance Tests

Commit Stage Compile

Commit Tests

Assembly

Code Analysis

BIN

AR

IS

VERSION CONTROL

ARTIFACT REPOSITORY

Environment

& Application

Configuration

Scripts

BIN

AR

IS

Develop Stage Design

Code & Script

Unit Test

Refactor

Rep

orts

Met

adat

a


Design Stage Model

Hypothesis

SBE

Wireframes

l e a n

レポ

ート

メタ

デー

タ

レポ

ート

メタ

デー

タ

バイ

ナリ

継続的デリバリー

テスター

セルフサービスデプロイメント

ソースコード & テスト

UATステージ環境設定

バイナリのデプロイスモークテスト

手動テスト

レポ

ート

メタ

デー

タ

キャパシティステージ環境設定


キャパシティテストを実行

オペレーション

ボタンを押すだけでリリース

Testers

本番(プロダクション) 環境設定


受入ステージ環境設定


受入テストを実行

コミットステージコンパイル

コミットテストアセンブリ

コードアナリシス

バイ

ナリ

バージョン管理

成果物(アーティファクト) リポジトリ

環境 & アプリケーション設定スクリプト

バイ

ナリ

開発ステージ設計

コード & Script ユニットテスト

リファクタリング

レポ

ート

メタ

デー

タ


設計ステージモデリング

仮説 SBE

ワイヤフレーム

l e a n

Assumption:

Organize with Projects

Up-front funding

Decompose into Detailed Tasks

Schedule Each Task

Manage Tasks to Schedule

Success = Cost/Schedule/Scope

Projects have an “end”

Project Teams Disband

Start of Project

Completion

Maintenance

Batch Funding →

Short Term Thinking


Projects

l e a n

想定: プロジェクトを組織する

事前に予算決め

詳細なタスクに分割

個々のタスクをスケジュール

タスクのスケジュール管理

成功 = コスト/スケジュール/スコープ

プロジェクトは「終了」する

プロジェクトチームは解散

プロジェクト開始

完了

保守

一括で予算決め → 近視眼的思考


プロジェクト

l e a n

Lean Principle:

Optimize the Whole System

Products

Incremental funding

Scope is expected to evolve

Learning is more important than “The Plan”

Manage Workflow, rather than Tasks

Success = profit/market share

Successful Products don’t “end”

Team usually stays with the Product

Concept Feasibility

Internal Release

Alpha Release

Beta Release

First Production Release

Major Release

Dot upgrade

Incremental Funding

→ System Thinking


l e a n

リーンの原則: システム全体を最適化

プロダクト

漸進的予算

スコープは進化することを予期している

学習は、「計画」よりも重要

ワークフローを管理。タスク管理でなく

成功 = 利益/市場シェア

成功した製品は、「終了」しない

チームは、製品とともに存続する

コンセプト実現可能性

内部リリース

アルファ版

ベータ版

製品版初版

メジャーリリース

小規模修正

漸進的予算

→ システム思考


l e a n

Empire State Building

September 22, 1929

Demolition started

January 22, 1930

Excavation started

March 17, 1930

Construction started

November 13, 1930

Exterior completed

May 1, 1931

Building opened

Exactly on time

18% under budget

One Year Earlier:

How did they do it? The key: Focus on FLOW. April 12 Copyright©2011 Poppendieck.LLC 27

l e a n

エンパイアステートビル

1929/9/22

解体工事開始 1930/1/22

基礎工事開始

1930/3/17

建設開始

1930/11/13

外装建築完了

1931/5/1 ビルがオープン

予定通り

予算は１８％下回る

当初予定より１年早く竣工:

どうしてこんなことが可能? 鍵は: 流れに集中すること April 12 Copyright©2011 Poppendieck.LLC 28

l e a n

Steel Schedule

We thought of the work as if it

were a band marching through

the building and out the top.

From: “Building the Empire State” Builders Notebook: Edited by Carol Willis


l e a n

鉄骨のスケジュール

自分たちは、ビルの中をしたから一番上まで行進するバンドみたいなつもりで仕事をしていた。



l e a n

The Four Pacemakers

1. Structural Steel Construction

Completed September 22, 12 days early

2. Concrete Floor Construction

Completed October 22, 6 days early

3. Exterior Metal Trim &Windows

Completed October 17, 35 days early

4. Exterior Limestone

Completed November 13, 17 days early



l e a n

４つのペースメーカー

1. 構造鉄骨の建築 9/22 完了, 12 日早く

2. コンクリート床の建築 10/22完了, 6 日早く

3. 窓枠などの外装と窓 10/17完了, 35 日早く

4. 石灰岩の外装 11/13完了, 17 日早く



l e a n

Key Success Factors

1. Teamwork of owner, architect, and builder

Eliminated design loops by consulting experts early.

2. Deeply Experienced Builders

Fixed Price Contract!

3. Focus on the key constraint: Material Flow

500 trucks a day – no storage on site

4. Decoupling

The pacemakers (and other systems) were designed to be independent

5. Cash Flow Thinking Every day of delay cost $10,000 ($120,000 today).

6. Schedule was not laid out based on the details of the building design, the building was designed based on the constraints of the situation.

Two acres of land in the middle of New York City, zoning ordinances, $35,000,000 of capital, the laws of physics, and a May 1, 1931 deadline.


l e a n

主な成功要因

1. オーナー、アーキテクト、施工者のチームワークエキスパートに早くから相談することで、設計のループをなくす

2. 熟達した施工者固定価格契約!

3. 主要な制約に集中: 資材の流れトラック500台/日 – 現地に資材置き場はない

4. 依存の切り離し４つのペースメーカー(と他のシステム) は独立して動けるように設計された

5. キャッシュフロー思考一日遅れのコストは、$10,000 (今の価値に直すと$120,000).

6. ビル設計の詳細をもとにスケジュールを引くことはしなかった。ビルは、状況における制約に基づいて設計されたニューヨークの中心の２エーカーの土地、土地利用区分、3500万ドルの資

金、物理法則、1931/5/1 という納期


l e a n

Lessons

Design system to meet the real constraints;

do not derive constraints from the design.

Workflows are easier to control &

more predictable than schedules.

Decouple workflows;

break dependencies!


l e a n

学び

システムを現実の制約に合うように設計せよ設計から制約を導く出すのではない

スケジュールよりワークフローのほうが

予想しやすく制御しやすい

ワークフローを切り離せ

依存関係をなくせ！


l e a n

Iterative Workflow

Concept

Product

or

Business Goals

High Level

Stories

& Tests

Daily

Delivery Discovery

Deployable

Software with

Test Suites

Feedback Ready–Ready

Done–Done

Every 2-4

Weeks

Shortly Before

Implementation


l e a n

繰り返しワークフロー

Concept

Product

or

Business Goals

High Level

ストーリーとテスト

毎日

デリバリー発見

デプロイ可能

テスト付きソフトウェア

フィードバック Ready–Ready

Done–Done

2-4週毎実装のちょっと前


l e a n

Kanban Workflow

Visualize and Manage Workflow Limit Work in Process

Clarify “Done” for each Column Understand Capacity

Discover Dev/Unit Test Deploy orem ipsum dolor sit

amet, co nse ctetur

orem ipsum dolor sit

amet, co nse ctetur


amet, co nse ctetur


amet, co nse ctetur

SIT 5 6 3

FLOW Avg cycle time: days 12


amet, co nse ctetur


amet, co nse ctetur


amet, co nse ctetur

Next 3


amet, co nse ctetur


amet, co nse ctetur

Weekly Dev

Ready

SIT Ready


Ready to Develop:

1. Wireframes

2. Story Tests

3. Less than 3 days work

Ready for system test

1. Story test passed & in

regression harness

2. No false negatives

3. Proper environment

Ready to Design:

1. Vendor time committed

2. ……..

Ready to Deploy:

1. Regression passed

2. ……..

l e a n

Kanban ワークフロー

ワークフローを見える化して管理仕掛品を制限

各列の “Done” の定義の明確化能力量を把握する

発見開発/単体テストデプロイ orem ipsum dolor sit amet, co nse ctetur

orem ipsum dolor sit amet, co nse ctetur



SIT 5 6 3

流れ平均サイクルタイム: 日 12




次 3



週次 Dev

Ready

SIT Ready


Ready to Develop: 1. Wireframes 2. Story Tests 3. Less than 3 days work

Ready for system test 1. Story test passed & in

regression harness 2. No false negatives 3. Proper environment

Ready to Design: 1. Vendor time committed 2. ……..

Ready to Deploy: 1. Regression passed 2. ……..


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

Principles of

Lean Software Development

1. Eliminate Waste

2. Build Quality In

3. Learn Constantly

4. Deliver Fast

5. Optimize the Whole

6. Engage Everyone

7. Keep Getting Better

Speed

Quality Low Cost


yrig

ht©

200

6

Pop

pen

diec

k.L

LC

リーンソフトウェア開発の原則

1. ムダをなくす

2. 品質を作り込む

3. 常に学ぶ

4. 速く届ける

5. 全体を最適化

6. 全員参加

7. 継続的改善

スピード

品質コスト低減



Thank You!

More Information: www.poppendieck.com



ありがとうございました!

詳細は: www.poppendieck.com

Documents

l e a n - IPA · 開発: TDD + CI (with Contract Tests) b. リファクタリング: コードをきれいに、シンプルに保つ c. 手戻りの防止: テストフレームワークで全体をテストする