# カイタク開発　KPTシート
[toc]

template

## YYYY-M-D
### Good
#### 清水
#### 杉田
#### 藤井
#### 矢代
---
### Keep
---
### Problem
#### 清水
#### 杉田
#### 藤井
#### 矢代
---
### Try

#### コミュニケーション

#### 設計・見積もり


#### 開発

#### スクラムイベント

#### その他

## 2021-10-18
### Good
#### 清水
- フロントに関するメンバーのエラー解決の助けをすることができた
- 早い段階で質問できた　--基準を決めたい
#### 杉田
- slackでの情報交換が活発だった
- 気軽に質問しやすい環境だった。
#### 矢代
- Zenhub上からしっかり取っていった
- わからないことからコールまでの時間がちょうどよかった
- 巻き取りが発生してもスムーズに対応できた

---
### Keep
- 早い段階で質問できた　--基準を決めたい
- 巻き取りが発生してもスムーズに対応できた
- slackでの情報交換が活発だった
---
### Problem
#### 清水
- slack上だと情報が流れてしまって見落とすことがある
- コーディングルールが定まってない
- コンポーネント化の基準が曖昧
- railsが弱め
#### 杉田
- 牛頭さんのアドバイスを3人が理解していなかった。
- 設計段階で話し合いをしていなかったので、レビュー中にお互いの意見がぶつかる事があった。
#### 矢代
- イシュー、PRのラベル管理
- テスト、シーディングの手探り感
- 設計
---
### Try
- (現象・意見)デグレや作り直しが起こる

- 仕様
- 設計

- (現象・事実)レビュー時の修正が多くなる
- 設計
- (原因・事実)開発メンバー同士のすり合わせをしてない
- 設計時のすり合わせの敷居が高い
- ほかメンバーに迷惑かなと思ってしまう
- そのissueでの不明点の少ないから
- (原因・事実)設計思想が違う
- 仕様
- すり合わせてなかった

- 設計とは？
- 仕様に対しての具体化
- どのようなコントローラやメソッドをつくるか
- 実装内容を細かに表す
- 内部設計
- ボタンの色のレベルまで落とし込む
- 見やすさ等考慮して、位置も決める
- 実装するにあたっての要件をまとめる
- 機能レベルで書き出す
- ディレクトリ、ファイル名等書く
- ページの内容も書く
- 抽象的かつ明確に、完成物をイメージする
- 具体的に掘り下げない
- 開発直前は具体化する ⭕

抽象的
- 機能レベルで書き出す
- ディレクトリ、ファイル名等書く
- ページの内容も書く
- どのようなコントローラやメソッドをつくるか
- ボタンの色のレベルまで落とし込む
- 見やすさ等考慮して、位置も決める
具体的

- 共通認識として
- 機能レベルで書き出す
- ページの内容も書く
- ディレクトリ、ファイル名等書く
- どのようなコントローラやメソッドをつくるか

## 2021-10-19〜20201-11-5
### Good

#### コミュニケーション
- コミュニケーションが増えた
- チームの雰囲気がとても良い（ペアプロできている）

#### 設計・見積もり
- 見積もりが手慣れてきた
- 見積もり・設計を全員で行なったことにより実装前にある程度方向性が定まったのがよかった
- 最初の見積もりのポイントつけで合わなくも、折り合いをつけて決定まで持っていけたのはよかった

#### 開発
- スクラム開発通りに開発ができてきたこと
- 全員でissueを片付ける意識が芽生え始めたこと(ペアプロで対応)

#### スクラムイベント
- デモがうまくいったっぽいのでよかった
- スクラムへの理解がある程度あり見積もりやスプリント計画、デモ等がスムーズに行えていた

---
### Keep
- 見積もり・設計を全員で行なったことにより実装前にある程度方向性が定まったのがよかった

- 全員でissueを片付ける意識が芽生え始めたこと(ペアプロで対応)

- チームの雰囲気がとても良い（ペアプロできている）

---
### Problem

---
一人10pt
- レビュー待ちが溜まった
- レビュー待ちが溜まる
- 原因
- 軽微なissueを5つほどPR出した。
- PRが出た際にPR対応にすぐに行けれなかった。

- 解決策
- レーンの制限を設ける(チーム人数-1がwipの数)
-
10pt:3,4,3

- リダイレクトの脆弱性の件、チーム内で対応できなかった。
9pt:3,3,3
- 原因
- 見積もり時点で脆弱性の話をしていなかった
- 解決策
- 1issueに対しての理解度をもっと上げる
- 見積もり時点で話し合いを行い、issueに書き込む

- レビューコメントの、「お気持ち・ぼやき」と「指摘」の対応に困る
6pt:4, 2

- issueの進捗状況がわからない。
5pt:3,2

- 見積もり前のため着手できるissueがなくて手待ちが発生した
5pt:3,2

- PO判断なく対応している？
5pt:3,2

- 各ミーティング時に司会を誰がするのか把握していなくて、1〜2分準備に時間がかかる。
3pt:3

- ラベル管理がめんどくさい（PR,イシュー両方）
pt:

### Try
- レビュー待ちが溜まる
- 解決策
- レーンの制限を設ける(チーム人数-1がwipの数)

- リダイレクトの脆弱性の件、チーム内で対応できなかった。
- 解決策
- 1issueに対しての理解度をもっと上げる
- 見積もり時点で話し合いを行い、issueに書き込む

## 20201-11-8〜20201-11-11
### Good

#### コミュニケーション
- POとのコミュニケーション取れている
- チーム外の人からも知見を借りていたこと

#### 設計・見積もり

#### 開発
- PRレビューが早かった
- 手待ちがなかった

#### スクラムイベント
- 1スプリントしっかりと終わらせれたこと
- スクラム体制レベルアップ
- リグレッションテストPR追加
#### その他
- レーン制限守れた
- 未完了のissueがあったものの、デモまでスムーズに持っていけた
- 素早くスケジュール調整ができていたこと

---
### Keep
- POとのコミュニケーション取れている
- PRレビューが早かった
- スクラム体制レベルアップ
- リグレッションテストPR追加
---
### Problem
#### 清水
- コンフリクト解消に慣れていない
- コミットメッセージに統一感がないためreleaseブランチにマージする際に微妙な感じになる
- リダイレクトテスト機能強化の設計が不十分だった

#### 杉田
- スプリント計画通りに終わらなかった
#### 矢代
- インフラ、むずい
- チーム外との話し合い
- どう提案？
- デプロイで事故りかけた？手順とか対策まとめておけばよかったか
- チェックリスト形式
- 故障かな？と思ったら
#### 藤井
- kanbanがまだうまく活用できていなさそう
- 資料系の更新がされていなさそう
---
### Try
- コミットメッセージに統一感がないためreleaseブランチにマージする際に微妙な感じになる
- prefix: #issue番号　メッセージ
- https://qiita.com/konatsu_p/items/dfe199ebe3a7d2010b3e

## 2021-11-12 ~ 2021-11-18
### Good
#### コミュニケーション
- 過去を遡る際スムーズだった
- チームワークがいい

#### 設計・見積もり
- 可用性の設計についてPOに納得してもらい了承を得ることができた

#### 開発
- インフラ意外に軽く済みそう？
- Hotfixの対応に慣れてきた（対応がないのがベスト)

#### スクラムイベント
- POの全体的な意向を知れた
- 業務と疎結合
- スコープ
- 外販予定

#### その他
- ベロシティ安定している
- PO確認ができている
- ルールをしっかり守っている
---
### Keep
- チーム内で助け合いながらデモをした
- コミットメッセージが統一されていた→ルール化

---
### Problem
#### 清水
- 設計の詰めが甘いため、開発やレビューで漏れが発生し、差し戻しになってしまう
- デモの日程の関係で毎回デモ前にバタバタしてしまう？

#### 杉田
- スプリントプランニング、デモ準備〜デモまでが短い(デモでゴタゴタする)
- hotfixを繰り返してしまった
#### 藤井
- デモ前バタバタしていた..?
- スクラムイベントの実施日時がずれがち
#### 矢代
- 差し戻し多い
- デモ前のハプニング
- デモ前に全体を通しての練習を個人だけでも時間を取るべき？
---
### Try
- デモの日程の関係で毎回デモ前にバタバタしてしまう？
- スケジュールを前もって確保する
- デモリハ、スプリントプランニング(火曜日:16時固定)

- 開発やレビューで漏れが発生し、差し戻しになってしまう
- hotfixもしっかり設計する

## 2021-11-19-2021-11-26
### Good
#### 清水

#### 杉田

#### 藤井

#### 矢代

#### コミュニケーション
- POへの連絡がこまめにできていた？
- PO確認がしっかりできていた
- スケジュール調整やペアプロなど声かけし合ってスムーズに行えた
- スケジュール的にデモ準備などが楽だった？

#### 設計・見積もり

#### 開発
- コーディングルールを決めることができた
- ペアプロが多かった
- コーディングルールのすり合わせをすぐした

#### スクラムイベント

#### その他
---
### Keep
- コーディングルールのすり合わせをすぐした(その他の疑問点を含む)
- PO確認がしっかりできていた
---

### Problem
#### 清水
- 計画に対して完了が0だった
- 非稼働の日にちを加味した計画が立てられてなかった
- Issueの対応漏れ、見落としがあった
#### 杉田
- #98が未着手のままだった。(受入条件を見ていなかった)
- issueの分割がうまく行えなかった

#### 藤井
- 実装していないものが出荷扱いになっていた？
- ベロシティが0ptだった
#### 矢代
- スクラムポイントが0
- 重いタスクの分割をしなかった
- デモ終了からデプロイまで7日かかった
- イシューがなぜかすり抜ける現象があった

`#98問題の究明`
満たしていなかった受入条件：
- クリック履歴一覧画面において、「送信済み」か否かがデータ行ごとに表示されること
- クリック履歴のCSVダウンロードで記録されるCSVファイルにおいても「送信済み」か否かがデータ行ごとに記録されていること

- 一緒に見積もりしちゃった
- PR時点でもイシューのリンクがひとつだった
- 98の受入条件を深く読んでいなかった
- 一緒にレーン移動していた
- 98の受入条件を見たタイミングは見積もりのタイミングだけ
- 確認すればよかったのでは
- 確認はしたが認識が薄かった
- https://buzz-ink.slack.com/archives/C014J00E170/p1635740183260800

- 今後
- 分かれている→ユーザーストーリーが違うのを前提とし、違いはなにかに焦点を当てる
- どうしてもわからなければPOに確認する。Slackではなくコール

---
3,2 1,5→11
- 計画に対して完了が0だった
- ベロシティが0ptだった
- スクラムポイントが0
- 原因
- 大きいイシューを分割しなかった
- 対策
- 8pt以上のイシューは分割する
- それぞれが価値を提供するものであること
- 例：マイグレーションとAPIを分けたりしない
- なかなか分けるのが難しいのはがでてきたら藤井さん、POに相談する

- 非稼働の日にちを加味した計画が立てられてなかった

4,8,5,5→22
- Issueの対応漏れ、見落としがあった
- #98が未着手のままだった。(受入条件を見ていなかった)
- 実装していないものが出荷扱いになっていた？
- イシューがなぜかすり抜ける現象があった

- 原因
- 一緒に見積もりしちゃった
- PR時点でもイシューのリンクがひとつだった
- 98の受入条件を深く読んでいなかった
- 一緒にレーン移動していた
- 98の受入条件を見たタイミングは見積もりのタイミングだけ
- 確認はしたが認識が薄かった
- https://buzz-ink.slack.com/archives/C014J00E170/p1635740183260800
- 対策
- 分かれている→ユーザーストーリーが違うのを前提とし、違いはなにかに焦点を当てる
- どうしてもわからなければPOに確認する。Slackではなくコール

PRにイシューの受入条件を書く

レビューの流れ
- 開発中
- 開発Done
- レビューcomplete
- レビュー依頼
- 出せる条件①、レビュイーはPR文面にあるセルフチェックボックスにチェックをつけている。対応しないものについては取り消し線を引いている
- 出せる条件②、受入条件についても、セルフチェックボックスとは別段落にissueの受入条件をコピーする
- LGTM
- 出せる条件、レビュアーがissueの受け入れ条件、PRのチェックして欲しい項目すべてにチェックボックスをつけていること

3,2 → 5
- issueの分割がうまく行えなかった
- 重いタスクの分割をしなかった

2 → 2
- デモ終了からデプロイまで7日かかった

---
### Try
- 開発時、レビュー時に完了の定義を参照する
- 8pt以上のイシューは分割する
- それぞれが価値を提供するものであること
- 例：マイグレーションとAPIを分けたりしない
- なかなか分けるのが難しいのはがでてきたら藤井さん、POに相談する