XPJUG関西 / XP寺子屋
1
「XP入門」追補版
2011.12.11
XP寺子屋
XPJUG関西 / XP寺子屋
2
アジェンダ
XPJUG関西 / XP寺子屋
3
2222.XP.XP.XP.XPのののの基本思想基本思想基本思想基本思想
XPの基本思想についてお話します。
2222.XP.XP.XP.XPのののの基本思想基本思想基本思想基本思想
XPの基本思想についてお話します。
3333.XP.XP.XP.XPのののの開発開発開発開発プロセスプロセスプロセスプロセス
XPの開発プロセスについてお話します。
3333.XP.XP.XP.XPのののの開発開発開発開発プロセスプロセスプロセスプロセス
XPの開発プロセスについてお話します。
4444....プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス!!!!!!!!
XPで使用するプラクティスをご紹介します。
4444....プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス、、、、プラクティスプラクティスプラクティスプラクティス!!!!!!!!
XPで使用するプラクティスをご紹介します。
1111.XP.XP.XP.XPのののの歴史歴史歴史歴史
XPの歴史についてお話します。
1111.XP.XP.XP.XPのののの歴史歴史歴史歴史
XPの歴史についてお話します。
XPJUG関西 / XP寺子屋
4
ToDo Doing Done
XPJUG関西 / XP寺子屋
5
XPとは?
• eXtremeProgrammingの略称。
• ソフトウェア開発手法の1つ。
• ソフトウェア開発において「良い事を最大限に実施」する手法。
XPJUG関西 / XP寺子屋
6
XPの提唱者
Three Extremos
けんと・べっく
Kent Beckうぉーど・かにんがむ
Ward Cunninghamろん・じぇふりーず
Ron Jeffries
XPJUG関西 / XP寺子屋
7
XPの歴史
• 最初にXPが実践されたのは「「「「C3C3C3C3プロジェクトプロジェクトプロジェクトプロジェクト」」」」。
• 危機的状況にあったC3プロジェクトを救うべく、過去に経験した手法を最大限に実施。その結果、プロジェクトの建て直しに成功。
• この経験を元に、XP本を執筆。急速に拡大。
日本で翻訳本『XPエクストリームプログラミング入門』刊行。2000年
米国で『eXtreme Programming Explained』刊行。1999年
ケント・ベックがC3プロジェクトに携わる。1996年
XPJUG関西 / XP寺子屋
8
名前の由来
• [[[[extreamextreamextreamextream]]]]=極端な/究極の
– 良良良良いいいい事事事事を徹底的に行い
– 不要不要不要不要なななな事事事事を徹底的に行わない
• [Programming][Programming][Programming][Programming]– プログラミングこそソフトウェア開発の「「「「中心活動中心活動中心活動中心活動」」」」
と捉えている。
良良良良いいいい事事事事 不要不要不要不要なななな事事事事
100%
0%
ソフトウェアソフトウェアソフトウェアソフトウェア開発開発開発開発プロジェクトプロジェクトプロジェクトプロジェクト
100%
0%
XPJUG関西 / XP寺子屋
9
アジャイル開発との関係
• XPは、アジャイル開発宣言に参加している開発手法である。
• アジャイル開発とは?
ソフトウェア工学において、迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称
~ 『ウィキペディア』からの抜粋 ~
XPJUG関西 / XP寺子屋
10
アジャイル開発との関係
• アジャイル開発宣言
プロセスやツール
包括的なドキュメント
契約交渉
計画に従う
個人と相互作用
動作するソフトウェア
ユーザとの協調
変化に対応
より
より
より
より
【従来の価値観】 【アジャイルの価値観】
• 左側にも価値はあるが、右側の方が,より多くの価値を含んでいると考える。
XPJUG関西 / XP寺子屋
11
ToDo Doing Done
XPJUG関西 / XP寺子屋
12
ソフトウェア開発者が考える事
XPJUG関西 / XP寺子屋
13
クライアントが望むモノを創りたい!
クライアントが望むモノを創りたい!
良いプログラムを創りたい!
良いプログラムを創りたい!
バグを無くしたい!バグを無くしたい!
もっと効率的に仕事がしたい!
もっと効率的に仕事がしたい!
この短期間でこれだけの量をこなすなんて不可能だ!
この短期間でこれだけの量をこなすなんて不可能だ! 人を投入しても仕事
が楽にならない!
人を投入しても仕事が楽にならない!
XPJUG関西 / XP寺子屋
14
たくさんの悩み、不満を抱えています。
あなたなら、どうしますか?
XPJUG関西 / XP寺子屋
15
XPJUG関西 / XP寺子屋
16
「変化を受け入れる」
それが、XPの基本思想。
XPJUG関西 / XP寺子屋
17
XPの基本思想
• 「変化を抱擁セヨ!」
– “変化”は与えられるものではない。
– 自分が変わらなければ、何も変わらない。
– 自分の不幸を嘆いても、誰も助けてくれない。
– 助けてもらっても、感謝しない。
XPJUG関西 / XP寺子屋
18
変化するためには、方向が必用。
XPJUG関西 / XP寺子屋
19
方向が分からないと…
XPJUG関西 / XP寺子屋
20
進むべき道
間違った道
XPJUG関西 / XP寺子屋
21
XPでは、次の3つの方向が示されている。
1.人の満足
2.変化に適応する
3.実績重視
XPJUG関西 / XP寺子屋
22
XPが指し示す方向• ソフトウェア開発関係者全員の満足
– ソフトウェア開発の中心は「人」– 「人」=ソフトウェアに関わる全員– 開発者と顧客の成功(WIN-WIN)を目指す
• 変化への適応を前提とする(変化はあたりまえ)– 未来を予測することは困難– 変化を抑止することも困難– だから、変化に適応できるソフトを作る
• 実績を重視する– 予測は外れると無駄になる– 過去に蓄積した実績値を用いる– 「昨日の天気ルール」
XPJUG関西 / XP寺子屋
23
これらの方向を、より明確に、より汎用的に示す指標が
「5つの価値」である。
コミュニケーション、 シンプル、 フィードバック、 勇気、 尊重
XPJUG関西 / XP寺子屋
24
コミュニケーション
25
コミュニケーション
• 人間が意思・感情・思考を伝達しあう事
• 「関係性」「雰囲気」「場所」「タイミング」
• 5つの価値の中で最も重要
• Face to Face が大事
XPJUG関西 / XP寺子屋
26
シンプル
27
シンプル
• 必要なモノ(コト)しかない状態
• 本質・メタ(抽象)
• すべてのものに適用可能
• 何をもってシンプルとみなすか、基準が必要
XPJUG関西 / XP寺子屋
28
フィードバック
29
フィードバック
• 反応、結果
• 例
– システムを実際に動作させる
– 顧客に使ってもらう
• 「挨拶」「お礼」は最も身近なフィードバック
– おはよう
– ありがとう
– おつかれさま
XPJUG関西 / XP寺子屋
30
勇気
31
勇気
• 判断する/決断する
–他の4つの価値に基づき、実施する/しないを決定する。
–何も考えないで実行する事は、「勇気」ではなく「蛮勇」である。
• アンパンマン
XPJUG関西 / XP寺子屋
32
尊重
33
尊重
• 人を思いやる気持ち
• 人を信じる気持ち
• 「「「「尊重尊重尊重尊重」」」」なくしてなくしてなくしてなくして他他他他のののの価値価値価値価値はははは成立成立成立成立しないしないしないしない。。。。
• 「チームのメンバーがベストを尽くしていることを疑うな」- Kent Beck
XPJUG関西 / XP寺子屋
34
コミュニケーションコミュニケーションコミュニケーションコミュニケーション
シンプルシンプルシンプルシンプル フィードバックフィードバックフィードバックフィードバック
勇気勇気勇気勇気
尊重尊重尊重尊重
5つの価値の関連
XPJUG関西 / XP寺子屋
35
ToDo Doing Done
XPJUG関西 / XP寺子屋
36
<問題>
今、日本で最も一般的に採用されているソフトウェア開発プロセスの名前は?
XPJUG関西 / XP寺子屋
37
<答え>
ウォーターフォール
XPJUG関西 / XP寺子屋
38
ウォーターフォール#1
要件分析要件分析要件分析要件分析要件分析要件分析要件分析要件分析
外部設計外部設計外部設計外部設計外部設計外部設計外部設計外部設計
単体試験単体試験単体試験単体試験単体試験単体試験単体試験単体試験
運用試験運用試験運用試験運用試験運用試験運用試験運用試験運用試験
開発開発開発開発開発開発開発開発
内部設計内部設計内部設計内部設計内部設計内部設計内部設計内部設計
結合試験結合試験結合試験結合試験結合試験結合試験結合試験結合試験
総合試験総合試験総合試験総合試験総合試験総合試験総合試験総合試験
・工程毎に作業が明確・工程の後戻りは無い・工程間の情報伝達は、
主にドキュメント・リリースは全工程終了後
XPJUG関西 / XP寺子屋
39
ウォーターフォール#2
要件分析要件分析要件分析要件分析要件分析要件分析要件分析要件分析
外部設計外部設計外部設計外部設計外部設計外部設計外部設計外部設計
単体試験単体試験単体試験単体試験単体試験単体試験単体試験単体試験
運用試験運用試験運用試験運用試験運用試験運用試験運用試験運用試験
開発開発開発開発開発開発開発開発
内部設計内部設計内部設計内部設計内部設計内部設計内部設計内部設計 結合試験結合試験結合試験結合試験結合試験結合試験結合試験結合試験
総合試験総合試験総合試験総合試験総合試験総合試験総合試験総合試験
仕様不明確
仕様明確
時既に遅し!!
上流工程のバグは、下流工程にならないと検出検出検出検出できないできないできないできない!!!!!!!!更に、お客様の間違いは、おおおお客様客様客様客様がががが触触触触ってってってって初初初初めてめてめてめて見見見見つかるつかるつかるつかる!!!!!!!!
XPJUG関西 / XP寺子屋
40
ウォーターフォール#3
• 後工程の変更は大変• 後工程の変更を抑えるべく、前工程の品質の作りこみが重要となる。• そのため、設計時に「将来の予測」を組み込むこととなる。• しかし、予測が外れると、後工程のリスクが高くなる
時間
コスト
後工程前工程
XPJUG関西 / XP寺子屋
41
管理変数
• 一般的に、管理変数として、「QCD」を使用する。
• 「開発規模」は、明示されていない。
• 仕様変更時、暗黙的にパラメタが変化する。
Cost
Quality Delivery
・Cost(原価)
・Quality(品質)
・Delivery(納期)
これらをバランスさせる事が大切
XPJUG関西 / XP寺子屋
42
XP#1
• 繰繰繰繰りりりり返返返返しししし型開発型開発型開発型開発((((イテレーションイテレーションイテレーションイテレーション型開発型開発型開発型開発))))– 「極小のウォーターフォール」の集合。– 小さな設計/開発を何度も繰り返す。
• 何度何度何度何度ももももリリースリリースリリースリリースするするするする– 開発中に顧客からのフィードバックが得られる– 後工程のリスクを削減することができる– 全部完成するまで待たなくても、一部の機能からメリットを教授することができる
• 要件要件要件要件////作業作業作業作業ははははカードカードカードカード単位単位単位単位– 見積もりはカード単位で行う– カードに予定/実績工数を記入し、次回の見積もりに使用することで、見積も
り精度がどんどん向上する– 粒度が下がるため、見積もり精度が向上する– 本当にやるべき作業が明確になる– カードの枚数で進捗把握も可能
XPJUG関西 / XP寺子屋
43
XP#2
▼お客様
リクエスト
ストーリカードストーリカードストーリカードタスクカードタスクカードタスクカード
製品
▼リーダー
▼メンバー
・要求を1件づつカードに書く・カード単位に見積もりを実施・優先度/工数/期間により、実施するストーリーを決定
・ストーリをタスクに分割・タスクを実行
・期間内に開発したストーリを満たすソフトウェアをリリース
XPJUG関西 / XP寺子屋
44
XP#3リリ|ス計画
リリ|ス
リリ|ス
リリ|ス
イテレーション
ストーリストーリストーリカード
イテレ|ション計画
イテレ|ション実施
イテレ|ション実施
イテレ|ション実施
タスク タスク タスク
手短な設計
テスト
コ|ディング
リファクタリング
ストーリストーリタスクカード
ストーリストーリタスクカード
ストーリストーリタスクカード
イテレーション イテレーション
ストーリストーリストーリカード
ストーリストーリストーリカード
XPJUG関西 / XP寺子屋
45
ストーリーカード
• 「目標カード」「やりたいことカード」
• 開発するターゲットがどのようなものかを書く
XPJUG関西 / XP寺子屋
46
タスクカード
• ストーリーを実現するために必要な作業を書く。
• 「設計する」「実装する」「テストする」などを書く。
XPJUG関西 / XP寺子屋
47
XPの管理変数
• QCDに相当する。
• QCDに無い「開発規模」=Scopeがある。
• 「Scope」でQCDを明示的にコントロールする。
Scope
Resource
Quality
Time
・Time(開発期間)
・Resource(開発人員/機材)
・Quality(品質)
・Scope(開発規模/ストーリの数)
限られた時間(Time)の中で、要求される品質(Quality)のものを、予算内(Resource)で消化可能なストーリ(Scope)をお客様に選択頂く
XPJUG関西 / XP寺子屋
48
相関図
Cost
Quality DeliveryScope
QCD Resource, Time, Quality, Scope
Resource
Quality
Time
Request
49
開発手法の比較• XPは、従来型と逆の価値観を持っている。
• XPの場合、変更コストを一定に保つことができる。
コード重視ドキュメント重視
現在必要な機能だけを実装将来の要求を予測して実装
人を重視プロセス重視
変更コストは常に一定開発後期の変更コストは高い
1モジュールが完成したら結合すべて完成したら結合
できるだけ頻繁にリリースリリースは一番最後に1度だけ
ユーザは開発チームの一員ユーザは外部
単体テスト作成後に実装実装後に単体テスト
【【【【XPXPXPXP】】】】【【【【従来型従来型従来型従来型】】】】
コスト
時間
▼従来型
時間
コスト
▼XP
XPJUG関西 / XP寺子屋
50
ToDo Doing Done
XPJUG関西 / XP寺子屋
51
プラクティス
• 「習慣」/「実践項目」の意。
• 経験に基づいて有用性が立証された実践項目。
• XPの開発プロセスの中に、散りばめられている。
• XPでは、14のプラィティスが提案されており、このプラクティスこそXPを最も象徴するものとなっている。
• プラクティスを実践することが、XPでは無い。
52
• 開発環境– 1. 全員同席
• 見積もり– 2. 計画ゲーム
• 開発プロセス– 3. 短期リリース– 4. 最適ペース– 5. スタンダップミーティング– 6. ユーザテスト
• 開発Tips– 7. シンプル設計– 8. ペアプログラミング– 9. テスト駆動型開発– 10. リファクタリング– 11. 常時結合– 12. コード共同所有– 13. コーディング規約– 14. メタファ
プラクティス一覧
XPJUG関西 / XP寺子屋
53
原則
• 「プラクティス」を実践する事で、価値が得られる。
• しかし、間違った方法では価値が得られない。
• 「原則」とは、プラクティスを実施して「価値」を得るために守るべき事柄である。
• 14の原則が提案されている。
54
原則一覧1.人間性
– 休養や達成感は必要。人間は馬車馬ではない。2. 経済性
– 利益がちゃんと得られる開発をしよう。3. 相互利益
– みんなの利益になるように活動しよう。他人のバグでも取るのだ。
4. 自己相似性– 開発の基本はみんな同じ。テスト作成→テストの動
作の繰り返し。5. 改善
– 理想と現実を近づけるために日々努力しよう。6. 多様性
– 多様性を否定しない。チームの衝突を納得行くように解決しよう。
7. 反省– 失敗を隠さず理由を分析しよう。
8. フロー– ソフトウェア間の結合は細かく行い、開発のフローを
止めない。9. 機会
– 問題が起きたら、それは変更するための機会と前向きに考える。
10. 冗長性– 冗長性も時には必要。大事な冗長性は取り除かな
いように。11. 失敗
– 失敗することは無駄ではない。解の出ない議論を繰り返さず、とりあえず作ってみよう。
12. 品質– 品質を低くしたからと言って、プロジェクトが早く進む
ことはない。13. 小さなステップ
– 一度に大きく変更せず、小さく変更してすぐテスト。14. 責任の受け入れ
– 権限と責任にずれがないようにする。さもないと「お前がやれ」ということになる。
XPJUG関西 / XP寺子屋
55
価値と原則とプラクティス
価値(5つの価値)
原則
プラクティス
• 原則を守ってプラクティスを実践することで、価値が得られる。