# 2021-09-21 レトロスペクティブ(振り返り)

## アジェンダ

- イテレーション振り返り(〜15分目安)
- [x] 良かったこと
- [x] どうすればもっとよくなるか？

- 本イテレーションでやることをチームで決める(〜30分目安)
- [x] ユーザーストーリーをどこまで実装するとPOに報告するか
- [x] ユーザーストーリーと直接関係のない部分をどこまで進めるか

- その他あれば(〜15分目安)

## 議事録

- **決定事項**
- ユーザーストーリーをどこまで実装するとPOに報告するか
- ユーザーストーリーと直接関係のない部分をどこまで進めるか
- 本イテレーションはフロント実装を先にすすめる
- 各ページの実装を行う。
- 主要なアクションとほかページへの遷移ができるUIだけがある。
- CSSで装飾は行わない。（デザインが来てからやります）
- 各ページが遷移できるようにする。
- ログインしている/していないでページのアクセス制限ができるようにする。
- モックデータを画面に出すところまでいけるかどうか微妙なので、1週間後に可否伝えます。
- エンドポイントを叩いてのデータ取得は実装しない。
- モデリング再検討を進める。

- イテレーション振り返り
- 良かったこと
- 皆でタスクを各自拾って実装に着手していたこと（遠藤）
- 事前に議論する土台の段取り準備して頂いたこと（遠藤）
- スプリントミーティング前にストーリーの実装を開始できていたこと(永井)
- 将来の布石となりそうな共通部分の整備とかができたのはかなり良いと思う（粟田）
- 全体像と具体的なタスクを把握できたこと（新井）
- あれやりますこれやりますと全員で動けたこと（村上）

- どうすればもっとよくなるか？
- 予めここまで実装します・できますとPOと期待値調整すること（遠藤）
- MTGはできるだけコンセンサスを取る議論にした方が良いと思った(遠藤)
- スプリントミーティングに使用するアジェンダのテンプレートを用意すると良いかも(永井)
- 動かせるものを見せるという点で、UIデザインをざっくり纏めておいて、紙芝居形式でこんな感じのアプリケーションになる予定です。と言えれば良かったかも(今回はデザインが提供されるので使えない方法ですが。)(永井)
- 実装も大切だがレビューがもう少しスピーディーな方が良いと思った。（粟田）
- ただレビューも結構負担になるので難しいところでもあると思う。
- 例えば、「このPR内容が全然分からないし調べるのもちょっと面倒だな〜」と思った人は、レビューしてないよっていうコメント付きでApproveするとか、レビュワーの負担を減らせると良いかも？
- **レビューした+Approve** が最低1人必要で、それ以外に **レビューしてない+Approve** が1人以上いればマージしてOKとか？
- **▶2日経過してアプルーブ2つつかない場合はPRオープンした人が時間を決めて集まれるひとが集まり説明する**
- ２週間で進捗報告はスパンが長いので、間にテキストベースで進捗報告する機会を設ける？（新井）
- その際動くものを見せる方法として、手順示してPOのローカルで確認してもらうというのはアリ？
- これやらなきゃなという具体的なタスクをどんどんissueにしてしまう（村上）
- **▶もう少しIssueを細かくわけてIssue沢山作って、開いてる人からやっちゃう**
- **▶状態のラベルを貼り付ける**

- 本イテレーションでやることをチームで決める
- モデリング再考
- 新しい概念や既存概念の詳細を昨日の会議で確認できたので反映させたい
- タスク管理のやり方再周知（Issue Open から PR Close）
- 誰がどの作業をやっているのかを確認しやすくする目的
▶ 共有済み
- バックエンド後回しにしませんか？という提案
- フロントエンドでAPI叩くところを全てモックして固定値でも良いと思う
- どうせ一部だけバックエンドと繋げても他が動かないとリリースはできない
- なら固定値でもフロントをある程度完成させた方がPO的には良いのでは？

- 〇〇○までやる
- 残イテレーション：3回
- 残ポイント：57
- 目標：1イテレーション 20pt消化

- 実装するユーザーストーリーを報告するチームでの方針を決めたい
- 個人的には来週までには何かしらの実装進捗がある報告したい（WANT）
- 本イテレーションは来週みせるタスクに全員で注力するべきと思う（骨組みのページで出さないのは後回し・エンティティ作成も後回し）
- コンフリクトは大歓迎
でないとこのままのペースだとチーム開発期間中にアプリ作成間に合わないのでは？と思っています
なにか他に良い意見があればなんなりとお願いします！！！
▶コンフリクトは開発モチベーショが下がるので避けたい

- どこまで実装することを報告するか？
- 案①
クライアントを新規登録できる 5pt
クライアントがログインできる 2pt
クライアント情報の登録ができる 13pt
懸念点：永井さんの負担が大き過ぎる
▶ボツ

- 案②
クライアント情報の登録ができる 13pt
裏で直接関わりのないフロント・バックエンドの実装をすすめる
懸念点：本イテレーションでも目標ptを消化できない
▶ボツ

- 案③
クライアント情報の登録ができる 13pt
自分の情報が確認できる 5pt
懸念点：そこそこボリュームが大きいので来週中の方向はどうするか？
▶ボツ

- 案④
先にフロントで画面を作っていく(Storybook や 作成した画面を共有して報告)
懸念点：ポイントが測れないので進捗が見えにくい
▶採用
懸念点については、予め事情を説明して残りのイテレーションで消化できると伝える。
ユーザーストーリーのポイントとは直接関連しないのでポイント消化できていないように見えるが、実装は進んでいるので残りのイテレーションで消化していける見込みでいます。

▶エンドポイントをまずは確定したい(miroは暫定)
▶本イテレーションは案④のフロント実装を先にすすめる
▶どこまでやるを話すか？
・各ページがあります。主要なアクションとほかページへの遷移ができるUIだけがある。CSSはない。（デザインが来てからやります）
・各ページが遷移できます。
・ログインしている/していないでページのアクセス制限ができる。
・エンドポイントを叩いてデータ取得は無理
・モックデータを画面に出すところまでいけるかどうか微妙なので、1週間後に可否伝えます
・~~エンドポイントを叩いてデータ取得はモックまで実装するかは、一週間進行して様子見る。~~
・ ~~コーチを選択するUI/UXは一週間進行してまた報告する。~~
・モデリング再検討をすすめる。
余裕がある人をすすめる。

- バックエンド実装の進め方について
- 0.APIエンドポイント設計
- モデリングとエンドポイント設計は別のお話
- フロントエンドでどんなAPIを叩くかを決める。それからバックエンドのAPIの実装を進める。
- 上記の間にモデリングを進める。
- 1.ドメイン層実装
- 2.ユースケース層実装
- インフラ層はおそらく一番最後（スキーマ作成）

- その他

## 関連リンク

- miro: https://miro.com/app/board/o9J_l0R7ZF0=/
- 第1イテレーションMTG： https://hackmd.io/AhXekMnWRm-z61hIv9h8ig?both
- 第2イテレーションMTG: https://hackmd.io/KyuWTmcqTqyUdEeaCmCB8w?both