# Agile459読書会

## 近況
### @ueda
- めっきり自転車に乗る機会が減ってしまって、腰の張りが気になったので10kmほど自転車に。腰だけでなく首のコリもやわらいだ。
- Slackでのコミュニケーションでトラブル。井戸端会議だと延々続くような。もう少し当事者意識を持って欲しいと思うと同時に、ゆとり(slack)も必要なのかも。
- 臨時の（不定期な）請求っていろいろ面倒。定期的な請求だと話が早い。

### @kobatomo
- タスクボード、チームメンバーから「こう変えたい」。
- カイゼンジャーニー
- alexa day

### @got
- TDD本はxUnit(Python)へ突入。
- 会社ではA4用紙でカンバン実施中。限られた個人スペースでどう見えやすくするかを試行錯誤中。

### @kkd
- レースで怪我して走れない。愛媛マラソンが近づいてる。。。ストレスと体重増ｗ
- 年明け３週連続東京出張。久しぶりにアジャイルコーチ業、みんな頑張れ！！
- Apple Watchを買った。それなりに便利だが、今ひとつ！？

# 7章 主要プラクティス

## ペアプログラミング（〜ペアとパーソナルスペース）

### @ueda
- Coderetreatやモブプログラミングの経験が大きい。ただし、そういう手法があるにも関わらず、個人の責任とか押し付けの現場が多いのが残念。
- ペアでの集中は疲れるので、しっかり休憩もとって。このリズムができれば生産性も上がると思うが、それが毎日延々と続くのもしんどいような。
- 以前、作業場で机周りの匂いを指摘されたことがあり、後で自分の腕時計が原因と気がついて反省。ナイロンバンド(PMX56-2592)の内側に皮が貼ってあって、それに汗が染み込んで匂っていた様子。今はステンレス製のバンド。

### @kobatomo
- ペアプロは、新人さんの育成で使う。
- 設計思想も引き継げるし、その人しかできない状況ではなくなるので良い。
- 著者は、いろいろな人とやれる環境なので羨ましい。
- 岡山のTDDBC
- 自分からやりたいと言ってほしい

### @got
- ペアプロ未体験。モブは昨年のAgileJapanで初体験！
- 業務上では周りにプログラムを書く人がいない・・・
- 人が困っていることに気づくと、ペア業務になってやっている。

### @kkd
- 昔こんな記事書いてたなぁ
- [第14回 ペア作業で効率の全体最適化を図る](http://itpro.nikkeibp.co.jp/article/COLUMN/20060705/242580/)
- [第15回 ペア作業による品質向上は目的ではなく結果である](http://itpro.nikkeibp.co.jp/article/COLUMN/20060721/243997/)
- 昔発表した資料みてもらえると、ペア含めてどんなことやってたかわかるかも。
- [プラクティス大集合(2006)](https://www.slideshare.net/kkd/the-collection-of-practice-in-our-team-2006-version)
- ペアプロはほんとに疲れるよ！（＝集中してる）
- 今ならモブを最初すすめるなぁ。ペアもいいけど。
- 最近だと、Google Docsでリモートでペアワークすることが多いなぁ
　　- 作ってレビューより、話しながら作る方が効率が良い。
　　- 時間を厳格に決めて（９０分）一コマで進めてきた。

## ストーリー

### @ueda
> 「アジャイルサムライ」P.107 よく書けているユーザーストーリーとは
> 顧客にとって何かしらの価値が書かれていること。
> お客さんが対価を払ってもいいと思えるもの。
- 「顧客に見える機能」をもう少し意識して計画したい
- 見積もりについては最近No Estimatesという議論もあるので、細かく金額を積み上げるよりは納期（期日）と予算でベストエフォート的な組み方ができれば。
- https://qiita.com/kickno/items/89d6170061ab14784c16

### @got
- 「ストーリーを書くこと」の重要性だと思って軽く読んでいた。
要望として出されたこと（概要、詳細）を一覧化してあるし・・・
- 「ユーザから見える単位」で「すぐに見積もる」こと、その見積もりを元にして得られるフィードバックが重要そう。
- 「短い名前を付けること（P42の一番下）」の重要性（利点というべき？）ってなんだろう？
- 簡潔さ。
- 一言で言い表せてないのは、整理できていない。いろんなのものが入りすぎている。

### @kobatomo
> イメージだけでは意識決定できない。車を賢く選択するには、費用と用途の両方の制約を考慮する必要がある。
- あー。これ今やっているなー。数字必要ですよねー。

> 顧客に見える機能の単位を使って計画すること。
- ストーリーは、タイトルのみでタスクボードに貼り付けている。詳細とか時間は、別ドキュメントでも自分は十分。
- ストーリーで書いておくという方が、的を絞れるからすき。
- 中には、設計。コーディング。デバッグ。をタスクボードに貼り付けている人もいる。まとめて書いているのだが、どれもしかかりになっている。自分もそうだったなー。変わらない人は、変わらない。ベイビーステップじゃなくなっちゃうんだよね。どれもしかかり。自分視点か顧客視点かの違い。

### @kkd
- （ユーザー）ストーリーは、『User Story Applied』といういい本があるが、翻訳されてない。ここに言語の壁がある。。。
- http://amzn.to/2DExIqx
- INVEST、３Cは覚えておいたほうがいいよ
- 　https://blog.guildworks.jp/2015/06/03/how_to_deal_with_invest_of_userstory/
- 「利用者視点」「タスクではなく実現する価値」「会話を誘発させる」「手段ではなく目的・ゴール」「話しながら落とし所を作る」
- 小さい（＝規模）ストーリーほどいいですね→
- カード。物理的制約があるのが良い。
- CCC (Card, Conversation, Confirmation)

## 週次サイクル

### @ueda
> 「今週実装する1週間分のストーリー」を顧客に選んでもらう
- 実践してみたい。（やったことがない
- 1週間単位のリズムって良さそう。ただし、月曜日のミーティングが苦痛にならないように。

### @got
- 気分よく土日で休みたいので、1週間のリズムに持ち込めるようにしたい。-
- 週次ミーティングを毎週月曜日に開催するのが良いかも。
「ミーティング＝上司への報告会」と考えてると、そんな気も起きないし「いつでもいいや」って思ってしまう。
- 「計画づくりは（必要だが）必然的なムダ」だよね？
- 計画づくりのスキルって個人の経験に左右されると思うことが多い。技術的に高められることってあるんだろうか？
- バリューストーリーマッピング（価値時間、無駄時間）
- アジャイルな見積と計画づくり

### @kobatomo
- 進捗状況は、どうレビューする？% は、正直よくわからないよね。やはりアウトプットか？
- ２。いいねー。顧客に選んでもらう。個人的に、顧客に選んでもらうのは、リリースのたび。価値を届けた後ですね。

- なぜ、週の初めに自動テストを書くの？難しい。テストが間違っていたら、後戻りも時間がかかるし、非効率。
　　 - ストーリーのゴールなので顧客と最初に決めておかないとね。自動テストとは違うよ。
- 計画の時間もタイムボックスかけてやらなきゃ、時間が勿体無い。
- 1on1やってた時も週１のサイクルでした。大抵木曜日。金曜日という予備日を設けたいから。（ゆとり）
- 月曜日には、手帳を見ながら、今週のざっくりとした予定を決めている。

### @kkd
- 最初はじめるには週はいい単位
- １月先のプランつくるのは結構大変
- 軌道修正がしやすい（＝フィードバックサイクルが適度に多い）
- もっと短くてもいい（＝練度が上がれば）
- １週間で作れるスピードを上げていく＝ベロシティ、という考え方
- タイムボックスも合わせてね
- 始まりを月曜にしないことがおおい

## 四半期サイクル
### @ueda
- 自分にとって四半期のテーマが重要。ストーリーの積み重ねと完成をただ繰り返すのではなくて、テーマのくくりでメリハリをつけたい。

### @kobatomo
- 半期に一度、チームとしての目標を決める。四半期でふりかえりる。月一度、個人の目標を振り返る。これが今の弊社かなー？
- テーマ、ストーリー、タスク、区別できかねる。テーマ：目標？ストーリー：機能。タスクは、機能を実現するための部品？
　 - テーマは、ストーリーが集まってできる何か
　 - ストーリーは、タスクが集まってできる何か
　 - タスクは、機能を実現するための作業
### @got
- 仕事だとプロジェクトの区切りがばらばらなので、4半期というと現状報告の場になっている。（年度の主で、短期だと四半期とは関係ない区切りが多い）
- 「前年度に計画したプロジェクトを実施していく」ことが多いので、1年間流されている間が・・・
- まずは自分の、次は自分たちの四半期の計画を立てて行くのもいいかも。

### @kkd
- 「一区切り」ですね。大きなふりかえり大事。ビジネスのふりかえり
- 一人になって出来てないな。。。今年はやろう！

## ゆとり
### @ueda
- 重要度の低いタスクを含めるのは割とやっていて、ちょっとした改善や機能追加に対応することが信頼にもつながる。立て込んできた時に外せる、というよりは小さなタスクでも実施することで信頼に繋がるし、達成感も味わえる。完成したら一服。
- 「8週間のうち1週間をギーク週間に」というのは良さそう。できればもう少し短いサイクルで。

### @kobatomo
- 信頼関係は、動くソフトウェアを顧客への価値を提供することで築かれる。
- 作業遅延が発生したため、当初予定していなかった攻めのスケジュールになることも。。。顧客、チームメンバとも調整し、できるだけ要望に応えていく。攻めのスケジュールになった結果、チームに負担をかけることもある。
- 攻めのスケジュールになると、残業、アウトプットの質の低下となることも、負のスパイラルはいつもすぐそばにいたりする。
- ゆとりは、必要。技術は、嘘をつかない。焦ってやっても。落ち着いて、確実に正確に。
- 相手に自分のスケジュールに可能な限り合わせてもらえるように、自分から締め切りを決めていくことも必要と思う。

### @got
- ゆとりは大事だが、「どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること」というプラクティスがしっくり来ない。
- 悪い言い方だと「何かあった時の逃げ道を作れ」のように見える。
- 「裏表なく」ではなく「賢く立ち回れ」？
- 何らかの問題が発生していて、そこまでのやるべきことを果たしているのであれば、その時に調整すればいい。（そこまでの信頼関係も必要）
- 「ゆとりを自ら作り出す」を少しずつ実行中。

### @kkd
- むかし、「20%ルール」をやっていた。でも結局仕事している人もいた。仕組みも大事だが、意識付けも大事。
- ゆとりがないと、変化に適応できない・持続可能ではない。
- ゆとりには自信はある！！（＝がんばらないことをがんばる）→ちがう！？ｗ
- 「やらないことをきめる」ということかもね。

## 10分ビルド
### @ueda
~~- CIの取り組みがまだできていないので今後の課題。~~
- ローカルの開発環境(Webサーバー、DB)が低スペックでテストをするのにとても時間がかかっていたのでチューニングして改善したことをふと思い出した。

### @kobatomo
- テストに10分以上、かかる時もあるので、見直しが必要だー。
- 全ての状況においてCIが必要かどうかは疑問。CIの前にユニットテストの環境、文化を作ることが自分は優先と考える。
- 一回も作ったことがなければ、どんなものか動かしてみるのが一番。

### @got
- 手持ちのプロジェクトはコンパイルが必要でないコードしか書いてないので、自動ビルドにあまり縁がない。
- 「すべてのテストは？」と考えると、結合テスト、システムテストまでは自動化していないので、道のりは遠い。
- 「既存のコードがあって、そのコードのテストを自動化をしたかったら、まずは自動ビルドから始めると良い」とテスト関係の人から聞いた覚えが。
「自動ビルドは手動ビルドより有益」につながってるのかも。

### @kkd
- スローテストはボトルネックなので改善する方向がいい（昔しんどかった。。。）
- 段階的に自動化しないとねー。一気にやるのは大変。手動を自動にする。
- 手順書→自動スクリプト
- 昔、手動テストの部分的自動化をやってたよ。
- http://www.jasst.jp/archives/jasst09e/pdf/D5-2.pdf
- ここはできる。できないを区別して少しずつやっていく。

## 継続的インテグレーション
### @ueda
- CIの取り組みがまだできていないので今後の課題。

### @got
- コードリポジトリとビルドシステムの連携が未経験。
- 軽量なサンプルプロジェクトで試す。
- 「インテグレーションとビルドによって、完全なプロダクトを作り出す」って手作業によるムダをなくすという意味？

### @kkd
- 2002年ごろは、自動テストを、ビルドサーバーで手動でテスト実行して、結果を確認していた。これもCI。
- JUnitReportというのを使って、結果をレポートに出力して、Webで見れるようにしていた。
- 実行をスケジューリングで自動でやるようにした→レポート確認
- JenkinsでいっきにCIが身近になった

## テストファーストプログラミング
### @ueda
- テストコードを書いていくうちに、最初の方のテストが不要になるケースもあって、でもリファクタリングせずにそのままになっていたり、あるいは別の目的で便利なので残しておいたり。
- テストを書かなかった頃は、リズムなどなくてストレスばかりの作業だった。
- そもそもアプローチの仕方が違った。かつては、何が必要か（どんなfunctionがあれば良いか）を考えて、目的に向けて組み立てていく感じ。今は、最初に最終目的を書いて、そこから掘り下げる感じ。

### @kobatomo
- 去年のオープンセミー岡山はレガシーと闘えがテーマだった。https://oso.connpass.com/event/53811/presentation/
- @t_wadaさんの資料はためになるよ。
- テストは、質を上げない。質をあげるのは、プログラミング。
- テストは、機会を与えてくる。ストレスを低下させてくれる。早いフィードバックで結果をくれるから好きなんです。
- テスト駆動開発の付録Cは、読むべきですね。
- 付録Cを読む会開きます？

### @got
- 数年前から自作分はあるべき姿を「一度に」テストを書いて開発・保守する方向へやっと遷移。
- 全方位に広がるテストコードの無いレガシーコードと戦いつつ、レガシーコードを増やさないよう学習中。

### @kkd
- TDDとテストファーストは違う
-

## インクリメンタルな設計
### @ueda（ですよね？自分で書いて忘れた...違ってたらごめんなさい
> 小さくて安全なステップで稼働中のシステムを変更する経験を積み重ねていく
- 最初のリリースはあくまでも試作で、そこからのリファクタリングが重要
- 言い換えると、何もない状態で詳細に設計をしたところで、実際に動かしてみないとわからないことが多い。

### @got
- 「経済性」と「改善」
- 余計な「念のため」の設計を入れてしまい、それが足かせになってたことがあった。それらも少しずつ闇に葬ってはいるが、まだまだ途中。
- 「リファクタリング」は未読。

### @kkd

## それから......

## 今日のふりかえり

- 週次サイクルは苦手、ストーリー勉強したい（@ueda)
- 読みたい本が増えた。時間が足りない（@got)
- 新しい言葉がふえた！（@kobatomo)
- 本ちゃんと読みます！がんばらないようにします！(@kkd)

## 次回
2018/2/7 (水) 19:30 - 21:00

対象　：　7章継続的インテグレーション　〜　8章まで

司会：got
connpass : kobatomo
wiki : ueda
hackmd : kkd

読書会のベロシティを測ろう。

## ベロシティ
- 今回は、7ページ