Contenu connexe
Similaire à Xp Terakoya No02
Similaire à Xp Terakoya No02 (20)
Xp Terakoya No02
- 2. ■参考文献
• 「よくわかる最新ＸＰの基本と仕組み」
– 監修：長瀬嘉秀
– 著者：畑田成広 樋口博昭
– 出版：秀和システム
• 「XPエクストリーム・プログラミング入門」
– 著者：KentBeck
– 出版：ピアソンデヂュケーション
2
- 3. ■アジェンダ
• １．概要
• ２．基本思想
• ３．開発プロセス
• ４．価値と原則とプラクティス
3
- 4. １．概要
• ＸＰとは？
• ＸＰの提唱者
• ＸＰの歴史
• 名前の由来
• アジャイル開発との関係
１．概要 4
- 5. >>ＸＰとは？
• eXtream Programmingの略。
• ソフトウェア開発手法の１つ。
• ソフトウェア開発において、良いことを
最大限に実施する手法。
１．概要 5
- 6. >>ＸＰの提唱者
• Kent Beck
– ケント・ベック
• Ward Cunningham
– ウォード・カニンガム
• Ron Jeffries
– ロン・ジェフリーズ
• この３人は「Three Extremos」
「 」
と呼ばれている。
１．概要 6
- 7. >>ＸＰの歴史
• 最初にXPが実践されたのは「C3プロジェクト」
プロジェクト」。
「 プロジェクト」
• 危機的状況にあったC3プロジェクトを救うべく、過去に
経験した手法を最大限に実施。その結果、プロジェクト
の建て直しに成功。
• この経験を元に、ＸＰ本を執筆。急速に拡大。
1996年 ケント・ベックがＣ３プロジェクトに携わる。
1999年 米国で『eXtream Programming Explained』刊行。
日本で翻訳本『XPエクストリームプログラミング入門』
2000年
刊行。
１．概要 7
- 8. >>名前の由来
ソフトウェア開発プロジェクト
• [extream]=極端な／究極の
良い事を徹底的に行い
– 良い事 良い事 不要な事
100% 100%
– 不要な事を徹底的に行わない
不要な事
0% 0%
• [Programming]
– プログラミングこそソフトウェ
ア開発の「中心活動」
「中心活動」と捉えて
「中心活動」
いる。
１．概要 8
- 9. >>アジャイル開発との関係(1)
• XPは、アジャイル開発宣言に参加している開発
手法である。
• アジャイル開発とは？
ソフトウェア工学において、迅速かつ
適応的に ソフトウェア開発を行う
軽量な開発手法群の総称 である。
～ 『ウィキペディア』からの抜粋 ～
１．概要 9
- 10. >>アジャイル開発との関係(2)
• アジャイル開発宣言
【従来の価値観】 【アジャイルの価値観】
プロセスやツール より 個人と相互作用
包括的なドキュメント より 動作するソフトウェア
契約交渉 より ユーザとの協調
計画に従う より 変化に対応
• 左側にも価値はあるが、右側の方が,
より多くの価値を含んでいると考え
る。
１．概要 10
- 11. ■グループミーティング
• ソフトウェア開発において、「良い事」「不要な
事」を、各自で思いつくだけ挙げてください。
– ３分（個人）
• 「良い事」「悪い事」を発表して下さい。
– ３分（グループ）
• その中で、全員が共感した「良い事」「悪い事」
を話し合って決めて下さい。（複数回答可）
– ５分（グループ）
１．概要 11
- 12. ２．基本思想
• 滝に打たれて苦労する
• ソフトウェア開発の暗黙の了解
• ＸＰが指向すること
• ５つの価値
２．基本思想 12
- 13. >>滝に打たれて苦労する
• ウォーターフォールの特徴
– 大規模開発に最適
– 仕様が途中で変化しない開発に最適
– 後戻りは想定外
• ウォーターフォールで苦労する原因
– 要員増加でコミュニケーション不足!!
– 仕様が途中で変化する!!
– 後戻りの発生!!（特に総合試験フェーズ）
ウォーターフォールのメリットが
生かせる開発が少ない!!
２．基本思想 13
- 14. >>ソフトウェア開発の暗黙の了解
• すべてのシステムに適用可能な開発手法はない
– 銀の弾丸は存在しない
– １システム毎にオーダーメイド
• 人の重要性
– システムを使うのも作るのも人である。
– 結局、ソフトは人の手で作られる
– 開発者のモチベーションが鍵
• 変化は起きる
– いつ、何が起きるか、予測する事は困難
– 変化は起こってあたりまえ
– 問題は、変化に素早く対応できるかどうか
誰も明言しないが、みんな心の中
で思っているハズ
２．基本思想 14
- 15. >>XPが指向すること
• 人の満足
– ソフトウェア開発の中心は「人」
– 「人」＝ソフトウェアに関わる全員
– 開発者と顧客の成功（WIN-WIN）を目指す
• 変化に適応する
– 未来を予測することは困難
– 変化を抑止することも困難
– だから、変化に適応できるソフトを作る
• 実績重視
– 予測は外れると無駄になる
– 過去に蓄積した実績値を用いる
– 「昨日の天気ルール」
予測することを止め、今必要なものだけを、変更しやす
く開発する。そのために、顧客と開発者の協力が必要!!
２．基本思想 15
- 16. >>５つの価値
• ＸＰが指向するものをより明確に、より汎
用的に示す指標が「価値」である。
• ソフトウェア開発の中で、方向性を決める
時、大いに役立つ指標となる。
• ５つの価値の種類
– コミュニケーション
– シンプル
– フィードバック
– 勇気
– 尊重 ← 「ＸＰ入門」第２版で追加
２．基本思想 16
- 17. >>５つの価値(1)
•コミュニケーション
– 人間が意思・感情・思考を伝達しあう事
– 「関係性」「雰囲気」「場所」「タイミング」
– ５つの価値の中で最も重要
– Face to Face が大事
２．基本思想 17
- 18. >>５つの価値(2)
•シンプル
– 必要なモノ（コト）しかない状態
– 本質・メタ（抽象）
– すべてのものに適用可能
– 何をもってシンプルとみなすか、基準が必要
２．基本思想 18
- 19. >>５つの価値(3)
•フィードバック
– 反応、結果
– 例
• システムを実際に動作させる
• 顧客に使ってもらう
– 「ありがとう」は最も身近なフィードバック
２．基本思想 19
- 20. >>５つの価値(4)
•勇気
– 判断する／決断する
• 他の４つの価値に基づき、実施する／しない
を決定する。
• 何も考えないで実行する事は、「勇気」では
なく「蛮勇」である。
– アンパンマン
２．基本思想 20
- 21. >>５つの価値(5)
•尊重
– 人を思いやる気持ち
– 人を信じる気持ち
– 「尊重」なくして他の価値は成立しない。
– 「チームのメンバーがベストを尽くしている
ことを疑うな」－ Kent Beck
２．基本思想 21
- 22. >>５つの価値(6)
尊重
コミュニケーション
勇気
シンプル フィードバック
２．基本思想 22
- 23. ■グループミーティング
• 「ソフトウェア開発」という作業の中で、自分の
中で持っている価値感(=大切な事)を思いつくだ
け挙げて下さい。
– ３分（個人）
• その価値を発表して下さい。
– ３分（グループ）
• その中で、全員が共感した「価値感」を話し合っ
て決めて下さい。（複数回答可）
– ５分（グループ）
２．基本思想 23
- 24. ３．開発プロセス
• 従来型の開発プロセス
• ＸＰの開発プロセスの特徴
• ＸＰの開発プロセス
– リリース計画
– イテレーション計画
– イテレーション実施
– リリース
• ＸＰの管理変数
• 開発手法の比較
３．開発プロセス 24
- 25. >>従来型の開発プロセス(1)
• 上流から下流へ。 ・工程毎に作業が明確
・工程の後戻りは無い
要件分析
要件分析 ・工程間の情報伝達は、
外部設計
外部設計
主にドキュメント
・リリースは全工程終了後
内部設計
内部設計
開発
開発
単体試験
単体試験
結合試験
結合試験
総合試験
総合試験
運用試験
運用試験
３．開発プロセス 25
- 26. >>従来型の開発プロセス(2)
• 成果物と設計の妥当性はＶ字カーブで検証
要件分析
要件分析 運用試験
運用試験 仕様
明確
外部設計
外部設計 総合試験
総合試験
内部設計
内部設計 結合試験
結合試験
時既に遅し!!
仕様 開発
開発 単体試験
単体試験
不明確
• 上流工程のバグは、下流工程にならないと
検出できない!!
検出できない
• 更に、お客様の間違いは、お客様が触って
お客様が触って
初めて見つかる!!
初めて見つかる
３．開発プロセス 26
- 27. >>従来型の開発プロセス(3)
• 変更のコストカーブ
コスト
時間
• 後工程の変更は大変
• 後工程の変更を抑えるべく、前工程の品質の作りこみが
重要となる。
• そのため、設計時に「将来の予測」を組み込むこととなる。
• しかし、予測が外れると、後工程のリスクが高くなる
３．開発プロセス 27
- 28. >>ＸＰの開発プロセスの特徴
• 繰り返し型開発（イテレーション型開発）
– 「極小のウォーターフォール」の集合。
– 小さな設計／開発を何度も繰り返す。
• 何度もリリースする
– 開発中に顧客からのフィードバックが得られる
– 後工程のリスクを削減することができる
– 全部完成するまで待たなくても、一部の機能からメリットを教授する
ことができる
• 要件／作業はカード単位
– 見積もりはカード単位で行う
– カードに予定／実績工数を記入し、次回の見積もりに使用
することで、見積もり精度がどんどん向上する
– 粒度が下がるため、見積もり精度が向上する
– 本当にやるべき作業が明確になる
– カードの枚数で進捗把握も可能
３．開発プロセス 28
- 29. >>ＸＰの開発プロセス(1)
▼お客様 ・期間内に開発したストーリ
を満たすソフトウェアを
リリース
製品
リクエスト
▼メンバー
ストーリカード
ストーリカード タスクカード
ストーリカード タスクカード
タスクカード
▼リーダー
・要求を１件づつカードに書く ・ストーリをタスクに分割
・カード単位に見積もりを実施 ・タスクを実行
・優先度／工数／期間により、
実施するストーリーを決定
３．開発プロセス 29
- 30. >>ＸＰの開発プロセス(2)
▼フィーチャー ▼ストーリー
イテレーション計画
リリース計画
イテレーション実施＃１
イテレーション＃１
イテレーション実施＃２
イテレーション＃２
･･･
･･･
リリース
▼タスク
手短な設計
テスト
コード リファクタリング
３．開発プロセス 結合 30
- 31. >>ＸＰの開発プロセス(3)
• ストーリーカード
– 「目標カード」「やりたいことカード」
– 開発するターゲットがどのようなものかを書く
– 「こういう画面表示が必要」「こういう機能が必要」といったことを
書く。
翔泳社webマガジン
■組込みZine
「組込みでジャイル」より。
３．開発プロセス 31
- 32. >>ＸＰの開発プロセス(4)
• タスクカード
– ストーリーを実現するために必要な作業を書く。
– 「設計する」「実装する」「テストする」などを書く。
翔泳社webマガジン
■組込みZine
「組込みでジャイル」より。
３．開発プロセス 32
- 33. >>ＸＰの開発プロセス >>リリース計画
• 要求事項から、ストーリーカードを作成。
• 開発者
– ストーリーカード毎に見積もりを実施。
– 単位時間あたりの消化可能ストーリー数も見積もる。
– 技術的リスクを洗い出し、お客様に伝える。
• お客様
– 開発者からの情報を元に、実施するストーリと優先順位
を選択頂く。
• 見積もりには「昨日の天気ルール」を適用。
– 「今日の天気は昨日の天気を元に予測する」
– 過去のストーリの実績を元に、工数を見積もる。
３．開発プロセス 33
- 34. >>ＸＰの開発プロセス >>イテレーション計画
• ストーリを理解する。
• ストーリをタスクに分割する。
– 分割したタスクは、タスクカードに記入。
• 開発速度を宣言する。
– 実施するタスクを消化するスピードを明確化する。
– スケジュールリングする。
• タスクを受け入れる
３．開発プロセス 34
- 35. >>ＸＰの開発プロセス >>イテレーション実施
• ペアを組む
• 手短な設計を行う
• テストを先に作る
– テストパターンを先に作ることで、仕様が明確になる
– 自動テストスィート(xUnit)でテストプログラムを作成
– 手書きのテスト仕様書でも可
• 実装
– テストがパスするコードを作成する
• リファクタリングする
– 常にコードをシンプルに保ち、変更容易性を確保する
３．開発プロセス 35
- 36. >>ＸＰの開発プロセス >>リリース
• 受け入れテストを作成
– システムを最も理解しているのは、お客様である。
– よって、テストパターンをお客様に作成頂くのがベスト。
• 受け入れテストを実施
– 過去に開発した機能の受け入れテストも実施することで、
デグレを防止する。
３．開発プロセス 36
- 37. >>ＸＰの管理変数(1)
Resource
• ４つの管理変数を使用する
– Time ：開発期間(Deliveryと同意) Time
– Quality ：品質
Scope Quality
– Resource：開発人員/設備(Costと同意)
– Scope ：ストーリーの数
• 従来のQCDに相当
• 限られた時間（Time）の中で、要求される品質
（Quality）のものを、予算内（Resource）で消化
可能なストーリ（Scope）をお客様に選択頂く
３．開発プロセス 37
- 38. >>ＸＰの管理変数(2)
• ４つの項目がバランスする事で、健全なソフト
ウェア開発が可能となる。
• スコープの増減が、最も低リスク。
– Time：納期が遅れると、ビジネスチャンスを逃す
– Quality：品質を下げるとバグ混入の危険性
– Resource：要員追加は、生産性低下となる
– スコープの変更は、他の管理変数に影響しない。
• スコープ増減を上手く機能させるためには、高い
見積もり精度が必要。
– ＸＰにより、見積もり精度の向上が可能
３．開発プロセス 38
- 39. >>開発手法の比較
• ＸＰは、従来型と逆の価値観を持っている。
【従来型】
従来型】 【ＸＰ】
ＸＰ】
実装後に単体テスト 単体テスト作成後に実装
ユーザは外部 ユーザは開発チームの一員
リリースは一番最後に１度だけ できるだけ頻繁にリリース
すべて完成したら結合 １モジュールが完成したら結合
将来の要求を予測して実装 現在必要な機能だけを実装
開発後期の変更コストは高い 変更コストは常に一定
プロセス重視 人を重視
ドキュメント重視 コード重視
• ＸＰの場合、変更コストを一定に保つことができる。
コスト コスト
▼従来型 ▼ＸＰ
時間 時間
３．開発プロセス 39
- 40. ■グループミーティング
• ＸＰの開発手法の中で、「良い点」と「悪い点」
を思いつくだけ挙げて下さい。
– ３分（個人）
• 「良い点」「悪い点」を発表して下さい。
– ３分（グループ）
• チーム内で最も多かった「良い点」と「悪い点」
を話し合って決めて下さい。（複数回答可）
– ５分（グループ）
３．開発プロセス 40
- 41. ４．価値と原則とプラクティス
• プラクティス • 価値と原則とプラクティス
• 開発環境 • 原則
– ▼全員同席 – ▼人間性
• 見積もり – ▼経済性
– ▼計画ゲーム – ▼相互利益
• 開発プロセス – ▼自己相似性
– ▼短期リリース – ▼改善
– ▼最適ペース – ▼多様性
– ▼スタンダップミーティング – ▼反省
– ▼ユーザテスト – ▼フロー
• 開発Tips – ▼機会
– ▼冗長性
– ▼シンプル設計
– ▼失敗
– ▼ペアプログラミング
– ▼品質
– ▼テスト駆動型開発
– ▼小さなステップ
– ▼リファクタリング
– ▼責任の受け入れ
– ▼常時結合
– ▼コード共同所有
– ▼コーディング規約
– ▼メタファ
４．価値と原則とプラクティス 41
- 42. >>プラクティス
• プラクティスとは？
– 「習慣」/「実践項目」の意。
• 経験に基づいて有用性が立証
された実践項目の事である。
• プラクティスは、継続的に洗
練／改善され続けているため、
数や名称が変化しています。
４．価値と原則とプラクティス 42
- 44. >>開発環境 >>全員同席
• 内容
– お客様～開発者まで、全員同じ
場所で作業する。
• 効果
– 質問のレスポンス速度向上
– コミュニケーション不足の解消
４．価値と原則とプラクティス 44
- 46. >>見積もり >>計画ゲーム
• 内容
– お客様と開発者の見積もりゲーム。
– 「期日までに何ができるか」「次に何を
するのか」を明確にする。
– 互いの役割に干渉してはならない。
– お客様の役割
• ストーリの提示
• ストーリの優先順位決定
• ストーリの実施可否決定
– 開発者の役割
• ストーリを見積もる
• 想定されるリスクを報告する
• 効果
– お客様の希望する価格で真に望む機能を
開発することができる。
– 変更を容認できる仕組みの提案。
４．価値と原則とプラクティス 46
- 48. >>開発プロセス >>短期リリース
• 内容
– 短期間で動作可能なシステムを
リリースする。
• 効果
– 開発期間中にユーザからの
フィードバックが得られる。
– 実装上のリスクが削減される。
４．価値と原則とプラクティス 48
- 49. >>開発プロセス >>最適ペース
• 内容
– 無理な作業は効率が悪い事に気
付く。
– 無理な作業は精神面への負担も
増加することを認識する。
– 実績に基づいて開発スピードを
調整する。
• 効果
– 人は最適なペースを維持しなが
ら作業すると効率が良い。
４．価値と原則とプラクティス 49
- 50. >>開発プロセス >>スタンダップミーティング
• 内容
– 毎朝同じ時間・同じ場所で、立ったま
まミーティングする。
– 昨日実施した事、今日実施することを
手短に報告する。
• 効果
– コミュニケーション促進
– 今日実施することを自分で宣言するこ
とで、実施内容が明確になる
– 問題が発生しても、最大２４時間で
キャッチアップ可能
４．価値と原則とプラクティス 50
- 51. >>開発プロセス >>ユーザテスト
• 内容
– システムを最も理解しているの
はシステムを使うお客様である。
– お客様に受け入れテスト項目を
作成頂く。
• 効果
– システムのゴールが明確になる。
– 抜け／漏れが明確になる。
４．価値と原則とプラクティス 51
- 53. >>開発Tips >>シンプル設計
• 内容
– 必要な機能のみ実装する
– 「将来必要と思われる機能」は
実装しない。
– １つのモノに、複数の機能を詰
め込まない。
– YAGNI（You aren’t going to
need it.=今必要なことだけや
れ）の実践
• 効果
– 変更容易性の確保
４．価値と原則とプラクティス 53
- 54. >>開発Tips >>ペアプログラミング
• 内容
– １台のマシンに２人でコーディングを
行う。
– １人はコーダ（ドライバ）、１人はレ
ビュアー（サポーター）。
– 頻繁に交代しながらコーディングを行
う。
• 効果
– １人が持っている知識を、開発しなが
ら全員に伝播することができる。
– １人が倒れても、もう１人が開発を継
続可能。
４．価値と原則とプラクティス 54
- 55. >>開発Tips >>テスト駆動型開発
• 内容
– コードを書く前にテストを考える。
– 考えたテストをパスするコードを書く。
– （可能であれば）テストを自動化する
• 効果
– コードの仕様が明確になる
– テストコードで品質保証が可能となる。
– デグレ混入の抑止
４．価値と原則とプラクティス 55
- 56. >>開発Tips >>リファクタリング
• 内容
– リファクタリングとは、コード
の振舞いを変化させず、中身を
整理すること。
– テストが成功したら、リファク
タリングする。
• 効果
– プログラムを理解しやすくなる
– 不具合混入を予防できる
– コーディング時間の短縮
– メンテナンス性の向上
４．価値と原則とプラクティス 56
- 57. >>開発Tips >>常時結合
• 内容
– 結合テストを自動実行可能にする。
– 小さな変更で、不具合が持ち込まれて
いないか確認する。
• 効果
– 変更に対する品質維持が可能となる。
– 勇気を持って変更することができる。
– 変更に対する品質保証が可能となる。
４．価値と原則とプラクティス 57
- 58. >>開発Tips >>コード共同所有
• 内容
– コードはチーム全員の共有資産
と位置づける。
– 誰でも修正可能な状態とする。
• 効果
– コードの知識を分散可能となり、
メンバー離脱時の負荷分散／リ
スク回避が可能となる。
– ただし、所有責任者が不明確と
なるため、「チーム全員が責任
者」である事を、事前に周知徹
底する必要がある。
４．価値と原則とプラクティス 58
- 59. >>開発Tips >>コーディング規約
• 内容
– チームメンバーが共有できる
コーディング規約を共同で作る。
• 効果
– ペアプロ／コード共同所有する
ためには、共有のコーディング
規約が必要。
– 規約違反により、違反箇所を修
正するロスコストが発生する。
４．価値と原則とプラクティス 59
- 60. >>開発Tips >>メタファ
• 内容
– 「メタファ」＝「たとえ」
– 複雑なものに、誰でも理解でき
る分かりやすい名前を付ける。
– 例
• クライアント／サーバシステム
• インターネット
• 効果
– 「メタファ」を活用することで、
強力な意思疎通が可能となる。
４．価値と原則とプラクティス 60
- 62. >> 価値と原則とプラクティス(1)
• ＸＰでは、ソフトウェア開発において、
５つの価値を重要視している。
– コミュニケーション
– シンプル
– フィードバック
– 勇気
– 尊重
• 単純にプラクティスを実践するだけでは、
５つの価値を得ることができない場合が
ある。
– 例
• Kent：花を植える時、等間隔を重視。
• 庭師：「肥料をやる方が大事」
• 価値とプラクティスを繋ぐ『橋』が必要。
４．価値と原則とプラクティス 62
- 63. >> 価値と原則とプラクティス(2)
• 価値とプラクティスの間に、「原則」
という橋を架ける。
原則
原則
プラクティス 価値
価値
プラクティス
• 原則を意識してプラクティスを実践す
ることで、効果的に価値を得ることが
できる。
４．価値と原則とプラクティス 63
- 64. >>原則(1)
• 人間性
– 休養や達成感は必要 人間は馬車馬ではない
• 経済性
– 利益がちゃんと得られる開発をしよう
• 相互利益
– みんなの利益になるように活動しよう 他人のバグでも取る
のだ
• 自己相似性
– 開発の基本はみんな同じ テスト作成→テストの動作の繰り
返し
• 改善
– 理想と現実を近づけるために日々努力しよう
• 多様性
– 多様性を否定しない チームの衝突を納得行くように解決し
よう
• 反省 「ゆめかがくにっき」様より抜粋
– 失敗を隠さず理由を分析しよう http://www.yumekagaku.com/
４．価値と原則とプラクティス 64
- 65. >>原則(2)
• フロー
– ソフトウェア間の結合は細かく行い、開発のフローを止めない
• 機会
– 問題が起きたら、それは変更するための機会と前向きに考える
• 冗長性
– 冗長性も時には必要 大事な冗長性は取り除かないように
• 失敗
– 失敗することは無駄ではない 解の出ない議論を繰り返さず、とりあ
えず作ってみよう
• 品質
– 品質を低くしたからと言って、プロジェクトが早く進むことはない
• 小さなステップ
– 一度に大きく変更せず、小さく変更してすぐテスト
• 責任の受け入れ
– 権限と責任にずれがないようにする さもないと「お前がやれ」とい
うことになる
「ゆめかがくにっき」様より抜粋
http://www.yumekagaku.com/
４．価値と原則とプラクティス 65
- 66. ■グループミーティング
• 仕事上、一番困っている問題を解決できそうな
プラクティスがないか、考えて下さい。
– ３分（個人）
• 一番困っている問題と、問題を解決するプラク
ティスを発表して下さい。
– ３分（グループ）
• チーム内で最も多かったプラクティスを発表して
下さい。
– ５分（グループ）
４．価値と原則とプラクティス 66
- 72. ご参加頂き、
ありがとうございました。
2008 / 5 / 17 72
