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

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

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/208938/)
* ハッシュタグ: [#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:35 | 60分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:35-21:40 | 5分 | 次回開催日と読む範囲決めてクローズ | |

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

## 目安の時間

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

## 感想・気づき

### 8.7 ストーリー

- 「ビルドの自動化」などストーリーでない例として出している。確かに顧客価値でないが、スプリントの取り組み対象としてどう挙げるかが悩ましい。
- `特別なストーリー`にある「非機能」のストーリーにするのが良さそうに思いますけどね。なんでわざわざ否定的な例として出されてるのか謎ですね…

> ストーリーは**顧客価値**を表しており、顧客の言葉で書かれている
- そうなんです。価値を表すことが大事なんです。:+1::+1::+1::+1:

> 次の例はストーリーではない
- よく見たことのある事例...

### 8.7.1 ストーリーカード

### 8.7.2 顧客中心

> ストーリーは顧客中心である必要がある
- こう言ったストーリーを各自が徹底するためにはどうすればいいのか、悩みが深い。ついつい自分のタスクレベルを出してしまう。 :+1::+1::+1::+1:
- 開発者のみでストーリーを出すので、ついつい技術的な視点ばかりになってしまうので、自分たちで「これ顧客中心じゃないよね」ど気づきたい
- 運用作業を楽にするためのストーリーを考えるときにどうしても主語が開発者になってしまうけど、みなさんどうしているんだろう？ :+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/835851745044594708)
- インテグレーションビルドを自動化する、というのはストーリーとして表さないって本書に書いてあるけど、それをやりたい時って別のストーリーに含める感じなんだろうか:+1:
- “As a (role) I want (something) so that (result).” みたいなテンプレを使うとか
- 「顧客」と「開発者」というのは動的な関係・立ち位置に過ぎない、と捉えられることができるとしたら、どうだろう
- 開発者自身もまた、相対的に「顧客」という立ち位置になりうる、というような
- という風な拡大解釈が可能なら、開発者が主語になるストーリーも合って良い気もする。コンテキストの明示は重要だろうけれど。
- P.275の *もし顧客がプログラマだったり、プログラマのためのソフトウェア…* の辺りがそういうことかもですね:+1:
- 顧客(スクラムでいうとPO)が優先順位判断できる、と言う記述があるので、それを基準にするのが良いのではと思いました
- POはROIの最適化がミッションなので自動的にPOが望むことにもなりそう
- :memo: 「顧客」はPO/PdMに置き換えても良いと思う
- :memo: 受託か内製かでも「顧客」の定義は変わりそう（企画・経営者だったり、発注元だったり）

### 8.7.3 ストーリーを分割したりまとめたりする

- > 大きなストーリーは CRUD (Create, Read, Update, Delete)操作に沿って分割すること。
- Vertical Slice
- サーバー側全部ひっくるめてストーリー切ってしまいがちだなぁと思った。サーバー側の操作を用意するとか。でもそうすると顧客の価値と異なってるからダメなんだろうなー。:+1:

### P.273 8.7.4 特別なストーリー
- P.273 スパイクストーリーという概念を採用したい。:+1:
- >必要な調査ではなく、目的の観点で表現しよう
- よい！

> アーキテクチャ、設計、リファクタリング、技術的インフラ
- リファクタリングとか、技術的負債の解消のストーリー定義は難しそう。:+1::+1::+1:
- for example, instead of saying “refactor authentication service,” say “reduce likelihood of authentication bugs,” or “decrease time needed to make authentication changes.”

### 8.7.5 質問

> プログラマ中心のストーリーよりも顧客中心のストーリーを作るほうがずっと難しい。（中略）顧客中心のストーリーの方がよい計画をもたらしてくれる。目的はいつでもソフトウェアをリリースできるようなストーリーを作ることだ。
- `特別なストーリー`に当てはまらない限り、常に顧客目線で書くべし、ということかな

> P.275 どうしたらステークホルダーにストーリーを使って機能要求を出すよう促すことができるのでしょうか？
- 現状の仕事がスクラムもどきにしかなっておらず、機能タスクばかりが並ぶ現状なので負け戦にしか見えない。:+1::+1:
社内の他部署が仕様をガンガン変えてくる状況にあるのでストーリーで出すように交渉してみたい。 :+1:
ダメなら PO にストーリーに変換してもらおう。
- ワークショップという非日常から一旦体験してもらって、徐々にストーリーを輸入するのもありなのかもしれない、と思った。

> なぜストーリーをイテレーションあたり 4 〜 10で完了できるような大きさにするのですか？
- この回答はいいなぁ。チームの規模に応じて、どれくらいの大きさがいいかを決めるのに基準となりそう。

### 8.7.6 効能

> ストーリーをうまく使うと、オンサイト顧客は自分たちが承認してスケジュールに入れた仕事をすべて理解することができる
- ストーリーを導入している現場のビジネスサイドにインタビューして、上記のような効果を実感できているのか聞いてみてもいいなって思った
- いい反応があちこちで聞こえるようだったら、そういった事例みたいなのをブログで公開してみると、他の現場に伝搬していくのかも。 :+1:

### 8.7.7　使用上の注意

> 顧客中心のストーリーの成否は、インクリメンタルな設計とアーキテクチャを使って、インクリメンタルにインフラを実装 できるかどうかで決まる。これができなければ、もっと大きな技術的負債を招いてしまうだろう。
- この前提が要求レベルが高いと感じる :+1::+1::+1::+1:
- レガシーなソフトウェアはインクリメンタルに開発できず、負のスパイラルになる悲しみ:+1:
- リファクタリングするなどボトムアップに改善するのがセオリーな気がするが、ストーリーから改善する方法はないのだろうか:+1::+1::+1::+1:
- まさに今のチームが、インクリメンタルな設計無しの顧客中心主義になっていて、負債が溜まりがちになっている
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/835856909902151740)

### 8.7.8 代替案
> 顧客は計画ゲームに参加することができない。顧客とプログラマの両方の情報を組み合わせることでよりよい計画を作る、という能力を損なってしまうだろう。
- ウォーターフォールでよく出てくるガントチャートが機能しきらないのはこの辺なんだろうな…
- 顧客視点のストーリーになってないと、確かに顧客は開発者がいうままに「そうなんですね」ぐらいしか言えなくなってしまいますね。

----------------------------------------------

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

### 8.7.1 ストーリーカード
* 10年前の本で紙でやろうと書いてあるが、現代ではそろそろテクノロジーが追いついたのでは？と思っているのだけどどうだろう:+1::+1::+1::heavy_check_mark:
- 第二版(ストーリーの話は2021.1に公開)をみると、ストーリーカードの節も、「質問」での紙カードの話もマルっと削除されてますね。:+1::+1::+1::heavy_check_mark:
- :eyes:
- なんだってぇー！
- リモート勤務の文化にも合いませんしね
- 第二版でもカード押し、virtual whiteboard 押しは残ってます。Even if your team is remote, use virtual index cards on your virtual whiteboard rather than a spreadsheet or dedicated planning tool.
- リモートからロボットハンドを動かす技術
- ストーリーは顧客の価値を書くので、別でタスクレベルの管理しないといけないと思うけど、紐付けはみなさんどうやってるんだろう？
- ストーリーの子としてタスクを切り出しています。そういう関連付けに対応していないツールつかってるとしんどそう…
- 同じくタスク切り出してますが、タスク単位のDoneがあいまいになりがち
- ストーリーの説明を書く部分にタスクを書いたりすることもあります。
- 自分のところはそれです。チェックリスト書いたり。

### 8.7.3 ストーリーを分割したりまとめたりする

> ストーリーの本質について考えよう
- この「本質」というものが難しいし、顧客は基本的に削ぎ落とすことを嫌うので本質をはっきりさせることに苦労するのですが、何か工夫していることありますか？（図解する、モックアップを作る、etc） :+1::+1::+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/835842126746353684)
- :memo: そもそも「本質」という言葉に警戒しちゃう
- :memo: あといるなら、複数人の顧客に話を聞けると、いろいろコンフリクト起こせて、より洗練された本質が聞けそうな感触
- :memo: 「そもそもこのストーリーって何でいるんでしたっけ？」って問いかけはやるかも
- :memo: いくつかの問いかけバリエーションを持っておくと良さそう

- 各イテレーションで4~10のストーリー、というのはイテレーション始める時いい基準になりそう。実際、どのくらいのストーリー数になってますか？
- 10あると、かなりスプリントゴールはブレそうな印象はある
- 「ユーザーストーリーマッピング」というプラクティスを聞いたことがあるが普段からやっている方がいたら感想を聞いてみたい
- 一度やってみたけど、ユーザの行動の流れを想定しやすくなるので良いと思います:+1:
- ストーリーを分割するタイミングとか、まとめるタイミングってどういう時にやっています？
- ストーリーはビジネスサイドと一緒に出すことが多いけど、分割のタイミングはエンジニアサイドのときだけでやることが多くて、そこらへんモヤってしています。:+1::+1::+1::heavy_check_mark:
- 大きければ分割検討するので見積時が多いです
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/835848662034153503)

### 8.7.4 特別なストーリー

#### バグのストーリー

- > 「私たちはこのバグを調査するのに1日かけるつもりだ。もしそれで修正できなければ、別のストーリーをスケジュールに入れる」
- これ、1日で修正できない場合、このバグはどうするのか？修正しないの？ :+1::+1::+1::+1::+1::+1::+1::heavy_check_mark:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/835839616610205726)
- 「別のストーリーをスケジュール」というのは、スプリントの中でおかわりする意図(他のストーリーと差し替え)になるのか、次のスプリントまでおあずけなのかの判断が別途ありそうですね。
- 緊急度によると思いますね。影響範囲が狭かったり回避策のあるバグの場合は次以降のスプリントにしますし、早急な対応が必要な場合は追加の調査ストーリーを積んで他のストーリーと差し替えて対応するのが良いと思います。（PM/POと合意の上で）
- 大きな不具合は計画的に修正しようという意味?
- :memo: これって調査じゃないですか？
- :memo: バグの重要度による
- :memo: 原因不明たまにある。今スプリントはログを入れて様子見るとか
- :memo: バグが修正できるか、と書いてあるので、 バグが修正できなくても、いったん回避策が取れるのであればそれでもいいよ、とビジネスサイドと交渉を取れれば、いったん違うストーリーをやるってのはあると思います（有りました

### 8.7.7
> XPの開発プラクティス（9章を参照）の大部分を使わずに、顧客中心のストーリーを使うことには十分注意しよう。 -p. 276
- 日本語だけ見ると、二通りの読み方ができてしまいそうだが、混乱した人がいなかったか気になった
- ”XPの開発プラクティス（9章を参照）の大部分を使わずに、顧客中心のストーリーを使うことが大事である。そういうやりかたができるよう注意を払おう”
- ”XPの開発プラクティス（9章を参照）の大部分を使わずに、顧客中心のストーリーを使うのは避けた方がよい方法である。そういうやりかたをしないよう注意しよう”:+1::+1:
- 原文を見ると、恐らく後者の意味
- > Be very cautious of using customer-centric stories without also using most of the XP development practices

----

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

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

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