Zenn
🏉

SCRUM BOOT CAMP THE BOOKのまとめ

2022/12/10に公開
#
アジャイル
#
スクラム
#
agile
#
scrum
idea

概要

SCRUM BOOT CAMP THE BOOKで紹介されている内容を各スクラムイベントごとにまとめました。
本ではストーリー仕立てで紹介がされており、非常にわかりやすいのですが、いざスクラム導入するために、各スクラムイベントの目的、進め方を定義しようとしたときには、イベントごとにまとめてあった方がわかりやすいと感じたのが背景です。

対象の方

  • スクラムを導入しようとしている方　※スクラム用語などはなんとなくわかっている
  • スクラムを導入しているが、スクラムイベントが形骸化してしまっていると感じる方

構成

  • 基礎編　Scrumってなに？

    • アジャイル、スクラムの基本的な考え方を説明

  • 実践編　どうやればうまくいくの？　こっちが本題

    • スクラムはあくまでフレームワークなので、具体的な実施方法までは定義していない
    • そこで、具体的にどうすればワークしやすいかを説明

基礎編　Scrumってなに？

アジャイル開発とは

「事前に全てを正確に予想し、計画することはできない」という前提をもつ

  • 関係者は目的のためにお互いに協力しながら進める
  • 利用者の反応や関係者のフォードバックを継続的に得ながら、計画を調整する
  • 一度にまとめてではなく、少しづつ作る。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する

スクラムとは

アジャイル開発手法の1つ

↓引用元。詳しくはこちらを読んでいただければです
https://www.ryuzee.com/contents/blog/7137

実践編　どうやればうまくいくの？

事前準備

  • プロジェクトのゴールを定義

    • プロジェクトで達成すべきこと、実現したいことを考える
    • インセプションデッキを用いるのも検討方法の1つ

  • プロダクトバックログアイテム(以下PBI)を洗い出し、優先度づけ、見積もりを行う

    • 実現したいこと（PBI）を具体的に洗い出す
      • 粒度は例えばユーザーストーリーごとなど
    • PBIに優先度をつける
    • PBIごとに見積もり（ポイント）をつける
      • 見積もりは相対見積もりで素早く行う。不確定要素がある時に詳細に見積もっても正確でないし、再度見積もりをすることになるため
      • PBIのなかで作業量が中間くらい、かつ、作業量を明確にイメージできているものを選び、基準して選ぶ。そのPBIの見積もりとして、フィボナッチ数のどれかを当てはめる。例えば３ポイント
      • その他のPBIは基準となるPBIと比較して相対的にどれくらい工数がかかりそうか、フィボナッチ数のどれかを当てはめる
      • 当てはめる際に見積もりポーカーが使える
      • ただし、この見積もりは確定したものではなく、スプリントが進むごとに適宜見直していく

スプリント計画ミーティング

  • 目的

    • スプリント内で確実に完了できる計画を作ること
      • そのため、着手するPBIと、その完了条件を具体的にし、チーム内で認識を合わせておく
      • スプリントの見積もりは正確にし、確実に達成できるとチームメンバーが思えるレベルにしておく

  • 進め方

    • 一部
      • POがプロダクトバックログから今回のスプリントでどこまで実現して欲しいのか伝える。"どこまで"の基準はベロシティを参考にする
      • POは開発チームに対象のPBIの内容を説明する
      • 完了の定義も決めておく
        • 完了の定義は見た目、裏側（コード品質）の両面で明確に定義されているべき
          • デモ手順通りに動作する（見た目）
          • XXXXについてのテストコードがある（裏側）
          • 最新の仕様がwikiにまとめられている
          • etc.
    • 二部
      • 開発チームがPBIを詳細なタスクに分解し、何時間かかるかを見積もる
      • タスクの単位は1日以下にし、具体的にしておく
      • スプリントの期間で本当に実現できるか、結果をPOに報告する

スプリントレビュー

  • 目的

    • スプリント計画ミーティングで計画したタスクが完了したかを確認する
      • ソフトウェアの場合は必ずソフトウェア触るデモ会で確認するべき。完了したという報告を鵜呑みにしてはいけない。
    • 動くソフトウェアを触ることで、プロダクト方向性があっているかを確かめる
      • 修正が必要であれば、PBIの入れ替え、追加、削除などを行う

  • 進め方

    • 各タスクごとにデモを行い、完了の定義を満たしているか確認
      • 完了定義を満たしているとPOが認めれば、そのタスクは完了にできる
      • 当初の完了の定義が満たせていればそのタスクは完了とし、修正は別タスクで行う
    • デモで動くソフトウェアを触り、PBIに修正が必要であれば修正する（リファインメント）

デイリースクラム

  • 目的

    • スプリントのゴールを守れそうか「毎日検査」する

  • 進め方

    • 各メンバーが以下を報告 ※以下は一例であり、チームに合わせて変えて良い
      • 前回のデイリースクラムからやったこと
      • 次回のデイリースクラムまでにやること
      • 問題点
    • 問題があれば別途場を設け、大きな問題になる前に早めに対処する
    • 進捗報告の場ではない
    • 時間は15分に収める

その他補足事項

  • ベロシティ

    • スプリントで完了したPBIのポイントの合計がそのスプリントのベロシティ
      • PBIの合計ポイント / ベロシティ = 全PBIを完了できるスプリント数
      • ベロシティ x 期間内に実施できるスプリント数 = 実現できるポイント
    • ベロシティは「安定」していることが重要
      • 安定していないと予測に使えない
      • ベロシティを上げたいという圧力があると、無意識に見かけ上のベロシティを上げてしまおうとするので注意する

  • タイムボックス（スプリント期間、デイリーの時間など）は変更しない

    • イレギュラーを許すと以降の予測に使用できないため
      • 例えばスプリント期間がバラバラだとベロシティもバラバラになり、予測に使用できない
    • 守れない場合は改善のタイミングだと気づかせるため
      • 扱うスコープが大きすぎる、準備が足りない　など

  • スクラム開発を円滑に進めるのを妨げる事柄を「妨害」と呼ぶ

    • 仕様が頻繁に変わる、技術負債が溜まっていて新規開発がしづらい　など
    • プロダクトバックログリストのように妨害アイテムを集めた妨害リストを作り、スクラムマスターが管理する
    • 妨害を解消するのはスクラムマスターの仕事

  • リリース特有の作業をするリリーススプリント

    • リリースに必要な作業＝リリースを満たす条件 − 完了の定義
    • 可能な限りリリーススプリントの作業は軽くできるよう、毎スプリントの完了の定義をリリースを満たす条件に近づける

Discussion