スクラムについて

今回は、Scrum Guideをはじめとした様々な書籍や資料を読んだり、業務でスクラムマスターとしてやっていく中で自分が腑に落ちた部分を書いていこうと思います。粗いところは少しずつ加筆して行こうと思っています。今まで読んできた主な書籍や資料は、参考資料として最後にまとめておきます。

そもそもアジャイルとは

アジャイルソフトウェア開発宣言
アジャイル宣言の背後にある原則
Don't Do Agile, Be Agile.
アジャイルはするものではなく、目指すべき状態
- 自分の理解では、アジャイルとは変化(市場, 要件, 技術, 組織構造, 人, ...)に対して、問題を見つけ、仮説を立てて検証を行い、変化に対応していくことを自立してできる状態、を指すと思っています

スクラムとは

現状を把握するフレームワーク
Scrum Guideに則る
スクラムは経験的プロセスを基本としている
- 経験したことから学ぶ
- 具体的に起きたこと、経験したことを元に業務を進めていく
- 机上の空論にしてしまうと、結論がでない、メンバーの理解が得られない、背景の共通認識を得られない、といったことが起こりうる
経験的プロセスは以下の3つの柱によって支えられている
- 透明性
  - 何を作るか
  - 誰がやるか
  - いつやるか
  - なぜやるか
  - どうやってやるか
- 検査
  - 成果物のレビュー
  - プロセスのレビュー
- 適応
  - 問題に対して柔軟に対応する

スクラムの役割

ProductOwner
- 「プロダクトのROIを最大化すること」に責任を持つ
- ROIを常に考えて、最小の機能で最大の効果を得られるようプロダクトを導いていく
Team
- 「ScrumTeamの生産性を最大化すること」に責任を持つ
ScrumMaster
- 「ScrumTeamが実現したいことを実現する確率を最大化すること」に責任を持つ
- 自走できるチームを作りあげることや、チームの問題を浮き彫りにしやすくする仕組みや支援を行う

スクラムイベント

スプリント
- 目的
  - 決まったタイムボックスを設けることで、スクラムチームのベロシティ(生産性)を測定するため
- 2~4週間のタイムボックス
- プロダクトの方針と今やっていることに乖離が出た場合POがスプリントの中止をおこなうこともできる
スプリントプランニング
- 目的
  - スクラムチームがスプリントで行うタスクの深い理解を得るためにおこなう
  - 開発チームが自律的に動く環境を作るため
- プロダクトバックログの中から、スプリントで実現するアイテムを選ぶ
- アイテムの数は、前スプリントまでの実績(ベロシティ)を参考にする
- ベロシティを計測するために、アイテムを実現するための想定作業見積もりを相対的なポイントとして開発メンバーで決定する
- プランニングポーカーがよく使われる
- 開発メンバーのポイントが揃うまで議論する。議論することで認識のズレや仕様の理解を確認できる。
- アイテムを実現するために必要な作業を開発メンバーで洗い出す
- スプリントで達成する目標（Sprint Goal）を決める
- リファインメントなどでDefinition of Doneをあらかじめ決めておく
デイリースクラム
- 目的
  - 透明性を確保し、開発チームの状態を可視化するため
- 同じ時間、同じ場所で毎日15分開催
- スプリントゴールに対して、以下の観点を共有する
- 昨日やったこと
- 次の24時間で行うこと
- 障害になっていること
- デイリースクラムは開発メンバーのもの。雰囲気や発言に影響がでてしまうので、スクラムチーム以外の人間を入れるのは良くない
- 開発メンバーがいないからといってスキップしてよいものではない
- リモートでできないか、時間をずらしてできないか考える
- どうしてもできない場合は、決まったフォーマットでSlackに流してもらう
プロダクトバックログリファインメント
- 目的
  - プロダクトがどういう方向に進んでいくかをスクラムチーム全員で共有するため
- プロダクトバックログアイテムの優先度の調整や、あいまいな要件を精査し、次のスプリントに容易に取り組める状態を作る
スプリントレトロスペクティブ
- 目的
  - プロセスの検証と適応によって、スクラムチームの状態を改善するため
- 2週間スプリントの場合、1.5時間
- スプリントゴールに対してチームの良い点、悪い点、次へのアクションをスクラムチームで共有する
- KPTなどのフレームワークをつかうことが多い
スプリントレビュー
- 目的
  - スプリントの成果物がスプリントゴールを満たしているか検証しプロダクトの状態を把握するため
  - プロダクトバックログの状態についてスクラムチームで議論し、より深い理解を得るため
- 2週間スプリントの場合、2時間
- POやステークホルダーなどとスプリントのインクリメントをレビューし、プロダクトバックログの精査を行う
- 最終的にdoneを判断するのはPOだが、DoDを定義しておくことでスクラムチーム全員が納得のいくdoneになる
- POがレビュー時に気が付いてdoneを変更することは基本的になし

スクラムの成果物

プロダクトバックログ
- プロダクトを実現するために必要な機能やユーザストーリーを優先度の高いもの順に並べたもの
- 一つ一つの項目をプロダクトバックログアイテムと呼ぶ
- それぞれのアイテムに対してDefinition of Doneを用意する
スプリントバックログ
スプリントで着手する予定のプロダクトバックログアイテムと、それを実現するための作業をまとめたもの

スクラムをなぜやるのか？

そもそもチームとしてどういう状態を目指しているのか？
- 自己組織化されたチーム
- 変化に対して柔軟に対応し、利益を生み出すチーム
業界やメンバーなど、チームを取り巻く環境は常に変化する
- 変化に柔軟に対応でき、変化によって発生した問題を解消できているならスクラムを導入する必要はない
- 問題を浮き彫りにすることでチームに成長の機会を与えるフレームワーク