Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Xp寺子屋出張版#2「xp入門 追補版」

1,365 views

Published on

2011/12/11 に開催した「Touch the Agile」の資料です。

  • Be the first to comment

Xp寺子屋出張版#2「xp入門 追補版」

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

×