- 開発の流れ
- 実装前に方針を話す
- 設計を決定するというわけではない
- [[🗃️ユーザーストーリー]]をタスク分解する
- [[🗃️カンバン]]で管理
- 完了基準を明確にする
- [[🗃️準備完了の定義(Definition of Rady)]]
- 定義例
- 誰にとっての価値があるのかが明確になっていること
- チケットの大きさが適切に分割されていること
- [[🗃️受け入れ基準]]が用意されていること
- 開発方針や設計など、他チームと協議/相談しなければならない事項が明らかになっていること
- 💭今のチームで、「生煮え」と表現しているやつは、この定義がちゃんとできていないことで起こっていそう。
- [[🗃️完成の定義(Definition of Done)]]
- 定義例
- コードレビューが完了していること
- テスト実行が完了していること
- デプロイが完了していること
- [[🗃️受け入れ基準]]
- ポイント
- 達成できたかどうかを客観的/定量的に判断できる
- 開発に着手する前に定義されている
- 解決したい課題や要求にフォーカスしており、実装や特定の解決策に依存しない
- 機能要件と非機能要件の両方が含まれる
- 受け入れ基準の間に依存関係がなく、それぞれ独立して確認できる
- 例: メールマガジンにバナーを掲載する
- メールマガジンにキャンペーンのお知らせバナーが表示されること
- バナーのクリック率が計測できること
- PC/SMPのメールクライアントでデザイン崩れがないこと
- メールクライアントが画像表示に対応していなかった場合、代わりのテキストリンクが表示されること
- [[🗃️未完了作業(Undoneワーク)]]
- 💭これいつも勘違いしてしまうやつ
- 徐々に[[🗃️完成の定義(Definition of Done)]]に含めていくことが望ましい。
- [[🗃️完成の定義(Definition of Done)]]に合わせて、[[🗃️未完了作業(Undoneワーク)]]を整理し認識すること、1つずつ[[🗃️完成の定義(Definition of Done)]]に取り込む必要がある
- 💭これはなかなかできないけど、チームを強くしていくために必要なプロセスな気がする