# Agile459読書会(2018/04/25)

## 近況
### @ueda
- 前回の「制約理論」について調べたら「ザ・ゴール」に行き着いて半分ほど読みました。
> なのでもう一度、ザ・ゴールを見る。（疲れるけど）
- 風邪気味で読書会の時は@gotさんのコメントに気づかず。今になってびっくり。
- Gist便利ですね。（今頃ですみません

### @kobatomo

### @kkd

### @got
- AgileJapanのテーマの一つでている「ビジネスとAgile」が頭の中をぐるぐる回る。

## 今回の役割
- 司会：@got

## 今回の目標
- 12章 スコープの管理
- 13章 テスト：早めに、こまめに、自動化

## タイムテーブル
- 19:30 - 19:35 自己紹介や近況など
- 19:35 - 20:05 12章
- 20:05 - 20:45 13章
- 20:45 - 21:00 振り返り

# 12章 計画：スコープの管理
### @ueda
> 現実離れした計画=不明確で不安定な人間関係
- 流れが悪いとさらに水圧をあげる
> 現実の変化を反映して調整された計画=リスペクトに満ちた相互に重要な人間関係
- そういう建設的な議論がされていれば、と強く思う。
- 火消しができたときは良い関係ができた。その中でも良くないコードには厳しく対応。
> 計画づくりが、XPの毎日、毎週、四半期ごとの活動 -> 新しい事実が登場すれば、それに合わせて計画を変更
- 硬直しているプロジェクトが多かった。
> チームの全員が計画づくりに参加すべきである。
- 強く同意。
> 一見すると発散的な顧客のニーズ
- チーム全体で相談
> すべてのストーリーをシャッフルして新規に並べ直す。
- 簡単に取り組めそうですね。
- データにしてしまうとできないけど、物理（付箋）にしたらできそう！
> 全員で見積もりをすれば、平均的な値に落ち着く。
- ふと思い出したトリム平均。異常値を取り除く。フィギュアスケートやスキージャンプの採点。
> ペアになると２倍以上の効果がある。ペアでやる方が完全でクリーンなコードが手に入る。
- 納得です。スキルの差があればお互いの教育にもなるし。
> 進捗が遅れているときは計画の再調整。顧客にストーリーを選択してもらう。
- こういうときこそ顧客と相談ですね。逆のパターンが多いような。
> 調整しないと、チームや個人の信頼が損なわれる。
- とても日常的なお話。
> ストーリーをインデックスカードに書いて、人目につきやすい壁に貼り付ける。透明性の実践。
- まずはここからですかね。XPへの取り組み。

### @got
> 「現実離れした計画」と「現実の変化を反映して調整された計画」
- 「死んでいる計画」と「生きている計画」？
計画と現実が離れているのになぜか変わらない（変えない）計画ってのを見た。
- でも経験の中で「生きている計画」と思っていたものも「時間」だけしか変えてなかった（すでに死んでいる？）
- 結果、気合（体力）でカバー・・・
> 計画の不確実性は、計画の重要性を否定するものではない。
- 「計画が不確実」だから「計画すること重要性は低い」と考える人がいる？
「計画すること重要性は低い」から「計画が不確実ままでいい」という考えがある？
> 品質が下がる→満足度が下がる→人間関係の崩壊
- 13章ストレスやTDD本で出てくる因果ループ図のイメージ。
> 計画づくりはチームが要望を認識する会議の場だが、専念するのはニーズだけだ。
> 計画づくりとは、「既定の時間内」に「耳を傾け」、「意見を出し合い」、「ゴールの認識を合わせる」もの
- 目的を見失わないように。
> 見積モデル、ストーリーに対するポイント付け
- 次は「アジャイルな見積りと計画づくり」を読みます（課題）
> ニーズやそれに関係する問題をチームがすべてを把握しておかなければ、ビジネス的にも技術的にも優れた選択をすることはできない。
- また出たビジネスの話。
原則の経済性（Economics）と相互利益（Mutual Benefit）を読み直し。
> 物事がうまくいかないときこそ、価値と原則を忠実に守り、プラクティスを修正して、有効性をできるだけ維持する必要がある。
- 価値と原則は変わらない。プラクティスを修正するためにはブレない軸が必要。
> 壁に貼ったカードは、透明性の実践だ。
- これまで出てこなかった「透明性」という言葉。原文はTransparency？
> 定義
> メタファー（イメージ）
> 必要なもの
> やり方（アドバイス）
> 問題が起きたら
- 原文だと単語が使い分けられていそう。
- @kkdに聞いてみよう！
- スコープと継続的な開発だからこそ出てくる言葉？
- 単発の仕事だとスコープを変更する＝仕様を変えてしまうことになる・・・
- 目の前に出てきたものを見ると、必要だと思っていたものが必要ではなくなることもある。
- フィードバックによるスコープ変更
- 作ろうとしていたもの7割がムダ

# 13章　テスト：早めに、こまめに、自動化
### @ueda
> スペースシャトルでは、ソフトウェアの欠陥は１世紀に1つまで制限されているはず（はずって何...?
[Developing software for the space shuttle](https://history.nasa.gov/computers/Ch4-5.html)
> Just days before the STS-7 flight, in June, 1983,
> an IBM employee discovered that the latest release of the compiler had a bug in it.
- コード自体に問題がなくてもコンパイラがバグってるなど。
- "Box 4-4: How IBM Verifies the Shuttle Flight Software" のくだりなど興味深い。
- 結局、
> however, the software can never be fully certified, and both IBM and NASA are aware of this.
> There are simply too many interfaces and too many opportunities for asynchronous input and output.
- で締めくくられているのはどうなのかと...
> 欠陥コスト増加(Defect Cost Increse)
> フィードバックループの長いソフトウェア開発スタイルはコストが高く、多くの欠陥が残る
- テストを書かずに、のちのテスト工程（テストチーム）を設けているプロジェクトにはこのように説明すればよかった。
> お互いが期待していることを伝達するコストは膨大
- 膨大というか、なかなか収束しない。伝わらない。

### @got
> 欠陥は信頼をぶち壊す。
- ここ１、２年の間で対岸（というよりは真横）で発生。その余波が管理台帳やチェックリストの増加を生むことに。
> 欠陥削減に対する投資は、チームワークに対する投資
- 人を増やして（間違った投資して）一部の欠陥を削減することはできても、チームワークは・・・
> 欠陥の発見や修正の予算は限られている。
- 技術的負債に対してお金を出す人の認識。
> 「プログラマーの視点で書かれたテスト」と「顧客やユーザの視点で書かれたテスト」
- 「コードに対するテスト」と「ストーリーに対するテスト」という認識で合ってる？
> 手動テストと自動テスト
- 手動テストのストレスはきつい。
そしてストレスから生まれる「影響ないんだからテストしなくて良いんじゃない？」を消しさりたい。
今はそれが一番の課題。
- ゼロから始めるからコストや期間の壁もあるけれど、得られるものは大きいはず。
> いつテストするか
- ウォータフォール型でも設計に対するテストはできる。
けど、テストをテスト工程直前に書く人が多くて、工程内でも後でも爆発する。
テストのつくり方としてのV字モデル自体は悪くないはずなんだが・・・
> 私は失敗するテストが1件だけになるようにしている
- ここまで書いておいてテスト駆動開発（執筆時点で発刊済）にあえて触れていないのは意図がある？
- 参考文献で「テストファーストプログラミングとインクリメンタルな設計の入門書」とも書いてあるのに・・・
- あくまでも「手法」の一つだから？

## ふりかえり
### @ueda
- ところで The Goal を知ったのは？
- 仕事の先輩から。ボーイスカウトの荷物を持ったところが面白いと聞いた。(@got)

### @got
- 二人だと歯止めがきかない・・・
- タイムボックス重要

## 次回
2018/5/9 (水) 19:30 - 21:00
14章、15章

### 役割分担
- 司会： @ueda
- connpass： @got
- connpassグループ通知
- グループ → グループにメッセージを送る
- wiki： @ueda
- hackmd： @ueda

## ベロシティ
読書会のベロシティを測ろう。
- 前々回は、４ページ
- 前回は、10ページ
- 今回は、11ページ