認定スクラムマスター研修で学んだこと
2016年くらいの話になりますが、認定スクラムマスタ(CSM)研修を受けてきたので、そこで学んだことを備忘録程度にまとめます。
※Scrumのルール自体は２年程度で改定されるそうなので、CSMも2年で失効します(自分のも既に失効してます)。そのため、投稿した2020年1月現時点ではルールが変わっている可能性があります。
基本的にはCSM研修で講師が話した内容をできる限りそのまま記述しています。
一部、個人の見解がありますが、それには★印をつけていますので、区別して参照してください。
前提
以下の資料を読んでおくことが前提で以下の話が進みます
-
Scrum Primer(日本語版)
- 講師のebackyが翻訳したもの
-
Agile Manifesto(日本語版)
- ここでは触れないのであまり意味無いです
-
Agile Principles(日本語版)
- ここでは触れないのであまり意味無いです
スクラムガイドは読まなくても良いです
また、研修の中でスクラムに関する書籍というものはエンターテイメントなので、そのつもりで読むのは良いそうです
スクラムを正しく学ぶにはScrum Allianceが認定した研修以外無いそうです
スクラムとは何か
プロジェクトの現状を把握するためのフレームワーク
スクラムによって何ができるようになるか
- 現状を把握することで戦略的に中長期の計画が立てられる
- 短期の確実な計画を立てることで、着実な進捗が見込める
スクラムができないこと
- 成果を出す
- スクラムが成果を出すのではなく、ヒトが頑張って成果を生み出している
- 生産性を向上する
- スクラムが生産性を向上させるのではなく、ヒトが頑張って生産性を向上させる
- ただし、Teamという役割は生産性を向上させることに責任を持っているので、生産性が向上するような仕組みがある
- 自律した組織をつくる
- スクラムが自律した組織をつくるのではなく、自律した組織が前提
- 自律した組織にするためのものではない
スクラムが適応できないもの
- 単純なプロジェクト
- 3ヶ月以下でリリースするプロジェクト
スクラムの構成
スクラムを構成する19のキーワードをルールとして覚えておく必要がある
3 keys
スクラムは経験的プロセス制御の理論を基本にしている
経験的プロセス制御の実現はこの3つが柱として支えている
スクラムの16のルールはすべてこの3つが根底にある
- Transparency
- 透明性
- Inspect
- 検証
- Adapt
- 適応
3 Roles
3つの役割を担うメンバーで構成された組織をScrum Teamと呼ぶ
Scrum Teamは7±2のメンバーで構成される
- Team
- Product Owner
- Scrum Master
5 Ceremonies
スクラムのイベント、MTG
- Sprint Planning
- Daily Scrum
- Product Backlog Refinement
- Sprint Review
- Sprint Retrospective
6 Artifacts
スクラムの成果物
- Potentially Shippable Increment
- Product Backlog
- Acceptance Criteria
- Sprint Backlog
- Impediment List
- Definition of Done
2 time
スクラムのタイムボックスと例外
- Sprint
- Sprint Stop
スクラムのルール
16のルール
Product Owner
羊飼い★
※Product Ownerのメタファーは現状ありません。これは個人の見解です。
目的
- TeamのROI(投資対効果)を最大化すること
- 成果の最大化とコストの最小化
役割
- Teamに対して開発ができる状態になるまで説明する責任がある
- Teamに合わせて最適なアプローチで説明する責任がある
- Product Backlog Refinement, Sprint Planning, Sprint Reviewに参加する
- Product Backlog, Acceptance Criteria, Product(製品品質)を管理する
コストの最小化について
- Minimum Requirement(最小要求)
- 3秒で決断する
- 選択肢を最低3つ持っていること
- 様々な譲許の変化に素早く対応できなければならない
- Teamの負債(undone)の整理のタイミングと優先順位を戦略的に判断する
誰がProduct Ownerになるべきか?
Teamコストの最小化を考えられるのはClient(Stakeholder), Supporterではなく、自分達の組織以外の者が担うのはあり得ない
必要なスキル
- 決断力
- 情報収集力
Team
羊
目的
世界一のチームになること★
※研修の中でTeamの目的については定義していませんでした。これは個人的な見解です。
役割
- Sprint Planningで約束したことを実現する責任がある
- 生産性を向上する責任がある
- 全てのCeremonyに参加する
- Sprint Backlog, Definition of Done, Product(技術品質)を管理する
生産性の向上について
- Velocity を安定させる
- undoneをdoneにする
※Velocityを向上させる必要はない
必要なスキル
- 約束したことを実現するスキル
- できなくとも代替案を出すスキル
- Feature Team
- なんでもできるようになる
Scrum Master
羊たちを守る犬
目的
- (スクラムをやるやらないに関わらず)チームの成果を最大限に発揮すること
役割
- スクラム導入の判断
- スクラムのルールを守る
- 常に現場を把握する責任がある
- スクラムを最大限利用する
- 全てのCeremonyに参加し、その目的を効果的に達成する
- 目的を果たしていないとScrum Master としてCeremonyに参加していないことと同じ
- 全てのArtifacts を管理する
必要なスキル
- Teaching
- Mentering
- Coaching
- Facilitating
- Situational Leadership
注意すること
1. 権利と責任が一致していない発言は控える
例えば開発の手段をTeamに言うのは良いが選択はTeamにさせなければならない
そもそも開発における権利が無いので、選択権はTeamにある
選択権を与えないとTeamの権利を剥奪して責任を押し付ける行為になる
2. 中立であること
Product Backlog Refinementに遅れて参加し、ドアに手をかけるとTeamの1人が泣いて出て行った。
Scrum Masterとして正しい行動とは？
Scrum Teamの問題なので(物理的な意味でも)中立な立場で観察する
Impediment Listに課題として管理し、後日Sprint ReviewもしくはSprint Retrospective でこの問題を問う
Memberの兼任について
それぞれ役割が明確に分かれているため、兼任できない
MemberとScrum Masterは兼任するケースはあるが、兼任できるというルールは無い
Potentially Shippable Increment
スプリント終了時に出荷可能なプロダクトを積み上げること
いつでも出荷可能である!=リリースできる
例えば機能単位であれば完成しているが、製品としては完成してない状態もある
Acceptance CriteriaとDONEが全て満たされている状態
※ただし現状このルールが守れているScrum Teamは無いといわれている
Product Backlog
- Productに必要なものProduct Backlog Itemという単位で定義し、並べた一覧
- Product Backlogは優先されるItemから上に並び、かつ上にあるItemほど明確である
- POはProduct Backlogの内容、可用性、優先順位に責任を持つ
- Product Backlog Item には最低1つ以上のAcceptance Criteriaが含まれる
- Product Backlog Itemには相対見積もりをするために最終的に作業するTeamがポイントを付け、その責任を持つ
- Product BacklogはSprint内で実施しているItem以外はいつでも変更が可能
相対見積もり
人間の特性として絶対見積もりより相対見積もりの方が精度が高い為、中長期の計画には相対見積もりを用いる
ポイントの決め方
PBIの見積もりでは時間という概念を持たない
ポイントはPlanning Pokerを用いる
まず、比較対象として2pointと8pointのPBIを決め、それと比較してポイントを見積もる
この比較対象は変更してはならない
ポイントの決定は以下の手順で行う
- POからPBIの説明を受ける(質問は可能)
- Team各人でポイントを見積もり比較する
- ポイントの高い者から順に根拠を述べる(議論はしない)
- POがACを調整する
- 1に戻り決まるまで繰り返す
INVEST
PBIはINVESTを満たしていなければならない
- Independent
- 依存しない
- Negotiable
- 交渉可能
- Valuable
- 価値がある
- Estimable
- 見積もり可能
- Small
- 最小単位(手頃なサイズ)
- Testable
- 検証可能
Acceptance Criteria
- Product Backlog Itemに最低でも1つは記述するP.OがAcceptするための条件
- Acceptance CriteriaはAcceptするための判断基準が明確に記載されている
- Acceptance Criteriaには満たさなければならないものだけでなく、満たさなくて良いことも明記する
Sprint Backlog
- Sprint内で達成するProduct Backlog Itemに対し、実現する為の方法をTaskという単位で記述し、並べたもの
- Taskは作業を細分化したもので、それぞれのTaskには時間の見積もりを記述する
絶対見積もり
- Sprintはタイムボックスである為、Sprint Backlogは時間という単位で絶対見積もりを行う
Taskの単位
認識のズレが無く、同じ時間で作業するためには誰がやっても同じ粒度であること
そうなるとTaskの最小単位は0.5h、最大で1h
これ以上の大きさになると見積もりにズレが生じやすくなる
Impediment List
- スクラムに関連する課題・優先順位・戦略を管理するもの
- スクラムに関することなら組織的な課題でも良い
- ScrumMasterの経験として組織的な課題にどう取り組んだかが重視される
- 課題の優先順位と、解決に向けた戦略の実行はScrum Masterが責任を持つ
- Impediment ListのItemはScrumTeamに関わらず、すべてのものが追加可能
- スクラムマスター以外が追加していない状態は興味の無い状態
Definition of Done
- 最初のSprintで作成するIncrementのDone(完成)の定義
- 作成されたDefinition of DoneはTeamとProduct Owner間で合意を得てなければならない
- DoneはProductをIncrementする為に必要なものを指す
- やらなくていいことは定義しなくて良い
- Definition of Doneはdoneとundoneに分けられる
- Sprintの中でTeamが当たり前のようにSprint内で満たせるものをdoneとする
- 逆に満たせないものはundoneとして定義する
- undoneは満たさなければならないものなのでSprint毎にPBIに追加しなければならない
- その為、undoneは負債である
- POは戦略的にこの負債を返済しなければ成らない
- Teamはこの負債が出ないようにundoneをdoneにしなければならない
doneとundoneの管理ルール
- undoneが5連続Sprint中に満たせれば、doneに入れる
- doneが1度でも満たせなければundoneになる
- 新たなDefinition of Doneができたらまずundoneに入れる
- どの開発でもやることはdoneにいれておく
- 開発によってやらない場合があるものはundoneにいれておく
Sprint Planning
Sprint PlanningはPart1とPart2の二部構成
それぞれ目的が異なる
Part1とPart2は繰り返されるため、わかりやすく2016年のルール改定で名称のみ統合されている
ただし、やることは変わらない
- タイムボックス
- ない
- 目安としてSprintが、1weekの場合は半日で行う
Sprint Planning Part1
- 目的
- Product OwnerがSprint完了時に何を達成したいかを明らかにする
- 参加者
- Scrum Team
- ルール
- ここで決められたことは変えない
- 成果物
- Product Backlog(PBIのlock)
Sprint Planning Part2
- 目的
- TeamとしてPBIをどのように実現するかを明確にする
- 参加者
- Scrum Team(ProductOwnerは任意)
- ルール
- 設計が完了していること
- 担当者をアサインしない
- PBIのTaskの中で優先順位をつけない
- Part1で決めたことを変える必要があればPart1に戻る
- 成果物
- Sprint Backlog
Daily Scrum
- 目的
- 日々学習したことを共有すること
- 参加者
- Scrum Master
- Team
- タイムボックス
- 1回15分
- ルール
- 1日1回以上実施する
- ディスカッションはしてはならない
- 3つの質問に必ず全員が答える
- 前回からやったこと/次までにやること/気になっていること
- Product Ownerに発言権はない
- 成果物
- Sprint Backlog(更新)
- Impediment List(追加)
Product Backlog Refinement
- 目的
- 中長期の計画をたてること
- 参加者
- Scrum Team
- タイムボックス
- Sprintの5-10%
- ルール
- Sprint中に1回以上実施する
- PBIの作成・更新/見積もり/優先度の変更を行う
- 成果物
- Product Backlog
- Impediment List
- Tips
- オススメは毎日DailyScrumの後にやる
Sprint Review
- 目的
- Productの成果の確認
- アイデアを出すためのディスカッション
- 参加者
- Scrum Team
- Stakeholders
- タイムボックス
- 1h/week
- ルール
- 必ず動くもので確認する
- lockされたPBIのAcceptance Criteriaが満たされていることを確認する
- Definition of Doneが満たされていることを確認する
- 時間がきたら終わり
- 成果物
- Product Backlog
- Definition of Done
Sprint Retrospective
- 目的
- プロセス(働き方)の確認
- Teamが生産性を向上させる為に次のSprintで改善する具体的な方法(take action)を1つ以上決めること
- 参加者
- Scrum Master
- Team
- タイムボックス
- 0.75h(0.5-1h)/week
- ルール
- テーマは2つ(Velocityの安定化/undoneをdoneにする)
- 組織的な課題はImpediment Listに入れて議論しない
- take actionの見直しをする
- 1つ以上のtake actionを決める
- take actionは最大20まで
- 成果物
- Impediment List
- take action
Sprint
- ProductをIncrementする為に必要な1-4weekの期間
- Sprintの期間は変更可能
Sprintの期間について
- 3ヶ月でスクラムマスターはチームビルディングをしなければならない為、Sprintの期間はできる限り短い方が良い
- 一昔前は2weekが一般的であったが最近では1weekの方が人気
Sprint Stop
- Sprintを停止すること
- Product Ownerがその判断をする
その他
自律したチーム
- Scrum Masterが3ヶ月で行うチームビルディングのゴール
- 3ヶ月という数字は組織論の中で、最長でもチームビルディングにかかる時間は3ヶ月であるという研究結果を元にしている
- 何故、自律したチームかというのも組織論の中で、最もパフォーマンスの高い集団が自律したチームであるという研究結果を元にしている
- 3ヶ月以上経つと効果がない
- スクラムの導入が3ヶ月未満のプロジェクトには向かないとされているのはこの為である
自律したチームの要素
- チームのゴールが明確であること
- チームの制約が明確であること
- チームのゴールを達成する為に何をすべきか個人が瞬時に判断して行動できること
Working Agreement
スクラムマスターがチームビルディングで好んで利用する手法
以下の３つをルールとして決める
- プロセスの決定ルール
- プロセスの変更ルール
- ペナルティ(ルールを破った際にどうなるか)
User Story
- Product Backlog Itemで最もpopularなフォーマット
- User Storyの形式で作成されたPBIのポイントはStory Pointとも呼ばれる
User Storyのフォーマット
<Who>として<What>が欲しい
何故なら<Why>だからだ
Velocityと中長期の見積もり方法
基本的にリリースまでのスケジュールを立てる為には、
ProductBacklogにある残りのPBIの総ポイントをVelocityで割り、
切り上げた数字のSprintが完了すればリリース可能になる
ここで利用するVelocityの求め方は以下の通り
- Sprintが5回未満の場合は直前のSprintのVelocity
- Sprintが5回以上の場合は直近5回のSprintのVelocityの平均値
- 日数が通常より少ないSprintは除く
- Velocityが極端に少ないSprintも除く