「実践反復型ソフトウェア開発読書会 -反復1-」に参加しました

2013/3/13(水) 「実践反復型ソフトウェア開発読書会 -反復1-」に参加してきました。

DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/3018

会場は日本オラクルです。@yokatsuki さん、いつも会場提供ありがとうございます。
参加者は12名くらいでしょうか。
以下の書籍をターゲットとした読書会なのです。

実践 反復型ソフトウェア開発 (2012/12/01) 津田 義史 商品詳細を見る

先日もDevloveでこの書籍に関するイベントがあり、それにも私、参加してブログに書きました。↓

2013/2/20(水) 「ビルド中心の開発 - タイムボックスと継続的インテグレーション -」に参加してきました。
http://makopi23.blog.fc2.com/blog-entry-51.html

今回は、先日のイベントの元ネタとなっている書籍の読書会という位置づけです。
今日は１～３章がターゲットでした。

1チーム3名くらいで参加者をチーム分けし、チーム毎にディスカッションというのを2回やりました。
2回目はメンバ交代で。

以下、チーム内ディスカッションや、共有の時間に他チームから出た意見のメモ。

---

■この書籍は教科書的な役割を果たすが、具体的にどうやるかは書いてない。
　→　具体的なやり方はこの読書会で話したらよいのでは。

■この本では、タイムボックスとフィーチャーボックスの２種類がある、という紹介がある。
　→　やっぱタイムボックスでやりたいよね～

■テストエンジニアって、結構いないけど重要だよね。
→ TISの鈴木三紀夫さんは、テストエンジニアとしては強烈、との話が出た。

■Rubyとかのスクリプト言語だと、明示的にコンパイルしないので、ビルドという感覚があんまりない

■図1.3の進化で、自分のやってるブランチが正しい方向に向かっているかをどう判断するか？
・進化を管理するためには、ブランチもきちんと構成管理しないといけない
・多様性を残すために、あえてブランチをマージせず残しておくこともアリでは。
　→ あるブランチがうまくいかなかったら、うまくいって残しているブランチに戻るとかできる。
・むりやりマージするとかダメよねー
・特定顧客向けにブランチを切ることはあるのでは。→　役目を果たしたら途中で捨てちゃう。
・スマホ対応家電とかはいきなりドクロに向かうブランチなのかも（笑
・Webサービスだとリリースは１つなので、基本はブランチ切ったらマージされることが多い。
・マージして１つのマスタにしてしまったら、試行錯誤の経路が失われる。
　→ ブランチを残しておくのもありでは。
・ドクロへ到達する期間が短いブランチはありえるのでは。数日とか。
　→　例えば、経営層に見せるためのバージョンをブランチで作って、ダメなら捨てるとか。

■開発が始まってからテスト自動化の仕組みを作り始めるのは遅い。
　→　プロダクトコードがない段階、スケルトンの段階からテストの仕組みは作り始めるべき。
　　　（この書籍で言うと、ゼロ機能リリースに該当するかなぁ）

■ドキュメントを作るのは、開発範囲を明示することで自分の身を守るためであることが多い。

■派生開発だと、その仕様になった「理由」を重視する。理由に迫ることで本質がわかる。理由は安定度が高い。

■見積りをストーリーポイントでなく時間で見積もると、精度が上がった。
　・この人はこの日は休暇を取得するとか、この日のこの時間は～～やる、とか、稼働時間がいくらになるかを詳細に詰めていくと見積りの精度が上がったとのこと。
　→　アジャイルは相対見積りで正確性はあまり推奨していないが、こーゆうやり方もアリ。

■リリースプランニングをあまり意識しないまま進めると、マイルストーンの最後の方になって、ぜんぜん間に合わないことが初めてわかる。。。
　→　リリースプランニングを意識してイテレーションを進めていくことで、それらを改善できた。

■ウォーターフォールバリバリのプロジェクトにテスト工程から途中参加するエンジニアに対するアドバイス
　・テストでは、業務要件だけ満たしていることが確認できれば良しとする。
　　（コードがぐちゃぐちゃのプロジェクトに途中参加する場合は、それしかできないのでは）
　・勉強会をやろう、と言うと拒否反応を起こされるので、コードレビューという名目で勉強会をやる。

■BMWでは、600人規模でアジャイル開発をやっているらしい。
　→　チーム毎にPO（プロダクトオーナー）を立ててスクラム的に開発し、スプリントレビューの場では各チームのPO自身がデモするんだとか。
　実に興味深いです。

■チャンピオンやドライバに相当する人が自発的に出てこないとマズイ。

---

★感想：
うーむ、書籍の内容というよりか、反復開発をテーマにざっくばらんに議論してしまった感があり、ちょと反省。
でも、こーゆーのもありかなーと思っている部分もあります。

あと、この書籍は私がこれまで読んできたアジャイル系の書籍と違って、だいぶ風変わりに感じました。
チームの組み方にしても、ビルド中心の回し方にしても。
コンプリートとフリーズの概念とか、テストエンジニアやテスターが開発者と分離された状態のロールとして定義されていたりとか、興味深いです。
また書籍名の一部に「ソフトウェア開発」という単語があるように、かなーりプログラマよりな視点だなぁとも思いました。
5章とかにブランチの話とかにページ数を割いていたりと、まだ読んでませんが新しい気付きが得られそうで楽しみです。

あと、著者の津田さんが風邪で欠席となってしまった点がちょびっと残念でした。

最後に、主催の papanda さん始め会場提供の @yokatsuki さん、参加者の皆さんありがとうございました。