## 開発スピードを上げるにあたって - 日付:2020年1月9日 13:00-15:00 @振り返りMTG ### 課題感 #### 飯野さん： リニューアルということもあり、スピード > 質に倒している。観点を減らしたりしてレビューの質を若干緩めれば早くなるかも #### 高橋さん： 捨てる項目を明確にすれば早くなる。例えば1回目のレビューで終わりにする。一回見たら動作確認はしないetc… しかし、決定的な「これ」というものはない toC向けという事もあり、質を落とすにも限度があるので難しい 書き方的な所で言えば、現状は5分以内でリファクタ案が出るようなら提案、出なかったらスルーで運用している #### 簗瀬さん： 悩んで聞きに行くのが遅くなる 聞きにいって判明することもあった そこが早くできたら良かった 待ち時間は特になかった 詰まった、詰まりそうなときはペアでやる様にした 結果前よりは早くなった #### 飯田さん： こだわり過ぎていた感はあったかも もっとこうした方が取り回しが効きそうとかを考え過ぎていた まだ前提知識とかが不足していて、全体を見渡すことができていない #### 鳥淵さん: 個人面： - spec書くのに時間かかる。テスト1 : 実装1ぐらいの割合 - レビュー対応に時間がかかっており、その工数が見積もりに入ってない気がする？ 全体： - レスポンシブ対応についてのやりとりを鑑みるに、事前にもっと連携がとれていればよかった - MTGやるのはいいが、何が目的になっているかが不明瞭だった（と感じる） - とくに定期的にやってるMTGについて - 例)今回のMTGだと、アジェンダが欲しかった #### かみPさん： - 事業部の方針としては、上半期までに(６末までに)リリース目標としている - テストについては手動テストで担保するもあり - ユーザーストーリーごとにspec必要か・不要かを書いてもいいかも？ --- メモ欄： TODO(今後やれそうなこと): ### 実装 - スピード > 質に倒す - 書き方についてはこだわり過ぎない ### テスト - テストを書かない - テストを書く範囲を限定する - 例えば正常系のみ書く - ユーザーストーリーごとにspecを書くか/書かないかを決める - SystemSpecでも、QAに ### レビュー - レビューの観点を減らす - 二度目以降のレビューで動作検証しない - 必要に応じてペア作業を盛り込む --- # 全体MTG 鳥淵さん： - Q：最小の横幅は？ - ３２０px以下の場合には考慮しなくて良い(最小デバイスがSE) 飯田さん： - アイコンロード中の画面の依頼等はどこでやればよいですか？ - Slackでお願いします（ながたきさん） ながたきさん： - Notion - ScrumMateにいれてるタスクをNotionに以降 - アプリのキックオフまでにWebでやり残したことをやっておきたい - タスク