リスクについて話す
リスクは何ですか？ リスクとは何ですか？ ソフトウェアおよびプロジェクト計画の複雑さを評価する際にリスクを考慮する方法は？ このトピックでこれについて話すことを提案します。 同時に、トピックを膨らませず、繰り返さないために、 リスクの 特定と軽減の問題-特定するアクション、リスクの可能性を減らすこと、およびその結果を最小限にすることについては、ここでは説明しません。
ソフトウェアの複雑さの評価における大罪に関する記事の出版後、著者も私もリスクについて何も言わなかったと言われました。 この迷惑な誤解を修正し、リスクとそれらの経験について少しお話したいと思います。
典型的なリスク
以下は、ソフトウェア開発プロジェクトの典型的なリスクのリストです。
- 他のプロジェクトから働くために、現在のプロジェクトから従業員をそらす
- 病気、特別な休日、結婚式、妊娠、休日など。
- クレームの調整における不合理な遅延
- 顧客の要件の予測できない変更/拡大
- 開発中の比較的新しい技術の使用
- 主要な開発者/アーキテクトの出発
- 顧客側の主要な従業員/代表者の変更
リスクではないもの
地球温暖化はリスクですか？ そして、市場の状況の変化は？ そして、顧客の会社が崩壊する可能性はありますか、それともあなたの会社は神に禁じられていますか？
「これらのリスクのどれをプロジェクトで考慮する必要がありますか？」
どういうわけか、次のプロジェクトの複雑さの推定を実施しました。 最近のプロジェクトに火をつけて、将来のプロジェクトの評価にできるだけ多くのリスクをかけるようにしました。 結果は非常に印象的なリストでした。
このリストを確認した後、私の前のリーダーとメンターは、「あなたの非専門性を危険にさらさないでください！」と言いました。 彼らは私と私の同僚を非専門主義だと非難した！？ それから私は彼に少し気分を害しました。 私たちは本当に私たちにリスクがあると思われる点をかなり除外することを余儀なくされました。 それからしばらく経ちましたが、少し冷めて本を読んで、以前の経験を再考しました。 今、私は多くの点で彼に同意しなければならないと言うことができます。 したがって、リスクと見なすべきではないいくつかのケースをリストします。
リスク、その確率は100％になる傾向があります
- 従業員の資格が不十分であることは、評価で最初に資格が定められるべき理由のリスクではありません（たとえば、 フォーカスファクターを使用）
- 定期的な従業員の休暇-彼らは多少事前に予測し、プロジェクト計画に追加することができます
- 要件の予測される変更-特定の開発モデルが選択された場合に発生する可能性があります（たとえば、 固定チーム ）
リスク、その確率は0になる傾向があります
このリストは少々手に負えないように見えるかもしれません。 これは、考えられる「信じられない」リスクを説明するためにのみ提供されています。 プロジェクトの性質とその期間によっては、同じリスクが信じられないほどになる可能性があることを理解することが重要です。
- 短期プロジェクトの実施中の既存の法律の変更
- プロジェクトソースコードの完全な損失
プロジェクトまたは方法論の一部であるジョブ
- コードレビュー-このアクティビティはリスクに起因することが起こります
- リファクタリング-彼らはこれを言う：「リファクタリングが必要な場合があります。」 「may」という言葉は紛らわしく、これがリスクであることを示唆しています。 実際、リファクタリングとは、事前に計画されている作業を指します。
リスクの計画
ここで余談をし、なぜリスクを考慮する必要があるのかを説明する必要があります 。 トムデマルコが言ったように、「 プロジェクトを管理するには、そのリスクを管理するだけで十分です。」 しかし！ これは、プロジェクトが既に開始された瞬間に適用されます。 管理するものがあるとき。 ここで、プロジェクトの評価と計画が開始前に実行されることを想像してください。 そして一般に、プロジェクトが開始されるかどうかは不明です。 この段階でリスクを考慮する必要がありますか？ はい、いいえ...
一方では、初期段階では、情報が不十分であるため、リスクを負い、それらを過小評価する可能性があります。 一方、これはそれらを完全に無視する理由ではありません。 妥当なバランスを探し、最初から特定したこのプロジェクトの最も重大なリスクを何らかの形で考慮しなければなりません。
用語の定義
「正味労働投入」の概念を紹介します
正味労働投入量は 、特定のタスクの実施に必要な「理想的な人の日」の労働投入量として定義されます。 ここでの意味を説明するために、経験豊富なスクラムマスターHenrik Knibergの トレンチの本Scrum and XPからの説明を使用します。 だから：
「 理想的なマンデーは、誰も主な職業から邪魔されない最も生産的な日です。そのような日はまれです。」 （c）Henrik Kniberg
言い換えると、リスクがどれも実現されないという条件で、タスクにこのような骨の折れる作業があると想定します。
タスクまたは「隠れた帽子」方法論によるリスクの均等な配分
「紹介」として、最近のプロジェクトの提出された見積もりに応じて、トップマネージャーの1人から話された逸話をお伝えします。
従業員は出張から到着し、経費報告書を提出します。そこで、特に「帽子：$ 100」と表示されます。
彼らは会計で彼に尋ねています...
-これはどんな帽子？
「まあ、私は自分で帽子を買った...かっこいい...すべて。」
-$％＆*＃！ レポートを変更してください！
まあ新しいものを持って、そこに再び「帽子：$ 100」
さて、再び、「$％＆*＃！」、帽子がないように変更してください。
持って来ます...彼らは見ます-すべてがうまくあります...あなたは掘ることはありません、帽子はありません...しかし、それがあったままの最終的な量。
彼らは尋ねる：
-そして帽子はどこにありますか？
-はい、彼女は...そこに...あなただけが彼女の地獄を見つけるでしょう！
したがって、リスクを考慮に入れる場合、同様の方法を適用できます。
たとえば、以下のガントチャートのフラグメントに示されているように、いくつかの追加の面倒さの形で表される1つまたは複数のリスクを、他の特定のタスクに単純に均等に分散できます。
ここでは、純粋な労働投入を伴うタスクの長方形が青色で示されています。 署名-タスク（人）に割り当てられたリソース。 労働強度が集中している長方形を赤で示しています。これはリスク対応のために追加されます。
このように、一方ではリスクが評価で考慮され、他方ではリスクに焦点が当てられません。 これはまさに、先ほど言及した本で出会った会計方法です。 この本はそれがリスク会計であると明確に述べていないが、その類似性は非常に明確であることに注意する。 興味がある場合は、計画に関する章を参照してください。
独立したタスクの分離
ここで、両方のリソースに関連付けられているが、解決するタスクの作業時間を延長しない何らかのリスクを特定したと想像してください。 以下のチャートをご覧ください。
図は、すべてのタスクの合計期間が増加していないことを示しています。 リスク長方形は他の長方形と平行です。 このアプローチは、タスクの全体的な複雑さを増すリスクが最終的な条件を変えない場合に適用する意味があります。 これは、プロジェクトの合計期間が長くならない場合に発生しますが、残念ながら非常にまれです。
それでは、別の図を見てみましょう。
ここで、赤いタスクリスクは、他のタスクと順番に（エンドツーエンドで）行きます。 したがって、作業の合計期間（期間）は増加しています。
計画の消費者がリスクを明示的に識別する必要がある場合、独立したタスクを識別することによるリスク会計アプローチは理にかなっています。 リスクタスクは架空のものであることを覚えておくことが重要です。 その結果、プロジェクトの実装中に、このタスクは特定のタスク（新しい青い長方形）に縮退するか、他のタスクと「マージ」されるか、まったく実行されません。 このような会計は、計画の初期段階で重要であり、時間のずれをなくしたり、予算を増やしたりしないようにします。
結論
リスクを考慮することはリスクとの戦いをあきらめることを意味するものではないという事実をさらに強調します。これは問題を解決するのではなく回避するための試みではありません。 多くの場合、リスクが可能性のカテゴリから不可能のカテゴリに移行するときに、このような条件を作成する方がより適切です。 ただし、一部のリスクを排除できない可能性があります。 この場合、このようなリスクを考慮すると便利です。
トピックが長すぎることが判明した場合は謝罪します。 私はすでにどこでも自分自身を制限しました。 特に、投稿では、 PERT方法論でリスク会計をどのように使用できるかについてはまったくありません。 トピックが十分に人気があることが判明した場合、別のトピックがこのトピックに作成されます。
最後まで読んでくれた人に感謝します！