概要
プロジェクトに関してソフトウェア「以外」の要素、すなわち個人やチームの能力や関係性、プロセスやツールなどに関して、チームの全員が現状認識を共有し、課題や改善案などを出し合います。
今回のスプリントについてうまく行ったことは何か、どんな問題があるか、次のスプリントで実施可能な改善策は何かなどを話し合い、チームの能力や開発効率の向上に繋げます。
一般的に立ち上げ間もないチームでは問題が多く、対処すべき点が多く出る傾向がありますが、開発と並行して改善を行うため、優先度を決めて1~2週間のスプリントで2~3個の改善に取り組むのが現実的です。
| 評価の観点 | 改善に向けて | ||
|---|---|---|---|
| 組織 | ビジネス | ・ユーザーに届けたいサービスの価値が実現できる組織になっているか ・想定していた売上や利益、費用削減効果を達成できる組織になっているか |
・開発チームだけでは改善が難しく、ステークホルダーを含む組織で取り組むべき問題も 少なくないため、関係者が集まってフラットに課題を共有し、解決策を検討します。 (ステークホルダーやプロダクトオーナーが参加できない場合にはエスカレーションを行います) ・課題だけでなく、必ず「うまくできていること」を認め合うことも重要であり、「より上手くできるようにする」ことをで組織の効率化を図ることができます。 |
| デプロイ | ・バージョン管理システムに格納された資材が、デプロイ可能な状態である割合 ・ソースコードをコミットしてからデプロイまでにかかる時間 ・デプロイの頻度 |
||
| 開発チーム | ビジネス | ・ユーザーに届ける価値をより大きくするために、 開発チームとして何をすべきか | ・ソフトウェアのビジネス価値について再認識を図るためインセプションデッキの見直しを行います。 ・バックログアイテムを着手可能 (Ready) 状態にするとともに、ストーリーの見直しを行います。 ・コミュニケーションの改善に必要なツールや、ペアプログラミングなどのプラクティスを検討します。 |
| 管理・運営 | ・ベロシティ(相対見積値による開発速度)の安定に向けた課題は何か ・チームの心理的安全性は醸成されているか (チームの誰もが思ったことを率直に話せる雰囲気になっているか) |
||
・レトロスペクティブのフレームワークは多数存在するが、主なものを以下に記載。
| フレームワーク | 概要 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| KPT | ・もっともメジャーなレトロスペクティブ手法です。 ・メンバー全員が以下のKeep/Problem/Tryの3点につ いて共有します。
実施イメージ  |
||||||||||||
| Sailboat Retrospective |
・開発に伴う様々な事柄を視覚的に表現するレトロスペクティブ手法です。 ・ゴールやリスクの項目があるため、関係者も含めた認識共有を行う際などに活用します。 ・全員で作成したのちに、阻害要因やリスクの軽減、推進状況の促進などを検討します。
実施イメージ  |
||||||||||||
| YWT | ・Y(やった)W(分かった) T (次にやること)に着目し て行うレトロスペクティブ手法です。 ・KPTよりも前向きに改善に取り組める、と言われています。
実施イメージ  |
