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