リスクベースのソフトウェア製品開発管理

この記事は、ソフトウェア開発に携わる人向けに書かれています。 開発プロセスの管理の原則を理解することは、プログラミングテクノロジーの実際の知識と同じくらい重要です。 この記事は、プロジェクトマネージャー（プロジェクトマネージャー）になりたい、またはプロジェクトマネージャーとして仕事をしたい人だけを対象にしているわけではありません。



管理手法自体に進む前に、プロジェクトチームで自分がどのように振る舞うかを理解することは悪くありません。 チーム関係のいくつかの基本原則を説明します。

•嘘をつかないでください。 真実を伝えるのがとても怖い場合でも。 彼女はまだ欺ceptionよりも優れているからです。 真実は適切な知覚のために「服を着せ」られなければならず、正しい瞬間を探さなければならないが、嘘をつくことはできない。 とにかく、真実が明らかになり、被害が大きくなります。

•同僚を理解しようとします。 それがあなたの上司、部下、従業員、顧客のいずれであっても、彼の代わりに立ち、あなたが彼の代わりに何をしたいかを理解すると、多くの質問が自動的に消えます。

•寛容になりますが、容赦しないでください。 誰でも間違いを犯す権利がありますが、自信を乱用することはできません。

•ペットや追放者を作らないでください。 すべてのチームメンバーに対する態度の基準は、権限の基礎です。

•行動が目立たなくなるほど、注意を払う必要があります。誓ったり、オフィスを走り回ったり、大声で話したりしないでください。 イギリス人は紳士は笑わず、笑うと言っています。



あなたはほぼ完璧な従業員になったので、考えてみましょう-顧客は何を必要とし、お金を払うのですか？ 彼はおそらくお金を返し、さらには利益を得たいと思っています。 彼にとって最も不快な言葉-私たちには時間がなく、成功しませんでした、彼らは間違った要求を与えました...そして彼が彼のお金のために望んでいたものを与えない他の何か。 これらはすべて、投資損失のリスクという1つのコンセプトと組み合わせることができます。 そのため、リスクの観点からさまざまな開発管理手法を検討します。 開発プロセス中に予期しない状況に遭遇することを保証して言うことができますが、あなたの都合ではありません。 それらはリスクです。 可能性のある不快な状況を事前に分析して示唆しようとしない場合、プロジェクトの救助と「予期しない驚き」からの保護の状況に常にいる必要があります。 たとえば、ハードディスクがすぐに読み取りを停止したときの痛みを伴う馴染みのあるケースを引用できます...そして悲しいことに、バックアップコピーは... また、リスクは必ずしも顧客のお金の損失ではないことを覚えておく必要がありますが、多くの場合、他の負の影響は信頼の喪失、将来の注文、またはプロモーションの可能性です。

ただし、リスクを明確に否定的なものとして扱わないでください。 多くの場合、迷惑が発生し、私たちは動員し、標準外の解決策を見つけ、対象分野をすばやく習得し、確実に解決策を覚えて将来の保護を開発することができます。 リスクがなければ、人生は退屈です。

ただし、リスク自体が同じタイプであったとしても、1つのプロジェクト管理方法論はありません。 理想的なプログラミング言語、オペレーティングシステム、テストツールなどがないのと同様に、プロジェクト管理方法論の開発もプロジェクトです。 ここでは、次の入力要素が重要です。

•顧客の頭の中でのプロジェクトの準備の程度、およびそれに応じて開発する必要があるものを説明する資料の入手可能性。 ここで、タスクを説明するドキュメント自体が変更される場合、外部環境によるプロジェクトの変更の影響も考慮する必要があります。 たとえば、オペレーティングシステムのバージョンが変更されました。

•開発チームの特徴。 専門的なスキルだけでなく、チームワーク、批判への準備、個人的な不便さの面でも。

•プロジェクトの時間とリソース（人）の規模。

•必要な製品の信頼性と正しい実装方法



最初に、顧客でプロジェクトがどの程度形成されているかを理解する必要があります。

•要求された製品を正確に把握する。 たとえば、標準で説明されている通信プロトコルを開発する場合。

•または、顧客がプロジェクトの大まかな考えを持っている。 たとえば、指定されたオプションとパラメーターを使用してインターネット上で検索システムを開発する場合。 ただし、開発プロセス中に、基準とそれらの相互の関係が変わる可能性があることは明らかです。

•顧客は非常に一般的な考えを持っているかもしれません。 たとえば、クライアントには、企業内のコミュニケーションを目的とした「オールインワン」のようなユニファイドコミュニケーションシステムがあります。 そして今、タスクは追加の「バン」を開発することです。 多くのオプションのリストがありますが、クライアントは、何がより良く、最初に開発するのがより有益で、次に何が良いかをまだ知りません。 そして、彼にとってより有益です-この関係は興味深い/高価です。



リスク分析に基づいた開発管理は、プロジェクトの実施プロセスにおけるネガティブなイベントを積極的に特定するための一連のアクション、およびそれらからのプロジェクトへの害を最小限に抑えるための手順として定義されています。 人が病気にならないようにすることは不可能であるように、リスクに関連する損失を完全に取り除くことは不可能であることに留意してください。 しかし、最も重要でコストのかかるリスクを特定し、それらに備えて、発生を制御することができます。

統計によると、時間内に予算内で完了するのはソフトウェアプロジェクトの28％のみで、完了前に開発の23％がキャンセルされ、プロジェクトの半分が予算を50％超えています。 最初に起こりうる問題について考え、開発プロセス中の「緊急」状況の発生に目をつぶらなければ、プロジェクトの終わりにはるかにリラックスした生活が得られます。

リスク管理には、アクションの2つのグループと再考のポイント（変更の決定-デザイン）が含まれます。 最初のグループはリスク評価で、2番目はリスク管理です。

リスク評価には、リスクの特定、分析、優先順位付けが含まれます。 リスク管理には、リスクの計画、対応、監視が含まれます。

リスクの特定。

この部分では、チームまたはそのリーダーは、実装中にプロジェクトを待っているすべての考えられるトラブルのリストを作成する必要があります。 リスクは、社会的リスクと技術的リスクに分類できます。 社会的リスクには、技術に直接関係しないすべてのリスクが含まれます。 たとえば、主要な専門家（病気、解雇）の損失、一時的な電気の停止、インターネット、プロジェクト要件の変更など。技術的リスクには、誰の過失に関係なく、タスクの不正確な完了によって生じる可能性のあるすべての側面が含まれます。 これは、誤って作成されたタスク、不便なフレームワーク、モジュール間の一貫性のないインターフェイスなどです。

リスクのリストには以下を含める必要があります。

•リスクの発生条件とその説明

•早期検出の症状（可能な場合）

•リスクの影響を受けるもの（時間、お金、評判）

•リスクがイベントになり、対処できない場合はどうなりますか

分析

リスクのリストが用意できたら、それらの分析に進みます。 各リスクについて、以下が特定されます。

発生する可能性と実行された損害の重大度。 両方の特性は、「小」から「大」までの約4つの値から量子化されます。 確率評価は、ブレインストーミングとしてチームで実行されます。 リスクの可能性を評価するには多くの方法があります。 それらのいくつかをここにあげます：

•類似プロジェクトの歴史との比較に基づく

•ポーカーメソッド。各参加者がひそかにマークを付け、結果を比較します。 これらは、最も頻繁に取得される推定値または算術平均のいずれかを基準として使用します。

•小グループの各リスクを評価し、チーム全体に提示するためのグループ方式。

•「悪魔の擁護者」メソッド。 リスクはチームによって分類され、誰もが最悪の方法でそれを説明しようとしています。 最終的に、リスクの「交渉」を調整して、可能性が低くなる可能性を特定できます。

各リスクについて理解できる値に達するまで、それぞれの方法が数回繰り返されます。

議論の結果、同様のコンテンツの表が表示されるはずです

優先順位	リスクの説明	症状	確率	害	レベルだった	対抗

このようなテーブルにはポイントが多すぎてはならず、プロジェクト参加者の数は1〜2でなければなりません。 したがって、グループに5人の人がいる場合、10を超えるリスクがあることは意味がありません。 20人以上のグループでは、リスクをグループに分ける必要があり、集団評価は従業員の総数を超えてはなりません。

優先順位付け

リスクは順番に並べられます-最も重要なものが最初です。 優先度は次の式で計算されます（この場合、評価の次元を計算するシステムで4）：

優先度=確率x害

計画中

リスクごとに個別に計画を立てる必要があります。 この表には、接近するイベントを示す可能性のあるリスクの症状もリストされています。

対抗

リスクイベントから保護するには、回避と保護の2つのアプローチがあります。 ショックに対する反応の完全な類推。 それを回避するか、保護することができます。 ただし、保護には代償が伴います。 たとえば、ディスク上の情報を保護するには、バックアップディスクと体系的なバックアップアクションのコストがかかります。 しかし、より複雑な状況では、保護システム自体が商業的に不当になることがあります。 したがって、式の有効性を推測するには：



保護の有効性=（対策前のリスクのコスト-対策を使用したリスクのコスト）/対策のコスト。



有効性が≤1の場合、そのような反作用の使用は推奨されないことは明らかです。

モニタリング

すべての要素が開発され、リスクテーブルがいっぱいになると、チームはプロジェクトの作業を開始し、リスクまたはその警告症状の発生の可能性を監視します。 リスクは、たとえば週に1回など、一定の規則で確認する必要がありますが、「デモ」または作業フェーズの完了までに確認する必要があります。 「ステージとゲート」制御方法が使用される場合、各目標を通過した後、テーブル全体が改訂されます。 リスクを修正し、表内での位置を変更した結果、以前のレベルのリスクが「レベルがありました」列に記録されます。 これにより、チームはリスクの変化のダイナミクスを追跡し、それに応じてリスクのアプローチポイントまたはその通過を理解できます。



効果的なリスクベースのプロジェクト管理の鍵は、チームメンバー、管理者、顧客の間で継続的に情報を交換することです。 これは重要です！ リスク情報を共有しなければ、知性のない指揮官のようになります。



ソフトウェア製品の開発には、シーケンシャルデザインと反復デザインという2つの基本的な手法があります。 ほとんどの開発者は、ウォーターフォールメソッドやアジャイルメソッドなどの用語に精通しています。 以下では、B。BemとR. Turnerの5段階モデル​​に基づいて、リスク駆動型モデルに適用される使用の正しいバランスを検討します。

しかし、最初に、両方の技術の長所と短所に注意する必要があります。

	滝	アジャイル
開発を調整する顧客の能力	低い HLD / LLD *またはTKドキュメントの開発の基礎	高い。 開発は段階的に実施され、その後の各段階は実装前に議論されます
決定の信頼性	説明した機能内で高	低い アイデアはもっと実現されます
リソースの量	大人数	小グループ
製品が得られます	ゆっくり	速い
選択したアーキテクチャの正確さ	考えて分析しました。	迅速な決定に犠牲
ジュニアの割合	専門家の指導の下で素晴らしいかもしれません	大きくない-すべてのチームメンバーは互いに依存しています

* HLD-高レベル設計、LLD-低レベル設計



このモデルの基本的な要因の1つは、チームの特性です。 BemとTurnerは、スタッフの資格スケールを開発しました。

レベル	特徴	フィットモデル
3	予期しない状況では、開発方法の指示を独自に修正する場合があります	すべてのモデルでの作業に適しています。 原則として、マネージャーです
2	状況に応じて方法を調整できます。 ある程度練習した後、レベル3に進むことができます	アジャイルグループやチームリーダーのような小さな滝に適しています
1A	彼はいくつかのプロジェクトの経験があり、小さなタスクのリソース/リスクを評価することができます	チームリーダーのリーダーシップの下で両方のモデルに適用可能
1B	経験の少ないプログラマーまたはテスター	アジャイルチームには望ましくありません。
-1	技術的な知識があるかもしれませんが、チームではうまく機能しません。	FreeLancerまたはコンサルタントとして使用できますが、両方の方法の参加者としては使用できません

プロジェクト管理を成功させるには両方の方法を使用しますが、どちらかをベースとして選択する必要があります。 以下は、基本的なプロジェクト管理モデルを定義する表です。

プロジェクトの特徴	アジャイルに基づいて	滝に基づいて
応用分野
主な目的	高速な結果出力。 明確なタスクではありません。	アーキテクチャの正確性、パフォーマンス、信頼性。
大きさ	小さなチームとプロジェクト	大規模なチームとプロジェクト
水曜日	高い変動性	低揮発性
運営管理
顧客関係	顧客満足度	TKに焦点を当てる
計画と管理	グループ自体が制御と計画を実行します。	計画に記載されている要件を満たす
情報伝達	密接な個人的コミュニケーションにおいて	文書で定義
技術的に
必要条件	ストーリーの形で優先順位を付けて装飾します。 顧客による変更が簡単	TKで記述され、TKに従って原則として変更されることはめったにありません
開発	シンプルなデザイン、小さな開発ステップ	広範な設計、反復ステップごとの大きな変更。
テスト	再利用と継続的な開発を伴う自動。	通常「ブラックボックス」テストの形式で文書化
スタッフ
顧客の可用性	簡単かつ頻繁に利用できます。	分離されており、しばしば利用できない
チーム	少なくとも30％のレベル2および3。ほとんど1Bはありません	10％レベル3から30％レベル1B
チームの内部構造は文化です	チームは責任を持ち、自由を享受する準備ができています	雇用契約では自由と責任は制限されています

次の表に基づいて、基本的なプロジェクト管理方法が選択されます。 BoehmとTurnerは、基本モデルを決定する5つの要因を特定しました。 それらを以下の表に示します。

ファクター	アジャイル	滝
グループ内の開発者の数	小グループ。 各参加者はすべての責任を負います。 グループにおける個人的な信頼と集団的な動機付け	大規模なグループやプロジェクトに適しています。 関係は、契約の枠組み内で形式化されます。
製品の信頼性と安定性	弱いテストであり、あまり信頼性がありません。 文書化されておらず、多くの場合、要件に該当しません。 プロトタイピング時に効果的	重要な製品に適用されます。 試作が難しい
ボラティリティ	設計のシンプルさと実装の容易さ。 信頼できるリリースに移行する場合の高いコストリスク	プロトコル実装など、十分に文書化された製品に適しています。
人員（チームの資格）、そのレベル	2-3レベルの一定の臨界質量がなければなりません。 レベル1Bを使用する危険性	設計段階でのみ、2〜3レベルのクリティカルマスが必要です。 該当するレベル1Bのスタッフ
グループの内部構造は文化です	集団的責任を持つグループ内の高い自由	彼らは、高度な労働保護を伴う雇用契約の枠組みの中で運営されています。

プロジェクトを視覚化するために、極座標図が開発されました。

プロジェクトがダイアグラムの中心に近いほど、プロジェクトの基礎としてのアジャイル手法に適しています。







そして最後に、基本メソッドが選択されると、代替メソッドを使用した調整に進みます。



その結果、リスク分析に基づいてプロジェクト管理の概念を形成するプロセスには5つのステップが必要です。



最初のステップはリスク分析です。

リスク表の設計。

アジャイルおよびウォーターフォール技術のリスク評価



ステップ2-リスクの比較：

基本的な方法が特定されたら、ステップ4に進みます。

見つけることが絶対に不可能な場合は、中間ステップ3に進みます。



ステップ3-アーキテクチャ分析：

基本的な方法で明確な結果を取得できない場合、または一部がアジャイルゾーンの内部にあり、一部が外部にある場合、チームはプロジェクトのアジャイル手法が最も適用可能な部分を分離しようとし、残りはウォーターフォールを使用して行われます。



第4ステップ-開発ライフサイクルの構築：

チームは、ステップ1の表のリスクと自分自身を比較することにより、概説された基本的な開発方法に従います。



ステップ5-実装と監視：

チームは絶えずリスクをレビューしており、要点に到達すると、設計はリスクの表を書き直します。



以下のブロック図は、リスク分析に基づいて開発プロセスをグラフィカルに示し、ウォーターフォールとアジャイルの2つの方法のバランスをとっています。







チームリーダーと主要なプログラマは、アジャイル開発方法論に参加する必要があることに留意してください。 ジュニアはスクラムの集会に参加しないほうがいいです。



あなたに成功したプロジェクトの友人！



使用されるソース：

Boehm、B. and R. Turner（2003）。 敏Ag性と規律のバランスをとるためのガイド：

困惑。 マサチューセッツ州ボストン、アディソン・ウェスリー。

ラーマン、C。（2004）。 アジャイルおよび反復開発：管理者ガイド。 ボストン

アディソン・ウェスリー。