遅れがあれば内容を共有 Bad 事務的に現状のタスクの進捗状況の確認 before タスクの問題点の共有 after Good 問題点のみを共有するようにした Good 人数も少ないので、報告せずとも他のエンジニアの状況は概ね理解できている Good 余った時間を数値確認(前日の売り上げ、会員登録数など)の時間に使っている デイリースクラムの before/after
Try)でスプリントを振り返る Good KPTで各自振り返る Bad 振り返りはKPTのみ before タスクの上振れや下振れを振り返る after Good プランニングポーカーで付けたポイントを元に、上振れ下振れを振り返る Good より自分たちのサービスに詳しくなっていく Good KPTは継続 Bad 強いて言うなら少し時間が掛かるようになった レトロスペクティブの before/after
ストーリーポイントは担当者が事前に付けておく Bad タスクの詳細を把握しているのは担当者のみ before プランニングポーカーの導入 after Good ポイントを付けをするために、全員がタスクの詳細を理解できる Good 各自の懸念や、時短ポイントを共有 Good 曖昧な仕様を確認して、仕様の確定、 PMに戻すなどを行う Bad プランニングの時間が増えた スプリントプランニングの before/after
PR作成のコストは低い Bad プロジェクトのPRの行数がかなり多くなってしまう Bad レビューで不具合を拾えない before PRをいくつかに分ける after Good PRを分けて100〜200行程度のサイズにしてレビューを依頼する Good 1回あたりのレビュー負荷が軽減されて、不具合に気づきやすくなった Bad PRを分ける手間が生じる プルリクエストの before/after