- WikiのURL(Markdown形式)や ...
- 画像URL や ...
- 操作可能な画面のURLや ...
- (あれば...) ...
- なぜこの変更をするのか、
- 課題は何か、
- これによってどう解決されるのか、
- など、この変更に対する概要を記載
- 主催者へのメリット・デメリット
- 応募者へのメリット・デメリット
- その他のユーザへのメリット・デメリット
- なにをどう変更したか
- ロジックがどういう手順で動くのか、
- DBからどういうクエリで何をとってそれに何を処理するのか、
- などなど、
- レビュワーにわかるように、技術的視線での変更概要説明
- 使い方の説明
- 再現条件 (例えば、いいねの状態、デバイスの状態、プランの状態や、設定によってこういう風に使える、とかこういう画面が出てくる、とか条件があれば)
- 変更前のスクリーンショット
- 変更後のスクリーンショット
- マイグレーションが必要な場合、
ALTER TABLE等を記載する
記入例:
ALTER TABLE message_send ADD body_replacements ...- 変更されるクエリ (変更前、変更後)
- 新規に追加されるクエリ
- 観点:
- WHERE句に指定した条件の index 設計は適切か
- 想定される対象のデータ量
- 想定されるデータ量が大量のとき大丈夫か (ダメな場合、いつまでにどうにかする予定があるのか、忘れないために別チケットを用意したか)
- メールアドレスや住所情報等、個人情報にあたるものを新規に保存する場合、ドキュメントを書き、そこへのリンクを貼る
重要な機能を追加・変更した場合、ログを仕込む必要があるか、ログが入っているか、入れているログが変更によって漏れていないかなどを確認する必要があります。
- 重要な機能であり、ログを仕込んだ (説明用Wikiへのリンク)
- ログを入れる必要ナシ
- テストする際の項目を、このように、チェック可能な形式で記載する。
- テストしたらチェックを入れていく。(staging でテスト、など出ない場合、基本すべてのチェックが終わった時点でレビューに入る)
- 特に、PC、モバイルの違い、応募フローの再現手順など、できるだけ広い視野で。
- 詳しくは、テスト観点リストも参照のこと。
- できれば、開発した人以外が 項目を洗い出してください。(開発者本人は、盲目的になっている可能性があります)
- 機能のON/OFF によって画面の出しわけ、機能が有効になったり無効になったりする場合、場合分けしてテスト項目を書く
- 他チームへテストを依頼した場合はチーム名書いておこう
- それをテストしたチームの人が、チェックを入れよう
箇条書きで書く。できれば次のチケットを作る。
- あれこれを治す #xxxxxx
- あれそれを実装する #xxxxxx
↓ 共有したい先にチェックをいれてください。
merge 時
HipChat: 部屋 @sotarok などを記載すると、共有時に自動的に mention もつけてくれます。
記法: HipChat: 部屋 @sotarok
社内共有:
- HipChat: Crocos ALL
- HipChat: リリース情報
- HipChat: 開発
- HipChat: グロースx開発
- HipChat: 営業x開発グロース
- HipChat: サポート
- メールで共有: (ここにメールアドレスを記載)
社外アナウンス (上から大きい順):
- プレスリリース
- 告知用ページ作成 (w/ グロース)
- 事前メールアナウンス (internal のアナウンス機能で)
- Facebookページでアナウンス
- アナウンス無し
- レビュワーに対する注意点 (ここはこういう風に思ったけどこういう風に実装した、ここはこうしようと思ったんだけどこういう悩みがありやめた、など注意点があれば)
- リリースに対する注意点 (その他)