2011/01/22

[読書メーター]2010年 12月読書まとめ

去年の12月の読書まとめ。
なんと三冊しか読んでいない。
理由はきっとリトルリトルクトゥルー
長い本じゃないのに、読み終わるのに多大な時間を費やしました。
きっと超短編の集まりなので、飛ばすところがなかったのが原因かなと思います。


12月の読書メーター
読んだ本の数:3冊
読んだページ数:800ページ

阪急電車阪急電車
ええ本です。各駅停車の恋話連作。宝塚駅に始まり西宮北口で折り返し宝塚駅まで。久しぶりに関西の女の人の強さと可愛らしさを再確認。関西人情はやっぱええね。
読了日:12月30日 著者:有川 浩
リトル・リトル・クトゥルー―史上最小の神話小説集リトル・リトル・クトゥルー―史上最小の神話小説集
これぞクトゥルーのバイブリオン!クトゥルーを全く知らない者は脳を崩され、多少知っている者は深くはまり、大いに知る者はテケリ=リ!
読了日:12月27日 著者:
猫物語 (黒) (講談社BOX)猫物語 (黒) (講談社BOX)
読了日:12月01日 著者:西尾 維新

読書メーター

2011/01/19

スクラム道.03 スプリント計画ミーティング

1/7日に永和システムさんで行われたスクラム道.03に参加してきました。
今回のテーマは「スプリント計画ミーティング」

Twitter上でも話題にあがっていたけど、
どうやらスクラム道のレポートブログが少ないらしい。
(私の場合は、平日は仕事の忙しさ、週末は子供と遊ぶのを理由に怠けてただけなんだけどね。)

ただ、レポートを書きやすいか書きにくいかでいうと書きにくい。

私が行ってる他の勉強会のスタンスは「Agileってこんなのだよ〜、W/Fの人にも分かりやすく説明するよ〜」ってノリが多いのに対して、
スクラム道は実際にスクラムを使ってる人たちの集いであり、専門的な話、実践している人しか分からない話が多い。
「下手な事はかけないなこりゃ」って気持ちがある。

今までは大した前提知識がなくても、なんとなく「Agileってこんなものなのか」と納得できてしまう内容だったのだが、スクラム道は「初心者歓迎」と書かれてはいるが、実際には初心者には厳しいのではないかと思う。

だが、そこがイイ。
一歩踏み込んだ議論の場ってのは中々ない。
ああ、私はこんなにスクラムの事を知らなかったのだな、と感慨深く思う。
(本読めよ)



大幅に横道にそれたけど、レポート書いていきます。

スクラム道の進行は三幕構成になっており、

  1. テーマに沿った読み手さんの発表
  2. それに対する質問とディスカッション
  3. 懇親会

となっています。


私はちょっと遅刻していったので、一幕の途中から参加だったのが残念。
参加した時はプランニングポーカーの話でしたね。

発表の内容はスプリント計画ミーティングについて。

ミーティングには1部と2部があり、
それぞれで各担当者(PO,SM,Team)の振る舞いが変わるといった話がメイン。
特にPOの扱いに関して発表の最中も色々と論議されてました。
※発表されたスライドの内容以下参照

Check out this SlideShare Presentation:
スプリント計画ミーティング
View more presentations from Miho Nagase.


発表が終わると次は皆で質問を持ち寄って喧々諤々と議論開始。
主たる話題は、POの扱いとタスクの分割をどのようにやるか、
特に「特定の人にしか出来ないタスク」をどのようにバラすか?
そのようなタスクを持ってる人の扱い方。
この辺りが実際にスクラムしてる人たちもお困りの様子。

議論が終われば懇親会へ行って皆で議論の続きをフリーディスカッションして終了。
酔っ払いの脳みそに残った記憶の残滓は

  • 「パッションは有限」
  • 「ScrumにCraftmanshipがないのはわざと」
  • 「スクラム道は初心者向けではなく一歩踏み込んだ議論の場」


まとめ
スクラム道は他の勉強会とは少しばかり雰囲気が違う。
パブリックな講演会ではないし、プライベートな仲間内での議論とも違う。丁度その間に位置する勉強会だと思います。


以下蛇足

二幕の議論の元になるポストイットの中で大して話題には上がってないけど気になった議題に
「タスク分割とWBSの違いは何か?」
がありました。

スクラムでのタスク分割はストーリー(バックログ)を実行可能なタスクにチームが分割すること。
W/FのWBSは作業工程を分割したタスクの積み上げで表すこと。
似たことを言ってるようだが、これらを同じものと言うことは直感的に違和感を感じる。

スクラム道の場では大した話題にはならなかったが、気になったので会社のW/Fラー達と話してみた。
(自論をぶつけてその反応を見るといった一方的な対話ではあるが)

まず、端的にスクラムのタスク分割を説明し、WBSと違うか?と聞いてみた
「同じものだと思う、言い方が違うだけではないか?」

そこで、もしWBSにマネージメント層もしくは客先のコミットメントが付与されていない場合はどう思う?
「そんなもの渡されても、取り扱いに困るだけだ。」

WBSとタスク分割の差はこれではないだろうか?
原理主義者が細かいところをつけば、タスク分割とWBSは違うと言うかもしれないが、私は両者は置換可能だと思っている。

しかしながら、実際の運用方法に大きな違いがある。
WBSにはコミットメントの付与が必要不可欠であり、
実際にチームの人たちが使う段階には、対内外的にコミットメントされている必要がある。
(comprehensive documentationであり、contractである)

こうでないと、W/Fのチームは作業を開始できない。開始してはならない。

よって、チームはWBSを変更できないし、
新しいタスクが発生したところでタスクの追加も出来ないので、
99%進捗イナズマ線ぐちゃぐちゃ現象なども発生する。

こんな感じだろうか。