アート・オブ・アジャイルデベロップメント読書会 8．２ リリース計画
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

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

# 自己紹介

- ファシリ役
- t2_kobayashi, madai0517
- 読み上げ役
- t2_kobayashi
- タイムキーパー
- madai0517

# 参加の仕方

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

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

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

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

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

# 感想など

## 目安の時間

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

## 感想・気づき
### 8.2 リリース計画
-

### 8.2.1 一度に１つのリリース
> 「少なくとも１５％のロスがある……。知識労働者を分割すれば、忙しくみえるかもしれないが、その忙しさの大部分は、仕事を次から次へと切り替えることによる中身のない作業である」[DeMarco 2002]
- さすがデマルコ先生:+1::+1::+1:

> こんな簡単なことが犯人なんだ。本当に驚くべきことは、とにかく一度に複数のプロジェクトに取り組んでいるチームが多いことだ。
- 自身の実感値でも完全に同意できる。だけど、なんで一度に複数のプロジェクトに取り組もうとするのだろう？　その心理に気付けるようになると、一度に1つに集中する有益さがもっと証明できそうな気がする。 :+1::+1::+1::+1::+1::+1::+1::+1:
- マネージャーが良かれと思った分散計画が多いですね。みんなで一つに取り込むことが非効率と思われがち。（ペアプロ否定意見に近いかも）

### 8.2.2 早期にリリース、頻繁にリリース

- 社内で早期リリースを難しくしてるのはリリース申請フローだなと感じて、うまい折り合いを考えたくなっています。(WF前提でできた組織):+1::+1:
- スクラムで言われる「スプリントゴール」も、早期リリースができないと意識が希薄になるなと。
- 変更承認プロセスがある程、パフォーマンスが低くなりがちってDevOpsの本に書いてあったのを思い出しました。 :+1:
- リリースを早く行うことを目指すと自然と開発チームの計画の仕方が上手くなる。そして最小限の実装になっていくメリット。
- 早く小さくリリースできないのに長期で大きなリリース成功できると考える人が多いです

### 8.2.3 頻繁にリリースする方法
> 各リリースに含める機能を減らして、もっと頻繁にリリースしよう
- これぞAgileの真髄だと思った。機能を減らさずにXPやScrumだけやってもAgileじゃないと思う。 :+1::+1::+1::+1:
- 小出しにしても価値はない、みんな揃ってリリースだ！って人の思考停止を解決したいが難しい。 :+1:

### 8.2.4 事例

> 理由が何であれ、頻繁なリリースにとって重要なことは、アップグレードに実際にかかる、あるいは、かかる と思われているコストを減らすことだ。
- 10分ビルドの話にも通じそう:+1:
- 時代背景によって変わってきたかもしれないですね。現代はアップグレードが容易にできることが多いですね。 :+1:

### 8.2.5 計画を適応させる

> ソフトウェアの価値を高めるために、学ぶ機会を作ろう。計画を、実装するための計画と同じように、学習のための計画として考えよう。よく分かっていないことに集中するようにしよう。何が不確かなのか? 何がよいアイデアなのか? よいアイデアのうちどれを実際にやってみせることができるのか? あれこれ考えているだけじゃだめだ。試してみよう。不確かなことはテストするようにしよう。
- 価値を高める学習のための計画としても考えるというのが良いなって思う。学んだ結果を計画に反映させて適応させる。 :+1::+1:
- 原文が learn なのか study なのかでニュアンスが変わるかも。study だと、調査・検討なども含まれてくるので、単に「学習」というだけではなさそう。:+1::+1:
- To increase the value of your software, create opportunities to learn. <-- learn ですね。

### 8.2.6 選択肢をオープンにしておく
> 図8−3 横スライスと縦スライス
- 最初は横スライスでストーリーを定義していたが、タスクへの分解が困難となりうまく行かなかった
- 縦スライスを意識してストーリーを作るようになるとうまくタスクに分解できるようになりベロシティも向上した :+1::+1::+1:

### 8.2.7　リリース計画の作り方

- プランの作り方にスコープボックスプランとタイムボックスプランがある、とある。QCDSのどこを固定にするかの話だが、スコープボックスプランは、ひたすらデリバリが延びがちな印象が強い。(とはいえ、機能を揃えてリリースしたくなる気持ちは強い):+1::+1::+1:

> リリース日と機能の両方を決めようとする人もいる。これは涙ながらに終わるだけだ。
- 今までの現場は全て両方で、涙がでそうになった。:+1::+1:
- 受託開発だとどっちも固定されていることが多い。 :+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815564037005508619)

### 8.2.8 最終責任時点で計画する
> 最終責任時点で計画するためには、段階的な計画期間を使おう。全体的な計画には、長期の計画期間を使い、特定の詳細な計画には短期の計画期間を使おう
- 不確実性コーンを具体的な利用シーンに当てはめてて面白い。具体的な段階が書かれていて、自分の状況に応用して使ってみたいと思った。無茶なスケジュールや計画はいつも逆算で出そうとしてしまう…:+1:
- 労力をかけた対応が、AWSのアプデによって不要になった出来事が最近あったので、まさにこの考え方の必要性を感じたところ。:+1:

### 8.2.9 適応型の計画と組織の文化
> P.229 アジャイル開発では、適応型の計画への移行ほど組織の文化に楯突くものはない。
- 最大の問題という気がする:+1: :+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815561138061574185o)
- :memo: 目立たないように適応型の計画をして、組織の文化の中でうまくやることもできる。適応型の計画をしよ う。でも、計画期間は組織の期待に沿うように設定しよう。
- :memo: 個人的には、CI/CDとかリリースを自動化を先にしてしまうのが良い気はします
- :memo: 結果出してから意見を言え！って言われますしね。事後に「成功した理由は適応型です！」って言うしか無い組織もありそう
- :memo: 私のチームだと、コード化されたユニットテスト→CI/CD→スクラム→テスト駆動開発→E2E自動化の流れで到達しました。

### 8.2.10 質問 (P.230)
- > 私たちは毎週リリースしようと考えています。これは間違っていますか？
- イテレーションとリリースって同期するものだと勝手に勘違いしていた(違ってもいいのね):+1::+1:

### 8.2.12 使用上の注意
> **適応型の計画をする**には、組織が「納期通りに、予算内で仕様通りに実現すること」ではなく、価値の観点でプロジェクトの成功を定義する必要がある。
- めちゃ刺さった。
自分のチームではそもそも「価値」が何かを定義していないように思える。そのため適応型の計画をしてスコープを狭めた時に、代わりとして価値が上がったことを認識できずに生産性が単純に下がったと評価してしまっていると思った。 :+1::+1::+1::+1::+1:
- 反対に、フィードバック等で価値が与えられているのかを知る指標がないと、良くなっているかも断言できないなと感じている

> 選択肢をオープンにしておこう。つまり、いつでもリリース可能な状態にしておき、方針を変更できるようにしておこう。…
- めっちゃ難易度高いやつ…組織抜きにしても整えなきゃいけない環境条件が多い…:+1: :+1:

## 疑問・参加者に聞いてみたいこと
### 8.2 リリース計画

### 8.2.1 一度に１つのプロジェクト（One Project at a Time）

- 受託開発など、月1人月確保できないシステムを対応することはよくあることと思います。どんな工夫をしてますか？ :+1::+1:
- 少なくとも１スプリント内では２つのプロジェクトをやらないようにする、とかですかね…
- 理由次第ですが、3:7の比率でA,Bのプロジェクトに参加。など決まっているとやりやすいイメージ。工数との関連はあまり感じてないです。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815558091533844490)

### 8.2.2 早期にリリース、頻繁にリリース

- 最近ソフトウェアの資産計上とバッティングする事例に当たりました。資産計上観点では当該プロジェクトのリリース日は１つである必要があるとかで、ビッグバンリリースせざるを得ないという方針を伝えられ…いやいやそんなはずは無いだろうと思っているのですが、似たような事例は無いですか？ :+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815550085693308978)
- 既存経理業務を変更したくないことによる嘘が混じっていそう。「工事完成基準」を適用しているが、「工事進行基準」を採用すれば解決できそう
- 廃止！？ https://www.orangeitems.com/entry/2020/03/05/103607

### 8.2.7 リリース計画の作り方

> 最小顧客価値のブレインストーミングをする ときには、プロジェクトビジョンを使おう。

- みなさんの現場でプロダクトビジョン（本書ではプロジェクトビジョンって言っているけど、おそらくプロダクトビジョンの間違い？）って作ってますか？　どんな風に作っているのか、聞ける範囲で聞いてみたいです。:+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815554264993759254)
- :memo: エレベーターピッチ
- :memo: インセプションデッキ、リーンキャンバス、仮説キャンバス
- :memo: やらないことリストが大事
- :memo: トレードオフスライダー。やるならポイント制で合計ポイントに制約を入れる。
- :memo: https://www.slideshare.net/kdmsnr/running-lean-17917258

### 8.2.9　適応型の計画と組織の文化
- 経営層に、計画に対して予算をとるから、何人（いくら）かかるか？っと聞かれます。:+1::+1::+1::+1::+1::+1::+1:
そのときに「適応型でいくので・・・」って、言っても怒られそうです。。。
会社は、期毎に計画と予算で動いているので、そこはやっぱりバッファを取ってって感じになってしまうのでしょうか？アジャイル的な、いい回答とかないでしょうか？
また、増員については今回触れられていませんが、人員についてもどう調整するればいいのか気になりました。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/815546188086509568)
- :memo: ロードマップを確認。ロードマップベースで「ここぐらい」という説明と、ぶれはばの説明をする。
- この質問はよく聞かれます。私の鉄板の回答は「悩んだら従来どおりの計画を出せば良い」です。理由はアジャイルな取り組みを選択するときにはきっと良くなる未来を描いています。コスト面で良い結果がでるなら従来方式の数字をだして、適応型がコストかかり赤字になるなら適応型を選択する理由がないからです。
---

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

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

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