コタツモデルを実現したスクラム開発 #devsumiA #qa_it

前の記事に書いた様に、アジャイルスクラムではチームがカプセル化されていて、プロダクトオーナーが作成・管理するプロダクトバックログの優先順位に従って開発されます。この優先順位はプロダクトオーナーが価値が高いものやリスクが高いと考えるものを高くして、早期に開発します。

しかし、以前書いた「アジャイル風開発ラフシミュレーション」の結果の様に、リスクが顕在化した際の影響を少なくするにはリスクの特性を考慮した優先順位をつける必要があります。

具体的には、リスクの大小だけではなく、リーンソフトウェア開発に書かれている様に「決定をできるだけ遅らせる」ことも必要に応じて行わないと行けません。たとえば、スクラムを活用したアジャイルなプロダクト管理(p.55)にあるように、ユーザインタフェースのデザインはその後の方向性を定めるために早めに実装して確認する必要があります。しかし、一度に全部を作るのではなく、典型的な画面をまず確認して、その後に横展開する方が効率的でしょう。

このような判断は、ある程度の実装の知識が必要になります。要求開発のコタツモデル（リンク先はITpro）の様に、ビジネスや業務だけでなく、常にシステムを考慮した優先順位を考える必要があります。

デブサミの講演「ソーシャルコーディング革命後の開発委託の世界〜QA@ITの事例」では、担当者の知っている言語Rubyを選び密度の高いコミュニケーションをはかる事で、コタツモデルに求められる効果を実現していました。アジャイル開発とスクラムで野中さんが、プロダクトオーナー及びスクラムマスターが「スクラムチームの内外両方に対して、積極的に働きかけなくてはならない」(p.239)を実現していたのです。

スクラムはアジャイル開発の優れたフレームワークのパッケージです。そのまま利用するだけでも大きな効果が得られるでしょう。しかし、より良くプロデュースすれば、さらに大きな効果が得られると思います。

スクラムに限らず、プロセス改善のゴールは組織やプロジェクトによって異なります。常に問題を見極める姿勢が大切だと思います。