アジャイルサムライ横浜道場「イテレーション運営：実現させる」に参加しました

2015/3/10(火) アジャイルサムライ横浜道場「イテレーション運営：実現させる」に参加してきました。

DoorKeeper
https://yokohama-dojo.doorkeeper.jp/events/20719

以下の書籍をターゲットとした勉強会（？）なのです。

アジャイルサムライ――達人開発者への道 (2014/06/25) Jonathan Rasmusson 商品詳細を見る

場所はいつもの横浜市西公会堂です。
参加者はスタッフさんいれて１０人かな。

今回は第9章「イテレーション運営：実現させる」がテーマです。
最初に道場主が9章の電子書籍版をプロジェクタに映しながら一通り説明を行いました。
その後各自、議論したい内容をホワイトボードに書き出し、投票で得票数の多いものから順に話し合いました。

ホワイトボードはこんな感じ。


以下、メモ。

---

■ ストーリーの書き方について
いちばん得票数が多かったテーマ。ちなみに、私がホワイトボードに書いたテーマ。
この章に出てくるストーリーの例として

• 作業許可証を申請する
• 作業許可証を印刷する
• ユーザーを追加する

とかが挙がってるんですが、これって「価値」じゃなく「機能」まで落とした書き方になってる点が気になりました。
書籍の6章に「よく書けているユーザーストーリーとは」というテーマがありますが、「価値がある」とか「ビジネス観点で」とか、書き方のアドバイスが書かれています。
でも上の例は、あんまりそうなってないかなー、と思ったのです。
もう一段、上の要求があるのでは、と。
例えば「ユーザーを追加する」というのは手段の１つであって、あくまでホントの目的は「ユーザー情報を管理したい」とかじゃないの？

というわけで、参加者さんから出た意見は以下のとおり。

• TFSを使ってるが、ストーリーを書くときに「～として、～がしたい。それは～だからだ」というテンプレートが出るようにしている。
• Tracのwikiに、良いストーリーの書き方例を、具体例を使って提示している。
• なぜストーリーという書き方が良いかというと、ディスカッションするための元ネタになるから。
• 価値ベースじゃなく機能ベースでストーリーを書いてしまうと、代案が出てこない。
  • 価値ベースで書いておくと、「それを実現するにはあの方法もあるよね」とか代案が出やすい。
• ストーリーは顧客に書いてもらうのも良いのでは。

■ タスク管理ってどうしてる？
このテーマは、ぺらさんが出してくださいました。
ちなみに私もこのテーマ、挙げようと思ってたんですよね。
というのも、アジャイルサムライもScrumBootCamp The Bookも、ストーリーをタスクに分解するお話が出てこないんです。
スクラムではスプリントプランニングで、プロダクトバックログアイテムをタスクに分解してスプリントバックログに積みますよね。
このネタが両方の本で、あまり出てきていないのが不思議でした。

このテーマで出てきた話題は以下のとおり。

• タスク管理は、カンバンに近い形でやっている。
• 最初はタスク分割するけど、慣れてきたら、タスクに分解せずにストーリーのまま開発を進めるやり方もある。
• タスクに分解せず、ストーリーの数だけで見積もるやりかたをやっている。
• タスクに分解すると、ポイントでなく時間単位で見積もれるようになる。
• 直前のイテレーション分だけタスクに分解している。
• タスクは、付箋のアナログ形式と、JIRAの電子形式で、１つのタスクを両者で管理している。
  • タスク分割に際にまずJIRAに書いて、そのあと付箋にも同じのを書くようにしている。
  • 二重管理になるが、慣れるとそれほど手間ではない。
• 遠隔地の分散開発だと、タスク管理は電子ツールに頼らざるをえない。
• 付箋をタスクボードに貼りに行くという行為自体が重要。そこからディスカッションが生まれる。
• Excelでタスクを管理すると、いつでも見れない点がダメ。

■ イテレーション・ゼロでスタートする為のチェックリストは有効？
イテレーション・ゼロで何を準備しておくかをチェックリストにしておくことは有効か？というテーマ。
他にも、イテレーション・ゼロ、スプリント・ゼロそれ自体の話題とかも出ました。

• チェックリストあれば有効なんじゃね？
  • イテレーションが進むと毎回、イテレーション・ゼロで何を準備したっけ？と忘れてしまう。
  • 次に活かすためにチェックリストとして残しておくと良いかも。
• CSM研修で講師の江端さんは、スクラムにはスプリント・ゼロというイベントは定義されていない、と言っていた。
  • 最初のスプリントの中で準備とかもやる。
• イテレーション・ゼロ用のチェックリストではないが、楽天の川口さんがHenrik Kniberg氏のスクラムチェックリストを日本語に訳して公開している。
• スクラムのアンチパターンとして「ScrumBut」というものがある。高江洲さんが詳しい。 by 道場主
  • Scrumのアンチパターン「ScrumBut」とは？  Ryuzee.com
  • ググると、先日のScrumGathering Tokyo 2015の道場主と高江洲さんのスライドがヒットした。

ざんねんスクラム座談会 from Takaesu Makoto

---
以降は時間切れでほとんど議論できなかったテーマ。


■ イテレーション(ｎ)で分析、次のイテレーション(n+1)で開発？
9.4節に「イテレーション(n)で分析をして、イテレーション(n+1)でストーリーとして開発する」という図があります。
この、ジャストインタイム分析がテーマです。

私もこの図、1巡目の読書会で意味がわからなかったんですよね・・・
たぶん、この概念はスクラムでいうバックログリファインメント（バックロググルーミング）に該当するんだと思います。
ちなみに、次回10章の10.1節の最後に、この話題が書いてありそう。

あと、「最初に全部分析しなくて大丈夫？最初に全部ちゃんと検討しましたか？」みたいな上司の考えに対する壁がSIerにはある、みたいな話題も出ました。

あと、分析ってどこまでやるの？というのもありますよね。

■ ユニットテストが無くても、イテレーションは回せる？

アジャイルをやろうとしたら、「自動ユニットテストなんて無くてもいいじゃん」と会社の雰囲気がなっているそうな。
お金を掛けたくない文化があって、テストデータとかExcelで作ってる、という話も出ました。

■ カンバンって実際に使ってる人？
TFSは2012からカンバンが使えるそうです。

---
そんな感じで、時間切れで最後の方のテーマは議論が出来ませんでした。

---

■ おまけ
終了後の飲み会にて。前回と同じ中華屋さん。
皿うどん、1人前なのにめっちゃデカい！

---

★感想：
年度末なためか、参加者は少なめだったので、もうちょっと参加者が集まるといいかなぁ。
でも、ディスカッションするにはちょうどいい人数かもしれない。

あと、この章でカンバンとWIPのお話が出てきますが、WIPってカンバンのレーン毎に設定することもあるようですね。
これは書籍には書いてなかった。

スタッフさん、参加者の皆さん、ありがとーございました。