カスタム開発におけるスクラムの機能については引き続き説明します。この記事では、リスク管理とアジャイルを横断する方法を説明します。
カスタム開発では、顧客と彼のビジネスに関連する追加の潜在的な問題があるため、リスク管理が重要になります。 従来のスクラムにはそのような規律が含まれていないため、アジャイルの原則を忘れずに、古典的なリスク管理アプローチを適応させる必要があります。
スクラムには明確な管理慣行はありませんが、反復的および漸進的な方法論と同様に、スクラムは顧客から早期のフィードバックを受け取ることでリスクを大幅に削減することに注意する必要があります。 スクラムは、スプリントの終わりに回顧を行うという非常に良い習慣も持っています。それは、リスクが実現された後、リスクに対する反応を開発するのに役立ちますが、残念ながら反応します。
リスクの処理は、この図に示されているいくつかの段階で実行されます。
最初のリスクブレーンストーミングセッションはゼロスプリントに含めることができます（ちなみに、革新的なスピードボートゲームの形式で実行できます）。その後、各スプリントをさらに分析し、対策を開発する必要があります。 対策は正確に予防する必要があることに注意してください、それは安価であることが判明します:)しかし、 KISSとYAGNIの原則を神聖に観察して、必要以上に行うことはありません。 顧客の代表者もブレインストーミングに参加して、考えられる問題についてのビジョンを表明できます。
ブレーンストーミングセッションを促進するには、次のリスクワークショップのいずれかを使用することを強くお勧めします。
- SEI分類ベースのリスク識別 -Software Engineering Instituteのリスク分類とアンケート
- MSF Risk Management Discipline ver 1.1-マイクロソフトのソフトウェアリスク分類の軽量バージョン
チーム全体（および顧客）がリスクを把握し、それらの管理に完全に参加できるように、リスクを視覚化する必要があります。 最悪のオプションは、リスクのあるExcelファイルを作成し（最も人里離れた隅に）、「このリスクは37番以下のレジストリにあり、phakapで」と言うことです。 最も「補助的な」オプションは、リスクボードを作成し、そのライフサイクルを追跡することです。
しかし、特に顧客がこの作業に関与するリスクで無理をしないことが重要です。なぜなら、プロジェクトとチームは、プロジェクトが潜在的な問題で構成されていると考えるからです。 この状況は、詳細なリスク分析を以前に実施したことのないチームで非常にはっきりと現れますが、単に目隠しをして熊手を踏んだだけです。
リスク分析と優先順位付けの段階でさらに詳しく見ていきましょう。 プロセスをできるだけ単純にすることに同意しました。したがって、定性的リスク評価と定量的リスク評価の中間点を見つけることを提案します。 定量的推定と数学的モデリングはかなりarbitrary意的なものであり、構築されたモデルの特性をよく理解する必要があります。
リスクの可能性と脅威（それがもたらす損害の程度）を評価するために3段階のみを採用し、金銭的な見積もりは使用しません。
もちろん、「赤」リスクに最大限の注意を払う必要があります。最も可能性が高いだけでなく、それらからの損害が最大になると約束されています。
リスクの運用監視と結果の修正に関連するアクティビティは、毎日のスタンドアップで実行するのに非常に便利です。チームは仮想の問題ではなく、特定のリスクで運用します。
教訓については、これにはレトロスペクティブが最適です。 これらの教訓とベストプラクティスは、たとえばスクラムオブスクラムなどのチーム間で配布する必要があることに注意してください。
投稿者： Boris Wolfson -Softline Developmentのヘッド