BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース スクラムのリスク管理

スクラムのリスク管理

ブックマーク

リスク管理は、プロジェクトにおける有害事象の可能性と影響の削減を取り扱う。アジャイルソフトウェア開発は、反復で進めていく性質上、リスク管理は暗黙のうちにプロジェクトのライフサイクルの一部となる。アジャイルコミュニティのメンバは、明確なリスク管理は必要なのか、スクラムであらゆる種類のリスクが管理できるのか、そして誰がリスク管理を行うべきなのかを議論している。

Michele Sliger氏(リンク)は、アジャイルソフトウェア開発では、デイリースタンドアップミーティングやイテレーション計画ミーティング、リリース計画ミーティング、ふりかえりやレビューのミーティングの一部として、いつもリスクへの取り組みが行われると述べている。しかしながら、彼女はリスク管理について体系的なアプローチ(リンク)を提案している。そのステップには次のものがある。

リスクの識別-チーム全体がこのエクササイズを反復ベースで行う。結果はホワイトボードやフリップチャートに記録される。

リスクの分析-判断や直観、経験を用いてリスクや損失の可能性を決める質的な分析。アジャイルの短い開発サイクルと一定したレビューは、これを実行可能で効果的なものにする。これは、量的分析が行われて多くの人が発生しうる損害にアサインされる、従来のプロジェクトとは異なる。

リスクへの対応計画-チーム全体で選択肢を考え、危険を軽減するための行動に参加する。

リスクの監視と制御-リスクは監視され、制御するための戦略は各イテレーションの終わりに議論される。リスクは、情報ラジエータを利用することによって、日常的にも監視される。

Ron Jeffries氏(リンク)はリスクがブロックされるものではなく(リンク)、そのかわり、失敗しそうなことのメモとして、スクラムマスタのウォッチリストにリストアップされることに言及している。彼の意見では、リスクには、コンテンツが作られないこと、新しい/なじみのない技術、地理的に分散したチーム、他のプロジェクトとの相互依存など、様々な形がありうる。スクラムチームは価値やリスクに基づいてストーリーを並べ替え、リスクを正しく識別して軽減するために、十分時間をかけてリスクの伴うストーリーに取り組む。リスクはストーリーとしてバックログに加えられ、対応されなければならない。

Michael James氏(リンク)は、スクラムのようなソフトウェア開発プロセスは、プロジェクトのライフサイクルの中で早くからリスクに対処していると述べている(リンク)。デイリースタンドアップミーティングやスプリントレビューなど様々な方法が提供されており、リスクは公にされて解決される。Michael氏の意見では、スクラムではリスクの一覧を作る必要はないが、リスクはチームによって定期的に管理されるだろう。

話は変わるが、あるアジャイリストたちは、スクラムはプロジェクトの外部にあるリスクには役に立たないと考えている(リンク)。スクラムは、要求の変更やコミュニケーションの不足、チームのメンバの能力の不足に関するリスクには役に立つ。しかし、プロジェクトの外部にあるリスクの解決にはスクラム以上のものが必要である。

Paul Hudson氏は、同様の考え(リンク)をスクラム開発グループで伝えている。彼は、スクラムはプロジェクトのほとんどのリスクに対処できるが、チームのレベルで対処できないリスクにはスクラムでは対処できない、と述べた。彼は自分の意見の裏付けとして、いくつかのリスクの例を挙げている。顧客のスクラムへの理解の不足、サードパーティの製品が期待通りに動かないこと、プロジェクトが依存している外部の要因が時間内に起こらないこと、チームのシステムのデータの紛失や破損、顧客の意見が一致していないこと、顧客の代表たちが個人的な利益を追求していてプロジェクトのゴールとぶつかってしまうこと、などである。

もう一つコミュニティで激しく討論されている問いは、「誰がリスク管理の責任を負うべきか?」というものである。

Michele Sliger氏(リンク)によれば、リスク管理はスクラムチーム全体のものであり、一緒にリスクを軽減する責任がある。

スクラム開発グループの議論(リンク)の中でRon Jefferie氏は、「スクラム的」にはリスク管理の責任を負うのはプロダクトオーナーであると述べている。あるメンバたちはRonに賛成し、プロダクトオーナーはどのリスクを軽減する必要があるかを決定するのに最適な人物であると考えている。なぜなら、ビジネスを一番理解しているのは彼だからである。プロダクトオーナーはチームの全員から意見を聞くことができるが、最終的な責任は彼にある。Peter Stevens氏は次のように付け加えている。

お金を払う責任者として、P-Oはリスクの削減に直接関心がある。スクラムマスタやチームはP-Oがバックログに最適に優先順位を付けるの手伝わなければならないし、そうするだろう。しかしROIはP-Oの責任であり、リスクの結果はコストとなるので、これはP-Oの責任である。

グループの別のメンバは、リスク管理はチームの責任であり、スクラムチームの全員が共同でリスクの解決に取り組まなければならない、と述べている。

このように、すべてのリスクをスクラムで管理できるのか、そしてリスクを明示的に管理するべきなのかについては、様々な意見がある。アジャイルコミュニティのほとんどのメンバは、プロジェクトに関連するリスクはスクラムで適切に管理することができるということに賛成しているが、リスクがプロジェクトの外部にある場合については隔たりがある。同様に、誰がリスク管理を行うのかについての一致した意見はない。プロダクトオーナーであるという可能性は濃厚なようだが、リスクはチーム全体で管理するべきだと考えているアジャイリストもいる。

原文はこちらです:   http://www.infoq.com/news/2008/07/managing-risk-with-scrum

この記事に星をつける

おすすめ度
スタイル

BT