蛙のつぶやき

Twitterのつぶやきを補足。システム開発、プログラム、ガジェット、趣味、地元話など。

Scrum Boot Camp 東京に参加しました。

アジャイル

という訳で、6月16日(土)、念願の Scrum Boot Camp 東京に参加してきました。
http://www.taoofscrum.org/contents/post/264
会場は品川駅前、Microsoft様の会議室！

会場到着

ビルの入口が通路から奥まったところにあって、普段通りに、ボーっと歩いてたら通り過ぎてたかも…危なかった；
ちなみにMicrosoft様にお邪魔するの初めてです。どきどき。



まずは@様より、会場のご説明と、書籍『アジャイルソフトウェアエンジニアリング』のご紹介がありました。

アジャイルソフトウェアエンジニアリング ~ 基本概念から継続的フィードバックまで (マイクロソフト関連書)

アジャイルソフトウェアエンジニアリング ~ 基本概念から継続的フィードバックまで (マイクロソフト関連書)

実はまだ買えてない…。
日経BP社のサイトから注文すると、6/30まで発行記念特別価格なので、早めに入手したいと思います。


本編

本編は、講演→ワークショップ を繰り返す形で進みました。
講師は、
@様（http://www.ryuzee.com/contents/blog/）
@様（http://takubon.hatenablog.com/entry/2012/06/19/120201）
です。

あと、@さんが、つぶやきのまとめを作成してくださっています。
http://togetter.com/li/321772
追っていくと大阪会場の様子も何となく分かりますね。感謝です！


ワークショップ

ワークショップはテーブル毎にチームを組んで行います。
自分は4番卓で、チーム名は「はなちゃん」に決定。
同じ卓のメンバーのお子様のお名前から頂きました。

紙ヒコーキワークショップ

Scrumのスプリントとチームによる改善を体感できたワークショップ。
とある制約内で、目標を達成するための紙ヒコーキをチームで作成します。
スプリントの最初に、何機が目標を達成するかを見積もるのですが、うちのチームは2回目まで成果が0だったので、見積もりとの乖離が激しかったです；

最終的な成果は以下の通り。
f:id:s-kic:20120620004245j:plain

3回目でボトルネックを発見し、その改善を図ったのが正解でした。
本当は最初のスプリントで、まずは見積もり分を達成できるようにする等、目的を共有しておいた方が良かったのかもしれません。

マルチタスクによる弊害

人間は並行（頻繁にスイッチング）して作業を行うと効率が落ちるんだよー、というワークショップ。
計算が苦手で、小学生の頃から算数の宿題をパソコンにやらせていた私のような人間にはキツさ倍増です；

社内用の吞み会管理システム作成

架空のプロジェクトで、プロダクトバックログから見積もりまでを体験します。
まずは、チーム全員がプロダクトオーナー役となり、プロダクトバックログの作成を行います。
その後、全員チーム役となり、プロダクトバックログからスプリントバックログを作成して、プランニングポーカーを使って見積もりを行います。

初めてプランニングポーカーで見積もりしました。
f:id:s-kic:20120620010326j:plain
最初は要領が掴めず、少し戸惑いましたが、同じチームにプランニングポーカー経験者がいたので、細かいアドバイスを頂けました。感謝です。

前提としてる技術や言語が異なると、結構、個々の見積もりに差が出ます。それを話し合って、認識の差を埋めていく。
プランニングポーカーは、認識の差を明らかにして、コミュニケーションの手助けをするツールであるということを改めて認識しました。


講演

講演の方ですが、全ての内容を追って書くと長くなりそうなので、以下、自分が当日気になった内容（見出し以下）と、自分の感想（⇒以降）でお送りします。
読んでいて意味不明だったらゴメンナサイ…。

変化しないものは滅びる

変化しない→価値が下がる→滅びる
つまり「変化しないものは滅びる」

⇒XPにも「変化を抱擁せよ」ってありますね。
⇒人間は変化を嫌う生き物なので、変わる勇気を持つ、というのがアジャイルの第一歩なのかもしれません。

Agileは形容詞

アジャイルは“度合い”の問題。[0|1]ではない。
どれだけ「アジャイル」か？

⇒最近の疑問。「アジャイル」が形容詞なら「アジャイルなウォーターフォール」は存在するのだろうか？ …もし存在するなら、WFからアジャイルなプロセスへの移行に使えないかな…と思ったので。

Agileは韓流の連続ドラマのようなもの。

視聴者の評判でどんどんストーリーが変わっていく。

⇒週刊連載の漫画も似ていますね…。アンケートで方向性が決まることも多いようですし。

自己組織化ができているチームとは

自分たちで一番良いパフォーマンスを見つけられるチーム。

コミットメントとは

全力でやること（Done）にしようとすることを約束する。
見積もりはコミットメントではない。

コミットする対象について

お客さんに対してコミットするのではなく、上司の評価に対して仕事をしてしまうのはダメ。

ふりかえりについて

KPTのPに毎回同じものが出てくる場合は、2つのケースが考えられる。
１．改善されていない
２．改善しなくていいものが出ている

⇒恥ずかしながら「改善しなくていいもの」の具体例が思いつきませんでした…。
⇒もう最適化されきっているので改善する必要がないもの？
⇒チームの力が及ばないところに制約があって改善できないもの？

ストーリーの作成について

バックログは50～100個くらいで。
粒度が大きければ見積もりの時点で分割する。
カードにはストーリーの価値（誰にどのような結果がもたらされるか）を書く。
POが複数いる場合、優先順位の最終決定権について事前に決めておくのがベター。
（チーフPOが決める、多数決で決める、など）

チームとしての見積もり

定期的なバックログ・グルーミングを行う。
会話して認識の差を埋めるのが大切。
見積もりのインフレがあった場合→見積もりの基準となるストーリーを別の物に変える。
漠然としたストーリーで見積もりが大きすぎる場合→ストーリーを分割する。
チームで不明な点がある場合はPOに要求を確認する。
POの要求自体が不明な場合は、ストーリーの優先順位を見直してもらう。
等の対策をとる。

記録と時間

実際にかかった時間を追跡しない理由
・上司がメンバーの評価に使うのを防ぐ。
・今まで実行した時間は「いつ終わるのか」に関係ない。
・厳密に記録をしなくてもタスクかんばんを見れば遅れているかは分かる。

時間と言う単位はメンバー、チームへの圧力になりやすい。
誰が今何をしているか？が重要。
チームの数値を個人の評価に使用すると、抜け駆け、秘密主義になってしまう。

Scrumの導入

小規模プロジェクトでScrumを成功させていないチームは、大規模プロジェクトでScrumを行うべきではない。
最初はトレーニングを行い、小さな規模のものから成功体験を積み重ねること。


※今後も当日のメモから拾って項目を追記するかもしれません。


最後に、うちのチームのふりかえり結果を載せておきます。
f:id:s-kic:20120620012610j:plain


〆


今回、一緒にワークショップをしたメンバーでランチタイムを過ごしたのですが、既にScrumを導入している現場の方がいらっしゃって、導入時の色々な問題や苦労した点を聴くことができました。

自分も、今後プロジェクトリーダを担当し、Scrumの導入を試みた時に、同じような壁にぶち当たると思います。
その時に本BootCampで学んだこと、チームでご一緒した方々のアドバイスや体験談が、大きな支えになるだろうと感じました。


講師の@様、@様、スタッフの皆様、参加者の皆様、
素晴らしい気付きと体験の場をありがとうございました！