http://kokucheese.com/event/index/37041/
2012-06-16 ScrumBootCamp 東京のまとめ
http://togetter.com/li/321772
きっかけ
アジャイルサムライの読書会でscrumのboot campを行うイベントが開催されるという告知があったので、楽しみにしていました。
講師が@ryuzeeさんということで、ぜひとも参加したいと思っていました。
当日も横浜道場で見かけたことのある方が多かったので、アウェーという感じが全くしませんでした。
講師が@ryuzeeさんということで、ぜひとも参加したいと思っていました。
当日も横浜道場で見かけたことのある方が多かったので、アウェーという感じが全くしませんでした。
講演
内容は、【Agile Japan 再演】アジャイルな開発からアジャイルな組織へに参加してきました #aj12returnを今回のboot campに合わせたものでした。
特に印象に残ったのは、アジャイルソフトウェア開発宣言に対するよくある誤解とトヨタ生産方式の箇所でした。
紹介された「トヨタ生産方式―脱規模の経営をめざして」の本を持っている方が意外と多かったので、探してみます。
特に印象に残ったのは、アジャイルソフトウェア開発宣言に対するよくある誤解とトヨタ生産方式の箇所でした。
- ドキュメントも作らないのではなく、必要な物は作る。無駄なドキュメントは作らない。
- 価値のある出荷可能な製品を継続的に届けることを重視する。
紹介された「トヨタ生産方式―脱規模の経営をめざして」の本を持っている方が意外と多かったので、探してみます。
ワークショップ -スクラム-
最初のワークショップは、ジェフ･サザーランドさんが行った紙飛行機のワークショップでした。
チーム名は、1番テーブルだったので「○太郎」にしました。(○に入る文字は想像にお任せします。)
他のチームでも会場が日本マイクロソフトなのにチャレンジャーな名前がいらっしゃったので安心しました。
スプリントは4回行われました。
やはり、スプリント1はタイムボックスの感覚に慣れず、プロセスもバラバラでした。
振り返りで
途中、制約が変わる際は成功率を上げる選択しました。
最後のスプリントまで成功数がだんだん上がっていく過程は、とても楽しいものでした。
振り返りの際に、共通認識を広げていくこととアイデアを出すことでもっと良いアイデアが出てくる部分は、チームとして同じゴールを見ているからこそだと感じました。
チーム名は、1番テーブルだったので「○太郎」にしました。(○に入る文字は想像にお任せします。)
他のチームでも会場が日本マイクロソフトなのにチャレンジャーな名前がいらっしゃったので安心しました。
スプリントは4回行われました。
やはり、スプリント1はタイムボックスの感覚に慣れず、プロセスもバラバラでした。
振り返りで
- ゴール(完成品の形態)の共有
- プロセスの改善
途中、制約が変わる際は成功率を上げる選択しました。
最後のスプリントまで成功数がだんだん上がっていく過程は、とても楽しいものでした。
振り返りの際に、共通認識を広げていくこととアイデアを出すことでもっと良いアイデアが出てくる部分は、チームとして同じゴールを見ているからこそだと感じました。
ワークショップ -プロダクトバックログ-
プロダクトオーナーってこんなに大変なのかと思いました。
確かに、始めのうちはスクラムマスターにサポートしてもらわないと厳しいと感じました。
優先順位をつけるための業務知識も必要だし、チームの開発スピードに併せてバックログの提供しなければならないので、従来の放り投げ型しか知らない場合はかなり大変だろうなと思いました。
特に、一つづつのバックログの価値についてチームに伝えなければならないので、曖昧だったり自分自身が理解していないとそこで停滞が生じてしまうということを身をもって体験しました。
社内の小規模プロジェクトから始める際のプロダクトオーナー向け勉強会とかあったら、参加してみたいと思いました。
確かに、始めのうちはスクラムマスターにサポートしてもらわないと厳しいと感じました。
優先順位をつけるための業務知識も必要だし、チームの開発スピードに併せてバックログの提供しなければならないので、従来の放り投げ型しか知らない場合はかなり大変だろうなと思いました。
特に、一つづつのバックログの価値についてチームに伝えなければならないので、曖昧だったり自分自身が理解していないとそこで停滞が生じてしまうということを身をもって体験しました。
社内の小規模プロジェクトから始める際のプロダクトオーナー向け勉強会とかあったら、参加してみたいと思いました。
ワークショップ -プランニングポーカー-
日本マイクロソフトさんご提供のプランニングポーカーを利用して、上記のプロダクトバックログで起こしたものにチームとして見積もりを出しました。
全員がプログラミング経験者だったので、話し合う内容も実装よりでした。
受け入れテストが明確だとポーカーの数字も収束しやすいというのを感じました。
ここでは、一回で揃ったから安心ではなくて全員で根拠を話し合うことで、漏れを見つけあったり、よりよいアイデアを生み出せるということが出来るのだと教えられました。
全員がプログラミング経験者だったので、話し合う内容も実装よりでした。
受け入れテストが明確だとポーカーの数字も収束しやすいというのを感じました。
ここでは、一回で揃ったから安心ではなくて全員で根拠を話し合うことで、漏れを見つけあったり、よりよいアイデアを生み出せるということが出来るのだと教えられました。
ワークショップ -スプリントバックログ-
優先順位上位３つのバックログに対して、それぞれタスクに分割してそれぞれの理想時間を付けました。
ここで興味深かったのは、ストーリーポイントと理想時間の合計に相関が無いようにみえたことでした。
大きすぎる機能を分割した場合、どこまで後のバックログに影響を考えるのか、言語やらフレームワークに依存してしまうのだと思いました。変化に対応しやすいものであれば、目の前のタスクに集中できます。そういった意味でも最近のフレームワークを勉強して変化に強いものを取り入れていくことは、重要だと考えます。
ここで興味深かったのは、ストーリーポイントと理想時間の合計に相関が無いようにみえたことでした。
大きすぎる機能を分割した場合、どこまで後のバックログに影響を考えるのか、言語やらフレームワークに依存してしまうのだと思いました。変化に対応しやすいものであれば、目の前のタスクに集中できます。そういった意味でも最近のフレームワークを勉強して変化に強いものを取り入れていくことは、重要だと考えます。
エピローグ
タスクボードやバーンダウンチャートをなぜアナログで行うのかという質問に対する返答で、自然に視界に入ってくるというのがありました。
やったことがない人間からすると、ツールがあるんだからソッチの方がいいのではと考えてしまいますが、ちょっとした変更や追記も簡単に出来るということも大事なのだなと思いました。
記録もデジカメでやればいいという程度で、清書は重要ではないということでした。
Scrum Boot CampはScrumの基礎知識を一方的に教えるつもりはなくて、自分自身で自分のコンテキストで使えそうな気づきを得るというキッカケの場だと思ってたりします。 #scrumbc
— Ryutaro YOSHIBAさん (@ryuzee) 6月 17, 2012一日でここまで濃い内容のワークショップをしたのは初めてでした。
今回のboot campで実感したのは、scrumではまるでアスリートのように自分の持っているものをどれだけ絞り出せるのかを考えて実践するということでした。
その為にも、基礎体力とも言えるスキルや経験がまだまだ足りないと思いました。
今回bootしたので次のステップに登るためにも、日々の改善の努力を続けて参ります。
最後に、講師の@ryuzeeさん、スタッフのスクラム道の皆様、会場を提供して下さった日本マイクロソフト様ありがとうございました。
