アジャイル・スクラム勉強会_ふりかえり

Transcript

1. アジャイルな改善の取り組み ふりかえり アジャイル・スクラム勉強会 Satoshi Harada
2. PDCAサイクル • 継続的な改善手法としてはPDCAサイクルが有名 ► Plan 計画する ► Do 実行する ► Check 実行結果を評価・分析する ► Action 改善策考えて計画に繋げる • アジャイルの継続的改善もPDCAサイクルに則る ► Plan 短い期間（イテレーション）を計画する ► Do イテレーションの計画を実行する ► Check イテレーションの結果を評価・分析する ► Action 改善策を考えて次の計画に反映する ✔ このうち、CheckとActionのための 取り組みがふりかえり
3. Try Problem Keep ふりかえりとは • イテレーションをふりかえることで、継続的な改善に繋 げる取り組み • KPTというフレームワークがよく使われる ► Keep 良かったこと・続けたいこと ✔ やってみて上手くいったことをチームに広める ► Problem 問題だったこと・改善したいこと ✔ 個人の問題とせず、チームの問題として扱う ► Try 次回のイテレーションの改善アクション ► KeepやProblemからチームの改善策を考え、次回のイテレー ションで実施する改善アクションとする
4. 実施タイミング • ふりかえりはイテレーションの最後に毎回行う • １イテレーションを１週間としている場合、１週間に１ 回はチェックと改善の機会がある １ヶ月目 ３ヶ月 ２ヶ月目 ３ヶ月目 仮に３ヶ月のプロジェクトを １週間のイテレーションで行う場合、 ふりかえりによる改善の機会は12回ある
5. 実際のやり方 • アナログ・デジタルどちらでもOK ► ホワイトボード ＋ ポストイット ► Trello, Github Projects, Atlassian Jira ✔ テレワークや、チームメンバーのロケーションがバラけている 場合はデジタルのほうが便利 TrelloでKPTのふりかえりを実施する例
6. ふりかえりのコツ • ファシリテーターが必要 ► 参加者から広く意見を募るが、より良い改善につながるように場をコント ロールする人が必要 ► 何も改善策が出ない・雑多な改善策が出すぎることもあるので、ちょうど 良い改善策の数になるように調整する ✔ チームが継続的な改善をできるようにアシストする • ダラダラやらない ► KeepとProblemは予め参加者に考えてもらっておく ► ふりかえりの会ではKeepとProblemを各自が説明し、Tryを考える場とす る • 感想だけを言う場にしない ► 「XXXだった」で終わりにしない ► 「XXXだったから、XXXにしたい」という行動プランまで考えるようにす る • 特定の人を批判しない ► 事象を憎んで人を憎まず ► 個人の課題ではなくチームの課題として捉え、改善策をチームで考える
7. 継続的改善への取り組み • Tryを考えて満足したらダメ • Tryを次のイテレーションの計画に含め入れる • 次回のふりかえりで、前回のTryが遂行されたかどうか チェックする • 問題が解消できていない場合は、引き続きTryとする Try イテレーション ふりかえり Try イテレーション ふりかえり Try イテレーション ふりかえり 続く… 計画に 反映 計画に 反映 計画に 反映 Try結果を チェック Try結果を チェック
8. マンネリを避ける • 何回かふりかえりを繰り返すとマンネリ化してくる ► アジャイルな取り組みをベースに、チームがチャレンジン グなTryを続けられるようにスクラムマスターが新たなTry を提示していく ✔ チームで一部の人しか持っていないスキル・知識を、他の人も 同じレベルでできるようにスキルトランスファーを進める ✔ タスク完了までのフローを改善する（WIP制限を検討） ✔ ペアプロ・モブプロを積極的に取り入れる ✔ テストやデプロイの自動化を推進する • チームの練度が上がって成長すると、 課題となる事柄も変化してくる ► それまで上手くいっていても、 新たな課題は発生する ► 改善に終わりはない
9. 雑談Time KPTのフレームワークでふりか えりを実施し、改善策を出して いく方法についてイメージでき ましたか？ 短い期間でくりかえしふりかえ りを実施し、継続的に改善を行 うことでチームの練度を上げて いくことについてどう思いまし たか？