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