Xp寺子屋出張版＃２「xp入門追補版」

XPJUG関西 / XP寺子屋

1

「ＸＰ入門」追補版

2011.12.11

ＸＰ寺子屋


2

アジェンダ


3

２２２２．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの基本思想基本思想基本思想基本思想

ＸＰの基本思想についてお話します。

２２２２．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの基本思想基本思想基本思想基本思想

ＸＰの基本思想についてお話します。

３３３３．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの開発開発開発開発プロセスプロセスプロセスプロセス

ＸＰの開発プロセスについてお話します。

３３３３．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの開発開発開発開発プロセスプロセスプロセスプロセス

ＸＰの開発プロセスについてお話します。

４４４４．．．．プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス！！！！！！！！

ＸＰで使用するプラクティスをご紹介します。

４４４４．．．．プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス！！！！！！！！

ＸＰで使用するプラクティスをご紹介します。

１１１１．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの歴史歴史歴史歴史

ＸＰの歴史についてお話します。

１１１１．ＸＰ．ＸＰ．ＸＰ．ＸＰのののの歴史歴史歴史歴史

ＸＰの歴史についてお話します。


4

ToDo Doing Done


5

ＸＰとは？

• eXtremeProgrammingの略称。

• ソフトウェア開発手法の１つ。

• ソフトウェア開発において「良い事を最大限に実施」する手法。


6

ＸＰの提唱者

Three Extremos

けんと・べっく

Kent Beckうぉーど・かにんがむ

Ward Cunninghamろん・じぇふりーず

Ron Jeffries


7

ＸＰの歴史

• 最初にXPが実践されたのは「「「「C3C3C3C3プロジェクトプロジェクトプロジェクトプロジェクト」」」」。

• 危機的状況にあったC3プロジェクトを救うべく、過去に経験した手法を最大限に実施。その結果、プロジェクトの建て直しに成功。

• この経験を元に、ＸＰ本を執筆。急速に拡大。

日本で翻訳本『XPエクストリームプログラミング入門』刊行。2000年

米国で『eXtreme Programming Explained』刊行。1999年

ケント・ベックがＣ３プロジェクトに携わる。1996年


8

名前の由来

• [[[[extreamextreamextreamextream]]]]=極端な／究極の

– 良良良良いいいい事事事事を徹底的に行い

– 不要不要不要不要なななな事事事事を徹底的に行わない

• [Programming][Programming][Programming][Programming]– プログラミングこそソフトウェア開発の「「「「中心活動中心活動中心活動中心活動」」」」

と捉えている。

良良良良いいいい事事事事不要不要不要不要なななな事事事事

100%

0%

ソフトウェアソフトウェアソフトウェアソフトウェア開発開発開発開発プロジェクトプロジェクトプロジェクトプロジェクト

100%

0%


9

アジャイル開発との関係

• ＸＰは、アジャイル開発宣言に参加している開発手法である。

• アジャイル開発とは？

ソフトウェア工学において、迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称

～『ウィキペディア』からの抜粋～


10

アジャイル開発との関係

• アジャイル開発宣言

プロセスやツール

包括的なドキュメント

契約交渉

計画に従う

個人と相互作用

動作するソフトウェア

ユーザとの協調

変化に対応

より

より

より

より

【従来の価値観】【アジャイルの価値観】

• 左側にも価値はあるが、右側の方が,より多くの価値を含んでいると考える。


11

ToDo Doing Done


12

ソフトウェア開発者が考える事


13

クライアントが望むモノを創りたい！

クライアントが望むモノを創りたい！

良いプログラムを創りたい！

良いプログラムを創りたい！

バグを無くしたい！バグを無くしたい！

もっと効率的に仕事がしたい！

もっと効率的に仕事がしたい！

この短期間でこれだけの量をこなすなんて不可能だ！

この短期間でこれだけの量をこなすなんて不可能だ！人を投入しても仕事

が楽にならない！

人を投入しても仕事が楽にならない！


14

たくさんの悩み、不満を抱えています。

あなたなら、どうしますか？


15


16

「変化を受け入れる」

それが、ＸＰの基本思想。


17

ＸＰの基本思想

• 「変化を抱擁セヨ！」

– “変化”は与えられるものではない。

– 自分が変わらなければ、何も変わらない。

– 自分の不幸を嘆いても、誰も助けてくれない。

– 助けてもらっても、感謝しない。


18

変化するためには、方向が必用。


19

方向が分からないと…


20

進むべき道

間違った道


21

ＸＰでは、次の３つの方向が示されている。

１．人の満足

２．変化に適応する

３．実績重視


22

ＸＰが指し示す方向• ソフトウェア開発関係者全員の満足

– ソフトウェア開発の中心は「人」– 「人」＝ソフトウェアに関わる全員– 開発者と顧客の成功（WIN-WIN）を目指す

• 変化への適応を前提とする（変化はあたりまえ）– 未来を予測することは困難– 変化を抑止することも困難– だから、変化に適応できるソフトを作る

• 実績を重視する– 予測は外れると無駄になる– 過去に蓄積した実績値を用いる– 「昨日の天気ルール」


23

これらの方向を、より明確に、より汎用的に示す指標が

「５つの価値」である。

コミュニケーション、シンプル、フィードバック、勇気、尊重


24

コミュニケーション

25

コミュニケーション

• 人間が意思・感情・思考を伝達しあう事

• 「関係性」「雰囲気」「場所」「タイミング」

• ５つの価値の中で最も重要

• Face to Face が大事


26

シンプル

27

シンプル

• 必要なモノ（コト）しかない状態

• 本質・メタ（抽象）

• すべてのものに適用可能

• 何をもってシンプルとみなすか、基準が必要


28

フィードバック

29

フィードバック

• 反応、結果

• 例

– システムを実際に動作させる

– 顧客に使ってもらう

• 「挨拶」「お礼」は最も身近なフィードバック

– おはよう

– ありがとう

– おつかれさま


30

勇気

31

勇気

• 判断する／決断する

–他の４つの価値に基づき、実施する／しないを決定する。

–何も考えないで実行する事は、「勇気」ではなく「蛮勇」である。

• アンパンマン


32

尊重

33

尊重

• 人を思いやる気持ち

• 人を信じる気持ち

• 「「「「尊重尊重尊重尊重」」」」なくしてなくしてなくしてなくして他他他他のののの価値価値価値価値はははは成立成立成立成立しないしないしないしない。。。。

• 「チームのメンバーがベストを尽くしていることを疑うな」－ Kent Beck


34

コミュニケーションコミュニケーションコミュニケーションコミュニケーション

シンプルシンプルシンプルシンプルフィードバックフィードバックフィードバックフィードバック

勇気勇気勇気勇気

尊重尊重尊重尊重

５つの価値の関連


35

ToDo Doing Done


36

＜問題＞

今、日本で最も一般的に採用されているソフトウェア開発プロセスの名前は？


37

＜答え＞

ウォーターフォール


38

ウォーターフォール#1

要件分析要件分析要件分析要件分析要件分析要件分析要件分析要件分析

外部設計外部設計外部設計外部設計外部設計外部設計外部設計外部設計

単体試験単体試験単体試験単体試験単体試験単体試験単体試験単体試験

運用試験運用試験運用試験運用試験運用試験運用試験運用試験運用試験

開発開発開発開発開発開発開発開発

内部設計内部設計内部設計内部設計内部設計内部設計内部設計内部設計

結合試験結合試験結合試験結合試験結合試験結合試験結合試験結合試験

総合試験総合試験総合試験総合試験総合試験総合試験総合試験総合試験

・工程毎に作業が明確・工程の後戻りは無い・工程間の情報伝達は、

主にドキュメント・リリースは全工程終了後


39


要件分析要件分析要件分析要件分析要件分析要件分析要件分析要件分析

外部設計外部設計外部設計外部設計外部設計外部設計外部設計外部設計

単体試験単体試験単体試験単体試験単体試験単体試験単体試験単体試験

運用試験運用試験運用試験運用試験運用試験運用試験運用試験運用試験

開発開発開発開発開発開発開発開発

内部設計内部設計内部設計内部設計内部設計内部設計内部設計内部設計結合試験結合試験結合試験結合試験結合試験結合試験結合試験結合試験

総合試験総合試験総合試験総合試験総合試験総合試験総合試験総合試験

仕様不明確

仕様明確

時既に遅し!!

上流工程のバグは、下流工程にならないと検出検出検出検出できないできないできないできない!!!!!!!!更に、お客様の間違いは、おおおお客様客様客様客様がががが触触触触ってってってって初初初初めてめてめてめて見見見見つかるつかるつかるつかる!!!!!!!!


40


• 後工程の変更は大変• 後工程の変更を抑えるべく、前工程の品質の作りこみが重要となる。• そのため、設計時に「将来の予測」を組み込むこととなる。• しかし、予測が外れると、後工程のリスクが高くなる

時間

コスト

後工程前工程


41

管理変数

• 一般的に、管理変数として、「ＱＣＤ」を使用する。

• 「開発規模」は、明示されていない。

• 仕様変更時、暗黙的にパラメタが変化する。

Cost

Quality Delivery

・Cost(原価)

・Quality(品質)

・Delivery(納期)

これらをバランスさせる事が大切


42

ＸＰ#1

• 繰繰繰繰りりりり返返返返しししし型開発型開発型開発型開発（（（（イテレーションイテレーションイテレーションイテレーション型開発型開発型開発型開発））））– 「極小のウォーターフォール」の集合。– 小さな設計／開発を何度も繰り返す。

• 何度何度何度何度ももももリリースリリースリリースリリースするするするする– 開発中に顧客からのフィードバックが得られる– 後工程のリスクを削減することができる– 全部完成するまで待たなくても、一部の機能からメリットを教授することができる

• 要件要件要件要件／／／／作業作業作業作業ははははカードカードカードカード単位単位単位単位– 見積もりはカード単位で行う– カードに予定／実績工数を記入し、次回の見積もりに使用することで、見積も

り精度がどんどん向上する– 粒度が下がるため、見積もり精度が向上する– 本当にやるべき作業が明確になる– カードの枚数で進捗把握も可能


43

ＸＰ#2

▼お客様

リクエスト

ストーリカードストーリカードストーリカードタスクカードタスクカードタスクカード

製品

▼リーダー

▼メンバー

・要求を１件づつカードに書く・カード単位に見積もりを実施・優先度／工数／期間により、実施するストーリーを決定

・ストーリをタスクに分割・タスクを実行

・期間内に開発したストーリを満たすソフトウェアをリリース


44

XP#3リリ｜ス計画

リリ｜ス

リリ｜ス

リリ｜ス

イテレーション

ストーリストーリストーリカード

イテレ｜ション計画

イテレ｜ション実施



タスクタスクタスク

手短な設計

テスト

コ｜ディング

リファクタリング

ストーリストーリタスクカード



イテレーションイテレーション




45

ストーリーカード

• 「目標カード」「やりたいことカード」

• 開発するターゲットがどのようなものかを書く


46

タスクカード

• ストーリーを実現するために必要な作業を書く。

• 「設計する」「実装する」「テストする」などを書く。


47

ＸＰの管理変数

• ＱＣＤに相当する。

• ＱＣＤに無い「開発規模」＝Scopeがある。

• 「Scope」でＱＣＤを明示的にコントロールする。

Scope

Resource

Quality

Time

・Time（開発期間）

・Resource（開発人員/機材）

・Quality（品質）

・Scope（開発規模/ｽﾄｰﾘの数）

限られた時間（Time）の中で、要求される品質（Quality）のものを、予算内（Resource）で消化可能なストーリ（Scope）をお客様に選択頂く


48

相関図

Cost

Quality DeliveryScope

QCD Resource, Time, Quality, Scope

Resource

Quality

Time

Request

49

開発手法の比較• ＸＰは、従来型と逆の価値観を持っている。

• ＸＰの場合、変更コストを一定に保つことができる。

コード重視ドキュメント重視

現在必要な機能だけを実装将来の要求を予測して実装

人を重視プロセス重視

変更コストは常に一定開発後期の変更コストは高い

１モジュールが完成したら結合すべて完成したら結合

できるだけ頻繁にリリースリリースは一番最後に１度だけ

ユーザは開発チームの一員ユーザは外部

単体テスト作成後に実装実装後に単体テスト

【【【【ＸＰＸＰＸＰＸＰ】】】】【【【【従来型従来型従来型従来型】】】】

コスト

時間

▼従来型

時間

コスト

▼ＸＰ


50

ToDo Doing Done


51

プラクティス

• 「習慣」/「実践項目」の意。

• 経験に基づいて有用性が立証された実践項目。

• XPの開発プロセスの中に、散りばめられている。

• XPでは、14のプラィティスが提案されており、このプラクティスこそXPを最も象徴するものとなっている。

• プラクティスを実践することが、XPでは無い。

52

• 開発環境– 1. 全員同席

• 見積もり– 2. 計画ゲーム

• 開発プロセス– 3. 短期リリース– 4. 最適ペース– 5. スタンダップミーティング– 6. ユーザテスト

• 開発Tips– 7. シンプル設計– 8. ペアプログラミング– 9. テスト駆動型開発– 10. リファクタリング– 11. 常時結合– 12. コード共同所有– 13. コーディング規約– 14. メタファ

プラクティス一覧


53

原則

• 「プラクティス」を実践する事で、価値が得られる。

• しかし、間違った方法では価値が得られない。

• 「原則」とは、プラクティスを実施して「価値」を得るために守るべき事柄である。

• 14の原則が提案されている。

54

原則一覧１．人間性

– 休養や達成感は必要。人間は馬車馬ではない。2. 経済性

– 利益がちゃんと得られる開発をしよう。3. 相互利益

– みんなの利益になるように活動しよう。他人のバグでも取るのだ。

4. 自己相似性– 開発の基本はみんな同じ。テスト作成→テストの動

作の繰り返し。5. 改善

– 理想と現実を近づけるために日々努力しよう。6. 多様性

– 多様性を否定しない。チームの衝突を納得行くように解決しよう。

7. 反省– 失敗を隠さず理由を分析しよう。

8. フロー– ソフトウェア間の結合は細かく行い、開発のフローを

止めない。9. 機会

– 問題が起きたら、それは変更するための機会と前向きに考える。

10. 冗長性– 冗長性も時には必要。大事な冗長性は取り除かな

いように。11. 失敗

– 失敗することは無駄ではない。解の出ない議論を繰り返さず、とりあえず作ってみよう。

12. 品質– 品質を低くしたからと言って、プロジェクトが早く進む

ことはない。13. 小さなステップ

– 一度に大きく変更せず、小さく変更してすぐテスト。14. 責任の受け入れ

– 権限と責任にずれがないようにする。さもないと「お前がやれ」ということになる。


55

価値と原則とプラクティス

価値（５つの価値）

原則

プラクティス

• 原則を守ってプラクティスを実践することで、価値が得られる。

Documents

Xp寺子屋出張版＃２「xp入門 追補版」

Xp寺子屋出張版＃２「xp入門追補版」