アジャイルプロセス協議会セミナーで「はじめてのアジャイル」をお話しました。
10月13日 アジャイルプロセス協議会セミナー2012(東京都)
30分間ですが、アジャイルプロセス協議会セミナーで、「はじめてのアジャイル」と言うテーマで
お話をしてきました。
ほぼ、アジャイルプロセス協議会の関係者と言う環境で、「はじめてのアジャイル」と言うテーマで話をするのは、緊張しましたが、せっかくなので色々とフィードバックを頂きたいと思っています。
7/19 アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」を開催しました。
アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」 - [PARTAKE]を開催いたしました
当日のタイムテーブル
19:00 開場
19:30-19:35 オープニング
19:35-20:20 「アジャイルリーダーシップと組織改革 ~楽天のアジャイル開発というリアル~」 @daipresents
20:20-20:50 (A)ディスカッション(ワールドカフェ + 発表)
21:50-20:55 休憩 & 席替え
20:55-21:25 「アジャイルペーペーシップとチーム改革 ~楽天のアジャイル開発というリアル another story~」 @TAKAKING22
21:25-22:55 (B)ディスカッション(ワールドカフェ + 発表)
21:55-22:00 クロージング
22:00-23:00 ビアバッシュ
今回は、楽天の藤原さん、及部さんにお越し頂き、講演を行って頂きました。
今回の特別編で楽天の藤原さんに講演して頂くきっかけとしては、横浜道場の懇親会等で参加者より「中々導入出来ない」、「組織が。。。」といった話を良く耳にします。
デブサミ2012に、私は参加出来なかったのですが、藤原さんの講演資料を見て、大きな会社である楽天で孤軍奮闘(最近は孤軍じゃなくなった? ^^)している藤原さんの講演を横浜で再演してもらい、横浜道場参加者への良い気づきになればと思いアポを取ったところ快く承諾して頂きました。
(とかっこ良く書いていますが、実は自分が見たかっただけとも言います^^; 主催者特権ですね^^)
この企画を横浜道場のスタッフに投げたところ、スタッフである下地さん(@nntsugu)さんが及部さんにお声がけして、今回の師弟対決が実現した次第です。
今回のプログラム的に、同じところ(楽天)の話を、違う視点(マネージャー・チームメンバー)で見られたのも大きいですね。
今回は、初めて試す事が多く、まとまるか少し不安ではあったのですが、ふたを開けてみれば特に問題も無く(Q&Aが盛り上がって終了が23時を回ってしまいましたが。。。)出来たのでは無いでしょうか。
今回の自分の収穫は
- 「アジャイルペーペーシップとチーム改革 ~楽天のアジャイル開発というリアル another story~」 @TAKAKING22
- 自分を変えて下さい。→今度、使おう!
- うまくいっていたチームがうまくいかなくなり、元に戻された。→自分ならやさぐれそうだけど、彼は違い、ふりかえりから改善を行い地道にチームを巻き込んで行った。 すばらしい!!
- 懇親会時のディスカッションは結構盛り上がる。
Q&AとKPTはgithubにまとめています。
Readingagilesamuraiinyokohama · agile-samurai-ja/support Wiki · GitHub
Q&A
KPT
以下、各テーブルのディスカッション時の模造紙
リンク
アジャイルサムライ読書会 横浜道場 「ユーザーストーリーを集める」を開催しました
7月5日 アジャイルサムライ 横浜道場「ユーザーストーリーを集める」を開催しました
今回から第3部に突入、第6章「ユーザーストーリーを集める」をみんなで読みました。
自分もチームに参加して輪読をしました。
自分が入ったチームで話が出たのは、
- 「時期尚早な事前分析」
- 現状の開発では正確な見積もりを求められるので必要
- 本当に必要になるかわからないしムダだよね
- 正確な見積もりを出せるレベルだと、もう作れるのでは?
- 文字で伝えるのは難しい
- 後で見ても思い出せない事も多い
- 文書にすると安心する
- 「ストーリー」
- 詳細に書きすぎると融通が効かなくなる
- ユーザーの言葉で書く事が重要
- INVEST
- 価値を書く事が重要
- 妄想でストーリーを書いていいのか?
- 役割は、顧客とシステム部門とで矛盾するストーリーも発生する
- 矛盾したストーリーを実装するかどうかはPOが決めれば良い
また、うちのチームでは、ビッグウェイブ・デイブのサーフィンショップのストーリーだしワークショップを行いました。
- その他ディスカッションタイム
- 網羅と言う言葉が出てきたら気をつける
- 網羅する事は必要なのか?
- 顧客から求められる
- 価値が明示的な場合には書かなくて良い?
- ストーリーとして記載されていれば書かなくて良い
- 網羅と言う言葉が出てきたら気をつける
他のチームのディスカッションの痕跡は以下の通り
ふりかえり
今回は、@yenjoji さんにファシリテーターをお願いして、自分は一参加者として参加しました。
が、話しすぎてしまったので、次回から気をつけて参加していきます。
Scrum Boot Camp 東京 でワークショップを担当しました。
品川の日本マイクロソフト株式会社様で、6月16日 Scrum Boot Camp 東京(東京都)が開かれました。
メイン講師は @ryuzee さん
安定の講師ぶりで、いつも参考にさせて頂いています。
内容は、各blogにお任せします。
やったこと
今回、自分は、プロダクトバックログ作成のワークショップ
プランニングポーカーのワークショップ
スプリントバックログ作成のワークショップ
を担当しました。
スクラムブートキャンプで初めて、ワークショップを担当することになって
結構緊張すると思っていたのですが、以外と自然な感じで出来たのでは無いかと
思っています。
自分の反省点
- ファシリテートが上手く出来ていなかった。
いきなりワークショップを始めようとしてしまい、ちょっと参加者を置いて行ってしまった感が。。。
- 質問に対して回答を@ryuzeeさんにお任せになってしまった。
とっさに質問の内容を理解して回答をしなくてはならないのですが、質問を理解するのに時間が掛かってしまってました。
初登壇と言う事で、自分にあまり余裕が無かったのが敗因だと思っています。
ブートキャンプ中の質問で気になったのをいくつかピックアップします。
- なぜタスクは時間で見積もるのに、ストーリーはポイントで見積もるのか?
タスクは実際に作業するところまで落とし込む必要がある為、ある程度正確な見積もりが出来るが、
ストーリーはタスクに比べれば曖昧な為、ポイントで見積もります。
- ストーリーポイントとタスクの見積もりとの関係
ストーリーポイントが5だから、そのストーリーのタスクの合計が約20時間である必要がある
等は、考えたくなる気持ちもわかりますが、たまたまその時間になっていると考えた方が良いです。
なぜなら、見積もりはあくまで見積もりであって目安でしか無いからです。
また機会があったら、どんどんやっていきたいと思っていますので
これからもよろしくお願いします。
参加者でアンケートを書いていない方は、今後の為にアンケートの記入を宜しくお願いします。
Scrum Boot Camp 2012/6/16 参加者アンケート Survey
提供:スクラム道
追伸
アジャイルサムライ読書会 横浜道場の方が多数参加してくれてうれしかったです。
もっとがんばろう!