アート・オブ・アジャイルデベロップメント読書会 6.7 イテレーションデモ
===
###### 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/785112149344780289)

# 自己紹介

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

# 参加の仕方

- マイクはいつでも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分 | 次回開催日と読む範囲決めてクローズ | |

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

# 感想など

## 目安の時間

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

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

### 6.7.2 2つの重要な質問
> 2. これからも続けていいですか？
- 原文みたら
> 2. May we continue?

だった。この方向性のまま開発を続けていいですか？という感じかな？
その他に、皆さんが必ずする質問などあればきいてみたい。:+1::+1::+1::+1:
因みに自分は「見た目とか動きとか気に入りました？」と「これで問い合わせ来ても説明できますか？」は聞くようにしています。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/881500822175903784)

### 6.7.3 毎週リリースは必須
> デモ終了後にはいつも、ステークホルダーが自分で試すことができるように実際に触れるリリースを提供しよう。
- 大規模なリプレイスなどリリースできない場合、検証環境にできているところとできていないところを伝えて検証環境にアップする、という形を取ってます。自分ではこれがいいかなと思ってますが、もっといい方法やこうやってるみたいな話を聞きたい。:+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/881503956310818836)

### 全体を通して
- 皆さん毎週のリリースはできてますか？:+1::+1::+1:

## 感想・気づき

- 99語まとめ
> Produce working software every week, and demonstrate to stakeholders that you have done so.
>
> Invite anyone who's interested to the demo. It should take about ten minutes. The product manager often conducts the session. Briefly describe the features scheduled, their value, and any unexpected changes. Build trust by being honest, not defensive, about changes.
>
> At the end of each demo, ask your executive sponsor two questions: "Is our work to date satisfactory?" and "May we continue?"
>
> Conduct demos at the same place and time each week. When schedule problems occur, a regular demo makes it easier to face reality.
>
> 毎週、動くソフトを作り、それを関係者にアピールする。
>
> 興味のある人をデモに招待してください。所要時間は10分程度です。プロダクトマネージャーが行うことが多いです。予定されている機能やその価値、予期せぬ変更点などを簡潔に説明します。変更点については、守りに入るのではなく、正直に話すことで信頼を築きます。
>
> 各デモの最後に、エグゼクティブ・スポンサーに2つの質問をしてください。「これまでの仕事は満足のいくものだったか」「続けてもいいか」です。
>
> 毎週、同じ場所と時間でデモを行う。スケジュールに問題が発生しても、定期的にデモを行うことで現実を直視することができます。

- [It's a Trap! (著者のこの章に関するコラム)](https://www.jamesshore.com/v2/blog/2008/its-a-trap)
- 「Wishful Thinking(希望的観測)」でストーリーを積みすぎて、デモができなくなると悲しい。(と体験すると、デモができるくらいの積み方になるかも？)

### 6.7　イテレーションデモ
> XPチームは毎週動作するソフトウェアを作る。いちばん最初の週からそうするんだ。そんなの無理だって？そんなことはない。ただ難しいだけだ。このペースを維持するには、たくさんの規律が必要だ。プログラマには、コードをきれいにしておくという規律が必要だ。顧客には、他の機能に取りかかる前に、まず1 つの機能セットを十分に理解して人に伝えるという規律が必要だ。テスターには、日々変更されるソフトウェアに取り組むという規律が必要だ。
- わかりみ。ソフトウェアの内部品質（変更容易性、テスト容易性）も必要ですし、MVPで少しづつリリースする前提があってのことですよね。 :+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/881513104008167465)

- １週間でリリースできる気がしない。:+1:
- コラムに「半分完成したデモにガッカリする」とあるが、1週間でリリースできる内容も「ガッカリする」内容になってしまうことがある気がする。

### 6.7.1 イテレーションデモの実施方法
> 興味のある人なら誰でも招待しよう。
- 興味を持って欲しい人、フィードバックを欲しい人は参加してもらうように念押しし、どうしても参加できない場合は録画して共有してます。録画共有しやすくなったのはリモートワークで良かったことの1つ。

### 6.7.3　毎週リリースは必須
> イテレーションデモはただの見せ物ではない。イテレーションごとに実際に進捗していることを知るための手段だ。デモ終了後にはいつも、ステークホルダーが自分で試すことができるように実際に触れるリリースを提供しよう。
- 実際に動くソフトウェアを提供することになるので、できているか、できていないかが明白になるので重要ですよね。また、動くソフトウェアをデモでお見せすることで、新しいアイディアや別の角度からのコメントもいただけるので、開発者としては嬉しい限りです。:+1::+1::+1:

> ビルドシステムが不完全だったり、適切なデモ環境がなかったり、インストーラがまだ書かれていなかったりするかもしれません。もしそうなら、これは大きな技術的負債の塊です。
- 結構、「後少しで終わるところです　（半日から1日)」となってるのは、以前よく見かけた。計画しにくくなる点では、確かに大きな技術的負債。:+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/881516434709172254)
- イテレーション最終日のイテレーションデモを待たずに、出来上がったストーリーからイテレーションの途中でもデモを早めに実施していくほうが良いという話を聞きましたが、そんな感じでやってる方の話があれば聞きたい。特にイテレーションが2週間だと、イテレーションデモが遠いので。。。:+1::+1:

### 6.7.4 質問
> ミーティングでは、問題を解決したり、優先順位を付けたり、解決策を設計し始める誘惑をこらえよう。
- わかるofわかる。解決の場ではないことを最初に話したり、パーキングロットを紹介したりして誘惑と戦わないとデモしてるはずが全然違う場になってしまうことある。:+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/881510971414302731)

> ステークホルダーは見たものに興奮して、たくさんの機能を追加したくなってしまいます。
- これは意見を聞いた技術者も実現性を考え始めてしまい、価値について考えずに進んでしまうパターンもあるなと思った。意見として受け止めるだけにして、後で冷静に考えるのは技術者のためにもなると感じる。:+1::+1::+1::+1:
- デモをお見せすることで新しい提案をいただいたときは、その提案の目的や背景をうかがい、その場でユーザーストーリーを記録するようにしています。その時点ではいつ頃に、どのような手段で、は会話しないです。スプリントプランニングやバックログリファインメントの際に詳細化であったり、スケジュールを決めることが多いかなと思います。:+1::+1::+1:

### 6.7.5　効能
> 毎週のイテレーションデモとデモリリースを実施すると、ステークホルダーに信頼を植え付けて、チームは出荷する能力に自信を持つことができる。
- わかりみ。POが開発者を信頼してくれるようになるのと同時に、開発者自身も成功体験を積み重ねていけるのは嬉しい限り。:+1::+1:

### 6.7.6　使用上の注意
> 　イテレーションデモはかなり目立つため、デモをでっちあげたくなるかもしれない。ロジックがまだ何も
ないのにユーザインターフェイスを見せたくなるかもしれないし、重大な欠陥のある操作を意図的に見せな
いようにするかもしれない。
- UI・UXが価値に大きく影響する機能は、ロジックなしのUIだけでデモすることもあると思うがどうだろうか...(特にデザイナーが絡んだりして早めのフィードバックをしたいときなど) :+1::+1:
- ありますが、動作しないソフトなのでイテレーションデモとは別なのでは？
- 動作するところまで実装が辿り着けていないときに、デモができないという不安・心理的負担を感じてしまうのと折り合いを付けて正しく報告してもらえるようにするにはどういう施策が有効か?

----

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

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

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