ガイドライン: プロセスのカスタマイズ
トピック
RUP (Rational Unified Process) で多数の成果物、作業、役割を並べ替える場合、以下のような疑問が浮かんでくることがあります。
- これは私にとって必要だろうか
- 自分のプロジェクトに必要なものを選別するには、どのように並べ替えたらいいだろうか
- RUP は当然ながら大規模なプロジェクト専用なのではないだろうか
これらの疑問点はすべて、カスタマイズのトピックに取り上げています。
ソフトウェア プロジェクトの目的は、製品を生産することです。良いプロセスとは、株主のニーズに合う製品をタイミング良く予算内で生産できるプロジェクトを実現するものです。
あるプロセスを良いプロセスとするための鍵は、最善の実践原則の手法に基づき、プロセスをできる限りシンプルにカスタマイズすることです。
ここには、プロセスのカスタマイズにおいて考慮すべきガイドラインを示します。より詳細なガイドラインは、「 概念: RUP のカスタマイズ」と「作業: プロジェクトのプロセスのカスタマイズ」を参照してください。
多くのプロジェクトに共通する問題としては、質の高い製品を生産するためのプロセスのライフサイクル全体に含まれる「重要」な要素が分からないままに、ある特定の分野ばかりに力を注ぎ、その些細な事柄にこだわりすぎるということが挙げられます。
通常、あるプロセスのすべての主要要素にバランス良く適度な力量で対応し、その後特定の問題領域を集中的に処理するほうが良い方策と言えます。
質の高いソフトウェア プロセスのためのフレームワークが作成済みのプロジェクトでは、一番問題があると識別された特定領域に効率良く力を入れることができます。問題領域は、プロジェクトのリスクを特定し、それを重要な順に整理し、この特定されたリスクに対する初期緩和戦略を決定するという方法に基づいて選択されます。
はっきりとは正当化できない作業や成果物を含めない
熱意あるプロジェクト マネージャや、プロセス エンジニアであれば、あると便利なメトリクス、コントロール、レポートなど、欲しい物をたくさんリストすることもできます。しかし、作業と成果物には時間と費用がかかるものです。これらの費用の中には、環境ツールセットとの毎日の相互作用などのように、目に見えるものも見えないものもありますが、標準的なタスクにとっては単に生産性を低下させるだけのものです。
希望リストの中から重大なニーズのあるプロセスだけを選別し、それがもたらす利益がコストを上回るかどうかを判断する必要があります。
開発者をプロセスから外す
設計、実装、テストなどの優れた技術を持つ、高度な教育を受けたスタッフがいるかもしれません。そういうスタッフに、フォームの穴埋めや、ドキュメントの文章の誇張、あるいは扱いにくいツールとの戦いで毎週何時間も時間を費やさせないでください。このような作業が必要なのであれば、有資格のサポート スタッフに任せることを検 討すべきです。
中間成果物の正式化は最小限に
中間の成果物の形式 (最終製品ではない成果物) は、それを生産するために必要な作業や考え方ほど重要ではありません。それらの目的さえ果たすならば、その見栄えや、作成に使用されたツールは何でもいいのです。Dwight D. Eisenhower が述べているように、「計画そのものは意味がない。計画の立て方がすべて」なのです。
陥りやすい落とし穴は、成果物の正式化を急ぎすぎることです。初期バージョン成果物は多くの場合急速に発展します。また、しばらくは流動的でさまざまに異なった表現を持ち、意味合いも変化します。正式に文書化すると、このプロセスの妨げになる可能性もあります。消耗品にとどまる可能性のあるモデルの改良に時間をかけることは、無意味です。初期の成果物では、手書きのダイアグラムと、簡単な説明を書きつけた索引 カードで十分である場合が多く、プロジェクトによってはそれだけで済むこともあります。
成果物をカスタマイズし、あらゆる形式で保持できるようにできます。たとえば、Vision のドキュメントを Web ページとして保存したり、Project Plan を Microsoft Project ファイルとして保存したり、Risk List を Rational RequisitePro に必要なタイプとして保存できます。
可能な限り一般化する
プロジェクトの中には、正式文書のテンプレートを配布するために、情報を手作業で切り貼りすることに多大な労力を費やしているものもあります。しかし、その代わりに、Rational SoDA などのツールを使用して必要なドキュメントをそのソースから生成することを検討してください。または、同じ情報をより単純な方法で提供できないか、たとえば Rational Rose Publisher に Web ベースの設計モデルを生成できないかなどと交渉してみることも検討してください。
多くの場合、その環境では暗黙のうちに情報が提供されるので、成果物をまとめて省略できます。たとえば、要件タイプをリストする Requirements Management Plan のセクションを生成するのではなく、該当する要件タイプと追跡可能性だけを記載するようにカスタマイズされた Rational RequisitePro プロジェクトだけを入手し、それに興味を持つ第三者に提示して見せることもできます。またたとえば、利害関係者に、別個のソフトウェア開発計画に画像をコピーせずに、Microsoft Project ファイルの読み取り専用ファイルを提供することもできます。
Web の利用
使いやすい成果物とは、価値のある情報を伝えてくれるものです。この情報は、それを必要とする人がすぐに利用できなければなりません。Web の技術は、この目的には最適です。要件、設計、実装を Web 上で公開できれば、すぐに旧式化してしまう紙の文書を無数に作成する必要もありません。
統合ツールの利用
プロセスに適したツールを選択し、またプロセスをカスタマイズしてツールに合うようにします。そして、使いやすいプロセスとツールセットができれば理想的です。通常、統合ツールは一貫性が高く、未統合のツールに比べ、メトリクスやレポートがより情報に富んでいます。
プロセスを定期的に点検、調整し、複雑さをできるだけ排除するようにします。プロセスの各ステップが最終製品に付加価値をもたらしているということをスタッフが確信していないなら、そのプロセスは機能していない可能性があります。
最善の実践原則を守ったカスタマイズ
RUP は、カスタマイズを奨励しています。ただし、カスタマイズはプロセスをまとめて省略するための免許ではありません。RUP の本質は、そのベスト プラクティスに体現されています。作業や成果物をニーズに合わせてカスタマイズする際には、最善の実践原則の精神を尊重してください。
|