ガイドライン: 反復計画書
トピック
方向付けフェーズにおいては、多くの場合、最大のリスクはビジネス面のリスクまたは技術面のリスクです。初期の主要なビジネス面のリスクは通常、プロジェクトへの資金提供を確保することです。したがって、多くの場合、概念の証明のプロトタイプが方向付けフェーズの結果となります。概念の証明のプロトタイプは主要な機能またはなんらかの基本的な技術を実地に示します。
新製品の最初の反復が通常は最も困難です。最初の反復では、ソフトウェアを産出することのほかに、達成すべき新しい事項がたくさんあります。たとえば、プロセスを導入すること、チームを編成すること、新しいドメインを理解すること、新しいツールに慣れることなどが挙げられます。アーキテクチャにどれだけ肉付けできているか、または達成できる使用可能な機能の程度については、期待を控えめに抑えるようにします。目標を高く掲げると、最初の反復の完了が遅れ、合計反復回数が少なくなり、したがって反復アプローチの利点を減少させるリスクがあります。最初の反復では、適正なアーキテクチャを得ることに焦点を絞るべきです。したがって、初期の反復の計画プロセスにソフトウェア アーキテクチャを含めておく必要があります。
推敲フェーズにおいては、安定的なアーキテクチャを定義すること、システムの基本的な振る舞いを設計し実装すること、一連のアーキテクチャ プロトタイプを通じて技術的アーキテクチャの課題を探求することに焦点を当てます。「アーキテクチャ的に重要な」シナリオは、システムのアーキテクチャを決まった方法で実行するサブフローです。
推敲フェーズの終了近く、および作成フェーズと移行フェーズの間に、変更依頼 (ソフトウェア変更依頼 (SCO) とも呼ばれます) が反復プロセスを動かし始めます。SCO の結果として、下記の事項が生じます。
- 拡張要求
- 範囲が個々のパッケージまたはクラスを超える変更依頼
- 反復の範囲および目的の変更
- 要求のベースラインの変更を提案する、または受け入れられた要求のベースラインの変更に対応する、要求の変更
これらの SCO を既存のプロジェクト計画、反復計画、およびリスクリストに照らしてバランスを検討します。SCO が原因で、要求の優先度を再評価したり、リスクの優先度を付け直したりする必要が生じます。ただし、プロジェクトの管理が損なわれないように、SCO を注意深く管理する必要があります。
作成フェーズおよび移行フェーズの間に、アーキテクチャに肉付けし、残っている要求をすべて実装することに焦点を当てます。
ウォーターフォール型のモデルでは、システム全体を一度で検討します。それと異なり、各反復期間ではシステムの機能の一部だけを検討します。各反復期間中に、システム全体のサブセットを分析し、設計し、実装します。サブセットの範囲およびどこまで掘り下げるかの選択は、以降の反復におけるリスクを減らす上できわめて重要です。そのための基本的な戦略は 2 つあります。具体的には、「広く浅く」と「狭く深く」です。
すべてのユース ケースを定義し、その大部分を詳細に肉付けして、手元の問題を明確に理解します。アーキテクチャも広範に定義し、アーキテクチャのコンポーネントによって提供される仕組みとサービスを定義し、サブシステム間のインターフェイスを定義します。しかし、内部的には相当のリスクまたは不確実性に対処する必要がある部分についてのみ詳細に検討します。実装は作成フェーズまでほとんど行いません。作成フェーズに入ってから、大部分の反復を実施します。
広く浅く戦略は下記の場合に適します。
- チームが、問題領域または技術分野のいずれかで (方法論またはプロセスも含めて)、経験不足の場合。
- 将来能力を発揮するためには健全なアーキテクチャを築くことが重要な要求であり、しかもアーキテクチャに先例がない場合。
ただし、この戦略には下記のような潜在的な欠点があります。
- チームは分析麻痺 (設計が完全でないと何も実装できないという、非論理的な考え) に陥る可能性があります。
- 自信と信用を築くために、多くの場合、早い段階で結果を出す必要があります。何か実行可能なものを産出しない期間が長くなればなるほど、チームは成果物を産出する自分達の能力に自信を失います。
- 技術的に十分掘り下げずに難しいアーキテクチャに挑戦することは、真の技術的なリスクにさらされる感じを受けます。
狭く深く戦略では、問題領域のスライスを徹底的に分析します。その細いスライスに関連するユース ケースを定義し、その大部分を詳細に肉付けして、手元の問題を明確に理解します。望ましい振る舞いをサポートするために必要なアーキテクチャを定義して、システムを設計し実装します。以降の反復では、別の縦のスライスに焦点を当てて、分析し、設計し、実装します。
狭く深く戦略は下記の場合に適します。
- 主要なリスクを克服するため、サポートを獲得するため、または有効性を証明するために、早い段階で結果を明示する必要がある場合。
- 要求が絶えず発展しているため、すべての要求を完全に定義してから詳細設計および実装の作業を開始するのが困難な場合。
- 締切を厳守するために、早期に開発を開始することが納入成功の鍵となる場合。
- 再利用可能度が高く、段階的な納入が大きく可能な場合。
この戦略には下記の欠点があります。
- この戦略をとると、各反復ごとに垂直的には統合されているが、水平的には互換性がないソフトウェアが開発される傾向があります。ときには、このことはストーブパイプ症候群と呼ばれることがあります。それらのソフトウェアを 1 つのシステムに統合することは困難です。
- まったく新しい問題領域に属するシステムまたは先例のないアーキテクチャに基づいたシステムを開発するには、この方法は適していません。なぜなら、そのようなシステムを開発 するためには、バランスの取れたアーキテクチャを実現するために、システムの機能の多くをサンプルとして取り上げる必要があるからです。
一般に、初期の反復は広く浅い色彩を帯びる傾向が強く、(既に安定したアーキテクチャが開発されている) 後期の反復は狭く深く戦略に従う傾向があります。
最初の反復が通常は最も困難です。なぜなら、開発環境全体が必要ですし、プロジェクト チームも多く揃っている必要があるからです。最初の反復では、ツールを統合しチームを編成することが、複雑さに輪をかける要因となります。アーキテクチャ的な課題に焦点を合わせると、神経を集中し、早い段階でチームが詳細な泥沼にはまり込んでしまうことを避けるために役立ちます。
- 方向づけに使用される狭く深く戦略
プロジェクトの基本的な実行可能性には、新技術の探索が不可欠です。多くの e-ビジネス プロジェクトでは、従来行ってきたよりもさらに深く探索する新技術を必要としています。概念の証明プロトタイプは今だに「使い捨て」と見なされており、探索の対象となるのはプロジェクト概念の実行可能性のみに限られます。
- 方向づけに使用される広く浅く戦略
この戦略は、システムの範囲を理解するため、およびシステムの機能性を試してアーキテクチャが希望の能力を提供できることを確認するためのものです。
- 推敲に使用される広く浅く戦略
このアプローチは、特定の技術的リスクに狭く深く焦点を当てながら健全なアーキテクチャを開発するのに役立ちます。健全なアーキテクチャが確立すれば、作成では再び狭く深く焦点を当てることができ、機能性を統合しながら少しずつ開発して提供できます。
- 作成に使用される狭く深く戦略
作成の反復は常に狭く深く行い、必要とされる機能性の開発および提供と同時に進行します。
新しいチームは通常、当初は自分達が達成できることに楽観的すぎることが多いようです。それに対処するため、そして実際の結果が楽観的な期待に達しなかったときにモラル上の問題が発生することを避けるために、最初の反復期間に達成できる機能の量を控えめに見積もるようにします。達成感を得て、プロジェクトに弾みをつけて、経験を積み重ねるようにします。
開発環境と開発方法の両方またはどちらか一方がチームにとって新しいものである場合、最初の反復期間で取り上げる機能の数を最低に絞ります。環境を統合し調整すること、および使用するツールに習熟することに、焦点を絞ります。
作業をやり直すことは、ある程度まではよいことです。反復開発の主要な利点の 1 つは、過ちを犯すことや実験を許しますが、それを早い段階で行って、修正措置を取れるようにすることです。しかし、特に技術者は、ある反復期間と次の反復期間との間で、完璧を期して再作業を繰り返す傾向があります。
各反復期間の終わりの、反復評価の間に、現在のリリースのどの部分をやり直すかを、チームは決定する必要があります。各フェーズにおける予想される再作業率を下に示します。この率はシステム全体に対する数字です。
- 方向付けフェーズでは 40 ~ 100%です。この段階では、実験的なプロジェクトチームを開発して、使い捨てにすることがあり得ます。
- 推敲フェーズでは、初期の反復期間においては 25 ~ 60%、後期の反復期間または評価サイクルにおいては 25% です。
- 作成フェーズでは、アーキテクチャをベースライン化した後では反復期間あたり 10% 以下、全体で 25% です。
- 移行フェーズでは 5% 未満です。
作業のやり直しが発生することは避けられません。誰も作業のやり直しが必要であると感じないときは、疑問を持つ必要があります。その原因として、下記の事項が考えられます。
- スケジュールが厳しすぎる。
- 真のテストまたは評価が欠けている。
- 動機が欠けているか、または焦点がぼけている。
- 再作業は悪いことである、リソースの無駄遣いである、無能力または失敗を認めることである、といった否定的な考えを抱いている。
再作業が多すぎることは危険シグナルです。それは、完璧を期しすぎているのかもしれないし、要求の変更が異常に多いのかもしれません。再作業の必要性を評価するために、開発企画書に照らしてチェックする必要があります。 反復管理に関しては時間枠に基づいた手法を採用していることから、前回の反復とは別の範囲の作業については、「再作業」の範疇に含めていないことに注意してください。この別の範囲の作業についてはプロジェクト管理者が、次回の反復の内容を定義するための機能群の中に含めておく必要があります。当然のことですが、そのような作業には高い優先度を付けるのが普通です。前回の反復において計画した目標を達成できなかった原因を突き止め十分に考慮することも、プロジェクト管理者に要求されます。たとえば、慢性的に要員不足のプロジェクトを運営している場合、スケジュールを死守するためにいい加減にスタッフを増員することは推奨できません。また、反復のたびに意気込みすぎた計画を立てるのも思慮に欠けていると言えます。このような対処をとると、通常はチームの士気を損ない顧客の怒りを買う結果になります。この問題に対処するには、適切なバランスを見い出す必要があります。また、COCOMO II ([BOE00] を参照) のような評価モデルも役立つ場合があります。プロジェクトは反復のたびに、生産性および品質の面での達成履歴を作成します。次回の反復を計画する際には、前回の反復で達成した内容がプロジェクト管理者にとって確固とした指標となります。
最初の反復が完了したら、チーム リーダーはそれをプロジェクト マネージャと共に作業レベルで作業計画に改良することができます。付属の Microsoft® Project テンプレート (作業レベル) は、これがどのように行われるのかを示します。これらの作業計画は反復計画から引き出されたものですが、これらは別個に生成された独立した成果物ではないことに留意してください。プロジェクト マネージャが制御し続ける場合は、作業計画をロールアップしてプロジェクト マネージャの反復計画の状態を示せることが重要です。
|