アジャイル開発プロセスの手順
開発プロセス
業務の整理（アクセシビティによるビジネスプロセス分析）
機能の洗い出し（ユースケースの洗い出し）
シナリオの作成（ストーリーのブレイクダウン）
TDDによる開発
- To-Doリストの作成
- テストコードの作成
- まずは赤でエラー
- ターゲットの作成
- 緑にリファクタリング
業務の整理
アジャイル開発では、ストーリーという単位でソフトウェアの要件を決めていく。
まず、
- 顧客が求める機能をストーリーカードに書いていく。
- そのストーリーに対して、エンジニアが工数を見積もり、開発を進めていく。
要件をだすためには、
業務フローを考えて、業務を整理した上で、そこに必要な機能を考えていく。
UMLのアクティビティ図を作成したりして、業務フローを書く。 ユーザーなどのエンジニアでない人でも、理解が用意にできるように。
機能の洗い出し（ユースケースの洗い出し）
ソフトウェアはユーザーが使うもの。
業務のどこかでアクティビティがコンピュータ化されたもの。
アクティビティの中からアクションという動作から機能が起動される。
UMLではこの機能のことを「ユースケース」と呼ぶ。
ユースケースの説明
ユースケースとは、システムが外部に提供する機能です。
システムのユーザーが認識できるレベルの機能であり、システム内部の詳細な機能は表現しない。
機能の詳細
ユースケースやストーリーは、あくまで概要程度のことしか書かないので、
内容を把握するために詳細を記述する必要がある。
高速アジャイル開発では、顧客から詳細を聞いて、ドキュメントとして残しません。
大規模な開発にも対応するには、ユースケース記述を記述する。
ユースケース記述では、機能の詳細だけではなく、この機能が使われる条件等も書いていきます。
とりあえず、簡素な書き方でもOK。
シナリオからテストへ
シナリオからアジャイル開発プロセスのテスト駆動開発へとつなげていく。
テスト駆動開発とは、
テストを先に書いて、その後にターゲットのコードを書いていく手法。
テストを書きながらインターフェースを確定していき、内部構造は後から設計していく。
設計と同時にコーディングをしていくので、設計書などは残さずに、プログラムコードだけが成果物になるのがほとんど。
TDDは、
テストをはじめに作成し、それをもとにプログラムを設計し開発すること。
このテストは、あくまでソフトウェア開発のためのテストで、品質やパフォーマンスを検証する目的ではない。
従来はプログラムを先に作成した後に、テストを行いプログラムの検証をしていた。 現在主流になっているTDDでは、実際のプログラムコードより先にテストコードを作成する。この方法を「テストファースト」と呼ぶ。
テストを作成するということは、はじめにインターフェースを考えることになる。
呼び出すオブジェクトへのインターフェースを、テストを通じて設計する。
その後で、インターフェースの先のオブジェクトの構造を実装していく。
テストと実際のターゲットクラスのコードの両方が同時に作成され、テストコードは常に実行されます。このことで、バグのないコードを保ちつつ、ソフトウェアを開発していく。
