アジャイルの主な実践手法とその取捨選択
第1回ではアジャイル開発の理念や位置付け、特徴について紹介しました。アジャイル開発にはより良いソフトウェアを低コストで、かつ高品質に開発できる大きなポテンシャルが秘められていると感じたことでしょう。今回は、アジャイル開発の代表的な手法「XP」と「スクラム」の特徴を紹介し、これらの手法を実際の開発現場にどのように適用していくのかを示します。
アジャイル開発の代表的手法
アジャイル開発には、さまざまな手法があります。
- XP
- スクラム
- 動的システム開発手法（DSDM：Dynamic Systems Development Method）
- クリスタル
- 機能駆動型開発（FDD：Feature Driven Development）
- アジャイルユニファイドプロセス（AUP：Agile Unified Process）
- リーンソフトウェア開発
このように数え上げればきりがないほどですが、この中で人気を二分しているのが「XP」と「スクラム」です。今回はこの2つの手法について解説します。
XP～開発メンバー個々の責任を重視～
XPはExtreme Programmingの略で、通常は「エックスピー」とそのまま読みます。この手法は1996年頃にケント・ベックらにより考案されました。XPは開発主体に内容を定義しており、比較的少人数での開発に向いていると言われています。
XPでは10個程度の具体的なプラクティス（実践）を定義し、ドキュメントの整備よりもソースコードを重んじると共に、開発者1人1人の責任を重視しています。以下に代表的なプラクティスを示します。
- 反復
- テスト駆動型開発
- ペアプログラミング
- リファクタリング
- ソースコードの共同所有
- 継続した結合
- YAGNI
- ストーリーの作成
- リリース計画
- 受け入れテスト
開発期間を1～4週間の短い期間（イテレーション）に区切り、期間ごとに部分的な設計／実装／テストを行ない、半完成システムのリリースを繰り返す。
Test Driven Development（TDD）とも呼ばれる。プログラムロジックをコーディングする前に、（自動化された）テストを作成する。プログラムロジックのコーディングは、そのテストをパスすることを目標に行なう。
2人1組で実装を行ない、1人がコードを書き、もう1人はそれをチェックしながらナビゲートする。
完成済みコードでも、随時改善する。外部から見た動作は変更しない。
ソースコードをチーム全員が断りなく修正できる。
単体テストをパスするコードが完成するたび、すぐに結合テストを行なう。
「You Aren't Going to Need It」の略。いま必要なことだけを行なう。必要な機能だけのシンプルな実装に止める。
求める機能のコンセプトを短い文章で記し、より詳細な仕様をチームミーティングを通して決定する。
どのストーリーをどの反復で実現するか、チームミーティングで決定する。
反復ごとに機能やコンセプトが実現できているかを確認する。
これらのプラクティスに従った開発の全体像は図1のとおりです。
特に注目すべきは、開発全体を細かい反復（イテレーション）に分割し、その期間中に開発～テストまでを完了させる（テスト駆動型開発）ことにあります。また、必要な機能だけを実装し（YAGNI）、随時改良を施していく（リファクタリング）ことを認めている点です。さらに、ソースコードを書くにあたっては、誰もがソースコードを作成／改造して良く（ソースコードの共同所有）、必ず2人1組で実施していく（ペアプログラミング）ことが重要です。
