# Agile459読書会(2018/05/23)

## 近況
### @ueda
- d3jsのチャートを手直し。[縦軸の最小値をゼロに。横軸が非表示だったので表示。](https://npmyj.github.io/reading-circle/burndown.html)
- 各値が見えるといいなぁｗ(@kkd)
- ザ・ゴールに続いて、クリティカルチェーン読んでます(39%)。ストーリー中の各場面で行われる議論、同じ議題を身の回りの人と議論してみるのも面白いかも。
- EC2のユーザーホームのpermission設定をミスしてログイン不可に。別のインスタンスにボリュームをアタッチして修復。

### @kkd
- 山口の周防大島に合宿にいってきた。そこでXPの価値を読み直した。宮本常一是非読んで。
- 創意工夫すること、いきいきとした暮らし、進歩とは何か？いろいろ現場に通じる話がある。

### @got
- アジャイルな見積りと計画づくりを読み始めた！
- 本の厚さと文字の小ささに驚いている。
- 新しめの本も読みたい。（カイゼンジャーニーとか）
- 並行で読めるだけの余裕なし。。。

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

## 今回の目標
- 15章 XPのスケーリング - 期間
- 16章 インタビュー
- 17章 はじまりの物語

## タイムテーブル
- 19:30 - 19:40 自己紹介や近況など
- 19:40 - 20:05 15章
- 20:05 - 20:25 16章
- 20:25 - 20:45 17章
- 20:45 - 21:00 振り返り

# 15章 XPのスケーリング

## 期間
### @ueda
- 頻繁に開始と停止を繰り返すプロジェクト
- 「ロゼッタストーン」を書く。将来の保守のための簡単なガイド。
- 環境の説明とかテストの回し方とかがあれば良いですかね。
- そもそも開始と停止を繰り返さないようにしたい。

### @got
> プロジェクトが停止する前に、XPチームで「ロゼッタストーン」を書くことが多い(p.110下)
- 停止ししてからでは遅いし、停止する前（気配すらないのに）書いてしまって変更コストがかかるのも微妙。
- 「新たに配属される保守担当者」がいることを前提として書くのならいいのだけれど・・・
- バランス難しい。

### @kobatomo
- テストのおかげでっていうの大事。

### @kkd
- 期間が長くなればなるほど、XPのプラクティスがきいてくる

## 問題の複雑さ
### @ueda
- 専門家とペアになって課題に取り組む。プロジェクトの中で学習。
- 理想的！！こうあるべき。こうありたい。こうあってほしい。
- ドメインエキスパート重要ですね。そういった人たちがどのくらい関わってくれるか？（@kkd)
- 忙しいからと関わってもらえない場合など。本当に必要？

### @got
> アクチュアリーとのペア(p.111中)
- ペアプログラミングではなくて、ペアワーク（ラーニング）？
- 協力というよりリスペクト大事。

## 解決策の複雑さ
### @ueda
- ビルドプロセスの制御（自動ビルド）
- ストーリーとストーリーボードにより取り組んでいる課題と時間を可視化。
> 継続的にデリバリーしながら少しずつ複雑さを削り取っていく。
> 適切な作業に必要な見積りが受け入れられやすくなる。
- 見積りから始まるのではなくて、XPで進めていく中で見積りが立てやすくなる。見通しが良くなる。

### @got
> システムが成長して複雑になり...ここでの挑戦は、問題をさらに悪化させないことだ。(p.111中)
- 成長にともなって複雑化し、問題が発生する。その問題を「受け入れる」ことと「眼をそむけること」は違う。
- でも受け入れて対峙することは簡単じゃない。

> 墓穴を掘る状況を脱する(p.111下)
- 墓穴から這い上がることだけに集中するとダメだよね。

> 計画づくりを見える化すれば、時間がかかっている場所を全員が把握できる(p.111下)
- 「全員」の範囲はXPチーム全体？顧客も含む？
- きっと広ければ広いほど良いと思うのだけれど・・・

### @kkd
> 少しづずつ複雑さを削り取っていくのである。自分のいる一隅を光で照らそう。
- Baby Stepだよね。小さくでもいいから、前進する。一歩一歩信じて。

## 失敗の重大さ
### @ueda
- 前にはNASAの引用がありましたが、ここでは人命に関わる病院のソフトウェア。
- XPによってトレーサビリティへの対応が簡単。
- 審査官との継続的な関係。（どちらかというとビジネス的な。

### @got
> XPの流れの原則からすると、審査がプロジェクトの最後のフェーズになってはいけない。(p.112中)
- スクラムの「あっても良いができるだけ無くせ」と言われる「リリーススプリント」に近いかも。
- そもそも「フェーズ」であることが流れの原則に反してる？

> 審査官との継続的な関係を築けば、審査の成功率が高まる(p.112中)
- 継続的な関係を築くにはお金が必要なことも・・・
- 費用と投資と話に！
- 「継続的な関係を築く」ことでお金の話も柔らかくなるのかも？

> トレーサビリティの実現(p.112下)
- まさかソースコードが管理されていないプロジェクトが未だにあるなんて！！！

### @kkd
> プラクティスは状況に合わせて修正すればいい
- これが一番大事。今何が必要で、何が必要ではないかを見極めるためには、今をフィルターなしで観察することが重要。でも難しい。

> 医療システム
- 咳さんの15年のXPプロジェクトは、医療システムでした。
- Crystalメソッドにも色があったなぁ。どうしたんだろ？

- 審査基準を事前に知って、完了条件・受入条件にしていけば、成功確率高まりそう

# 16章 インタビュー
### @ueda
> C++にはツールが不足しているため...
- 探してみた。[Ten C++ Testing Tools for Developers to Consider](https://www.codeguru.com/cpp/slideshows/ten-c-testing-tools-for-developers-to-consider.html)
> ペアを組もうとしなかったり、コードの所有権を主張したりするプログラマー
> 解雇する勇気を持つべき
- 解雇というのはなかなか難しいですね。
> オンサイト顧客 -> 後の「本物の顧客参加」
- (p.73-74)プロダクトマネージャーをふりかえって、「必要なストーリーを選択」、「顧客とプログラマーのコミュニケーションを促進」が理解できた。
- 最後のメッセージが良いですね。
- フィーチャー単位で計画
- イテレーションの期間を固定
- 顧客をチームと同席
- チームをオープンスペースで

### @got
> 気をつけておかないと、スコープを管理できずにスコープクリープが発生してしまいます。(p.117上)
- 何に気を付けるんだろう？
- 「スコープクリープ」については、第7章 主要プラクティス - テストファーストプログラミングに書いてある。(p.48)
けど、プログラミングの話じゃないと思うんだけれど・・・
- もしかして優先度が高いストーリーの詰め込みすぎ？
> アドバイス(p.117下)のメモ
> 計画の項目は、顧客が関心のあるフィーチャーでなくてはいけません。
> 四半期ごとにリリースを計画、イテレーションはそれよりももっとこまめに
> イテレーションの期間は絶対に固定しましょう
> チームをオープンスペースで働かせてください
> XPをウォーターフォールに組み込んでも効果が得られる

### @kobatomo
> チームには「プロセスはXPだ！」
　- Why? XPかをどう説明したのだろう？（強制しているみたいで少し違和感）
　- ソーシャルチェンジのところを知りたい。
> Object Mentor社 の 1週間のトレーニング
　- 1週間で価値がわかるプログラムはすごい。どんな内容なのか興味津々。
　- コーチは必要ですよね。迷ったときの指針が欲しい時がある。
> XPの導入
　- プラクティスを通じて 33% >> 80-90% XP導入へ。
　- どのくらいの期間がかかるだろう。
> 1回のデザイン会議で 1-2年分のストーリーが手に入る
　- 多すぎる情報をどのように管理するか課題になりそうだ。
　- 情報の鮮度も大事ですよね。
> フィーチャー単位で計画してください。
　- 自分も望む。
　- そのフィーチャーを顧客にちゃんと届けられたかで計画して欲しい。

### @kkd
> プロダクトマネージャ
- 今で言うとPOですね。エンドユーザーは別にいる。

> 顧客が関心のあるフィーチャ
- ここに繋がるスレッド参照〜。 https://twitter.com/yusuke_arclamp/status/993773701991579648

- Sabreの論文みつけた
- https://pdfs.semanticscholar.org/2a6d/34f96f831098d4afb848de03026144d75081.pdf
- Agile Maturity Map（アジャイル成熟度マップ）

# 第Ⅱ部 XPの哲学
### @got
> 組織変革などの人間の難しい問題
> こうした教訓を学べば、XPの適用を加速できる。(P.118下)
- XPを補う強み。手をだせていないので、もっと手をのばしたい。

### @kobatomo
> XPの適用を加速できる。
- 相手の背景を把握した上でトヨタ生産方式、リーン生産方式の話をしたってことかな？

### @kkd
- 「独学の技法」という本参照。
- https://amzn.to/2LnRBU3
- 他分野の知識を学び、それをいかす。（そのままではない）
- 人も問題（＝組織）が一番難しい

# 17章 はじまりの物語
### @got
> 正しい答えを計算する必要がなければ、いくらでもシステムを早くできる。(p.121中)
- システムを早くすることに迫られたことがなかったので、あまりピンと来なかった。
- 「システム」を「リリース」と読み替えたら、ぐったりする話に変わった。

> イースターとポンチキ(p.121下)
- イースターというよりカトリックの文化を全然知らなかった。
- 40日間の断食(食事を減らす)があるとか、頭の片隅に保管。
- ポンチキはあんドーナッツのジャム版だと思ったらイメージできた。

> チームメンバーへのインタビューと質問への回答
> どう答えればいいか、自分でもわかっていなかった
> このような説明を一日かけて繰り返し、そのたびに少しづつ体制に慣れ、そのたびに少しづつ詳細を加えていった。(p.122下-p.123上)
- ひどい状況だなｗとぱっとみ思った。
- これって「説明」を1日繰り返したから出来たことなんじゃないかな？
「文章の作成」を1日繰り返しても出来なかったと思う。(2週間あったのに・・・)

> 私が目盛りの10だと思っていたものは、実際には8、あるいは6だった。それは、「その後の経験」でわかったことだ。(p.123中)
- 「その時」じゃなかったんだ。「いつ」だったんだろう？

### @ueda
> (p.123中)私が「基礎」を整えたと言ったのは、... 、チームだったからである。
- ちょっと意味がわかりません。
- ビジョンを提示しただけで、チームがその方法を使いソフトウェアを開発した。
> (p.124上)エンドツーエンドは思っているよりもはるかに遠い
- 肝に命じておく。
- 2000年に技術の主流がJavaになっていたのが残念。

### @kobatomo
> Smalltaklのパフォーマンスチューニングに関して..
- アウトプットファーストだ。

> 小さいチームで最初からやり直す選択。
- この判断ができた経営陣がすごい。作ったものはなかなか捨てられない習慣もある。
- １から始めることを選択させたプレゼンがきになる。

> 私がソフトウェアエンジニアリングで重要だと思うすべてのことを取り入れた
- Kentが最初に導入しようとした価値、原則、プラクティスはなんだろう？
- 計画ゲームだね、この文を見ると。後は自動テスト、短期リリースとかかな？(@kkd)

### @kkd
- コンサル的にはかなり嫌なPJ
- 本気で関わって逃げてないのが偉い！（仕事だからだけど）
- ロン・ジェフリーズ、マーチン・ファウラーが関わってる
- ロンはXPの父の一人と言われる人、マーチンはソフトウェア開発の新しい概念を説明するのが上手の偉い人
> エンドツーエンドはおもっているよりもはるかに遠い
- ラスト１マイル問題、といいますね。
> 日本のSmalltalk失敗PJがあった。
- [九大病院“つまずき”の真相 - 「要件定義の甘さ」が尾を引く](http://drillbits.tumblr.com/post/15664104845/%E4%B9%9D%E5%A4%A7%E7%97%85%E9%99%A2%E3%81%A4%E3%81%BE%E3%81%9A%E3%81%8D%E3%81%AE%E7%9C%9F%E7%9B%B8-%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9%E3%81%AE%E7%94%98%E3%81%95%E3%81%8C%E5%B0%BE%E3%82%92%E5%BC%95%E3%81%8F)

- はじまりのプロジェクトから２２年。未だにこのくらいもできてない所多いよね。。。。
- 『パターン・Wiki・XP』も読もう！（電子書籍あるよ）

## ふりかえり

### @ueda
### @got
- 一人だと流してたけど、他の視点で他の章とのつながりが見えるのがいい！
### @kkd
- on timeでいけた！嬉しい。
- 個人のひっかかりは、面白いね。
- 章単位でまとめてやったらどうか？
- 人が少ないから進みがよかった？
- ２人だと逆に時間かかった。
- skypeのURL公開やめる？スパムが多い
- Skypeのルーム（URL)を作り直そう！
- 次回は新しい方で（公開はしない。connpassで投げる・Slackで投げる）

## 次回
2018/6/13 (水) 19:30 - 21:00
- 対象： 18章〜20章

### 役割分担
- 司会：@got
- connpass：@kkd
- connpassグループ通知
- wiki：@ueda
- hackmd：@ueda

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