アート・オブ・アジャイルデベロップメント読書会 8.5 イテレーション計画
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/03/14](https://discord.com/channels/767540649418686486/774111081634332673/820576677389533215)

# 自己紹介

- ファシリ役
-
- 読み上げ役
-

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:35 | 60分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:35-21:40 | 5分 | [miro](https://miro.com/welcomeonboard/DgN2fhzWfBt3jHeC1h5Clteo4TvoXmS6Hx06eM46RiQEpjkVv52ZlMeu8u2nLRJ0)を使って振り返り | |
|21:40-21:45 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

### 目安の時間

- 1トピックにつき5分を予定しています
- 盛り上がったら延長することもあります

## 感想・気づき

### 8.5.1　イテレーションのタイムボックス
- > イテレーションのタイムボックスは問題を防ぐことはできないが、問題を明らかにして、その状況を是正する機会を与えてくれる :+1::+1::+1::+1::+1:

### 8.5.3　イテレーションの計画方法
- > まずストーリーをエンジニアリングタスクに分割することから始めよう。
- ここまで細かく分割した方がいいのだろうか、大体口頭確認で終わってた気がする。

### 8.5.6　時間のかかる計画づくりセッションに対処する
> 長々と議論しているのであれば、共通の設計理解が欠けているのかもしれない。コードの共同所有とペアプログラミングをすることで、この問題を改善しよう
- こういうケースでドキュメントが足りないからだとよく言われるが、そういう人は意外と自分が理解するとドキュメントを書かない。 ペアプログラミングで解消できる部分はそうしたいと思った。:+1: :+1:

### 8.5.7　

### 8.5.8　うまくいかないとき
- > コミットメントを重要視すると言うことは、コミットメントしたことを全て必ず実現させることを意味しているのか？いや、もちろんそんなことはない。コミットメントとは、問題を何とか上手く解決して、イテレーションのストーリを実現するのに必要なことをすると言うことだ。:+1::+1:
- そ、そうなのか・・・！「コミットメント」って人によって受け取り方が大きく違いそうだ :+1:
- 100%の確約と捉えるケースが多いけれど、全力を尽くすが本来のニュアンス、と聞いたことがあります。:+1:
- > 　ベストを尽くしたにもかかわらず、ひどい一週間をすごして、ステークホルダーにデモするものがまった くないという結果になるかもしれない。こうなることを、失われたイテレーションと呼んでいるチームもある。彼らはコードをロールバックして、まるで失われたイテレーションがなかったかのように以前のベロシティを使う。
- これよくわかりません。ロールバックとは本当にコードを消し去るのかデモ用にブランチを過去に移動するのか？ 「以前のベロシティを使う」は次の見積もり基準に失敗したイテレーションの値を使わないという意味だと理解しました。

### 8.5.9　部分的に終わった仕事
- > 部分的に完成したストーリーはまれなはずです。
- 慣れてきてたはずでも、出来上がり直前に考慮漏れだったり、新たな問題だったりを見つけてしまって終わらない。。。というのまだよく見かける。:+1: :+1:
- > 　部分的に完了したストーリーを処理するベストな方法は、完了していないストーリーに関するコードをすべて削除してしまい、完全に完了したものだけを出荷することだと考えているチームもある。
- これを実施して本当に消すのは勇気がいるなぁ:+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/830784440350277672)

### 8.5.10　緊急の要求
- 今の現場でたまに発生していた。結果リファインメントを週に２回設置して「検討するバックログはありません」と言わせ続けることで「思いつきではなくちゃんと考えてくださいね」というメッセージを届けることに成功した。:+1: :+1:

### 8.5.11　バットマン
- 理屈はすごくよくわかるし、実際いたらすごく助かる。しかし、組織的にそういう人は置けないケースが多いし、短期間でも立ち回れる人が自由になってるケースは少ないんじゃないかなぁ... :+1:

### 8.5.14　使用上の注意
- えっ、必要な関連プラクティス、多すぎ・・・？笑

### 8.5.15　代替案
- > イテレーションを何週間経験したかではなく、何回イテレーションを回したのかによって、XPに対する理解が深まるようだ:+1::+1: :+1:
- これは非常に重要な観点！
- > もし仕事を完了するのにもっと時間が必要だと感じたら、長期のイテレーションを使ってはいけない。:+1::+1: :+1:
- これも重要

## 疑問・参加者に聞いてみたいこと

### 8.5.3　イテレーションの計画方法
- 現在のチームの運用にはストーリーがなく、ただ漫然とタスクのみが積みあがっています。
どうにも全体像が見えなかったりするなど何となくうまく回っていない印象があります。
同じようにやっていて「これは上手く回っている！」 といった体感を得られている例などあれば聞いてみたいです。:+1::+1::+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/830766284693045278)
- > まずストーリーをエンジニアリングタスクに分割することから始めよう。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/830769399140450305)
- 実際にタスクを分解している方はどう言う風にやられているのか聞いてみたいです:+1::+1::+1::+1: :+1::heavy_check_mark:

### 8.5.8　上手くいかない時
- この対応難しいですよね、デイリースクラムとかで達成できないことがあった時、皆様はどういう対応をしていますか？:+1::+1::+1::+1::+1: :heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/830772143653912596)

### 8.5.11　バットマン
- このプラクティスをやろうとしても専門性が偏り、負荷が偏ることの方が多いイメージです。この辺り上手くやったことがある方がいらしたら経験を聞いてみたいです。

### 8.5.12　質問
- > 残っているタスクはすべて他のペアが現在取り組んでいるタスクに依存しています。私は何に取り組むべき でしょうか？ 　これは思っているほど頻繁には起こらない
- 複雑な要件のあるストーリーでは(リファクタすべきレガシーなコードに手を入れなければならないときも)発生しがちだと思いますが、皆さんのチームではどうなのか聞いてみたい :+1::+1:
- バックログアイテム同士が直列な場合、並行可能な数を考慮してプランニングするようにしています
- 当初バグは見つけたら即直すってやってました。品質低い状態で完了したつもりになると後々チームの負債になるぞって意識付けしたくて。ただ、上司のマイクロマネジメントが始まり不具合を次イテレーションにまわしてタスクとして見積もることで不具合を直しても仕事したように見える変な状況が始まっています :+1::+1::sob::+1::+1: :heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/830775229348970506)

### 8.5.15 代替案
- > イテレーションの長さ
- 自分は過去に１週間でやってる現場を多く経験しているのですが、新しい環境では２週間でやってほしいと言われており、フィードバック回数が減ることを懸念しています。
- そこで、実際みなさんどれくらいの長さでやっていて、それぞれで良かったところを聞いてみたいです。:+1::+1::+1: :heavy_check_mark:
- 実験的に1週間から2週間にしたことがありますが、計画しないといけない内容が倍になって単純に大変になり、不確実性が増えて計画通りに達成できる可能性が減った感じがあります。結局すぐ戻しました。
- リリースはしないけど２週にして２回回すはやったことあります
- 「自分たちが確度高く予測可能なのはどのくらいの期間か」というのも言われますね。
- > しかし、私は営業日によるイテレーションをおすすめしない。これはステークホルダー と一緒に予定を立てるのを難しくするためだ。XPチームのいつものリズムは信頼を生み出すすばらしい方法 であり、営業日によるイテレーションでは同じ効果を得ることができない。
- わかりみ:+1:

### その他
- 負荷テストやセキュリティテスト、システム総合テストのようなQ3,Q4テストは一週間スプリントで毎回されていますか？ :+1::+1::+1::+1::+1: :heavy_check_mark:
- 二週間スプリントだとストーリーが多くなり考えることな多くなるため、一週間スプリントにしたのですがテストのオーバーヘッドを気にするメンバーもいる状況です。単体テストはテストコード、ある程度のざっくりした自動化されたE2Eテストもあるにはあるのですが、まだまだ手動ですべきテストもあり、その部分がオーバーヘッドに感じるようです。
- ↑ 半分の期間ならテストも減るのでは？と思ったり
- 8.5.15 代替案の話題に関連ありそう
- less(LargeScaleScrum)では、そう言う作業を「UndoneWork」として、バックログアイテムを「完全Done」にしたあと、リリースする前にしないといけない作業という概念があります。そう言ったテストはそのような扱いにするのも手だと思います
- https://less.works/jp/less/framework/definition-of-done

----

## ミニエチュードの質問
* ミニエチュードは、このプラクティスに対して気づきを得るための質問です
* 詳細はP76ページを参照してください
* 以下の質問に、回答を継ぎ足していってください

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)

---------------

## ☆ 次回、19:30 からもくもく会予定