Download as PDF, PPTX
![>>名前の由来
ソフトウェア開発プロジェクト
• [extream]=極端な／究極の
良い事を徹底的に行い
– 良い事 良い事 不要な事
100% 100%
– 不要な事を徹底的に行わない
不要な事
0% 0%
• [Programming]
– プログラミングこそソフトウェ
ア開発の「中心活動」
「中心活動」と捉えて
「中心活動」
いる。
１．概要 8](https://image.slidesharecdn.com/xpterakoyano02-091129000006-phpapp02/85/Xp-Terakoya-No02-8-320.jpg)
More Related Content
Xp Terakoya No02
- 1. eXtream Programming入門 ~理論から学ぶＸＰ～ 2008 / 5 / 17 1
- 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
- 43.
- 44. >>開発環境 >>全員同席 • 内容 – お客様～開発者まで、全員同じ 場所で作業する。 • 効果 – 質問のレスポンス速度向上 – コミュニケーション不足の解消 ４．価値と原則とプラクティス 44
- 45.
- 46. >>見積もり >>計画ゲーム • 内容 – お客様と開発者の見積もりゲーム。 – 「期日までに何ができるか」「次に何を するのか」を明確にする。 – 互いの役割に干渉してはならない。 – お客様の役割 • ストーリの提示 • ストーリの優先順位決定 • ストーリの実施可否決定 – 開発者の役割 • ストーリを見積もる • 想定されるリスクを報告する • 効果 – お客様の希望する価格で真に望む機能を 開発することができる。 – 変更を容認できる仕組みの提案。 ４．価値と原則とプラクティス 46
- 47.
- 48. >>開発プロセス >>短期リリース • 内容 – 短期間で動作可能なシステムを リリースする。 • 効果 – 開発期間中にユーザからの フィードバックが得られる。 – 実装上のリスクが削減される。 ４．価値と原則とプラクティス 48
- 49. >>開発プロセス >>最適ペース • 内容 – 無理な作業は効率が悪い事に気 付く。 – 無理な作業は精神面への負担も 増加することを認識する。 – 実績に基づいて開発スピードを 調整する。 • 効果 – 人は最適なペースを維持しなが ら作業すると効率が良い。 ４．価値と原則とプラクティス 49
- 50. >>開発プロセス >>スタンダップミーティング • 内容 – 毎朝同じ時間・同じ場所で、立ったま まミーティングする。 – 昨日実施した事、今日実施することを 手短に報告する。 • 効果 – コミュニケーション促進 – 今日実施することを自分で宣言するこ とで、実施内容が明確になる – 問題が発生しても、最大２４時間で キャッチアップ可能 ４．価値と原則とプラクティス 50
- 51. >>開発プロセス >>ユーザテスト • 内容 – システムを最も理解しているの はシステムを使うお客様である。 – お客様に受け入れテスト項目を 作成頂く。 • 効果 – システムのゴールが明確になる。 – 抜け／漏れが明確になる。 ４．価値と原則とプラクティス 51
- 52.
- 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
- 61.
- 62. >> 価値と原則とプラクティス(1) • ＸＰでは、ソフトウェア開発において、 ５つの価値を重要視している。 – コミュニケーション – シンプル – フィードバック – 勇気 – 尊重 • 単純にプラクティスを実践するだけでは、 ５つの価値を得ることができない場合が ある。 – 例 • Kent：花を植える時、等間隔を重視。 • 庭師：「肥料をやる方が大事」 • 価値とプラクティスを繋ぐ『橋』が必要。 ４．価値と原則とプラクティス 62
- 63. >> 価値と原則とプラクティス(2) • 価値とプラクティスの間に、「原則」 という橋を架ける。 原則 原則 プラクティス 価値 価値 プラクティス • 原則を意識してプラクティスを実践す ることで、効果的に価値を得ることが できる。 ４．価値と原則とプラクティス 63
- 64. >>原則(1) • 人間性 – 休養や達成感は必要 人間は馬車馬ではない • 経済性 – 利益がちゃんと得られる開発をしよう • 相互利益 – みんなの利益になるように活動しよう 他人のバグでも取る のだ • 自己相似性 – 開発の基本はみんな同じ テスト作成→テストの動作の繰り 返し • 改善 – 理想と現実を近づけるために日々努力しよう • 多様性 – 多様性を否定しない チームの衝突を納得行くように解決し よう • 反省 「ゆめかがくにっき」様より抜粋 – 失敗を隠さず理由を分析しよう http://www.yumekagaku.com/ ４．価値と原則とプラクティス 64
- 65. >>原則(2) • フロー – ソフトウェア間の結合は細かく行い、開発のフローを止めない • 機会 – 問題が起きたら、それは変更するための機会と前向きに考える • 冗長性 – 冗長性も時には必要 大事な冗長性は取り除かないように • 失敗 – 失敗することは無駄ではない 解の出ない議論を繰り返さず、とりあ えず作ってみよう • 品質 – 品質を低くしたからと言って、プロジェクトが早く進むことはない • 小さなステップ – 一度に大きく変更せず、小さく変更してすぐテスト • 責任の受け入れ – 権限と責任にずれがないようにする さもないと「お前がやれ」とい うことになる 「ゆめかがくにっき」様より抜粋 http://www.yumekagaku.com/ ４．価値と原則とプラクティス 65
- 66. ■グループミーティング • 仕事上、一番困っている問題を解決できそうな プラクティスがないか、考えて下さい。 – ３分（個人） • 一番困っている問題と、問題を解決するプラク ティスを発表して下さい。 – ３分（グループ） • チーム内で最も多かったプラクティスを発表して 下さい。 – ５分（グループ） ４．価値と原則とプラクティス 66
- 67. 最後に。 67
- 68.
- 69.
- 70.
- 71. 皆さん ＸＰｅｒ（ＸＰ実践者） です！！ 71
- 72. ご参加頂き、 ありがとうございました。 2008 / 5 / 17 72