「すくすくスクラムin大阪」第一弾参加。

2010/4/25（日曜日）に開催された「すくすくスクラムin大阪」に参加した。

「スクラム」とは、アジャイル開発の１つに分類されるソフトウェア開発手法である。名前の由来は、ラグビーの「スクラム」が元になっており、「開発チーム全員でスクラム組んで一丸となり、てソフトウェアを開発しよう！」というもの。

チームが開発に注力するため、様々な手法が提案されている。

　・バックログ

　・スプリント

　・スクラムミーテイング

　etc, etc……

今回は、この「スクラム」という開発手法を体感する事がゴール。

主催は、「すくすくスクラム」。司会は　ebackyさん。

下記にワークショップの内容を簡単に紹介する。


--------------------------------------------------------------------------
シナリオは「新しい家を作る」ことが目的。

いくつかのチームに別れ、各チームをそれぞれ「家族」に見立て、役割（ロール）を明確にし、ロール毎に新しい家に対する要求を出す。

出された要求に対し見積もりを行い、タスク分けを行い、タスク単位にブロックの組み立てを行う。見積もりは、ブロックの個数単位。タスクをスプリント単位に実施し、１スプリント終了毎にふりかえりを行う。

家を建築中、隣の家のお父さん　（顧客）　に優先順位付けと、出来栄えの評価を実施してもらい、開発チームが見落としている観点や、開発者の都合で決めた仕様の問題点を指摘してもらい、軌道修正する。

--------------------------------------------------------------------------

上記ワークは、スクラムのプロセスのすべてが含まれている。

　・プロダクトバックログの作成

　・各プロダクトバックログの見積もり方法

　・プロダクトバックログからタスクへの分割

　・開発チームの開発スピード（ベロシティ）の測定

　・改善活動（ふりかえり）

　・顧客を開発に巻き込む

特に参考になったのは、「プロダクトバックログ」（ストーリーカード）の書きかた。

　（１）記入者の役割

　（２）欲しい機能／性能

　（３）欲しい理由／得られる価値

そして、もう１つ大きな参考になったのが、規模の分からない機能に対する見積もり方法。
（１）「プロダクトバックログ」をすべて出す
（２）その中から最も規模の小さいものを１つ選び、ポイントを「２」にする。
（３）（２）の４倍のものを１つ選び、ポイントを「８」にする。
（４）（２）（３）を元に、他のカードをすべて見積もる

これらの基準は、実践的で効果的な内容でした。

--------------------------------------------------------------------------

その他、気付き事項を列挙。

・スプリント

　「イテレーション」とは違う。「全力を尽くす」という意味合いが込められている。

・done（完了）

　誰もがわ納得できる、分かり易い判断基準が望ましい。

・コミュニケーションコストを払った方が、ステークスホルダーからの協力が得られやすい。

・時間がなくなると、コミュニケーションを止める。

・日本人の特徴「言わなくてもわかるだろ？」

・朝会、ふりかえりはコミュニケーションコストが掛かるが、本当に高いのか？

・良いコミュニケーションとは、相手の考えを理解すること。

--------------------------------------------------------------------------

たった１日でしたが、書籍で読んで理解していた内容に、実体験が加わって、更に理解を深めることができた。

次回、5/29に「すくすくスクラムｉｎ大阪　第二段」が開催される。そちらも楽しみである。