アジャイルサムライdevLOVE道場 最終回「飛翔」 2012.1.28

リアルタイムツイートされてしまいました。。
まさか最終回に寝坊するとは…orz

・・・・・・

ブログに書くのはこれが初めてとなりますが(単にサボっていたorz)、実はdevLOVE主催の勉強会
「アジャイルサムライdevLOVE道場」に参加しておりました。

アジャイルサムライ−達人開発者への道−

第一回の模様を紹介している記事はこちら。
「アジャイルサムライ読書会　DevLOVE道場 第一回【萌芽】」詳細レポート
(そういえば、当初は11月完結予定だったんだね…)

実際はこんな感じのスケジュールでした。
第一回「萌芽」　2011/8/25
第二回「発展」　2011/9/20
第三回「深化」　2011/10/20
第四回(開発Day)　2011/12/4
第五回「飛翔」　2012/1/28

３〜４人のチームでそれぞれ造るモノを決め、実際に「インセプションデッキ」「ユーザストーリー」を作り、
タスク分割、開発作業…など(かなり駆け足で)やったものの。

モノはできませんでした。。。(+o+)

ともかくふりかえり

チームで出た感想。

• どんなチームでもプロダクトオーナー、スクラムマスターの存在は必要
• 決定権の無い人同士だと難しい。物事の決定・マネジメントをする役割も立てればよかった
• 本を読むだけではなく、それに沿って実際にやってみて気付くことも多い

まさに「見るとやるじゃ大違い」と言いますか、正直まだ本の内容も読み込めてないこともあり
ストーリーの切り方、タスクの粒度、いちいちつまずいた気がします。
それに、メンバーが互いに遠慮しあってしまい、「何を作りたいのか？」がぼんやりしたまま開発に入ってしまったことも
うまくできなかった要因の一つだと思います。。。

マスターセンセイ

また、今回はこの本の監訳者である西村直人氏と角谷信太郎氏が特別ゲスト「マスターセンセイ」として登場。
参加者が両名にききたいことを寄せて、いろいろ答えてくださいました。以下抜粋。

Q：タスク分割にどのくらいの時間を割くべきか？
A：これなら作れそう、と納得できるまで。目安としては2週間のタイムボックスならば2時間くらい。

Q:そもそもタスク分割って何？
A:自分たちの作業をみつけること。チーム内でどうすれば終わらすことができるか、それはチームや各メンバーのスキル・職種・成果物によって異なるのであえて本では触れていない。

ストーリーは要求→それをどう作業(タスク)に落とすかは自分たちで考える。

Q:ストーリーを満たすために新しくシステムの設計が必要になる場合、それもタスクと呼ぶべきか？
A:初めてのメンバー、初めての案件であるほど必要。

アジャイルやろうという時、急いでスプリント計画やイテレーションを回さないといけないと思ってないだろうか？
プロジェクトを始める前の事前準備は大切。そこをじっくりやってから回せばよい。

Q:タスク洗いだしのコツは？
A:いろんな立場に立って考える。初めから全てのタスクを洗い出すことは不可能。あとから漏れをみつけても、それをカヴァーできるようにイテレーション内で動けていればよい。むしろそのほうが大事。

• 「この人にしかできないタスクがある」という状態は避ける。

今回の道場は分散型パートタイム的チーム編成だったので、アジャイルには一番向かないパターンかもｗｗｗ

Q:ストーリーポイントの振り方。１、３、５で振るけれど、同じ３でも１で振ったストーリーよりは大きいが３倍ほどはない…というものがある場合迷う。
A:数値はあくまで計画を立てるための目安でしかないので、だいたいあってればよい。(カンバンはS/M/L)

Q:インセプションデッキってあの形式で使えるもの？
A:あのままの形式でもわりと使える。少し追加してもいいとも思う。

• もともと英語で書かれているものを日本語訳しているので若干違和感のある表現になっているが、むしろエレベータピッチの日本語訳の方が難しかった。
• トレードオフスライダーは認識合わせに使える。
• やらないことリストもいい。やることはほっといても湧いて出てくるので、早いうちからやらないことを決めておけば本当に大事なことに集中することができる。

Q:本の順序どおりにインセプションデッキを決めていくべきか？
A:多少順序を変えても問題ない。一度作ってそれきりにせず、必要に応じてアップデートできていればよいものなので。

Q:ご近所さんはどこまでの範囲を言うのか？たとえば外部のシステムを使う場合、それもご近所さんと呼ぶのか？
A:コアチーム+調整を含む作業的やりとりが発生するところ(人)は全て指す。ご近所さんは人が対象。システムそのものは含まれないが、システムを利用する上で担当者と何らかのやりとりが発生するならばそのシステム担当者もご近所さんになる。

書ききれないほどご近所さんがいるときは…泣きながら全て挙げだそう。。。
→書ききれないほどいる場合、そのこと自体が問題であることがわかる(代表者を立てれば済むのではないか、など環境の問題点をあぶりだせる)

Q:スクラムマスター以外のメンバーがご近所さんと仲良くなるためには？
A:本来、スクラムマスターは目立ってはいけない。問いの例はチームを守ろうとするあまりスクラムマスターというよりリーダーの仕事をしてしまっているパターン。
スクラムマスターは黒子であり、チームが開発に集中できるように動くことが大事。

Q:チームメンバーが開発に集中できず、しょっちゅう相談の場に連れ回されていることが日常化しているが…
A:対策としては、
・もう少し要件を揉んでから会議に呼んでもらう
・複数メンバーがいれば、交代で会議に出る
・相談してくる側にも、開発者の手を止めていることをもう少し分からせる必要がある。
・定例会議を設定し、相談や調整ごとは全てその時間内にしか受け付けないようにする。

Q:メンバーは離れていても大丈夫？
A:開発チーム内で離れてしまうのはツライ。やむを得ず離れる場合、それでも大丈夫であるというコンテキストがないと実際難しい。

総評

西村氏
・実際に剣を振ってみたからわかることがあったと思う。(やらないことリスト、ポイント見積もりなど)
・今回やったことを自分の現場でやろうとすると…もっと苦労しますｗ

角谷氏
・全五回で開発というかなりムチャのあるものだったので、成果物ができなかったことでがっかりする必要はない。むしろその過程での気づきが大事。
・思っていたよりもあまり上手くできなかったのではないだろうか。現場に持ち込むと、なおさら感じると思いますｗ

Togetter

最後にトゥギャりをぺた。
アジャイルサムライ DevLOVE道場 #5 飛翔