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

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

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/223506/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/09/12 Sun](https://discord.com/channels/767540649418686486/774111081634332673/886560503554539520)

# 自己紹介

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

# 参加の仕方

- マイクはいつでも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.8.2 進捗報告（必須）

- ビジョンステートメントを進捗報告で話すという発想はなかった
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886583906655154207)
- やったことある人はいますか:+1::+1::+1::heavy_check_mark:
- みなさんの現場で、リリース計画はどのように管理していますか:+1::+1::+1::+1::+1::+1: :heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886578803550330910)
- うちの場合だと1ヶ月のバーンダウンチャートの中でリリースするストーリーはmiroで。Qごとにリリースしていきたいものは、スプレッドシートで管理して、みんなで優先順位を付けているのですが、二重管理になっている感じがしていて、しっくり来ていない
- みなさんの現場で、(ここで評価が難しいと言われている)生産性は測っていますか、測っている場合どうやっていますか:+1::+1::+1::+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886572882250059806)
- P.152 スループット
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886591915246616576)
- スループットの報告って、例えばどういうこと？:+1::+1:
- ストーリー数との違いは？

### 6.8.4 マネジメント報告（オプション）

> P.152 機能を測定する代わりに、ビジネスにおけるチームの影響力を測定しよう。投資収益にような客観的な価値の指標を作ろう。利益やコスト削減、その他の価値のある結果に基づいて作ることができる。
- なるほど。具体的に何かビジネス指標を設けて開発している人いますかね？:+1:

> P.153 時間の使い道
- 時間の使い道の集計してますか？してるなら、どのような方法でしてますか？:+1::+1:

## 感想・気づき

- in 99 words
- > A vision statement, weekly product demos, release and iteration plans, and a burn-up chart are a normal byproduct of your work. Share them as a matter of course.
Other reports take extra time. They're technically waste, but may be necessary to help build trust in your team. Roadmap and status emails summarize your release plan and demos. Productivity, throughput, and defect reports help management understand your effectiveness. Time usage reports help explain your velocity.
Avoid reporting lines of code, numbers of stories, and velocity. They're misleading at best. Avoid sharing code quality metrics, too: they require expert interpretation.
- > ビジョンステートメント、毎週の製品デモ、リリースとイテレーションの計画、バーンアップチャートは、あなたの仕事の正常な副産物です。それらは当然のこととして共有します。
その他の報告書には、特別な時間がかかります。技術的には無駄なものですが、チームの信頼関係を築くためには必要なものかもしれません。ロードマップやステータスメールは、リリース計画やデモの内容をまとめたものです。生産性、スループット、および欠陥のレポートは、管理者があなたの有効性を理解するのに役立ちます。時間使用量のレポートは、あなたの速度を説明するのに役立ちます。
コードライン数、ストーリー数、ベロシティの報告は避けましょう。これらはせいぜい誤解を招く程度のものです。また、コード品質の指標についても、専門家による解釈が必要なため、共有は避けましょう。
- [コラム: Work in Progress](https://www.jamesshore.com/v2/blog/2008/work-in-progress)
- > 物事をさらに困難にするために、測定はどれほど正確であっても、機能不全のリスクがあると言う人もいます。
- 計測した時点で、計測されたメトリクスだけを達成しようとする人がいるっていう話もある。:+1:

### 6.8.1 報告の種類

- 進捗報告とマネジメント報告という種類を明確に分けたことはなかったので、この言語化は大きな気づき:+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886586054633738270)

> マネジメント報告は上級管理職向けです。これらは、管理者が傾向を分析して目標を設定できるようにする高レベルの情報を提供します。
- 結構、これを人に伝えるのに苦労する。上級管理職が、これを使ってどういう行動するかを期待して書くのは心がけたい。(職場で時々、上級管理職が理解できない用語を並べてたりを見かける):+1:

> でも気をつけよう。報告には、開発とは別の時間とエネルギーが必要だ。だから考え得るすべての報告を作ってはいけない。重要なステークホルダーを満足させるのに十分な報告を提供しよう。
- 必要なときに、必要な分だけやる
- 報告自体に複雑なものが紛れ込もうとしたときには、その報告がなぜ欲しいのか聞いてみたい:+1:

### 6.8.2 進捗報告（必須）
> バーンアップチャート
- プロジェクトに対してはバーンアップを、スプリントに対してはバーンダウンを。

### 6.8.3

> ロードマップ
- アジャイルはじめたての組織だと、これがないことが上層部にとってのアジャイルへの不信感につながる気がする。「標準提供すべきではない」といったものの、悩ましい。:+1:
- 提供すべきではないって書いてありました？
- "As with progress reports, report only what you must." というので、「必要と感じた時だけ」という意図で読み取っていました。

### 6.8.4 マネジメント報告（オプション）

> 価値の客観的な尺度を考え出すことは、生産性を報告する上で最も難しい部分です。指標はビジネスにとって何が重要かによって異なるため、具体的なガイダンスを提供することはできません。プロダクトマネージャーと上級管理職は、この対策の作成を支援できるはずです。
- 真っ先に、「デモとかレトロスペクティブとか、打ち合わせを減らせ」というのを言われる。この辺の価値が、時間効率を考えてる(かつスプリントミーティングに出てこない)上級管理職に伝えるのが難しい。:+1:

### 6.8.5 その他の報告（非推奨）
> P.155 ベロシティ
> 生産性が変化したことと見積もりに一貫性がないことを区別する方法はない。
> 意図的にベロシティを向上させることができてしまうので、私は生産性の測定方法としてベロシティを使うのには反対することを強くおすすめする。
> 何よりも、決して別のチーム同士でベロシティを比較してはいけない。
- 回りくどい訳になっているけど、意図は強く反対する、だと思う。本当にこれ大事。ベロシティは「長期計画のため」の「参考値」くらいで良くて、それ以上の意味を持たせないほうがいい。:+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886588794239844382)
- 第2版だとキャパシティって言っているのは、↑のような理由から変えたのだろうと思った
- > Capacity was originally called “velocity.” I don’t use that term any more because “velocity” implies a level of control that doesn’t exist. Think of a car: it’s easy to increase the velocity; just press the pedal. But if you want to increase the car’s capacity, you need to make much more drastic changes. Team capacity is the same. It’s not easily changed.
- >容量はもともと "ベロシティ "と呼ばれていました。なぜなら、"ベロシティ "という言葉は、存在しないレベルのコントロールを意味するからです。車を考えてみましょう。速度を上げるには、ペダルを踏めば簡単です。しかし、車のキャパシティを増やそうと思ったら、もっとドラスティックに変えなければなりません。チームの容量は変わらない。簡単には変えられない。
- https://www.jamesshore.com/v2/books/aoad2/capacity

### 6.8.6 質問
> P.156 プロジェクトマネージャーのしごとはチームが円滑に機能するのを助けることだ。決してクリティカルパスにいる人たちの作業負荷を増やしてはいけない。
- 全PdM/PjMの胸に刻んでおきたい言葉。:+1::+1::+1:

### 6.8.8

> 報告に費やした時間は、開発に費やせなかった時間です。
- リーダーとかになると、ほとんどレポートに費やすことも少なくない印象。:+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/886590381440004126)

----

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

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

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