プラクティス
- プラクティスはXPチームが日々行うこと
- 価値によって目的が与えられて、初めて意味を持つ
- 価値を元に行う行動
- コミュニケーションを重視している（価値）から、デイリースタンドアップミーティングに出席する（プラクティス）
基礎プラクティス
全員同席
- チーム全体が入れるだけの十分な広さの空間を確保すること
- プライバシーを満たすために小さなプライベート空間を作ったり、労働時間を制限する
チーム全体
- プロジェクトの成功に必要なすべてのスキルを持つ人々からチームを構成する
- 部門を超えた「職能横断的チーム」という考えと同じ
情報豊富な作業空間
- 自分の作業空間を、行っている作業が明確にわかる空間にする
- 利害関係者が作業空間に入って15病でプロジェクトの見通しを把握できる状態
- 壁にグラフやストーリーカードを分類して貼ることで情報を迅速に伝えることができる
活気のある仕事
- 高い生産性を維持できる時間で仕事を行う
- 病気のときに仕事に来るのは、仕事への貢献を示すようにはならない
ペアプログラミング
- 1台のマシンの前に2人で座った状態ですべてのプログラムを作成する
- 2人で会話しながら、同時にプログラミングを行ってプログラムを向上させようとすること
- ペアプログラマが行う内容
- 互いに職務に集中する
- システムを洗練することについて意見を出し合う
- アイデアを明確にする
- パートナーが作業に行き詰まったときにはイニシアチブを取る。
- チームのプラクティスに対する責任を互いに負う
ペアプログラミングと個人の空間
- ペアを組む両者が居心地がいいパーソナルスペースを設定する
- ペアを組む際は個人の衛生と健康を考える
- 咳をするときには口を抑える、匂いの強い香水はつけない・・・など
ストーリー
- 顧客の目に見える機能単位で計画する
- ストーリーとその他の要件処理方法との違いは「早期の見積もり」である
- 見積もりはビジネス観点と技術的観点の交換の機会になる
- 実用性の高いアイデアを早期に生み出すことができる
- 最小の投資から最大の利益を得る方法について考える
１週間サイクル
- 1週間単位で作業を計画する
- 週の頭にミーティングを行う
- 現在までの進捗状況のレビュー前（週の予測と実際の進捗を見比べるなど）
- 今週実装する1週間分のストーリーを顧客に選択させる
- ストーリーをタスクに分割する
- 週の始まりはストーリーの完了時に成功する自動テストを書き、残りの日にちでテストがパスすることを目指す
四半期サイクル
- 四半期単位で作業を計画する
- チーム・プロジェクト・進捗・大きな目標との調整を考える
- 四半期ごとのテーマを計画する
- テーマに対応する四半期分のストーリーを選択する
- チーム外で管理されているボトルネックを特定し、修正する
- 全体像に焦点をあてて、プロジェクトが組織に適合しているかを確認する
- 「テーマ」は市場戦略のロードマップ
- 「ストーリー」は全体像をあまり考えず、今週集中する作業
ゆとり
- 計画には、遅れが生じた場合に捨てることができる重要でないタスクを含めること
- ex) 8週のうち1週は「マニアの週」にする
- ex) 1週間分の予算の20%はプログラマが選択したタスクに当てることにする
10分ビルド
- 10分間でシステム全体を自動的にビルドし、すべてのテストを実行する
- 10分以上かかると実行されることが少なくなり、フィードバックの機会を失う
- まずは「ビルドしてテスト実行」といった一連のプロセスの自動化を目指す
常時結合
- 2, 3時間以内に変更の結合とテストを行う
- チームで行うプログラミングは分割統治ではなく、「分割し、統治し、結合する」ことである
- 常時結合には非同期式と同期式がある
- 非同期式は、変更をチェックインするとビルドシステムが変更を検知し、ビルドとテストを実行する
- 問題があればメールなどで通知される
- 同期式は変更をチェックインしたあとすべてのテストスイートが実行されるのを待つ
- 待っている間に自然な反省時間が生まれる
- 手戻りがない
- 非同期式は、変更をチェックインするとビルドシステムが変更を検知し、ビルドとテストを実行する
テストファーストプログラミング
- コードを変更する前に、失敗する自動テストを作成する
- テストファーストプログラミングは多くの問題を解決する
- 仕様の拡大
- 「万が一に備えて」コードを挿入することを防ぐ
- 本当に必要な場合は現在の作業を行ったあとで別のテストを作成する
- 結合度と凝集度
- テストの作成が困難な場合は、結合度が高く、凝集度が低いケースが考えられる。設計ミスの表れ。
- 信頼
- 動作するきれいなコードを作成し、自動テストによって意図を示すことで仲間から信頼を得られる
- リズム
- 次に行うべきことが明確になる
- 「テスト→コード→リファクタリング、テスト→コード、リファクタリング…」
- 仕様の拡大
- 静的分析やモデルチェックといったツールをテストファースト方式で使用できるかもしれない
- システムにデッドロックがないかを「テスト」する
- すべての変更が終了したら、再度デッドロックがないことを検証する
- ソースコードの変更のたびにテストが実行される「常時テスト」方式もある
インクリメンタル設計
- システムの設計に毎日投資する
- システムの設計をその日のシステムの必要性に適合させるように努める
- XPチームは将来の要件に設計を適合させる
- ソフトウェアの変更による費用が劇的に増えない状況にする
- 小さくて安全なステップで設計を変更する
応用プラクティス
実顧客の参加
- システムによって生活やビジネスに影響を受ける人をチームの一員にする
- 顧客は自由に使える予算があり、開発リソースを何に費やすかを選ぶことができる
- 「ある人に特化したシステム」になるという反論があるが、成功したシステムを一般化する方がゼロから作るより容易である
インクリメンタル配置
- 既存のシステムをリプレイスする際に、プロジェクトの最初から移行作業を順次行っていく
- 一気に大規模なリプレイスをしない
チームの継続
- チームメンバの交代は適度な頻度にする
- チームが安定したまま、知識と経験の継続的な拡大というメリットが得られる
チームの縮小
- チームの能力が向上したら作業量を一定に保ったまま、徐々にチームの人数を減らす
- 余った人同士で別のチームを形成できる
根本原因の分析
- バグが見つかるたびに、バグと原因を取り除く
- バグの再発防止とチームが２度と同じ間違いをしないようにするため
- バグに対処するためのプロセス
- バグを実証するため、要求される振る舞いを記述したシステムレベルの自動テストを作成する
- 最も小さいスコープでユニットテストを作成し、バグを再現させる
- ユニットテストが動作するようにシステムを修正し、システムレベルのテストも動作することを確認する
- バグが生じた理由と見つけられなかった理由を考える
- 5回のなぜで考える
コードの共有
- チームメンバ誰でもシステムのあらゆる部分を常に改善することができる
- コードの各部分に対して責任者をおかない
コードとテスト
- 永続的な成果物としてコードとテストだけを保持する
- コードとテストからドキュメントを生成する
- 直接的な価値を生み出すコードとテスト以外の成果物はすべて無駄である
単一のコードベース
- 単一のコードだけを存在させる
- コード分岐は無駄を作り出す
- 現在デプロイされているシステムのバグを修正すると、ほか全てのシステム、ブランチに修正を取り込まなければいけなくなる
- 取引先によってソースコードのバリエーションを変えない
日時配置
- 毎晩、新しいソフトウェアを本番環境に配置する
- 日時配置には複数の必須条件がある
- プログラマが作成している内容と本番環境の内容にずれがない
- 1年あたりの欠陥が数件以内である
- ビルド環境が自動化されている
- デプロイツールがインクリメンタルなロールアウトとロールバックを含め自動化されている
- チームと顧客の間に強い信頼が築かれている
協議によるスコープ契約
- ソフトウェア開発に関する契約を作成する
- 時間・費用・品質を定め、開発スコープを継続的に協議することを要求する
利用分払い
- 課金体系を「システムが使用された分だけユーザに課金する」利用分払いシステムにする
- お金は究極のフィードバック
- 何に対して改善を促進するかについて、正確な情報を適宜得ることができる
- リリース分払いでは、サプライヤーの利益と顧客の利益が対立する
- サプライヤーは多くの中身のないリリースを行おうとする
- 顧客は各リリースに多くの機能が含まれることを望む
- サブスクリプションモデルでも、継続率でフィードバックを得ることができる