Xp Terakoya No02

1,369 views
1,294 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,369
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Xp Terakoya No02

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

×