DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/2715
場所は有楽町のぐるなびです。参加者は30名↑でしょうか。
私、このイベントの一番の申込者でした。
自分の仕事にも直結するし、なによりも自分にとって興味がある内容だったので即申込したのです。
ちなみにこの講演はデブサミの再演とのこと。
この再演に先に申し込んでたので、デブサミではあえてこのセッションを聴講対象から外しておきました。
以下、聴講時にとったメモ。
■講演者の津田さんからの宣伝（津田さんの著書）
 | 実践 反復型ソフトウェア開発 (2012/12/01) 津田 義史 商品詳細を見る |
■普段はマイクロソフトでテストエンジニアをやっている
■反復型ソフトウェア開発の特徴は2点。
①タイムボックスを繰り返しながらインクリメンタルに開発
②初期の段階でインテグレートする
■今日のゴール
・タイムボックスと継続的インテグレーションを理解することがゴール
・本を買ってもらうことがゴール
■タイムボックスとは
・入り口と出口で区切られた、開発プロジェクトの全期間を表す箱
・作業はすべて、この箱にいれて管理する
・作業を箱に詰めることをタイムボクシングという
・作業の大きさを適切に見積もることが重要
■三択の質問。箱に入らなくなった場合にどうするのか？
１．無理やり詰め込む。（品質を諦める）
→ 残業。品質を落として終わらせる。
→ ひどい結果になる。
２．箱を大きいものに取り替える。（納期を諦める）
→ つまり、スケジュールを伸ばす。
→ それでも入らないと、更に箱を伸ばす、ということを繰り返してしまい、いつまで経っても終わらない。
３．全部入れることを諦める。（スコープを諦める）
→ 正解
→ 本当に必要な作業を詰めていく事ででミチゲート（mitigation）できる。
（mitigation＝痛みを和らげること，緩和，軽減）
→ 作業を箱から追い出すことができる。リーズナブルな値段で開発できるようになる。
★作業の範囲を減すことで品質と納期を守る。これが基本的な戦略。
■ちょうどよいタイムボックスの長さは？
→ 入れたい作業の大きさによる。
→ でも、大きすぎる箱は使いにくい。
→ 大きい箱の中に小さい箱をいれて、間仕切りを作ることをやる。
■作業の大きさを見積もって、計画的に優先度の高い順に積めていく。
→ はみ出したものは次の箱にれる。
■スプリントの入り口では、スプリントプランニングをやる。
マイルストーンの入り口では、マイルストーンプランニンング。
■バックログは、残りの作業の一覧。
→ バックログには3つのことを添付する。
①具体的な作業の内容
②工数
③優先度
■時間を使うものをすべて作業としてバックログに積む。これを作業の入り口で作る。
■途中でバックログを増やすのは基本的にやらない。
・走ってる最中にゴールを動かしてしまうと到達できなくなる。
・次のタイムボックスの入り口で追加するのがよい。
・新しい作業を追加しないとどうしてもダメな場合のみ、バックログに足す。
その際、優先度の低い作業をバックログから削る。
・今目指しているゴールの方向性に「意味がない」と途中で気づいた場合は、プランニングからやりなおす。
■途中でバックログを減らすことはありえる。
・作業を延期する場合は、パントする。
・ボールが落ちる前に蹴って誰かにキャッチしてもらう。とりあえず作業を先送りする。
・作業を次のタイムボックスに蹴り入れる。
→ 「パント」という概念は便利なので覚えて帰ってもらいたい。
■出口条件（Exit Criteria）
・残作業がゼロ
・バグがゼロ(ZBB: Zero Bug Bounce）
・出荷可能（potentially shippable）
(ship 出荷する, shippable 出荷可能)
→ 具体的な数値目標になっていることが望ましい。
■ゼロ・バグ・バウンス
・一部分を引き伸ばすとバーンダウンチャートになる。
・出口条件の到達はプロジェクトを通して継続的に観察し、追跡する。
■出口でスプリントビルドを作る
・ジェフ・サザーランドのScrum Handbookに「スプリントビルド」というのが書いてある。
→ 無料でwebで読める。（http://jeffsutherland.com/scrumhandbook.pdf）
■この範囲の作業は全部やらないといけない、という場合、優先度をつける必要がない。
＝ フィーチャーボックス
■逆にタイムボックスをやりたいなら優先度が大事。優先度を付けないとフィーチャーボックスになってしまう。
■スタンドアップミーティングの15分間のタイムボックスに入らない話題は、捨てるのではなく、次のミーティングにパントする。
→ 優先度をつけて大事なものから報告。
■ウォーターフォールはゴールにたどり着いてから、ゴールが目的のモノかどうか始めて分かる
■CI（Continuous Integration）
・継続的にインテグレーションビルドを作る
・継続的な統合
・XPの一部として紹介されることが多いが、CIも昔からあった。
■「デイリービルドをプロジェクトのハートビート（心拍）とせよ」 by スティーブ・マコネル
ちなみに彼の著書「Code Complete」は入社2年目くらいに読んだが、とても名著だった。
 | Code Complete第2版〈上〉―完全なプログラミングを目指して (2005/03) スティーブ マコネル 商品詳細を見る |
■プロジェクトの初期にビルドを作り、以降も継続的にやっていく
→ 最近は一日一回でなく、１日に何回もビルドをやる。
■「ビルド」を「ビルド」する
＝ 「実行可能なソフトウェア（名詞）」を「実行可能なソフトウェアを構築する（動詞）」
（料理を料理する、という日本語と同等）
■料理をお届けするときに大切なこと
→ いつも同じものを作ること。
■ソフトウェアも同じ。
・いつ誰が作っても同じビルドができる必要がある。また再現性がないとダメ。
・ビルドの再現性を確保することが重要。
■名著「達人プログラマー」
ビルドはCRISPであるべきだ。
・Complete : ゼロからビルド可能
・Repeatable： 再現可能
・Informative： 情報を提供可能（ビルドエラー情報とか）
・Schedulable： スケジュール可能
・Portable： すこかしこでビルド可能
ちなみに私、この書籍も入社2年目のときに読んだ。しかも「Code Complete」の次に読んだ本だ。
 | 達人プログラマー―システム開発の職人から名匠への道 (2000/11) アンドリュー ハント、デビッド トーマス 他 商品詳細を見る |
■CRISPなビルドは「さしすせそ」
■ビルドの再現に必要なもの
・材料一式（ソースコード）
・レシピ（ビルド手順書） → 作業の依存関係
・清潔な厨房（ビルドマシン）
・調理器具（コンパイラ、ビルドサーバ）
■子供をいれて自由に遊ばせるものが「サンドボックス」の由来
・サンドバックスは外界と隔絶している。
・サンドボックスはばっちいところ。
・サンドボックスで作った料理には、虫バグが入る
→ 清潔な厨房（ビルドマシン）でビルドすべし。
■AntはTomcat専用のビルドツールだった。
→ 便利なので、汎用ツールとしてリリースされた。
■リポジトリを清潔に保ちたい。
→ 悪いことを教えてくれるのは、ビルドが壊れたあと。
→ どうせならコミットの前に悪いことは教えてほしい。
→ バディビルドの自動化
■バディ＝相棒
■バディビルド ＝ 修正を相棒に渡してビルドしてもらう
＝ コミット依頼するとサーバがバディビルドとオートメーション（自動テスト）を実行し、OKならコミットする。
■Code Complete（コーディング完了） → 安定化 → Code Freeze（リリースの準備）
・安定化期間でテストをやってバグを消す。
・品質熟成期間、焼き上げ時間、と呼ぶこともある。
・スクラムだと、バグ修正スプリント。
■安定化の時間を長く使ってはいけない。バグ修正スプリントはスクラムでは推奨していない。
■テストをする目的は何か？
・バグを見つけるためにテストする
・バグを見つけられないテストは意味がない
→ 本当にそうか？いや、そうではない。
→ テストをする目的は、バグを見つけるためではない。
・品質の情報を集めるためにやるのがテストである。
・バグがないことを確認するためにするのがテストである。
■Code Complete（コーディング完了）したのに、テストしないとバグがあるのかないのか分からないのはダメ。
■ソフトウェアは短い時間で焼き上げる
■コードコンプリートのあとにテストコードコンプリートがある
■不定期なビルドは、CIビルドと呼ばれる。
定期的なビルドは、スプリントビルドと呼ばれる。
→ CIビルドと定期的なビルドの両方が必要。
■津田さんからのAction
・計画駆動なアジャイルをしてください
・津田さんの著書を買ってください
■ダイアログ
■自動テストもいいけど、Selenimuつかいにくいよね
■手動テストでも、探索テストとかいいよね
■CIで政治的な問題で手動テストが採用されたりとか、CIの教育どうするかとか悩んでる。
■FlashとかSilvertestで自動テストできない。どうすれば良いか？
→ Viewの自動テストが難しいのでViewを極力薄くしてはどうか。
→ Flashのバージョンがまちまち。クリーンではない環境が反乱している。
■テストの自動化は単体テストレベルのイメージだった。でもテストにはフェーズがある。
→ 自動化はどこまで答えてくれるのか？
■開発者がコミットする前に、コミットしていいかのテストをテスターがやる
■実装とテストとレビューをひとまとまりにしている。
エンドツーエンドのテストは不足しがち。製品出荷可能なテストがないと苦しいなと感じている。
■手動テストと自動テストの話は、「テストの４象限」が参考になる。
テストの4象限の話とかはこの資料がいいかもです #devlove アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- on @slideshare slideshare.net/satoshimasuda/…
— takao.oyobeさん (@TAKAKING22) 2013年2月20日■DBアクセスとか、振る舞いが時によって変わるテストはテストが作りにくい。自動化されてたりしますか？
・DBアクセスとかはものにやったらやらない、というのはどうか。
・ロジックのテストはけっこう自動かされている。
・自動テストは何度も実行する箇所をターゲットとするとスッキリするのでは。
・品熟期間に自動テストするのは意味ないのでは。
■最初からテストを作ってないとしんどい。ビルドシステムとかmakefileテストスクリプトもリポジトリに入れておく。
→ ソースをコミットするとmakefileスクリプトが動いてテストされるようにておく。
■4/19,4/20に渋谷の某所でテストのカンファレンスをやる。参加者は120～150人くらい。
CITCON (Continuous Integration and Testing Conference)
★感想：
自分の多少なりともCIを仕事で使ってるので、とても興味深く話を聞かせていただきました。
バディビルドとかゼロ・バグ・バウンスとか、面白い概念や用語も知ることが出来たし。
あと、ダイアログの時間に話を聞いてみると、みんな悩んでるところはけっこー同じなんだな、と思いました。
デブサミの吉羽さんの話を聞いたときにも思いましたが、一度、徹底的に自動化の仕組みを作りこんでみたいと思いました。
最後に津田さん、ぱぱんださんはじめ、会場提供者さん、運営者さん、ありがとうございました。
- 関連記事
-
- 「横浜道場 番外編 "自分の価値観を見える化してみよう"」に参加しました
- 「ビルド中心の開発 - タイムボックスと継続的インテグレーション -」に参加しました
- アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」に参加しました
