Extreme Programming (XP) 概要

Extreme Programming (XP) 概要です

1. Extreme Programming (XP) 概要 2019/1/6 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. 初版から現在までのプラクティスの変遷 初版(1999) 【12】 2nd Edition(2004) 【24】 現在? 【19】 主要プラクティス 導出プラクティス 共同のプラクティス 管理者のプラクティス 計画ゲーム 全員同席 本物の顧客参加 反復 責任の受け入れ 短期リリース チーム全体 インクリメンタルなデプ ロイ 共通の用語 援護 メタファ(比喩) 情報満載のワークスペ ース チームの継続 オープンな作業空間 四半期ごとの見直し シンプルな設計 いきいきとした仕事 チームの縮小 頻繁なふりかえり ミラー テスト ペアプログラミング 根本原因分析 リファクタリング ストーリー コードの共有 開発のプラクティス ペアプログラミング 週次サイクル コードとテスト テスト駆動開発 顧客のプラクティス 共同所有 四半期サイクル 単一のコードベース ペアプログラミング ストーリーの作成 継続した統合 ゆとり デイリーデプロイ リファクタリング リリース計画 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を活用) ストーリーの作成 プロダクトバックログ リリース計画 スプリントプランニング 受け入れテスト 受け入れ基準 短期リリース リリース判断可能なインクリメント
No comments...
Attractor Inc. Founder / CTO / Agile Coach / Certified Team Coach / Certified Scrum Professional / Certified ScrumMaster / Certified Scrum Product Owner Twitter : @ryuzee Web : https://www.attractor.co.jp/ Web : http://www.ryuzee.com/

Related Slides