Clean Agileを読んで押さえておきたいと思ったポイントを軸にアジャイル開発について自分なりに整理してみました。
目次
サークルオブライフ
上の図はXPのプラクティスを描いた図で、アジャイルの本質を示した原型であり、最も典型的なものとなっています。
ビジネスプラクティス
最も外側にあるのが、ビジネス向けのXPプラクティスです。ビジネス側と開発チームの両方がプロジェクトをマネジメントするための原則を提供しています。
計画ゲーム
計画ゲームは、このリングの中心的な役割を果たします。これはプロジェクトを機能、ストーリー、タスクに分割する方法を示している。またこれらの機能、ストーリー、タスク見積り、優先順位付け、スケジューリングのガイダンスを提供しています。
ストーリーの作成
システムの機能をユーザーの視点から簡潔に記述したユーザーストーリーを考えます。
例)
車の運転手として、
アクセルペダルを強く踏みたい。
それは車の速度を上げるためだ。
この時、ストーリーの詳細化は避けます。ストーリを話し合うときに詳細を全て書き留めるべきと思いがちだが、そのような衝動を抑える必要があります。
ストーリーの見積もり
ストーリーの見積もりは見積もり時間ではなく、見積もり労力を単位とします。ログアウト機能は1ポイント、ログイン機能は3ポイントのようにポイント数を選択します。
イテレーション
イテレーションは一連の工程を短期間で繰り返す開発サイクルのことで、イテレーションプランニングミーティング(IPM)から始まり、期間の1/20の時間になるようにします。
各イテレーションの目標は、ストーリーを完成させてデータを生成することです。
ベロシティ
イテレーションの最後の作業は、ベロシティ(開発速度)とバーンダウンチャート(プロジェクトの進捗)の更新です。受け入れテストをパスしたストーリーのポイントだけをチャートに記録します。
小さなリリース
小さなリリースは、小さな単位で作業するようにチームをガイドします。
プラクティス
小さなリリースのプラクティスは、開発チームはできるだけ頻繁にソフトウェアをリリースすべきというものです。
受け入れテスト
受け入れテストは、機能、ストーリー、タスクの「DONE」の定義を提供します。明確な完成基準の設定方法をチームに示します。
プラクティス
受け入れテストのプラクティスは、ビジネス側がユーザーストーリーの振る舞いを形式的なテストで記述し、開発者がそれらのテストを自動化することです。
テストはイテレーションにおけるストーリーの完成の定義であり、ストーリーは受け入れテストをパスするまでは完成ではありません。
チーム全体
チーム全体は、ソフトウェア開発チームはプログラマー、テスター、マネージャーなどの様々な職種で構成されており、共通のゴールを目指してみんなで協力するものだという考えを示しています。
同じ場所
同じ場所にいるだけなのにチームの効率が劇的に向上するとされています。
家からのリモートも増えてきたが、同じスペースにいることによる雑談や即席のMTGなどが失われるため、偶発的な会話がなくなりがちです。
チームプラクティス
「サークルオブライフ」の中間のリングは、チームのプラクティスを示しています。これらのプラクティスは、開発チームがチーム内やマネージャーとコミュニケーションするためのフレームワークと原則を提供します。
持続可能なペース
持続可能なペースは、開発チームがリソースをすぐに消費してしまい、ゴールの手前で力尽きないようにするためのプラクティスです。
献身
残業したからといって、雇用主に献身的であることを示したことにはなりません。
すべての残業が悪というわけではないが、残業によってスケジュールが短縮されるよりも、残業にかかるコストの方が大きくなりやすいことを意識する必要があります。
共同所有
共同所有は、プロジェクトにおいてチームに「知識の断絶」が起きないようにするためのプラクティスです。
アジャイルプロジェクトでは、コードはチーム全体で所有しており、チームの誰もが全てのモジュールにいつでもチェックアウトして改善できます。
継続的インテグレーション
継続的インテグレーションは、チームが現在地を常に把握できるように、フィードバックループを何度も閉じることにフォーカスするプラクティスです。
継続的ビルドの規律
継続的ビルドは絶対に壊してはいけません。ビルドが壊れた時は緊急事態であり、全てのプログラマーは作業を中断し、すぐにビルドの復旧に取り掛かる必要があります。
メタファー
メタファーは、チームとビジネス側がシステムについてコミュニケーションするための語覚や言語を作成し、広めるためのプラクティスです。
チームが効果的にコミュニケーションするためには、製薬と規律を持つ用語や概念が必要になります。
ドメイン駆動設計
ドメイン駆動設計のなかにユビキタス言語という用語があり、これはメタファーのプラクティスに採用されるべき概念です。
チームに必要なのは問題領域のモデルであり、それを全員が合意した語彙(ユビキタス言語)で記述します。ここでいう全員とはプログラマー、QA、マネージャー、顧客、ユーザーを含めた全員です。
テクニカルプラクティス
「サークルオブライフ」の最も内側のリングは、最高の技術品質を保証するために、プログラマーをガイドおよび強制するための技術プラクティスを示しています。
テスト駆動開発(TDD)
テスト駆動開発は、技術チームが高品質を維持しながらすばやく進むための命綱です。
TDDの3つのルール
- 失敗するテストを書くまではプロダクションコードを書いてはいけない
- 失敗するテストを必要以上に書いていけない
- プロダクションコードを必要以上に書いてはいけない
この3つのルールに従うことでデバッグの軽減、優れた低レベルのドキュメンテーション、楽しさ、完全性、分離といった様々なメリットがあります。
勇気
完全なテストスイート(ソフトウェアテストの目的や対象ごとに複数のテストケースをまとめたもの)があると、コードを変更する恐怖がなくなります。
コードをクリーンにする恐怖がなくなるため、コードをクリーンにするようになります。
システムを整理して秩序を維持できるようになり、システムの設計を損なうことがなくなります。
リファクタリング
リファクタリングは、すべての作成物の継続的な改善と改良を促進します。
リファクタリングによって振る舞いを変更することなく、システムの構造を改善します。
シンプルな設計
シンプルな設計、チームがムダなことをしないようにガイドするためのプラクティスです。
必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持します。
設計のウェイト
設計が複雑になれば、プログラマーにかかる認知的負荷は大きくなります。この認知的負荷が設計のウェイトで、設計のウェイトが増えるほどシステムを理解したり操作するために必要な時間や労力が増えます。
シンプルな設計のゴールは、設計と機能の複雑さのバランスをとることであり、要求とのバランスを保ちながら、継続的にシステムの設計をリファクタリングしていきます。
ペアリング
ペアリングは、革新性と正確性を促進するレベルで、技術チームが知識の共有、レビュー、協力ができるようになるためのプラクティスです。
ペアになるプログラマーは異なる役割を担当します。ひとりがドライバーで、もうひとりがナビゲーターです。
ドライバーはキーボードとマウスを持ち、ナビゲーターは俯瞰的な視点でドライバーにアドバイスします。
ペアになるのは一般的に短時間で、多くの場合は1〜2時間以上は続かないです。