はじめに
最近気がついたのですが、いつの間にか５年間スクラム案件に従事していました
５年間のうち、おそらく５スクラムプロジェクトほど経験してまして
ただ、経験していても本来のスクラムなのか？というルールが各プロジェクトにはあり、
本格的なスクラムって実際体験したことがないかもと思いました...
理由は、プロジェクトの諸事情や、開発メンバーの諸事情等さまざまです。
なかなか、スクラムのルールをしっかり遂行するには、条件揃えるの難しそうです。
そうすると、本来のスクラムのプロセスを忘れがちで、次キックオフの時に思い返すのが大変になるんですよね。
数年越しの本スクラムを思い出すという、、
そんな私のためのスクラムのプロセス備忘録をメモがてら残しておこうと思い記事にまとめました...!
時々過去の体験談も挟みつつまとめます！
ウォーターフォール、スクラムの違い（システム開発向け）
ウォーターフォール
- How：最初に計画を定義して、厳密にその計画に従って最後まで進める
-
メリット：
- 実施内容が明確になり、Endが明確になる。
- プロジェクトに対する予算が明確になる。
- 実施内容が明確な為、人員を揃えやすい。（人員の組み換え、追加もしやすい） -
デメリット：
- 開発プロダクトに対して具体的なイメージがない場合、仕様決めから始まる為、実現までに期間を要す。
- 計画を遂行中に、割り込み課題・仕様の変更等が発生した場合、計画の練り直し・予算の見直し等が発生してしまう。
- ビジネス（ユーザー）側と、開発側との間で認識齟齬が起きていた場合、発覚に遅れが生じる（計画がすべて完遂された後になることがある）
アジャイル
- How：チームで目標・プロセスを決め、それに対して短期間のPDCAサイクルを繰り替す
-
メリット：
- 短期間プロセスによる密な連携が必要なため、ビジネス（ユーザー）側と開発側との認識齟齬が発生しにくい。発生しても、早期に発見できる。
- 成果物の具体的なイメージがなくても小規模な目標からスタートできるため、早期実行に移しやすい。 -
デメリット：
- 成果物のゴールがないため、Endが不明確となる。
- 開発プロダクトに対して柔軟な設計を行なう必要がある。（割り込み課題・仕様の変更等が生じた際に対応に時間がかかってしまう。最悪、作り直しに。）
- 人員の追加・組み換えを容易にできない。（メンバーそれぞれがプロダクトの目標やプロセスを認識した上で取り組む必要があるため）
スクラムの用語
登場人物
- プロダクトオーナー（PO）：プロダクトに対して、何を実現したいかを考える責務（What）
- スクラムマスター（SM）：プロダクトの何をに対して、どのように実現をするプロセスを円滑に進めればいいかを考える責務（Process）
- デベロッパー（DEV）：プロダクト成果物に対して品質の責務を持つ：プロダクトのWhatに対して、どのように実現するかを考える責務（How）
- ステークホルダー（SH)：プロダクトに対しての利害関係を持つ。プロダクトのエンドユーザー等。（Feedback）
※各チーム：PO、SM、DEVの各チームを指す
※全チーム：PO、SM、DEVすべてのチームを示す
スプリントとは
スクラムチームで決めた、バックログ着手をして、成果物（インクリメント）を既存プロダクトに追加できる状態にするまでの期間（PDCAサイクルのPlan・Do・Checkを実施する期間）。
1 or ２週間で設定することが多い。開始終了の曜日を決めておくとスクラムイベントが計画しやすい。
インクリメントとは
スプリント期間で出した成果物。完了されたバックログから構成される。
スクラムプロセスの図
スクラムのプロ
1. ワーキングアグリメントを決める
各チームのメンバー全員で、仕事上のルール・価値観などを明文化した文章を作成。
こちらは後に実施するレトロスペクティブ等で定期的に見直す。
- PO：例）1. 全員参加し、全員意見を出す、2. 毎週〇日の〇時にバックログ全体を振り返る...etc
- DEV：例）1. 使用言語は〇〇、2. 詳細設計は全員で行い、属人化させない...etc
- SM：例）1. イベント中はすべてのチームメンバーが参加しやすいようにファシリテートを実施, 2. POが初心なので、要所でPO・SMの定例を実施（どのように作成を進めるか認識合せ。等）...etc
2. プロダクトバックログ作成
プロダクトバックログとは
チームで成し遂げたい作業。プロダクトの要件
プロセス
※主にPOが実施するが、誰でも作成可能
- プロダクトビジョンを作成（チームの長期的な目標。達成したい将来の状態）
- プロダクトゴールを決める。（プロダクトビジョン達成に対して、必要なアクション。成果物を抽出）
- ステークホルダー（エンドユーザー、顧客等）からプロダクトに対する要求を聞き、必要な要件としてプロダクトバックログに定義をする
- 開発チームからプロダクトに必要な作業（How）を聞き、EPICとして定義する
- POがプロダクトバックログをビジネス価値の観点から、ユーザーストーリーマッピングを元にEPICに優先順位をつけていく
- POが、EPICの中から、１スプリントで、開発~リリースできる状態までに持っていける粒度でプロダクトバックログを作成。
- POが、プロダクトバックログをビジネス価値の観点から、プロダクトバックログを優先順位づける。
- POは、スプリント毎に定期的にプロダクトバックログの見直し、優先順位の付け替えを行って管理をする
- POはバックログの並び順を元に、各スプリントのスプリントゴールを決める（各スプリントゴールを1~2センテンスで記載）
例）
下記のバックログがあったとする
- B-1：生産物に値段を編集できる
- B-2：生産の値段を参照できる
- B-3：ログインできる
<ビジネス観点からみたユーザーストーリマッピング>
- 1：認証されたユーザーのみ使用できる → B-3 優先順位１
- 2：生産物の値段を参照できるものが欲しい → B-2 優先順位2
- 2：生産物の値段が編集できると尚いい → B-1 優先順位2
3. バックログリファインメント
リファインメントとは
次以降のスプリントに対して、実施する可能性のある優先順位の高いバックログの実施内容を明確にし、
ポイントの見積もりを行い、バックログが着手可能な状態にもっていくイベント。
プロセス
- 詳細な質問がたくさんあると盛り上がってしまう傾向があるので、POはある程度詳細に要件を詰めておいたほうがよさそう
- 全チームが参加
- 開催日は、DEVチーム人数が少ない場合は次スプリント開始の前日とか。DEVチーム人数が多い場合は、毎日30分とか実施するチームもある。キックオフし立てのチームだと、着手可能なバックログがないため、臨時で実施したりする。緊急で実施しないといけない割り込みバックログがある場合も同様
- 時間は大体1~2時間程度。リファインメント実施が必要なバックログ数によって調整するチームが多い。質問で盛り上がる場合があるので、ワーキングアグリーメントで１バックログに対してかける時間を決めたりすると良い
- POから、バックログの内容をDEVへ説明する
- DEVは開発観点でバックログを確認し、バックログの内容に対してPOへ質問をし、不明点を解消する。（質問内容、回答等をバックログに記載しておく）
- （初めてのリファインメントの場合のみ）、基準となるバックログのスクラムポイントを仮置きして、それを基準にポイントを出すようにチーム全員に周知する
例）「生産物一覧が閲覧できる」のバックログは、2ポイントとしましょう。 - DEVチーム全員がバックログに対して内容がクリアになった段階で、このバックログに対して「基本設計」~「開発」~ 「テスト」~ 「開発完了」までの予定のスクラムポイントをDEVチーム全員で出す。
- フィボナッチ数列のみの指定で、ポーカー等を使うと良い → DEVチーム全員がバックログの内容のみでポイントの大きさを判断できる環境をつくる。
- ポイント=工数は❌ → ポイントはバックログに対する作業の「重み」で出す（工数は開発者の技量に左右されてしまうため、全員で認識を合わせることがかなり難しい。スクラムとして良くない）
- DEVチーム全員で出したポイント数が４つ以上の数字にまたがっている場合は、一番大きいポイントを出した人、一番低いポイントを出した人の意見を聞き、再度ポイントを出す。（チームのポイントの認識を少しずつ合わせていく）
- DEVチーム全員で出したポイント数が３つ以内で隣り合っている場合は、平均値を出して、それをバックログのスクラムポイントとする。
- スクラムポイントが出たバックログは「開発着手可能」となる
4. バックログアイテムを作成する
バックログアイテムとは
バックログを実現するために必要な構成要素（基本設計部分にあたるかも）
プロセス
-
DEVチームの代表者１名が実施すると良い。（これが決定という訳ではなく、その後のプランニングでDEVチーム全体の合意をとる。属人化はしない。）
-
リファインメントで開発着手可能となったバックログに対して、DEVチームにて、必要な作業を洗い出す
例）DB設計、バックエンド開発、フロントエンド開発、バックエンドフロントエンド繋ぎ込み、テスト...etc -
１をバックログアイテムとして作成し、各バックログアイテムに対して受け入れ要件を定義しておく
3. スプリントプランニング
プランニングとは
スプリント期間で実施したいことを明確するためのプランニングを実施するイベント。
プロセス
- 多くのチームは、次のスプリントの開始日前日に実施
- 全チームが参加
- 実施時間は、DEVチームが2人、１週間スプリントだと30分程度で収まる（4人、2週間だと2時間くらい？）
- POから次週のスプリント期間で達成したいスプリントゴールを説明（プロダクトバックログ作成:プロセス7）
- 達成したいスプリントゴールを元に、次週のスプリントバックログをPOとDEVで相談して決定
- 次週のスプリントバックログを実現するバックログアイテムをDEV側で説明
- DEVチーム全体で、バックログアイテムに対してQ&Aを実施し、不明点を解消する（詳細設計を実施するチームもある）
- 前回のスクラムポイント結果を踏まえ、次週のスクラムポイント計画を算出
- ３回スプリント前までの消化スクラムポイント結果の平均を算出（昨日の天気）
（例） 次週がスプリント4だとする スプリント1：8point スプリント2：8.5point スプリント3：7point （8point + 8.5point + 7point)/3 = 7.8point- DEVチーム全体の全予定工数に対して、休暇・早退・別プロジェクト作業等予定がある時間を引き、次週の予定工数とする
（例） 3人メンバーがいる。１スプリント5日。1日8時間の作業時間。 全員スクラムイベント1日とられるので、1スプリント4日とする。 4 * 3 = 12（通常の予定工数） 次週は、 1人が1日お休み 1人2時間スクラムから抜ける時間がある （4)+（4-1)+（4-2/8)=10.75（次週予定工数）- ３回前までのスクラムポイント結果と、次週予定工数を元に、計画ポイント数を算出
（例） 次週のキャパシティ：10.75/12 * 100 = 89.6% 次週の計画スクラムポイント：7.8 * 89.6/100 = 6.988 ≒ 7（繰り上がり） - 計画スクラムポイントを元に、バックログアイテムの見積もりポイントを照らし合わせ、次週実施するバックログアイテムを決定する
4. デイリースクラム
デイリースクラムとは
スプリントゴールを達成するために必要な共有、相談の時間。
プロセス
- 毎日実施
- DEVチームが参加（POも任意で参加）
- 15分程度
- 遂行しているバックログアイテムの作業に対して障害あった場合の共有
- 次のデイリースクラムまでの実施バックログアイテムの再計画
5. スプリントレビュー
スプリントレビューとは
スプリントで出たインクリメントのフィードバックを得て、
次にやるべきことの精査を実施する。
プロセス
- スプリント最終日に実施
- 参加者はPO,DEV,SM,SH全て
- スプリントゴールの説明（PO）
- インクリメントのデモストレーション（DEV）
- フィードバック（SH）
- フィードバックのプロダクトバックログ反映の検討（全員）
- 次週以降のスプリントゴールの確認
6. レトロスペクティブ
レトロスペクティブ
プロセスの振り返りを実施し、次週以降のスプリントプロセスを改善していく。
スクラムチームの加速の実現へ。
プロセス
- スプリント最終日、スプリントレビュー後に実施
- 参加者はPO,DEV,SM
※各チーム、ワーキングアグリメントと責務が違うため、別々に実施したほうが良い。（過去、経験談。一緒にやると、POが悪い・DEVが悪いという構図が出来て、各チームの改善が進まなくなる） - 各チームで１時間ほどKPTを出す。（あくまでも、スプリントゴールを達成するまでのプロセスに対してのKPT）
- 必要であれば、各チームのKPT結果を元に、全チームで再度KPTを実施するのもよさそう。（横断プロセスの課題もありそう）
例）
-- 画像貼る ---
7. リリースプランニング
リリースプランニングとは
揃ったインクリメントをどのタイミングでリリースをするか計画をする
ユーザーストーリーから起こしたEPICを元に、確認を実施する。
プロセス
- （初回ファインメント後）EPIC内のバックログの予定スクラムポイント数を合計
- 予定スクラムポイント数をy軸に、ここまでにこのEPICを終わらせたいの日付をx軸に当てて、傾線を表す
- 毎週の消化スクラムポイント数の結果を、グラフで表す
- ３の先は、過去３スプリントのEPICに関わる作業の合計から平均を出して、傾きを描いた予想予定完了日を示す
- このバーダウンチャートを利用して、リリース日を特定・調整する
-- 図 ---
まとめ
まとめてて、長くて心が折れそうになりました。
でも仕組みを思い出すことができたので、自分的に満足です。
今後もこのメモを更新していこうと思います...!
自己満メモでしたが、読んでくださった方ありがとうございます。
さ、スクラムちゃんとやろう...