理由はそのうち考える

まずやってみよう

スクラムガイドを読んでスクラムをおさらいする

スクラムガイドを読んだ

いつの間にかCSMの更新月になっていた。業務ではスクラムを使っていないので今回はどうしようかなあと迷っていたとき、 社内にスクラムでやりたい人がいるという話を聞いた。そこで自分CSM持ってますよと話をしたら勉強会を企画してほしいとのこと。 ちょうど迷っていた矢先の話で、いい後押しになる機会が得られてラッキーと思い引き受けることにした。 しかし暫くスクラム関連の書籍などに真剣に目を通しておらず少し不安。というわけでスクラムガイドを読んでおさらいしようと思う。

The Scrum Guide

スクラムの定義

複雑で変化の激しい問題に対応するためのフレームワークスクラムチーム・その役割・イベント・作成物・ルールで構成されている。 決定的な方法論ではない。

スクラムの用途

研究分野・新規開発・派生開発・保守など様々な用途がある。
スクラムはソフトウェア開発のみならず、個人や社会が日常的に使用するあらゆるものに使用されている。

スクラムの理論

経験的プロセス制御の理論を基本としている。
透明性・検査・適応の3本柱によって、経験的プロセス制御の実現を支えている。 検査と適応のために4つの公式イベントがある(後述)。

透明性

結果責任を持つものに対して見える化されていること。 見ている人が共通理解を持つこと。共通理解の例としては、プロセスの用語を参加者全員で共有している・ 作業する人とそのインクリメントを検査する人が「完成」の定義を共有しているといったようなことが挙げられる。

検査

スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を察知する。

適応

プロセスの不備が許容値を超え、成果と成るプロダクトを受け入れられないと検査担当者が判断した場合、 プロセスやその構成要素を調整する必要がある。調整はできるだけ速く行い、これ以上の逸脱を防がなければならない。

スクラムの価値基準

5つの価値基準があり、これを取り入れ実践するとき、スクラムの3本柱は現実のものとなり、あらゆる人に対する信頼が築かれる。 スクラムチームのメンバーは、仕事をすすめるなかで、これらの価値基準を学習・探索する。

確約(commitment)

ゴールの達成に全力を尽くすことを確約する。

勇気(courage)

正しいことをする勇気を持つ。

集中(focus)

ゴールの達成に集中する。

公開(openness)

すべての仕事や問題を公開する。

尊敬(respect)

互いを尊重する。

スクラムチーム

3つのロール(役割)で構成される。スクラムチームは自己組織化されており、機能横断的である。 チーム外に頼ること無く、自分たちの選択によって物事を進めていく。

プロダクトオーナー

開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。 プロダクトバックログを管理する一人のひと。 プロダクトバックログアイテムを明確に表現し、開発チームに理解してもらう。

開発チーム

各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることの専門家で構成されている。 自己組織化されていて機能横断的。開発チームのメンバーに専門領域があったとしても、肩書き・サブチームなどは持たない。 自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。 あくまで「開発チーム」として、最終的な責任はチーム全体で持つ。4~9人くらいで構成される。 この範囲を超えると生産性を最大化できずうまく回らなくなる。

スクラムマスター

スクラムの促進と支援に責任を持つ。スクラムをうまく回すための人。 理論・プラクティス・ルール・価値基準を全員に理解してもらう。 プロダクトオーナーや開発チームの支援を行うサーバントリーダー。 外部の人との調整も行い、スクラムチームとやりとりをするときに役に立つこと・立たないことを理解してもらう。 組織にも働きかけ、他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。

スクラムイベント

1つのスプリントの中に4つのイベントがある。すべてのイベントは時間に上限のあるタイムボックス化されたイベント。

スプリント

スクラムの中心。「完成」した利用可能な、リリース判断可能なプロダクトインクリメントを作るための1ヶ月以下のタイムボックス。 開発中は常に一定の長さ。スプリントが終了すると、すぐに新しいスプリントが開始される。 スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。 1ヶ月以上になると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性があるため、この長さを 上限として検査・適応することで、予測可能性が高まり不確実性に対応する。スプリントはプロダクトオーナーの権限によって中止することもできる。

スプリントプランニング

スプリントの作業計画。スクラムチームの共同作業。スプリントが1ヶ月の場合、最大8時間。 プロダクトバックログ・最新のプロダクトインクリメント・開発チームが予想するキャパシティと過去の実績などから、 インクリメントで何を届けるか・インクリメントを届けるために必要な作業をどのように成し遂げるか・スプリントで何ができるかを考える。

スプリントプランニングでは、スプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的のこと。 スプリントプランニングが終了したとき、開発チームはどのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかを プロダクトオーナーとスクラムマスターに説明できるようになっている必要がある。

デイリースクラム

開発チームのための15分間のタイムボックス。毎日決まった時間・場所で開催する。次の24時間を計画する。 前回のデイリースクラムから行った作業の検査と今後のスプリント作業の予想をすることで、チームのコラボレーションやパフォーマンスを最適化する。 デイリースクラムは開発チームのためのもので、構成も開発チームが設定する。開発チーム以外が参加する場合は、開発チームの邪魔にならないようにする。 デイリースクラムは開発チームのプロジェクト知識を向上させるもので、検査と適応の重要なイベント。

スプリントレビュー

スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うもの。 スクラムチームとステークホルダーがスプリントの成果をレビューする。スプリントが1ヶ月の場合は最大4時間。 プロダクトオーナーがプロダクトバックログアイテムの「完成」したものとしていないものについて説明する。 またプロダクトバックログの状況を説明する。開発チームは「完成」したものをデモして、インクリメントに対する質問に答える。 グループ全体で次に何をすべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。

スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログ

スプリントレトロスペクティブ

スクラムチームの検査と次のスプリントの改善計画を作成する機会。スプリントレビューが終わって、次のスプリントが始まる前に行う。 スプリントが1ヶ月の場合、最大3時間。スクラムマスターは、このミーティングがポジティブで生産的になるようにする。

人・関係・プロセス・ツールの観点から今回のスプリントを検査する、うまくいった項目や今後の改善が必要な項目を特定・整理する、 スクラムチームの作業の改善実施計画を作成する、といった目的がある。 スプリントが効果的で楽しいものになるようにするための取り組みでもある。

スクラムの作成物

プロダクトバックログ

プロダクトに必要だと把握しているものをすべて順番に並べた一覧。 上に並んでいるものほど明確で詳細。 プロダクトに対する変更要求の唯一の情報源。プロダクトオーナーがその内容・可用性・並び順に責任を持つ。 プロダクトが存在する限り、存在し続けるもの。複数のスクラムチームが同じプロダクトの作業をする場合、 1つのプロダクトバックログに記述する。スプリントレビューにおいて、残作業を追跡する。

プロダクトバックログリファインメント

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積もり、並び替えをすること。 プロダクトオーナーと開発チームが協力して行う継続的なプロセス。いつどのようにリファインメントするかは スクラムチームが決定する。リファインメントは開発チームの作業の10%以下にすることが多い。

スプリントバックログ

スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、 スプリントゴールを達成するための計画を合わせたもの。これにより、開発チームがスプリントゴールを達成するのに 必要な作業がすべてみえる化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した 優先順にの高いプロセスの改善策を少なくとも1つは含めておく。スプリントバックログは十分に詳細であり、今後も 変更される可能性のある計画。またスプリントで創発される。新しい作業が必要なった時点で開発チームがスプリント バックログに作業を追加する。開発チームのみがスプリントバックログを変更できる。デイリースクラムで残作業を追跡する。

インクリメント

これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたもの。 スプリントの終了時には、新しいインクリメントが「完成」していなければならない。また常に動作する状態で、 検査可能なものである。

作業の透明性

スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。 透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。スクラムマスターは、開発チーム、 プロダクトオーナー、その他の関係者と一緒になって、作成物が完全に透明化されているかを理解する。

完成の定義

プロダクトバックログアイテムやインクリメントの「完成」を決めるに時には、全員がその意味を理解しておかなければならない。 作業の完了についてメンバーが共通の理解を持ち、透明性の確保をしなければならない。 インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプロダクトに適した「完成」を 定義しなければならない。また複数のスクラムチームがある場合は、共通の「完成」の定義を使用しなければならない。

スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。そうした場合、以前に 「完成」したインクリメントにも影響があることが明らかになる可能性もある。

最後に

ざっとスクラムの基礎を並べてみた(なるべく個人の解釈を挟まず写経っぽく)。 改めて読んでみると、ニーズが多様化する現代において、とてつもなく不確実なものを作っていく必要がある。 そのフレームワークとしてスクラムはとても合っている。基礎的な知識はとてもシンプルで理解しやすいが、 いざ実践となると難しくなる。またその根底にあるのは対話で、いかなるときにおいても話し合いによって共通の理解を得ることが重要。 5つの価値基準を携わる人ひとりひとりが理解(および理解しようと)し、心理的安全性を確保することが大前提となる。 人に寄り添うフレームワークとしてのスクラムは、個人的にはとても共感できるので好き。