アジャイル開発を考える - リスクを考えたプロセス -
大昔のリスクマネージメントの教科書には
- リスク = 影響 × 可能性
- マネジメントするには、リスクを取り除くか、あらかじめ工数を組み込んでおく
といったことが書かれていました。これがアジャイル開発という考え方によって、どう変わったのか考えてみました。
アジャイル開発には、リスク駆動という考え方があります。アジャイル開発の基本はincrementalあるいはiterativeな反復開発で、複数回のリリースが行われます。最初のリリースで、リスクの大きな部分を開発して問題をなくしておけば、その後のリスクを軽減することができます。
実はこれで解決できないタイプのリスクがあります。それは、決定することのリスクです。早めに決めてしまうことで、その後の仕様(制約)が決まってしまい、柔軟な対応ができなくなるような場合です。
無理やりこじつける(カバチっていうのでしょうか?)と決めないということを開発しておくということになるのでしょうが、このような場合はリーンソフトウェア開発の「決定をできるだけ遅らせる」という表現が的確でしょう。
決定することにリスクがあるなら、あえて決定を遅らせて、選択肢を残しておくという考え方です。もちろん遅らせることで他の作業にも影響が出ますから、限界(期限)がありますし、選択肢を残すための設計上の工夫が必要になるかもしれません。そのようなことを考えても、メリットがあるなら遅らせるのです。
このように考えると、リスクを取り除くか計算しておくのですから、リスクマネージメントの基本の延長に過ぎないような気がします。さらに考えると、リスクの結果は手戻りなのですから、「手戻りを減らして生産性向上」という昔からの目的は変わっていないともいえると思います。
日本でのアジャイル開発はXPから始まりました。それはショッキングなもので、既存の開発とはかけ離れているように思いました。でも、実際はリスク駆動というリスクマネージメントであったり、課題を順にこなして、スクラムという名称で一定期間は仕様を凍結するといったことを、プラクティスとしてまとめたもので、普通の開発をまとめなおしたものではないのだろうかと思った次第です。
« 堂島ホテルロール | トップページ | Switchy! : Google Chrome用簡単多機能プロキシー管理ソフト »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
« 堂島ホテルロール | トップページ | Switchy! : Google Chrome用簡単多機能プロキシー管理ソフト »
コメント