最善の実践原則: ソフトウェアを反復的に開発すべし
リスクを軽減するには、反復的な方法で段階的にソフトウェアを開発します。それぞれの反復で、実行可能なリリースを作成します。
トピック
反復的な開発手法を使用するプロジェクトには、複数の反復で構成されるライフサイクルがあります。1 つの反復は、開発サイクルのどの段階に反復があるかに応じて、ビジネス モデリング、要求、分析と設計、実装、テスト、導入をさまざまな割合で並べた、一連の作業で構成します。方向づけフェーズと推敲フェースの反復は、管理、要求、設計作業に重点を置きます。作成フェーズの反復は、実装とテストに重点を置きます。移行フェーズの反復は、テストと導入に重点を置きます。反復は、時間枠に基づいた手法で管理する必要があります。この手法では、反復のスケジュールは固定であると見なし、反復の内容の範囲をそのスケジュールに合うように積極的に管理する必要があります。
初期の設計では、重要な要求に欠陥が含まれることがよくあります。設計上の欠陥の発見が遅れると、コストが超過してプロジェクトが中止に追い込まれることもあります。
すべてのプロジェクトに複数のリスクが存在します。ライフサイクルの初期段階は、リスクを回避したことを検証し、計画の精度をより高めることができます。それでもシステムを統合するまでは、多くのリスクが発見されません。どんなに経験を積んだ開発チームでも、すべてのリスクを予測することはできません。

ウォーターフォール型のライフサイクルでは、ライフサイクルの終盤になるまでリスクのない状態を保っているかどうかを検証することはできません。

反復型のライフサイクルでは、主要なリスクのリストに基づいて、1 つの反復で開発する追加分の要素を選択します。反復ではテスト済みの実行可能ファイルを作成するため、目的のリスクが軽減されたかどうかを検証することができます。
次のさまざまな理由から、一般的に反復型の手法はリニア型またはウォーターフォール型の手法に比べて優れています。
- 要素が段階的に統合されるため、早期にリスクが軽減される。
- 要求と戦術の変更に対応できる。
- 製品の改良と洗練化が促進され、より堅牢な製品になる。
- 組織はこの手法から学んでプロセスを改良できる。
- 再利用性が向上する。
ある顧客はかつて、「ウォーターフォール型の手法を使用すると、プロジェクトの終盤が近づくまで、ときには統合の途中まではすべてが順調に見える。そしてすべてが破綻する。反復型の手法を使用すると、長期にわたって実状を隠すことは非常に困難である。」と述べています。
プロジェクト管理者は、反復型の手法を終わりのない作業と見なして採用を拒むことがよくあります。Rational Unified Process では、反復型の手法は十分に管理され、回数、期間、目的に応じて反復を計画します。参加者の作業と責務を定義します。客観的な進捗度を把握します。1 つの反復から次の反復で同じ作業のいくつかを再度実行しますが、これも十分に管理されています。
反復型の手法を使用すると早期にリスクを軽減することができます。これは、統合の段階でのみ多くのリスクが指摘され発見されるためです。初期の反復を実行する際にすべての作業分野を実施して、ツール、市販ソフトウェア、要員のスキルなど、プロジェクトのさまざまな側面を経験します。リスクだと思われていたものがリスクではないとわかることもあれば、新たに予想外のリスクが発見されることもあります。
統合は最後の 1 つの「大掛かりな作業」ではなく、要素を段階的に組み込みます。実際に、反復型の手法では継続的に統合を実行します。従来は長くて不明確で困難な期間で (プロジェクト終了までの作業全体の 40% を占める)、正確な計画の立案が困難であったものを、最初は統合する要素がはるかに少ない 6 つから 9 つの小さい統合に分割します。
反復型の手法を使用すると、要求は作業の進展に伴って通常は変化するものであるとして、その変更を考慮に入れることができます。
要求が変化したり要求が「揺れ動いたり」することは、常に、プロジェクトのトラブルの最大の原因であり、納品の遅れ、スケジュールの狂い、顧客の不満、開発者の欲求不満などをもたらしてきました。25 年前、Fred Brooks 氏は「目的が 1 つの計画でも、方法はいくつもある」と述べています。ユーザーの意向は常に変化します。これは人間の本質です。最初に描いたシステムを受け入れるようにユーザーに強要するのは正しくありません。状況が変わればユーザーの意向も変わります。ユーザーは環境と技術についてより多くを学び、開発中の製品の中間段階のデモンストレーションを見ます。
反復型のライフサイクルでは、製品に対して戦術的な変更を行う方法として管理を実行できます。たとえば、既存製品との競合で、機能を削った製品を早い段階でリリースすることによって競争相手の動きを抑えたり、特定の技術に別のベンダーを採用したりすることがあります。
反復型の手法では、作業を進めながら技術的な変更を行うこともできます。いくつかの技術が変わったり、新しい技術が標準になった場合、プロジェクトでそれを利用することができます。これは、プラットフォームが変わったり、基本部分の環境が変わった場合特に有効です。
反復型の手法を採用すると、何回もの反復を経てエラーが修正されるので、より堅牢なアーキテクチャができあがります。早期の反復期間に製品が完成すると、欠陥が早く発見されます。性能上のボトルネックは、納品の直前ではなく、早期に発見して解消することができます。
反復的な開発を行うと、プロジェクトの最終段階で 1 回テストを実行する場合に比べ、より入念にテストされた製品が完成します。複数の反復にわたって重要な機能が何度もテストされ、テスト方法そのものとすべてのテスト対象ソフトウェアを時間をかけて完成させることができます。
開発者は作業を進めながら学習することが可能で、さまざまな能力や専門性をライフサイクル全体を通していっそう完全に発揮できます。
計画を立てたりスキルが向上するまで長期間待つのではなく、テスト担当者は早くからテストを行い、テクニカル ライターは早くから文書の作成を開始します。追加のトレーニングまたは外部からの支援が必要な場合は、初期の反復における評価レビューで見つけることができます。
プロセス自体も、開発を進めながら改善したり洗練させたりすることができます。反復の最後に行う評価では、製品やスケジュールの面からプロジェクトの状況を調べるだけでなく、次の反復に活かすために組織やプロセスで変更が必要な点を分析します。
反復的なライフサイクルでは再利用が促進されます。事前にすべての共通点を識別する必要がある場合に比べ、部分的な設計または実装を行うと共通部分を容易に識別できます。
再利用可能な部分を識別して開発する作業は、簡単ではありません。初期の反復で設計レビューを行うことにより、ソフトウェア アーキテクトは予想外の潜在的な再利用性を識別し、以降の反復でさらに開発を進めて共通のコードの完成度を向上させることができます。
反復型の手法を使用すると、市販の製品を容易に活用することができます。複数の反復期間にこれらの製品を選択して統合し、アーキテクチャに適合するかどうかを確認することができます。
|