Zenn
🛠️

"SCRUM BOOT CAMP THE BOOK" 読書ノート

2021/06/29に公開
アジャイル
スクラム
書評
tech

はじめに

"SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発"の読書ノートです。

<a href="https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK【増補改訂版】-スクラムチームではじめるアジャイル開発-ebook/dp/B086GBXRN6?_mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3UMMT6X802GOY&dchild=1&keywords=scrum+boot+camp+the+book&qid=1624921720&sprefix=scrum+boot+cam%2Caps%2C247&sr=8-1&linkCode=li2&tag=i0fe2-22&linkId=ea702e9985c6d3d372dc366a2a677a05&language=ja_JP&ref=as_li_ss_il" target="_blank"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=B086GBXRN6&Format=SL160&ID=AsinImage&MarketPlace=JP&ServiceVersion=20070822&WS=1&tag=i0fe2-22&language=ja_JP" ></a><img src="https://ir-jp.amazon-adsystem.com/e/ir?t=i0fe2-22&language=ja_JP&l=li2&o=9&a=B086GBXRN6" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />

要約

スクラム概要

  1. スクラムは、1990 年代にジェフ・サザーランド氏とケン・シュエイバー氏が、1986 年のハーバード・ビジネス・レビュー誌に掲載された野中郁次郎氏と竹内弘高氏による論文「 The New New Product Development Game 」の内容をソフトウェア開発に応用して創始した。
  2. スクラムのルールは スクラムガイド （ https://www.scrumguides.org/ ）
    で定義されている。

スクラムの流れ

スクラムの流れは次の通りである。

  1. 立ち上げ
    • 機能や要求を並べ替えたプロダクトバックログを作る。
    • 最長8時間のスプリントプランニングを通じて、最長1ヶ月に区切った開発期間スプリントを計画する。スプリントプランニングはスプリントの目標であるスプリントゴールを規定する。
  2. 実行
    • スプリントの進捗はデイリースクラムとスプリントバックログで管理する。1 タスク は1日以内で終わるサイズにする。
    • デイリースクラムでは、スプリントゴール達成のために昨日やったこと、今日やること、障害となることを報告する。
    • 開発チームは、スプリントごとにインクリメントを作成する。インクリメントとは、今回のスプリントまでで完成したすべてのバックログ項目を合わせたものであり、通常は評価可能な動作するソフトウェアである。
  3. 振り返り
    • スプリントの最後にスプリントレビューを通じて、インクリメントを評価する。
    • スプリントレビューのあとに、反省会としてスプリントレトロスペクティブを行う。

ロール

スクラムのロールは次のとおりである。

  • プロダクトオーナー(PO)がプロダクトのWhatを担当する。
  • 開発チームがプロダクトのHowを担当する。
  • スクラムマスターが開発チームの教育やファシリテーションを担当する。

実践のポイント

実践のポイントを整理する。

ロール

実際の現場でロールを当てはめようとしたときに、その人の肩書きを見て適任
だとか不適任だとかを決めつけてはいけない。

決めつけは良くない。年齢や役職で判断しないこと。

スクラムではロールの兼任は禁止されていない ... プロダクトオーナーとスクラムマスターを兼任するのは絶対にダメだ

ロールの兼任はだめ。

とくに製品に責任を負うプロダクトオーナーとチームを外部から守るスクラムマスターでは利益相反があるので。

スプリントプランニング

開発を進めるうえで大事なことをより詳しく正確に知っておくのが大切だ。どうしても、一方的に説明を受けただけでは不十分なんだ。 ... みんなそれぞれに疑問や不安を抱えたままでは、みんなで協力してゴールやミッションを達成していくなんてできない。だから、スクラムチームの全員が、不安を持たなくなるぐらいまで自分たちの向かう先について知っておくことが大事なんだ。

開発チーム全員がゴールを理解しておくことが大事。

スクラムチーム全員が「これなら確実に達成できるぞ」と自信が持てるぐらい、具体的で詳細な計画を作らないといけない

具体的な計画を「チーム全員で」作らないといけない。プロダクトオーナーがトップダウンで決めつけてはいけない。

タイムボックス

まずはタイムボックスを守ること

  • スプリントの期間は 1 か月以内
  • デイリースクラムは 15 分以内
  • スプリントプランニングは 8 時間まで（スプリント期間が 1 か月の場合）
  • スプリントレビューは 4 時間まで（スプリント期間が 1 か月の場合）
  • スプリントレトロスペクティブは 3 時間まで（スプリント期間が 1 か月の
    場合）

自分たちでタイムボックスを決めたら、それを頑なに守ることが大事。タイムボックスを守らないと、今回のベロシティを次のスクラムでの見積もりに使えなくなる。

バックログ

多くのスクラムチームでは、適切にプロダクトバックログの項目を分割して、着手す
るものを調整している。
もちろん、分割するときには注意が必要だ。たとえば、分割しやすいからといっ
て画面だけ作ったりするのはダメなんだ。スプリントレビューでは実際に動いてい
るものを見て、フィードバックがもらえるようになってなければいけない。

必要に応じてタスクを分割する。

1 つのプロダクトバックログ項目に対して複数のメンバーで協力して取り組むことを、スウォーミング（Swarming）と言います

1つのタスクを複数名で担当するモブプロのようなことをしてもよい。

ベロシティ

ベロシティに求められるのは安定していること

ベロシティが安定しているということは、トラブルの対処がうまいということの裏返し。また安定していると見積もり精度が上がるメリットもある。

Discussion