スクラムガイド〜2020/11版〜

スクラムガイドが更新されていたので感じたこと、こんな理解をしているみたいなことをまとめます。

タイトル未設定

スクラムの目的

究極なことを言うと、ボク等は「分からない」ことを「分かる」と表現することがよくあります。
太陽が東から登る理由を「地球が自転している」「太陽の周りを公転している」みたいなことから説明することはできますが、なぜ自転してる？なぜ明日も同じことが起こると言い切れる？みたいな部分から説明できる人はいないと思います。
「わかる」ためにはなんらか前提が必ず存在しており、その前提の上で考える以上のことはボクたちの能力からは不可能と考えるべきです。

チームで働くことについても同様で、変数がボクたちが把握できないレベルで存在します。
そのため、全て起こることに対して「わかる」ということはありえません。スクラムにおけるその「前提」に当たる部分が「経験」になります。

万人に対して100%正解と言える開発手法は存在しません。経験から何かを学び、次の行動に活かしながら学んでいくしかないので、スクラムは「発見しやすい（透明性）」「分類しやすい（検査）」「学びやすい（適応）」を満たすただのフレームワークに過ぎません。

スクラムチームの構成

・プロダクトオーナー１人
・スクラムマスター１人
・開発者複数人

開発で言えば、価値を生み出すDoneまでにざっくり「価値を発見する」「価値を届ける」の２種類行う必要あるが、ここまで全てスクラムチームで完結する。
届けるためにはテストをしなければならない、価値を発見しなければならない・・・と考えると、自ずとメンバーの特性は決まってくるように思える。

プロダクトオーナーはRoIを最大化する事に責任がある。
目に見える形として、バックログをメンテしている。
とはいえ、バックログを整えるのはプロダクトオーナーのみではなく、全員でやる必要がある前提ではあるものの、最終的な決定権はPOが持っているべき。

スクラムマスターはスクラムを確立させることに責任を持つ。
変な言い方だが、スクラムチームにとってスクラムが有用で無いと判断すればスクラムマスターはスクラムをやめるよう促す。
スクラムの理論を全員に理解してもらえるよう支援する（なんでもやる）が、意思決定権は無い。

開発者は常に結果に対して責任を持つ。
スプリントの計画を作成するところから完成の定義を作り、ゴールするまでを自立した組織として行う。

イベント

スクラムにはいくつかイベントが存在している。
これらは「透明性」「検査」「適応」をこなすために設計されている。
可能なら複雑さを低減するために同じ時間と場所が望ましい。
しかし、これもコロナ禍などの場合はその時々で「検査」し、「適応」する必要があり、場所というのは同じツールなどで複雑さを低減できる。

スプリント
１ヶ月以内の決まった長さで回す１サイクル。
プロダクトゴールに達成するために必要なすべての作業はスプリント内で行われる。
これは検査と適応を素早く行うためで、少なくとも必ず１スプリント内では行われるフレームワークになっている。
仮にスプリントゴールが役に立たなくなった場合、プロダクトオーナーがスプリントの中止をする権限がある。

スプリントの中で行われるイベントは次の通り。
・スプリントプランニング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ

スプリントプランニング
必ずスプリントの初めに行う。
プロダクトオーナーが用意したバックログを見ながらスクラムチームがこのスプリント内で何を行うか決定する。
終わった時に得られる価値は何か、どう達成するかを全員の認識が一致するよう計画する。

デイリースクラム
毎日同じ時間、同じ場所にて行う。最大15分のイベントで検査と適応を行う。
プロダクトオーナーやスクラムマスターもアイテムに取り組んでいる場合は開発者として参加する。
計画の調整には良いきっかけにはなるイベントだが、この時だけではなく開発者は常に頻繁に話し合う。

スプリントレビュー
スプリントの成果を検査し、今後の適応を決定する場。
特にアウトプットについてのみではなく、自分たちが何を得てどう変化したかをレビューする。アウトカムを意識するとよさそうに思う。
ただし、スプリントレビューをリリースするための関門と見る必要はない。

スプリントレトロスペクティブ
個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを振り返る。
うまく行った事、問題が発生した事、どのように解決されたかについて話し合う。影響の大きな改善はできるだけ早く対処する。

プロダクトバックログ

プロダクトの改善に必要なものが順番に並べられたもの。
スプリントプランニングの時には選択する準備ができているようにする。
そのためには選択に必要な透明性が必要であり、透明性のためには定期的にスクラムチームはリファイメントを行う。

プロダクトのゴールは将来の状態を示している。それがスクラムチームの計画の目的となる。
バックログはその将来の状態を定義するものになる。

スプリントバックログ

開発者の持ち物、計画。
リアルタイムに現在の状況がわかるようにしなければならない。
デイリースクラムで検査できるほどの詳細さ、透明性が必要。

スプリントゴールは唯一の目的。ゴールはプランニングで作成されて、毎日検査される。
途中で予想と異なる進捗と判断した場合は、プロダクトオーナーと相談しながらスコープの調整を行う。

スプリントの中で完了したPBIの集合をインクリメントという。
複数のインクリメントが連携して機能する事を保証する検証は必要。
Doneの定義を満たさないものはインクリメントと見なさない。

完成の定義（Doneの定義）

プロダクトの品質基準を満たすインクリメントの状態を示したスクラム正式な記述。
完成の定義が組織で決定されている場合はそれに従う。そうでなければ感性の定義をスクラムチームが作成する。

まとめ・感想

2017年のものと異なり、ITに特化した記述がなくなっていた。幅広く使えるフレームワークになっていて、その認識が広まっている証拠なのだなと思う。
そして、スクラムに必ず出てくる「同じ空間」という言葉はここには載っていないことに気づいた。2017年版を見返してもなかった。
唯一似たような記述としては「複雑さを低減するために同じ時間、同じ場所が望ましい」という記載のみ。
ここでいう「同じ場所」はもしかしたら技術の力で「空間」というものを超えられるのであれば、昔から言われているスクラムの「同じ空間」というものの見方が変わってきているのかもしれないと感じた。