2010年4月26日月曜日

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

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


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

チームが開発に注力するため、様々な手法が提案されている。
 ・バックログ
 ・スプリント
 ・スクラムミーテイング
 etc, etc……

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

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

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


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

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

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

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


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

 ・プロダクトバックログの作成
 ・各プロダクトバックログの見積もり方法
 ・プロダクトバックログからタスクへの分割
 ・開発チームの開発スピード(ベロシティ)の測定
 ・改善活動(ふりかえり)
 ・顧客を開発に巻き込む

特に参考になったのは、「プロダクトバックログ」(ストーリーカード)の書きかた。
 (1)記入者の役割
 (2)欲しい機能/性能
 (3)欲しい理由/得られる価値


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

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

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


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

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

・done(完了)
 誰もがわ納得できる、分かり易い判断基準が望ましい。

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

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

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

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

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

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

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

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

0 件のコメント:

コメントを投稿