1. Extreme Programming (XP) 概要 2019/4/26 改定 Ryutaro YOSHIBA, Attractor Inc. Scrum Alliance Certified Scrum Team Coach.

2. XPとは ✤ ソフトウェア開発の制約に対応する軽量な方法論かつ思想 ✤ XPは、ビジネス側と開発側の両者が共通な達成可能なゴールに集中するための、 ビジネス及びソ フトウェア開発の規律 ✤ 価値・原則・プラクティスから構成される ✤ Kent Beckが中心となってまとめていた ✤ 初版:Extreme Programming Explained: Embrace ChangeOct 5, 1999 ✤ 第2版: Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)Nov 26, 2004 by Kent Beck and Cynthia Andres ✤ 数度の改訂を経て現在に至る ✤ プラクティス数12 => 24 => 19と変化

3. XPの構成 ✤ 以下のことが含まれる ✤ 5つの価値 ✤ ✤ コミュニケーション / シンプリシティ / フィードバック / 勇気 / リスペクト 14の原則 ✤ 人間性/経済性/相互利益/自己相似性/改善/多様性/ふりかえり/流れ/機 会 / 冗長性 / 失敗 / 品質 / ベイビーステップ / 責任の引き受け ✤ 開発の改善に効果があることが実証された19のプラクティス ✤ 全部はやっていないのでXPではない、とはならない。考え方のベースライ ンとして捉 える

4. 価値・原則・プラクティスの関係 ✤ 価値:自分たちにとって何が重要か、評価の軸になるもの。なぜそのプラクティス を 行うのかの目的となるもの ✤ プラクティス:価値を具体化したもの。状況によって個々のプラクティスの価値が 高 かったりそうでなかったりする。価値の説明責任を果たす ✤ 原則:抽象的な価値と具体的なプラクティスを橋渡しするもので、活動の指針

5. XPのプラクティスの変化 初版(1999) 【12】 2nd Edition(2004) 【24】 現在？ 【19】 主要プラクティス (13) 導出プラクティス (11) 共同のプラクティス (4) 管理者のプラクティス (5) 計画ゲーム 全員同席 本物の顧客参加 イテレーション 責任の受け入れ 短期リリース チーム全体 インクリメンタルなデプロイ 共通の用語 援護 メタファ（比喩） 情報満載のワークスペース チームの継続 オープンなワークスペース 四半期ごとの見直し シンプルな設計 いきいきとした仕事 チームの縮小 ふりかえり ミラー テスト ペアプログラミング 根本原因分析 リファクタリング ストーリー コードの共有 開発のプラクティス (6) ペアプログラミング 週次サイクル コードとテスト テスト駆動開発 顧客のプラクティス (4) 共同所有 四半期サイクル 単一のコードベース ペアプログラミング ストーリー 継続した統合 ゆとり デイリーデプロイ リファクタリング リリース計画 40時間労働 10分ビルド 交渉によるスコープ契約 ソースコードの共同所有 受け入れテスト オンサイトのユーザ（顧客） 継続的インテグレーション 利用都度課金 継続的インテグレーション 短期リリース コーディング規約 テストファーストプログラミング インクリメンタルな設計 最適なペース YAGNI

6. 共同のプラクティス (4プラクティス) ✤ 反復 ✤ ✤ 共通の用語 ✤ ✤ チーム全員が使う用語や概念を一致させる。初版の「メタファー」 オープンな作業空間 ✤ ✤ イテレーションという短い期間に区切って繰り返す。開発もコーディングとテストを繰り返す 作業に集中でき、顧客を含めて全員が一箇所に集まって作業を進める環境を用意する。初 版の「オンサイトのユーザー」 頻繁なふりかえり ✤ 現状を把握し、過去のフィードバックを反映していく

7. 開発のプラクティス (6プラクティス) ✤ テスト駆動開発 ✤ ✤ ペアプログラミング ✤ ✤ テストを先に記述し、そのテストにパスする少量のコードを書くことを繰り返しなが ら開発する。シンプルでわかりやすい設計が可能となる。テストは自動化が推奨 ドライバーとナビゲーターの2人がペアになってコードを書く。問題解決の時間が 短くなる、常時コードレビューが行われることで品質があがる等の利点 リファクタリング ✤ 完成したコードでも随時改善を行う。自動化されたテストがあることが前提となる

8. 開発のプラクティス (6プラクティス) ✤ ソースコードの共同所有 ✤ ✤ 継続的インテグレーション ✤ ✤ 誰が作ったソースコードでも開発チーム全員が断りなく修正を行うことができる。また、全 ての コードに対する責任を全員が担う。これを実現するために全員が同一のコーディング 規約を使 うと良い 単体テストを通るコードができるたびに残りの部分と結合して、問題点がないかを探す。 最低で も1日に1回は行う。継続的インテグレーション用のサーバやサービスを利用する のが一般的 YAGNI ✤ You Aren't Going to Need It(それは必要にならない)。先のことを考慮して機能を増 やしたり 設計を複雑にするのは避けて、本当に必要になったときに対処を行う。またムダ な機能や使って いない機能やコードを削ぎ落とす

9. 管理者のプラクティス (5プラクティス) ✤ 責任の受け入れ ✤ ✤ 援護 ✤ ✤ 押し付けではなく、開発チームがストーリーの実現を約束できるようにする チームの活動が円滑に進むように支援し、妨害となるものを取り除く。外圧やス テークホルダーとの関係など 四半期ごとの見直し ✤ プロジェクトの進捗状況を顧客とともに四半期ごとにレビューし、必要なら今後 の計画を見直す

10. 管理者のプラクティス (5プラクティス) ✤ ミラー ✤ ✤ いまどういう状態かチームが分かるようにする。ストーリーカードや重要な資料 を壁にはって見える化するなど 最適なペースの仕事 ✤ 集中力を高め、効果を最大化し、持続可能であるために週40時間の労働時間に する

11. 顧客のプラクティス (4プラクティス) ✤ ストーリーの作成 ✤ ✤ リリース計画 ✤ ✤ どのストーリーをどのイテレーションで実施するかをチームが主体となって決定する 受け入れテスト ✤ ✤ 求める機能の要件を短い文章で記載するストーリーカードを作成する。そのカードを元に 会話をする イテレーションごとに顧客の立場から、ストーリーが実現できているかを確認する 短期リリース ✤ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする

12. 共同のプラクティス 開発のプラクティス 管理者のプラクティス 顧客のプラクティス XP Scrum 反復 スプリント 共通の用語 (XPを活用) 開けた作業空間 (XPを活用) 頻繁なふりかえり スプリントレトロスペクティブ テスト駆動開発 (XPを活用) ペアプログラミング (XPを活用) リファクタリング (XPを活用) ソースコードの共同所有 (XPを活用) 継続的インテグレーション (XPを活用) YAGNI (XPを活用) 責任の受け入れ コミットメント 援護 スクラムマスター 四半期ごとの見直し スプリントレビュー ミラー デイリースクラム、スクラムボード 最適なペースの仕事 (XPを活用) ストーリーの作成 プロダクトバックログ リリース計画 スプリントプランニング 受け入れテスト 受け入れ基準 短期リリース リリース判断可能なインクリメント