Programming log - Shindo200

イベント参加記録とプログラミング系の雑記

LEGOでスクラムを体験してきました

アジャイルサムライ』を読んでスクラムの概要について学んだり、ハッカソンに参加してスクラムのような形で開発したことはありますが、「スクラムの思想についてちゃんと知っているか」と聞かれたら「はい」と答えられる自信はありません。スクラムの思想について学べる良いイベントがないか探しているときに『LEGO®ではじめるスクラム入門』というイベントがあることを知りました。Doorkeeperに過去のイベントの参加者の名前と一言が掲載されているのですが、過去の参加者にRuby界隈で活躍されている方が多くて気になりましたので、参加してきました。

イベントについて

このイベントでやることは以下になります。

  • スクラムの思想について講義
  • レゴを使ったワークショップ

Doorkeeperからイベント概要を引用させていただきます。

なんとなく流行っているから……という理由でアジャイルを採用してもうまくいきません。開発者であれば気になる技術プラクティスから導入したいと思うかもしれません。むしろテスト駆動開発継続的インテグレーションなどは必ず実施したいプラクティスです。しかし、アジャイル開発は 複雑で変化の激しい問題 に対応するための方法論です。

こうした複雑な問題に対応するには、開発チームだけでなく 関係者全員 で継続的に意思決定をしていく必要があります。そのためには、 共通認識を合わせる ことが重要となるのです。

講義

最初は『スクラムガイド』を翻訳された角さんによるスクラムの思想についての講義でした。講義を聴いて大事に感じたことは「変化に対応するために短い期間でレビューを行い、繰り返して良い物を作っていく」ということでした。講義中に「最高においしい焼きそばを作る方法を考えてください」という問題が出ましたが、

  1. 料理人から作り方を教わる
  2. 良い食材を揃える
  3. 作る
  4. 完成

というスタートからリリースまで一直線の考えを出してしまったので、「失敗しやすい案を出してしまいがちだから、気を付けないと」と思いました。

ワークショップ

ワークショップの課題は「理想の街作り」です。チームメンバーで父、母、息子、ペットなどの家族の役柄を決めて、それぞれその役柄に成り切って、街に欲しい建物とその理由をユーザーストーリーとして出していきました。ユーザーストーリーを出したら、「理想の街」のイメージを模造紙に書いていきます。自分たちで開発するのは自分のチームの「理想の街」ではなく、他のチームの「理想の街」になりますので、他のチームの方が見てもわかりやすいようにイメージを書いておきます。

f:id:Shindo_Masaya:20130513160050j:plain:w400

スクラムではチームでの共同開発を大事にするので、建物の優先順序やタスクの見積もりなど、開発に関わることはすべてチームメンバーで話し合って決めていきます。わからないところがあったら、プロダクトオーナーを通して受注先チームに質問します。変化に対応するために、スプリントごとに受注先チームに現状報告と要望の確認をします。今回のイベントでは1スプリントを7分としましたので、こまめに現状報告と確認をしていて、受注先チームも交えて開発を進めているように感じました。

f:id:Shindo_Masaya:20130517020650j:plain:w400

建物を作るときは、先に建物の土台だけ作っておいて、後は適当にプロトタイプを作ってチームメンバーに見せて壊して、またプロトタイプを作って…という作業の繰り返しで進めていました。少し無計画な作り方な気がしますが、わりとスムーズに作ることができました。短い時間で開発を行う場合は、計画よりもコミュニケーションを大事にしたほうが上手くいくのかもしれません。(もちろん、無計画な開発を勧めている訳ではありません。)
また、私のチームはレゴブロックが少なくなっている後半のスプリントで「隣のチームがタワーを建てていたから、それよりもっと高いタワーが欲しい。」という要望を受けました。苦労しそうな要望に戸惑いましたが、「自分のタスクが終わったらタワーを建てるのを手伝おう」「この大きさのブロックを重ねてタワーにしよう」とチームで案を出しただけで、意外にもスムーズに完成させることができました。スプリントごとのベロシティを見ると、「7→7→10→12」と少しづつ増えていっていましたので、スプリントを重ねるごとにチームメンバーが開発の雰囲気を掴んでいたから、後半のスプリントでも簡単な提案だけで上手く作ることができたのかもしれません。

f:id:Shindo_Masaya:20130515213002j:plain

問題点

チームメンバー全員が作業に集中し過ぎてしまったせいか、終わっているタスクを「完了」に移すことを忘れてしまいました。実際の開発でもチケットを閉じ忘れて、プロジェクトの進捗状況がわからなくなってしまう失敗がありそうです。適度に模造紙を見て、「終わっているタスクはありますか?」と声をかけるのが良さそうです。

これから参加される方へ

スクラムの思想にある「変化に対応する」を感じるためにも、発注先チームに追加要望をたくさん出すことをオススメします。また、あると助かる建物を要望するよりも、レゴで再現したらどうなるのか気になる建物を要望したほうが面白くなるかもしれません。

f:id:Shindo_Masaya:20130513175253j:plain:w400