アート・オブ・アジャイルデベロップメント読書会 計画ゲーム
===
###### 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/xx/xx]()

# 自己紹介

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

# 参加の仕方

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

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

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

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

# タイムテーブル

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

* 流れ
* 10分ごとにトピックを区切って議論します
* 10分経った段階できりがよければ次の話題に、そうでなければ延長します
* 議論するトピックは最初に「いいね」がついた数の多い順です。
* 「疑問・参加者に聞いてみたいこと」→「感想・気づき」の順番で進めます
* その前に、議論するトピックを決めるための投票を行います
* ひとり1トピックには1票、全体では何票でもOKです

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

### 目安の時間

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

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

- 表記 "the planning game"（theがついていたり、gamesと複数形にならない）のは、Jamesさんの意図が何かあるんですかね？（気にしすぎかもしれません）
- planning gamesとひとくくりにしていないので、1回1回が別々なgameと捉えているということなのかな？
- 皆さん「Planning Game」プレーしてますか？ 私の環境では開発者とビジネスサイドとで会話する場があるので、その場がプレーできる場だったんだなと気付きました
-

## 感想・気づき

### How to Play (やり方)

- > The stories are “just right” when the whole team can finish four to ten per week, or about six on average.
> チーム全体が週に4〜10回、または平均して約6回終了できる場合、ストーリーは「ちょうどいい」です。
- 感覚としてわかる数字。5~6, 1日ひとつカンバン動いてると、特にリズムができてない時はだれない。 :+1:
- > Developers, review the story cards and sort them into several groups:
> 開発者は、ストーリーカードを見直して、いくつかのグループに仕分ける。
- ストーリーは計画ゲームの時点では大きさが分かるくらいの詳細化でいい。他方で、ストーリー着手の直前に詳細化してタスクを分解
- 同じストーリーなのに、状況によって詳細化の程度が変わってくるのが興味深いと思った
- 聞いてみたい：皆さんの開発チームではストーリーの詳細化の粒度についてどう認識合わせしていますか？
- 意図：計画ゲーム時点で詳細化しすぎる開発者がいたら計画ゲームがなかなか終わらないんじゃないか->何か工夫しているか知りたい:+1::+1:
- ミクロに盛り上がる、あるある。

### Keep Your Options Open (オプションを開いたままに)

- > Try to create a plan that allows you to release at any time. You don’t have to actually release all the time, but you want to be able to release at any time, even in the middle of working on an increment.
> いつでもリリースできるプランを作成してみてください。実際に常にリリースする必要はありませんが、増分作業の最中でもいつでもリリースできるようにする必要があります。
- 先日トランクベース開発のイベントで「CIって、本番統合できるまでがIntegrationでしょう」という話があった。スプリント中も、いつでもリリースできる状態というのはハードル高そうな一方で、ストーリーがそれぞれ独自で価値を持てている証拠なのかも。:+1:

- >A better approach is to create stories that include all three horizontal layers but provide narrower individual utility.
> より良い方法は、3つの水平レイヤーをすべて含みながら、個々の効用を狭く提供するストーリーを作ることです。
- どうやって練習したらいいか、皆さんのやってる方法知りたいです:+1::+1:

### How to Win the Planning Game (計画ゲームに勝つ)

- >Customers change direction. Time appears out of nowhere. It’s the miracle of collaboration.
>お客さまが方向転換する。時間はどこからともなく現れる。それは、コラボレーションの奇跡。
- customerとdeveloper2つの立場がいるゲームが機能していますよねー
- 皆さん経験あります？

### Prioritizing Development Decisions (開発決定の優先付け)

- >If a development decision isn’t optional, it isn’t a story.
>開発の決定がオプションでなければ、ストーリーにならない。
- ビジネスの決定が必須であることがストーリーの条件なのかなと思いました
- 開発の決定が必須ならば、ストーリーではなくタスクということ？

### Facing Reality (現実の直面)

- >Customers, the planning game is almost certain to give you information that makes you unhappy.
- これによりチームがギクシャクしないように回せる人、が非常に貴重だし、割と日本のノリによる難しさがあると感じる。 :+1:

### Iterating the Planning Game (計画ゲームの繰り返し)
### Questions (質問)
- >How can we encourage stakeholders to use stories to request changes?
> ステークホルダーにストーリーを使って変更を要求するよう促すにはどうしたらよいでしょうか
> It’s not necessary. Instead, team members with customer skills should interpret stakeholders’ ideas and turn them into stories for the team.
> それは必要ありません。その代わり、カスタマースキルを持つチームメンバーがステークホルダーのアイデアを解釈し、チームのためにストーリーにする必要があります。
- カスタマースキルを持つ人ってどういう人がステークホルダーの解釈の代わりをするのだろうか
### Prerequisites (前提条件)
### Indicators (指標)

### Alternatives and Experiments (代替手段)
- > Be sure to keep them customer-centric, though! Otherwise, they’re just tasks.
> ただし、必ず顧客中心に保つようにしてください。それ以外の場合は、単なるタスクです。
- 最後にさりげなく大事なことが書かれてた。:+1::+1: