アート・オブ・アジャイルデベロップメント読書会 8.3 計画ゲーム === ###### 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/820576677389533215) # 自己紹介 - ファシリ役 - - 読み上げ役 - # 参加の仕方 - マイクはいつでもONにして、話に参加して結構です。 - テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。 - 聞いているだけの方もOKです！ # ディスカッションをより豊かにするためのグランドルール [アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu) - 参加者は毎回任意 - 今回は不参加、次回は参加をするといった気軽な感じ - 途中参加も断然OK! まずは聞くだけでも大丈夫です！ - フィードバックを恐れない - マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう - アウトプット7割：インプット3割の気持ちで臨みましょう！ - 経験の有る無しは気にしない - 自分はアジャイル非経験者だから……と気後れする必要はないです - 堂々と意見や疑問を語りましょう - ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです - 電子書籍で読んでいるとページ数ではわからないため - 話していない人が、率先してメモしましょう - このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :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分 | [miro](https://miro.com/welcomeonboard/DgN2fhzWfBt3jHeC1h5Clteo4TvoXmS6Hx06eM46RiQEpjkVv52ZlMeu8u2nLRJ0)を使って振り返り | | |21:40-21:45 | 5分 | 次回開催日と読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 ### 目安の時間 - 1トピックにつき10分を予定しています - 盛り上がったら延長することもあります ## 感想・気づき ### 8.3.1 ゲームのやり方 > 顧客が価値に関する最高の情報を持っている（中略）プログラマはコストに関する最高の情報を持っている（中略）成功する計画には両方のグループからの情報を考慮する必要がある - この認識を顧客と揃えておくの超重要:+1::+1::+1: - 個人の勝敗でなく、全員が勝つか全員が負けるかであるという話。当たり前のことだけれども、意外と抜け落ちて「顧客vs開発者」な思考になってることも見かけるような。(変な要求が来た、とか。あいつら言っても全然やってくれない、とか。):+1::+1::+1::+1::+1::+1::+1::+1::heavy_check_mark: - 開発と保守チームの関係もそうだよね - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820633913989922827) - :memo: 一度対立構造になった後にもとに戻るいい方法が知りたいです - :memo: 水曜どうでしょう好きの自分としては「腹を割って話そう」ですねｗ - :memo: 対立している中にいない人が個別に話を聞いてあげてから、当事者同士を話させるとよさそうに思いました > たとえ２つのストーリーが同じ優先順位であっても、どちらか一方をもう一方より前に持ってこなければならない。どちらを先にすべきかわからなければ、ランダムに１つ選ぼう。 - これ大事ですよね。みんな優先順位高とかいう人を撲滅することから始まる気がする。私は普段みんな同じぐらい大事と言われたら意図的に後で良いものを上にしましょうと話、相手から「それはもう少しあとで良い」と言わせるようにしてます。:+1::+1::+1: ### 8.3.2 ゲームの勝ち方 - 誠実でオープンな対話があれば、コラボレーションという奇跡が起きる。なかなか、そこまでの奇跡が起きず、「いや、どっちも欲しいな。。。」という選べない感想しか引き出せないこともある。(提示側で、顧客がどっちに行きたそうかの想像力を持っているのが大事？):+1: > p.235 同様に、プログラマは顧客が何を重要だと考えているのか分かっていないことが多く、結局、価値のないストーリーを実装してしまう - たしかに要求の真意を理解する前に、自己防衛的な反応をしてしまってることが、自分にもあると感じてとても刺さった。:+1::+1::+1::+1::+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820636452848140289) ### 8.3.3 質問 > p.236 顧客が見積もりについて説明を求めてきたときには、技術的なオプションを説明してはいけない。その代わりに、技術を**通訳して**あげて、ビジネスの影響という観点で選択肢を説明しよう - つい技術的な話をしがちだけど、そうすると溝が深まるばかりなので、このことを常に意識しようと思った。:+1::+1::+1::+1: - 技術的負債など、「これがあると何が困るのか」とかを話してあげた方が理解してもらいやすいですよね > p.236 私たちのプロダクトマネージャーは優先順位付けをしたがりません。全部重要だと言うんです。どうすればいいですか？ :+1: - 「断固とした態度を取ろう」という回答が素晴らしい。決定することが失敗につながるのを恐れてなかなかやってもらえない。 - 私の知る限りプロダクトマネージャーの多くはプロダクトの成功より自分の評価を上げるために仕事をします。決断したことより決断のミスを責められるのを恐れ避けるようになります。そして上司のご機嫌伺いのためにプロダクト開発チームにとって足かせとなる要求ややらなくてよい仕事を運んできます。 - jiraなどではチケットを順番づけないといけないUIなので、強制的に順序づけさせるのはよいUIだと思いましt > 顧客が見積りについて説明を求めてきたときには、技術的なオプション を説明してはいけない。その代わりに、技術を通訳してあげて、ビジネスへの影響という観点で選択肢を説明しよう。 - ここまで著者が説明してくれないといけないほど、界隈のコミュニケーションレベルが低いのだと感じてしまった。他業界で働いている友人等を見ても、常に相手視点に立って専門用語を避けながら話してくれる。用語が分からない人への説明を意識し過ぎると会話のスピードが落ちるなんて言われたこともあるが、今回の例のように実際に求められるシーンもあるので、どちらにも対応できるような自分でありたい。 :+1: ### 8.3.5 使用上の注意 > 計画ゲームはプログラマが制約だと仮定している これを顧客が理解してくれていると、要望や仕様が遅れるとスケジュールが逼迫するというのも理解してくれそう。（理解して欲しいな） > P237. 計画ゲームはまた、プログラマがインクリメンタルに設計やアーキテクチャを実現できることを拠り所にしている。 プログラマにこうした能力がなければ、チームはいつの間にか、計画づくりを難しくしてしまうような技術的なストーリーや おかしなストーリーの依存関係を作ってしまうだろう。:+1::+1::+1::+1::+1::+1::+1: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820637961635758120) - この前提、結構ハードルが高いですよね。笑:+1: - インクリメンタルに設計やアーキテクチャになっている”前提”がそもそも出来てないなぁ・・ - インクリメンタルに設計を行えないと、ストーリーの優先順位を顧客が決められないですね。とくに新しいアイデアをすべて実現不可という回答をプログラマがしてしまいそう。 技術的負債を回収するサイクルがないこともおかしな依存関係を生みやすい ### (全体) - スクラムのリファインメントに吸収されていそう - ただ、リファインメントの説明だけ読んでもこの具体的な温度感は伝わらなさそう、合わせて読むと良さそう ## 疑問・参加者に聞いてみたいこと ### 8.3.1 ゲームのやり方 > 私のお気に入りの計画づくりのやり方は、チームと重要なステークホルダーを大きな会議テーブルに一同に集めることだ - 時間が合わないとかで実現するのかなりハードル高い…他にどんな方法があるだろ？:+1::+1: - 先にエンジニアだけで相対値を決めちゃってリーダーと顧客で話し合うみたいなことをやっていましたが、知識が二人で閉じちゃってたので、あんまりうまく行かなかった印象です。。なので私も気になります！ > 3. 顧客が相対的な優先順位に従って、ストーリーを計画にいれる。 - 相対で工数を見積もったものの、どこまでのストーリーを次のスプリントに入れていいかが相対だとぱっと分からない。そのため、結局必要な絶対時間を入れてほしいと言われてしまうのですが、相対の場合どこまでを次スプリントに入れるかの決定方法が知りたいです。:+1: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820618654752178226) - チームのベロシティに従って（極端な言い方をすると）機械的に算出しますね :+1::+1::+1::+1::+1::heavy_check_mark: - [過去の読書会でベロシティについて扱ったときのHackMD](https://hackmd.io/4KyyucKfSeW0bX-Kdzqp6A#882-%E3%83%99%E3%83%AD%E3%82%B7%E3%83%86%E3%82%A3) ### 8.3.2 ゲームの勝ち方 > プログラマが見積りをすると、顧客はプログラマを歯軋りさせるような質問をするものだ。（中略）頭の中で単に情報を要求するだけの表現に言い換えてみよう。何が簡単で何が難しいかについて話すことで、この要求に答えよう - メールやSlackとかの非同期な場面では落ち着いて整理できるけど、対面している同期的な場で皆さんどうやって冷静さを保ってますか？:+1::+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820626078866997248) - :memo:「技術的な話でなくトースターの文脈で伝える例」と同じで、相手が求めてる方を常に考えることが大事なのかなと思いました（それを言っちゃ終いだが） - :memo:ポイント数で会話しないと、たとえばチームの能力が変動した時に前会話した時とこれから対応するときに日数が変わりうることが説明出来ない（なんで日数かわるの？）かなという印象です。 > プログラマは顧客が何を重要だと考えているのか分かっていないことが多く、結局、価値のないストーリーを実装してしまう。 - 計画ゲームをすることで解消できると思いますが、そのやり取りで得た知識をチームで持ち続ける良い方法はないでしょうか？こういった、なぜこの方法で実装したのかという知識が共有されなかったり、埋もれてしまうことで似たようなやり取りをしてしまうことが多いので気になっています。:+1::+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820628084633632771) ### 8.3.4 効能 - 受託で体感したことない（上手くいったことない）・・・受託で実現できた方いらっしゃいます？:+1::+1::+1::+1::+1::heavy_check_mark: - 一括請負ではなく準委任契約に持っていくことで一体感あるコラボができたことあります(仕事なんで契約ベース) :+1::+1: ### ※ discordのコメントへのどれ話題にあげるか投票タイム ※ - 実際だと、ベロシティではめて行くと優先度上位のストーリーポイントが高いものばかりで、採用されるのが「優先度1位、4位、5位」みたいな時がある。そうなると、「相対的な優先順位」とは違ってきますね。。。というところが疑問なのかも？と思いました。:+1: - 工数と言われても、正直なところ、詳細に分析と設計の洗い方針決めをしないと見積もるのはむずかしいので……ってなりがちではある。ので、直観的な難しそうさでポイントを振るところから、っていう理解。:+1::+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820623850617307137) - :memo: 規模と期間を切り離す目的がストーリーポイントだったかと思いすので、期間はまずは考えないことですよね。 - :memo: エピックレベルの超ざっくりしたポイント数だして、ここ最近のベロシティをもとにざっくり計画出すことはありますね。ただ、これもPDMとの信頼関係次第なのだと思います汗 - 顧客と話すときにも相対的なポイントで話すのがよいのでしょうか？8.3.3　質問では、日付けで説明していますが・・・:+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/820631464772501556) - まだベロシティがわかっていない時点での、あるいは、ベロシティが大きく変化したときの、どれくらい盛り込むかは悩ましい問題。多めに盛り込んで、出来なかったところは次のイテレーションで、ってするしか。:+1: ---- ## ミニエチュードの質問 * ミニエチュードは、このプラクティスに対して気づきを得るための質問です * 詳細はP76ページを参照してください * 以下の質問に、回答を継ぎ足していってください ### (このプラクティスを使ったことがなければ) - 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？ - これまで経験したものとどう違うか？ - 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？ ### (このプラクティスを使っているなら) - 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない) - もし書かれているとおりに従うと、何が起こると思うか？ - このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)