### 5-1 関係者との認識合わせ 1. 適切な関係者を揃える 2. ゴールの認識を揃える - whatではなく、howに目が向いていると開発する内容が適切か判断できなくなる - 関係者から話を聞いて、なにを成し遂げたいのかを確認する - ❓ゴールは[[🗃️プロダクトゴール]]かな？なにを意識して決められるといいだろう？ 3. スコープの認識を揃える - やるべき項目を洗い出す - 緊急度や重要度を考慮して、優先順位をつける - 必ずやる項目以外に、できればやりたいなどの濃淡をつけることが大事 - 過去の[[🗃️ベロシティ]]をもとに、どれくらいでリリースできるかを考える - [[🗃️ユビキタス言語]]があると、関係者間の認識のズレなく進めやすくなる - 実例による仕様を確認する - 実際のユースケースを用いて要件を整理することで、関係者の理解を1つにする - Given(事前条件) - When(トリガー) - Then(事後条件) - Q: どこまで確認したらいい？ - A - 次にどこへ向かうのか、どこまでいけばその先が見えるのかがわかっていて、重要なことが隠れていないと感じる - キックオフ後に、定期的に話す - 毎日話す時間をとることで、不十分だった議論を継続し、認識のずれに気づける - 分散してけいぞくてきにかいさいすることで、各参加者が理解する時間を十分に取れるようになる - 関係者の認識がある程度揃ってきたら、頻度をさげる - 開催コストと、共有コストが問題になることがあるので、メンバーをわけて消臭することも考える - 💭ここが一番ネックになりそう。でも関心の高いトピックがあるとか、不確実性が高い状態が続くなら、こういう手もありなのかも。 - 進め方の認識を揃える - 不確実性の高いものからやる - 💭よさそう - コントロールできない事項の決定はできるだけ先送りする - 可能性を考慮に入れてシステムを設計し、情報が揃ってから意思決定を行えるようにする - 💭これも、時間を無駄にしてしまわいないように意識したい ### 5-2 開発内での認識合わせ - 大きめの開発は、[[🗃️Design Doc]]で目線を合わせる - 開発の背景、目的、設計を、代替案を整理するドキュメント手法 - 筆者: 数ヶ月かかる or 複数の選択肢がある開発は、1~2週間取って用意する - 比較的形式ばらないドキュメント - 意味があるとされる項目 - 目標ではないこと - 代替案 - → スコープの広がりを抑制。開発時にどこまで考慮して獅子決定したのかを推し量ることができる。 ### 5-3 計画の継続的な見直し - [[🗃️ユーザーストーリー]]を小さく分ける - [[🗃️INVEST]]に照らして考える - 💭[[📗ユーザーストーリーを分けるときに意識できるといいこと]]は、ちゃんと意識できるようにまとめておいた