アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」に参加しました

2013/5/14(火) アジャイルサムライ読書会　横浜道場　「現場の状況を目に見えるようにする」に参加してきました。

DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/3455

以下の書籍をターゲットとした読書会なのです。

アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る

場所はいつもの横浜、アットウェアさんです。
参加者は15人くらいでしょか。

今日は通常会ということで、11章「現場の状況を目に見えるようにする」がターゲットでした。
ウチの班は4名で、ホワイトボードはこんなカンジ。


11.1節に「リリースボード」というのが出てきたのですが、私、このプラクティス初めてでした。
ストーリーボードでもタスクボードでもなく、リリースボード。

どうやらマスターストーリーリストをボード化したものらしいです。
ココを最初に読んだとき、「あれ？ユーザーシナリオをマスターストーリーリストで一覧化して、リリースボードにもまたシナリオを貼るの？それって二重管理じゃね？」と疑問に思いました。

その辺のモヤモヤもあって、シナリオとタスクの管理方法について結構ディスカッションしました。
あと、 班の御一人の事例を紹介してもらいました。興味深かったのでメモ。



■ユーザーストーリー（上図の左側）
・横浜道場の付箋を２つ合体させたような、横長で少し大きめの付箋を使うそうです。
・付箋には以下の情報を書くとのコト。けっこー盛りだくさんですね。
　①識別ID
　②ストーリーポイント
　③What
　④Whom
　⑤Why
　⑥やること
　⑦やらないこと

■タスク（上図の右側）
・ユーザーストーリーをタスクに分解する。
・タスクも付箋に書き出すが、ユーザーストーリーより小さい付箋に書く。
・タスクの付箋には、見積時間（理想時間。単位h）と実作業時間の２つを書く。
　→　両者を一目で比較することができ、見積時間と実作業時間が乖離しているタスクがすぐわかる。

■ユーザーストーリーとタスクの付箋運用で工夫していること
・あるユーザーストーリーの付箋と、そのストーリーを分解したタスクの付箋を同じ1枚のA4用紙に貼ることで、ユーザーストーリー毎に用紙で分けているとのこと。
・各開発者の名前シールを貼った磁石を用意し、今誰がどのタスクをやっているかがわかるよう、磁石をタスクの付箋に上からくっつける。
・ユーザーストーリーはチケット管理システムのような電子でも管理しているとのこと。

■バーンダウンチャート

・バーンダウンチャートを１イテレーション毎に書く。
・横軸は１イテレーションの経過日付を書く。
・縦軸の左側にチームのベロシティ、右側にそのイテレーションで開発するタスクの総見積時間を書く。
・バーンダウンで開発完了の線を、バーンアップで実作業時間の線を書く。

こーゆう事例を紹介してもらえるのは大変ありがたいですね。

---

■ウチの班でディスカッションしたネタのメモ

■タスクボードとかインセプションデッキとかを壁に貼ったが、チーム外の他の人に見向きもされなかった。
→　見える化したからといって、上司とか同僚とかが興味を持ってくれるとは限らない。
→　逆に、見える化することで、興味を持ってくれる人とそうでない人が一目でわかるようになる。

■タスクの粒度は8h前後の作業。二日くらいで仕上げられる程度がいいのかも。

■派生開発やXDDPにも繋がるが、ユーザーストーリーは「理由」が大事。
・理由はブレにくい。
・理由を明確にしておくことで、そのストーリーが実現困難になった時とかに代案を探しやすい。
・派生開発では、ユースケースだけでは足りない、と主張している。理由が大事と言っている。
・この話の関連で「ICONIX（アイコニクス）」という開発方法論がある、というお話を聞いた。
・ICONIX（アイコニクス） は、ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論である。
　RUPと同様にICONIXプロセスはUMLのユースケース駆動であるが、RUPより軽量である。
　by wikipedia http://ja.wikipedia.org/wiki/ICONIX

■11.4節のディスカッション
・ドメイン用語とかはWikiに書き残す運用にしている、という話が出た。
・参照で関連付けたり、リンクを押すと定義が見れたりできる。
・手軽に編集できる。
・人の入れ替わりが多かったり新人が入ってきたときに共有しやすい。

■11.5節のディスカッション
・組み込み開発でハードウェアのテストをする際に、バグ監視の指標にMTBFを使っている、という話が出た。
→　テストを継続して行い、バグが検出されるまでの時間（≒MTBF）で品質の安定性を見るらしい。
・バグ対応作業も、チケットや付箋として起票し、見える化して管理すべき。

---

■各班の発表で出たお話のメモ
■用語集は量が膨大だが、勘違いしそうな用語は貼り出すようにしている。
・これまで間違えたことがあるものを張り出す。
・これまで痛い目を見た用語を張り出す。

→
この工夫は個人的には、良いなぁ、と思いました。なんか、思いやりを感じました。
「用語一覧表に書いてあるだろ、ちゃんと見とけやボケ！」みたいな、見た見てない問題のような風景でなく、これは注意が必要だから見ておいてね、という心遣いが見えてなんか良かった。

■貼紙の進化、という概念が紹介されてた。
・貼り出すと、重要なものに集中する、という効果が得られる。
・壁は狭いので、必然的に重要なものを絞らざるを得なくなる。
・自分が報告しなくても、貼り出したものを上司が見てくれれば、報告の手間が省ける。
・陳腐化しない効果もある

■用語集ってそもそもなんで必要なの？
→　お客さんと会話するため、概念を共有するためでは？
→　ユビキタス言語の一種では。

■プレゼン能力が重要、という話が出たが、プレゼン能力って必要？
→　そもそもプラクティスとかがうまく説明ができないのは、理解が足りてないだけでは？

■瑕疵担保期間を過ぎているかどうかで、バグ対応するか否かを変える、という紹介があった。

---

★感想：
予習というか、対象範囲を軽く読んでから参加したのですが、実際にディスカッションしてみると新たな気付きとかが多くてマジ驚き。
あと今回もいつもどおり15分のスプリントを4回回したのですが、11章は2回で読めちゃいました。
なので残りの2回分、30分間はまるまるディスカッションしてました。
これが案外いいと思った。直前に読んだ内容に引っ張られすぎず、11章全体について結構な深さで議論できました。
今後も4回のスプリントのうち、最後の1回は全体ディスカッション用に取れるといいのでは、と思ったり。

懇親会のビールとピザも、おいしかったです。
道場主様、スタッフ様、参加者の皆様ありがとうございました。