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.

Xp2 2014版

956 views

Published on

XPJUG 2014祭り オレ流XP入門

Published in: Software
  • Be the first to comment

Xp2 2014版

  1. 1. オレ流:XPとは  良いソフトウェア開発するためのカタログ  カテゴリは2つ  良いソースコードを継続的に書くためのもの  良いチーム活動を継続するためのもの  利用ガイド  価値(value)=判断するための基準  プラクティス(practice)=技法  原則(principle)=ある領域の指針 2
  2. 2. 例:お菓子を作る  価値:判断基準を決める  家族がおいしいというお菓子を作る  家族の要望を聞く(コミュニケーション)  家族の意見を受け入れる(フィードバッグ) 3
  3. 3. 例:お菓子を作る技法  技法(お菓子作り用)  レシピは、「簡単」「失敗しない」をキーワードで選ぶ  レシピの注意点はしっかり守る  ツールなどは100円ショップで買う  専用のツールを使う  手順を明確にする  ツールと材料を準備する  最初に、材料は全部計る  片付けをする  作りながら、片付ける  材料を少し変えて、バリエーション 4
  4. 4. 例:お菓子を作る原則  原則(XPそのまま)  Humanity(人間性)  安全性、達成感、成長、親密さ  Economics(経済)  価値がある、目標を達成している、要件に合っている  Mutual Benefit(相互利益)  家族のみんなが喜ぶ(利益になる)  Self-Similarity(自己相似性)  レシピ(パターン)を利用する  Improvement(改善)  繰り返すことで上手になる  Diversity(多様性)  様々なスキル(作る、片づける)が良い結果 5
  5. 5. 例:お菓子を作る原則  原則(XPそのまま)  Reflection(ふりかえり)  上手く行った理由、失敗した理由を考え、分析する  Flow(絶え間なく)  作ると片づけるを同時に行う  Opportunity(機会)  失敗は学習と上手くなる機会  Quality(質)  品質は犠牲にしてはならない  Baby Steps(ほんのちょっとづつ)  少しずつステップアップ  Accepted Responsibility(責任の受け入れ)  結果の責任を受け入れる 6
  6. 6. 例:お菓子を作るポイント  大切なこと  コンテクスト(Context)  状況をはっきり認識する(やりたいこと、できること)  状況(自分の習熟度)に合わせて、価値・技法・原則を 選んだり、追加したりする  変化を受け入れる  状況も、対象や時間で変わる  練習  最初は練習として、やってみる(失敗する)  少しずつ、新しいことに挑戦 7
  7. 7. オレ流:XPのまとめ  プロジェクトごとに、「価値・原則・プラクティス」 マップを作成し、目的を共有する  状況を考えることが大切  XPは目的ではありません、カタログです  XPと直接関係ありませんが 8 「成せば為る成さねば為らぬ何事 も 為らぬは人の成さぬなりけり」 上杉鷹山
  8. 8. XP入門  目次  目標  焦点と内容  定義  価値、原則、プラクティス  まとめ 9
  9. 9. 目標  XPの目標  優れたソフトウェア開発を行うこと  現在の多くのソフトウェア開発はカイゼンできる  低コスト  少ない欠陥  高い生産性  投資回収率  ソフトウェア開発  良い方法と悪い方法がある  優れたチームは、同じような方法が採用されている  優れたソフトウェア開発チームの共通点  ソフトウェア開発チームのパタン・ランゲージ 10
  10. 10. 焦点と内容  焦点  プログラミング技術  明確なコミュニケーション  チームワーク  内容  理念(価値)  コミュニケーション  フィードバック  シンプルさ  勇気  尊重  原則  プラクティス  互いに補足  補完的な原則  共有するコミュニティ 11
  11. 11. 定義(他の方法論との違い)  短期の開発サイクル  インクリメンタルな開発手法  ビジネス要件の変更にともなう、柔軟なスケジューリ ング  信頼性の高い自動テスト  コミュニケーション、テスト、ソースコードに対する信 頼  継続する発展的な設計プロセス  メンバー間の協調関係に対する信頼  チームメンバーの短期的な要求とプロジェクトの長期 的な利益の両方に対応するプラクティス 12
  12. 12. 価値、原則、プラクティス プラクティス、価値  プラクティス(practice)  新しいソフトウェア開発を実行するための技術  技術レベルの知識と理解  価値(value)  新しいソフトウェア開発を実行するための全体を 捉える力  判断レベルの知識と理解  ある状況で何が望ましいか、望ましくないかの根 拠  判断するための大まかな基準 13
  13. 13. 価値、原則、プラクティス 価値とプラクティスの関係  結びつけることが必要  結びつくことが、プラクティスを実践する正当な理由  価値が、プラクティスの目的を明確にする  プラクティスが価値を証明する 14 価値によって プラクティスが目的を得る
  14. 14. 価値、原則、プラクティス 原則と3つの関係  原則(principle)  価値とプラクティスとの隔たりを埋めるもの  特定の領域の変わることがない指針 価値プラクティス 15 原則は橋
  15. 15. XPとはXPの真髄  社会的な変革(social change)  障害となる慣習やパターンを取り除く  自己改革  子供じみた自己  他の誰よりも知っている  1人にしてくれれば、素晴らしい結果が出せる  成熟した自己  ビジネスや仕事のコミュニティで自分の場所を見つける  手順  最も良い自己になるためのプロセス  良いプロセスで開発者として最善を尽くす  実際にビジネスで利用できるコードを作成する  信頼関係  成功するためには技術と信頼関係が必要 16
  16. 16. 「XPとは?」という疑問に対する回答 社会的な変革(social change)とは  役に立たない技術的習慣や社会的な習慣を 捨てて、機能する新しい習慣を行う  今日全力を尽くすことに対して自分自身を評 価する  明日には、より良い結果を得られるように努力 する  チームの共通の目標に対する貢献度で自分 自身を評価する  ソフトウェア開発の中で人間的な要求がある 程度満たされるように求める 17
  17. 17. まとめXPとは  自分自身を最初に改善しなければ、何の改善も ない  自分の価値を考えて、その価値と調和した生活 を意識的に選択する  調和した中で生き、優れた仕事を行う 18
  18. 18. 詳細  XP第2版(変化を受け入れる)紹介  まえがき  XPとは  運転の心得  価値、原則、プラクティス  結論  書籍紹介 19
  19. 19. まえがき  XPの目標  優れたソフトウェア開発を行うこと  現在の多くのソフトウェア開発はカイゼンできる  低コスト  少ない欠陥  高い生産性  投資回収率  ソフトウェア開発  良い方法と悪い方法がある  優れたチームは、同じような方法が採用されている  優れたソフトウェア開発チームの共通点  ソフトウェア開発チームのパタン・ランゲージ 20
  20. 20. XPとはXPの真髄  社会的な変革(social change)  障害となる慣習やパターンを取り除く  自己改革  子供じみた自己  他の誰よりも知っている  1人にしてくれれば、素晴らしい結果が出せる  成熟した自己  ビジネスや仕事のコミュニティで自分の場所を見つける  手順  最も良い自己になるためのプロセス  良いプロセスで開発者として最善を尽くす  実際にビジネスで利用できるコードを作成する  信頼関係  成功するためには技術と信頼関係が必要 21
  21. 21. XPとはXPの焦点と内容  焦点  プログラミング技術  明確なコミュニケーション  チームワーク  内容  理念(価値)  コミュニケーション  フィードバック  シンプルさ  勇気  尊重  原則  プラクティス  互いに補足  補完的な原則  共有するコミュニティ 22
  22. 22. XPとは定義(他の方法論との違い)  短期の開発サイクル  インクリメンタルな開発手法  ビジネス要件の変更にともなう、柔軟なスケジューリ ング  信頼性の高い自動テスト  コミュニケーション、テスト、ソースコードに対する信 頼  継続する発展的な設計プロセス  メンバー間の協調関係に対する信頼  チームメンバーの短期的な要求とプロジェクトの長期 的な利益の両方に対応するプラクティス 23
  23. 23. XPとは定義(第2版での追加項目)  軽量である  多くの荷物を持っては俊敏に動けない  ソフトウェア開発における制約への対処方法 に基づく方法論である  どのような規模のチームにも適応できる  規模によってプラクティスの選択や追加が必要  曖昧で変化しやすい要求仕様に適合する 24
  24. 24. XPとはリスクへの対処  プロジェクトの遅延、ビジネスの変化、ビジネ スの誤解  短いリリースサイクル  プロジェクトのキャンセル、誤った機能強化  ビジネスの価値に基づいたリリース計画  システムの陳腐化  自動テストによる、変更への対応  欠陥率  様々な視点からのテスト(プログラマやユーザ) 25
  25. 25. 「XPとは?」という疑問に対する回答 社会的な変革(social change)とは  役に立たない技術的習慣や社会的な習慣を 捨てて、機能する新しい習慣を行う  今日全力を尽くすことに対して自分自身を評 価する  明日には、より良い結果を得られるように努力 する  チームの共通の目標に対する貢献度で自分 自身を評価する  ソフトウェア開発の中で人間的な要求がある 程度満たされるように求める 26
  26. 26. 運転の心得XPのパラダイム  XPのパラダイム  常に注意を払う  状況に適応する  変更する  ソフトウェアのすべての要素は変化する  要素  要件、設計  ビジネス、テクノロジー  チーム、チームのメンバー  問題は  変化に対処できないこと 27
  27. 27. 価値、原則、プラクティス プラクティス、価値  プラクティス(practice)  新しいソフトウェア開発を実行するための技術  技術レベルの知識と理解  価値(value)  新しいソフトウェア開発を実行するための全体を 捉える力  判断レベルの知識と理解  ある状況で何が望ましいか、望ましくないかの根 拠  判断するための大まかな基準 28
  28. 28. 価値、原則、プラクティス 価値とプラクティスの関係  結びつけることが必要  結びつくことが、プラクティスを実践する正当な理由  価値が、プラクティスの目的を明確にする  プラクティスが価値を証明する 29 価値によって プラクティスが目的を得る
  29. 29. 価値、原則、プラクティス 原則と3つの関係  原則(principle)  価値とプラクティスとの隔たりを埋めるもの  特定の領域の変わることがない指針 価値プラクティス 30 原則は橋
  30. 30. 価値目的と役割  目的  チーム(組織)の成功  役割  開発の指針  チーム(組織)内で個人がどのように振舞うべきか 31 コミュニケーション シンプルさ フィードバック 勇気 尊重(尊敬) 5つの価 値
  31. 31. 価値コミュニケーション、シンプルさ  コミュニケーション  最も重要  チーム意識と効果的な協力関係  ほとんどの開発の問題は、誰かが解決策を知って いる  シンプルさ  最も知的  今日の問題を解決できるようにシステムをシンプ ルにする  動作させるための最もシンプルなことは何か  シンプルさは状況によって異なる 32
  32. 32. 価値フィードバック  方針は、長期に渡って一定ではない  ソフトウェア開発の詳細、システムの要件やアーキテク チャ  最初から正しく(変化を予測した) 開発ができない理 由  「正しく」行う方法を知らない  今日は正しくても、明日は正しくない場合がある  正しい方法で実装するために時間がかかる  状況が変わるため、正しく行う前に無効になってしまう  目的を達成するためには  フィードバックを使用するカイゼンによって目的に近づける  早いフィードバックがカイゼンを早くする 33
  33. 33. 価値勇気  勇気とは  恐怖を前にしたときに有効な手段  恐怖への対処なしに、効率的な作業はない  真実を伝える勇気  コミュニケーションと信頼が生まれる  新しい解答を探す勇気  フィードバックを生む 34
  34. 34. 価値尊重  4つの価値の背景に尊重が存在する  尊重の意味と役割  チームの人と人間としての価値は同じ  チームがチームであるためには尊重が必要  人間性と生産性を同時に改善する  チームへの個人の貢献が尊重されるべき 35
  35. 35. 価値5つの価値以外の価値  各組織やチームに応じた、さまざまな価値が ある  必要に応じて、新しい価値を選択する  その他の価値の例  安全性  セキュリティ  予測可能性  生活の質 36
  36. 36. 原則  原則とは  ソフトウェア開発の具体的な指針  プラクティスの指針  紹介する原則について  ソフトウェア開発の唯一の原則ではない  他に必要となる原則がある場合もある  XPの指針となる原則 37
  37. 37. 原則人間性  ソフトウェアは人が開発するもの  人間の弱さを意識し、長所を利用する  優れた開発者に必要なこと  必要最低限の安全性  達成感  所属意識  成長  親密さ 38
  38. 38. 原則経済性  経済性とは  ビジネス価値がある  ビジネス目標を達成している  ビジネス要件に合っている  XPでの対処法  ビジネス価値の高い要件から提供する  ソフトウェアとチームの価値を高める 39
  39. 39. 原則相互利益  全ての活動は、関係者全員の利益とならなけ ればいけない  XPでは、最も重要な原則だが、順守は困難  XPの相互利益とは  現在の自分、将来の自分、顧客にとって利益があ るプラクティスを選ぶ(探す)こと 40
  40. 40. 原則自己相似性  自己相似性とは  役立つ形(パターン)を探し、解決策として利用す る  適応範囲  パターンは、状況によって機能する場合としない 場合がある  パターンは、異なる規模でも利用できる場合があ る 41
  41. 41. 原則改善(カイゼン)  ソフトウェア開発に完全なプロセスはない  「完全」は動詞である  カイゼンの繰り返しによって、洗練する  インクリメンタルな設計  設計を洗練するためには、カイゼンが必要  理想と現実を近づけるためには、カイゼンする 42
  42. 42. 原則改善を妨げるもの  無駄の増加の原因  開発組織の硬直化  社会構造の専門化  無駄を抑制するためには  新しい技術的な効率性を用いて、効果的で新しい 社会的な関係を可能にする  完全性を求めずに、カイゼンを作業に盛り込む 43
  43. 43. 原則多様性  チーム員が同じでは、効率的ではない  多様性  様々なスキルや姿勢が解決策を発見する  多様性がチームには必要  多様性は衝突を生む  衝突の意味  解決策が複数ある状態  衝突の解決  個々の意見を尊重し、チーム全体として解決を行 う 44
  44. 44. 原則反省  優れたチーム  作業を行い、作業方法と理由を考える  成功した理由、失敗した理由を分析する  誤りを公表し、学習する  反省する時期  作業を行ってから反省する  反省だけ行っていては、前に進まない  実行しながら反省を行う 45
  45. 45. 原則フロー、機会  フロー  開発をフェーズに分けずに、全ての活動を同時に 行う  活動を連続したフローとする  機会  問題を変更の機会と捉える  問題を学習とカイゼンの機会と捉える  問題を解決するプラクティスを採用する 46
  46. 46. 原則冗長性、失敗  冗長性  困難な問題に対しては、さまざまな方法で対処しなければ ならない  プラクティスは、冗長性を持つものがある  冗長性が単なる無駄にならずに、問題を解決することがあ る  失敗  成功することが困難な場合は、失敗する  失敗することの価値  失敗によって知識を得る場合  複数の選択肢の決定に、失敗を利用する  失敗することが成功への最短で確実な道になる 47
  47. 47. 原則品質  品質を犠牲にしてはならない  品質を犠牲にしても、プロジェクトは早くならない  品質を向上させる  かえって、早い納品につながる  生産性、有効性といった特性の改善になる  高い品質が仕事に誇りを生む  できる範囲で、最善の方法を行う  品質がプロジェクトを安定させる 48
  48. 48. 原則小さなステップ  大きなステップ  大きなステップで、大きな変更を行うことは高いリ スクを伴う  小さなステップ  正しい方向に進んでいるとわかる最も小さいス テップを考える  確実に、目標に近づける 49
  49. 49. 原則責任の受け入れ  責任とは  責任は割り当てることはできない  責任は受け入れることができるだけ  責任と権限  責任を持つことは、権限を持つことになる  責任と権限のずれは感情的な負担となる 50
  50. 50. 原則結論  原則を理解し、目的にあったプラクティスを見 つける  原則がアイデアを生む  原則を理解することで、有効な新しいプラク ティスを作成する 51
  51. 51. プラクティス  プラクティスとは  チームが日々行うこと  プラクティスの実行  価値によって目的を意識して実行する  複数のプラクティスが相互作用を生む  複数の使用によって、劇的に改善される  プラクティスの選択  状況に合わせて選択する 52
  52. 52. 基礎プラクティス 全員同席、チーム全体  全員同席  チーム全体が入る空間を確保する  コミュニケーションを向上させる  チーム全体  チームとは  一員である  共に取り組んでいる  お互いの作業、成長、学習をサポート  チームの構成は、動的に変化する 53
  53. 53. 基礎プラクティス 情報豊富な作業空間、活気のある仕事  情報豊富な作業空間  作業が明確にわかる状態にする  15秒間でプロジェクトの見通しが把握できる  活気のある仕事  高い生産性を維持できる空間で仕事をする  ソフトウェアにはアイデアが必要である 54
  54. 54. 基礎プラクティス ペアプログラミング ペアプログラミングと個人の空間  ペアプログラミング  2人で、プログラミング(分析、設計、テスト)を行う  ペアプログラマが行う内容  お互いに集中する  意見を出し合う  アイデアを明確にする  パートナーの問題を共に解決する  プラクティスに対する責任を負う  一人で考える必要があれば、ペアを解消する  個人の空間を尊重しなければならい 55
  55. 55. 基礎プラクティス ストーリー  顧客の見える単位で計画する  ストーリーと要件のちがい  要件には、絶対かつ不変な意味合いがある  変更の受入れを抑制する  ストーリーで重要なことは、早期の見積り  ビジネスの観点と技術的な観点に相互作用の機会  見積りを前提に、スコープの分割、結合、拡張を行う  ストーリーと見積りの制約を把握する 56
  56. 56. 基礎プラクティス 1週間サイクル、四半期サイクル  1週間単位で作業を計画する  短時間で正しい計画できる単位で計画する  計画を立てる行為自体には価値がない  四半期単位で作業を計画する  四半期ごとに、進捗や目標との調整を行う  四半期ごとの計画  テーマの計画、テーマに対するストーリーの選択  ボトルネックの特定、修正  プロジェクトが組織に適合していることを確認する 57
  57. 57. 基礎プラクティス ゆとり  責務を果たすことの重要性  オーバーコミットによって無駄が発生する  管理不能な欠陥  士気の低下  人間関係の対立  控え目であっても、責務を果たすことで信頼は生 まれる  計画のゆとり  遅れが生じたときにカットできる重要でないタスク を盛り込む 58
  58. 58. 基礎プラクティス 10分ビルド、常時結合  10分間でシステム全体をビルドし、テストを実 行する  自動ビルドは、手作業のビルドよりもはるかに役 に立つ  常時結合  2~3時間以内に結合とテストを行う  結合までの時間が長いほど、費用は大きくなり、 予測できなくなる 59
  59. 59. 基礎プラクティス テストファーストプログラミング  コードを変更する前に失敗する自動テストを作 成  効果  仕様(スコープ)の拡大  結合度と凝集度  設計を良くする  信頼  動作するシステムが信頼を生む  効率的なリズム  テスト→ コード→ リファクタリング 60
  60. 60. 基礎プラクティス インクリメンタル設計  システムの設計に毎日投資を行う  変更の準備  変更による費用が増えないような状況を維持する  常に設計に注意を払う  設計投資期間を短くするのではなく、設計投資を必要に応 じて行う  設計の指針  重複のない設計を行う  作業が進んで理解が進んでから設計を行う 61
  61. 61. 応用プラクティス  応用プラクティス  基礎プラクティスを理解してから、必要に応じて採用するプ ラクティス  実顧客の参加  インクリメンタル配置、日次配置  チームの継続、チーム数の縮小  根本原因の分析  コードの共有、コードとテスト、単一のコードベース  協議されたスコープ契約、利用分払い 62
  62. 62. プラクティス結論  ソフトウェア開発を成功させることに必要なの は、プラクティスだけではない  価値や原則を見直して、個々のチームにあっ た解決策を考える 63
  63. 63. 結論  自分自身を最初に改善しなければ、何の改善も ない  自分の価値を考えて、その価値と調和した生活 を意識的に選択する  調和した中で生き、優れた仕事を行う 64
  64. 64. 書籍紹介  XPエクストリーム・プログラミング入門  変化を受け入れる第2版  ISBN4-89471-685-2  この資料の内容は、前半の一部です  書籍には、さまざまなアイデアが満載です  ぜひお手に取って熟読ください 65

×