APP KPT

1. Try

1.1. 挑戦中

1.1.1. (New!)Trello終わった方がコメントを残し。気づかれるようにする

1.1.2. 平行案件はTrelloのチケットに影響があることをコメントで分かるようにしておく(上村)

1.1.3. 浅い設計でAPIとネイティブ側で話し合って決めていく。もっと一緒に考える

1.1.4. KPTの頻度 大きいリリース案件があったら、必ずやる。(それ以外は1ヶ月に1回でもいいのでは?)

1.2. 一旦ストップ

1.2.1. デザインのルール化

1.2.2. メモリーリーク対応が重要だと改めて痛感した (5/27KTP)

2. Problem

2.1. 挑戦予定

2.1.1. QAの起票が多くなりがちで、検証側の負荷が高くなってるように見える

2.1.2. 検証がギリギリだった

2.1.3. 負債返却をやるか迷った

2.1.4. 気づかなかったバグが結構発見された

2.2. 様子見

2.2.1. 上村さんがメンションに気が付かない

3. Keep

3.1. 習慣化

3.1.1. タスク管理がしっかりとできている

3.1.2. リリースの切り分け(優先順位)ができる

3.1.3. デザインとAPIの距離が近く、修正と共有がしやすい

3.1.4. 仕様やデザインの良し悪しに議論できる

3.1.5. 検証(QA)をやってもらえて実装が早い

3.1.6. ドキュメントを細々やらなくても実装ができる

3.1.7. 1人1人が連携しながら自走できる

3.1.8. 朝会で小話をする文化

3.2. 継続中

3.2.1. メンバーがデザインルールを理解している

3.2.2. Trelloのチェック列に移動しておく事で、開発がスムーズに進んだ

3.2.3. ［Try昇格］開発中に気づかなかったバグや負債返却を見つけたらバックログにバンバン上げていく

3.2.4. ［Try］QAの負荷をなくすため、制作の精度をあげる