アート・オブ・アジャイルデベロップメント読書会 Incremental Requirements
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/247466/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2022/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分を予定しています
- 盛り上がったら延長することもあります

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

-
-

## 感想・気づき

--- **Incremental Requrements (インクリメンタルな要件)** ---

### The Living Requirements Document (生きた要件ドキュメント)

- >They act as a living requirements document for the team.
チームのための生きた要求文書として機能する。
- They=On-site customersだから、オンサイト顧客がliving requirements documentなのか
- ドキュメントを書くのではなく、オンサイト顧客とのコミュニケーションに*置き換え*る。なるほど

- >On-site customers are expected to figure out requirements just prior to being asked about them. The key to doing this successfully is expertise.
~~現場のお客さま~~ オンサイト顧客は、聞かれる前に要件を把握することが求められます。これを成功させるために重要なのは、専門知識です。
- このあと、プロダクトマネージャーにはこういうことを、ドメインエキスパートにはこういうことを質問するって続きますが、オンサイト顧客って抽象的な概念なんですね。具体的な質問によって聞く相手も変わると読みました
-

### When Experts Aren’t Part of the Team

- >It’s tempting for people in this situation to become gatekeepers, acting as a go-between and interpreting experts’ statements. Don’t make that mistake. If your on-site customers aren’t experts, then they need to facilitate conversations between the team and the experts, so everyone on the team can learn directly from the source.
このような状況にある人々は、ゲートキーパーになり、専門家の発言を仲介し、解釈するようになりたくなります。その間違いをしないでください。オンサイトの顧客が専門家でない場合は、チームと専門家の間の会話を促進する必要があります。これにより、チームの全員がソースから直接学ぶことができます。
- マネージャー層が間に挟まってくるパターンはやはりイマイチ。
テンポが下がるだけでなく生の意見やちょっとしたニュアンスを感じ取れなくなるので本当に辛い。
- が、こうしたコミュニケーションが苦手なエンジニアが多いのも事実...

-

### Work Incrementally (インクリメンタルに仕事をする)
#### Purpose and visual plan

-
-

#### The planning game

-
-

#### Mock-ups, customer examples, and completion criteria

-
-

#### Customer review

-
-

### Documentation

- > Although Agile teams replace documentation with face-to-face communication, some documents still have value.
> アジャイルチームは、文書を対面でのコミュニケーションに置き換えますが、それでも価値がある文書もあります。
- コードや成果物は What や How を残せるけれど、Whyを残したり、認識合わせしたりするにはやはりドキュメントが欠かせないと思う。

#### Product documentation

- > Product documentation is delivered to customers. Examples include user manuals, help pages, and API reference documentation.
> 製品ドキュメントをお客様にお届けします。例えば、ユーザーマニュアル、ヘルプページ、APIリファレンスドキュメントなどがあります。
- AWS式としてよく知られる「最初にリリースノートを書く」は、プロダクトが目指したい姿を合意するのに有効なのだと思う。(実際書いたことはない。。)

#### Operations documentation

-
-

#### Governance documentation

-
-

#### As-built documentation

- >As-built documentation can take the form of written documents or video walkthroughs.
As-built documentationは、文書やビデオによるウォークスルーの形で提供されます。
- As-builtドキュメントではないかもしれないですが、思い出したのが[プログラミングというより物事が出来るようになる思考法](https://note.com/simplearchitect/n/n388201603a28)。アメリカのMicrosoftで働いている方の記事
>自分のチームのアーキテクチャはめっちゃくちゃ複雑なので、各マイクロサービスごとに誰かが作った内部用のビデオが存在する。
- 参加者の中にビデオをドキュメントとして残している方っていますか？ どんな感じか聞いてみたいです
-

### Questions (質問)

- >To reduce documentation, you have to replace it with some other forms of communication.
ドキュメントを減らすには、他のコミュニケーション手段に置き換える必要があります。
- 置き換えるって重要だなあと思いました。「俺たちはアジャイルだからドキュメント作らない！」じゃないんですよね。ドキュメント以外のコミュニケーションに置き換えられるから、結果的にドキュメントが残らない

- >Things that can seem nitpicky to programmers—such as the color of the screen background, or a few pixels of alignment in the UI—represent polish and professionalism to customers.
画面の背景の色やUIの数ピクセルの配置など、プログラマーにとってはつまらないように見えるものは、顧客にとって洗練されたプロ意識を表しています。
- この考えは素敵だなあ

### Prerequisites (前提条件)

-
-

### Indicators

-
-

### Alternatives and Experiments

-
- > If you’re looking for opportunities to experiment, experiment in the other direction: increase communication, increase expertise, and decrease handoffs. Mob programming is the result of one such experiment.
> 実験する機会を探している場合は、コミュニケーションを増やし、専門知識を増やし、ハンドオフを減らすという別の方向で実験してください。Mobプログラミングは、そのような実験の結果です。
- 一方でMobプログラミングで何となくわかった感じになる(会話したところで全体が見えた気になる)というケースも。全貌や思想を理解するには、やはりドキュメントが必要だと思う。

### Further Reading

-
-