Morichan

2022-10-28に投稿

スクラムマスターについて、研修で得た知見

スクラム知見

TL; DR

スクラムは１日にしてならず。

内容

スクラムマスター研修を受けたので、その際に得た知見を書いておきます。
スクラムマスター研修とありますが、実際にはスクラムに対する知識も増えたので、スクラム全体に対する内容もあります。

スクラムについて

スクラムガイド

シンプルさ

スクラムは、スクラム単体では不完全なように意図的に作られている。
スクラムは、拡張できる。

リスクについて

アジャイルではリスクを下げ続ける、ウォーターフォールではリスクが上がり続ける。

スクラムマスターが実施すべきこと

専任の／安定したチームの構築
明確な「完成の定義」の策定
スクラムが明らかにしていることを、無視せず対処

スクラムの要素

スクラムには、次の要素がある。

3つの役割
3つのアーティファクト（成果物）
5つのイベント

3つの役割

プロダクトオーナー
開発者
スクラムマスター
- スクラムマスターは場を用意する責任はあるが、問題を解決する責任は無い
- スクラムマスターはスポーツコーチのようなもの
- スクラムマスターは、最初に、自分の助けが必要か尋ねる（自分から首を突っ込むことはしない）

3つのアーティファクト

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

5つのイベント

スプリント
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ

リファインメントは、頻度が高いため、イベントに含まれない（後述）。

3つの役割に大切なこと

プロダクトオーナー：決断力（と権限）

プロダクトオーナーは、高速に変化する外部／内部の状況に対して、迅速な決断をする必要がある。
また、外部への承認を通せるだけの権限が必要である。

開発者：汎用性

開発者はエキスパート（1つのことしかしない人）になってはならない。
どのようなタスクに対しても実行できるだけの知識を得る必要がある。

スクラムマスター：影響力

スクラムマスターは、他者を巻込むための影響力が大切である。
影響力には、権威は必要無いが、知識／資格／コネといったソフトスキルが重要となる。

リファインメントの頻度

プロダクトバックログのリファインメントは、プロダクトオーナーが予定をたててでも、最低限でも毎日は実施すべき。
理想としては、1日に何回でも実施すべき。

また、スプリントバックログは、すべての開発者がリアルタイムに作業状況を反映させるべき。

これが、デイリースクラムで進捗報告しなくても問題ない理由となる（バックログを見ればわかることをわざわざいう必要はない）。

外部からの仕事の対処

スクラムマスターや開発者に対して、外部からの仕事が依頼された場合は、プロダクトオーナーに判断を仰ぐ。
それにより進捗が遅くなるのはプロダクトオーナーの責任となる。
それをプロダクトオーナーが許容するのであれば、外部の仕事をスクラムチームメンバが担って構わない。

ユーザーストーリーに必要なもの

以下の要素を含める。

誰が、......をしたい、なぜなら......
価値（受入基準）
作者（チケット作成者）
見積り

プロダクトオーナーにプロダクトバックログの価値を理解させるためのツールの1つであることに気をつける。
プロダクトバックログアイテムの1つにリファクタリングとあっても、それだけではプロダクトオーナーは価値を見出せずに無視してしまうかもしれない。
ここに、顧客の価値を書く事で、プロダクトオーナーの注意を引きつけることができるはず。

スプリント計画のトピック

以下の要素を含める。

スプリントの価値
できるようになること
できるようにする方法

スプリント計画で開発者を割当てるのはスプリントバックログアイテムではなくタスクであることに注意する。
1つのスプリントバックログを、開発者全員でタスクに取掛かることが望ましい。

各イベントの理想的な時間配分

スプリント：1day ~ 4weeks
スプリント計画：8h/month
デイリースクラム：15min/day
スプリントレビュー：4h/month
スプリントレトロスペクティブ：3h/month

スクラム運用のテクニックについて

スクラムの要素 + α

以下は例として挙げる。

5つの役割 = 3 + 2
6つのアーティファクト = 3 + 3
7つのイベント = 5 + 2

5つの役割

プロダクトオーナー
開発者
スクラムマスター
ステークホルダー
スクラムメンター
- スクラムマスターを補助するための、スクラムチーム外の人
- スクラムマスターのコーチ役

6つのアーティファクト

プロダクトバックログ
スプリントバックログ
インクリメント
プロダクトゴール
プロダクトロードマップ
リリース計画

7つのイベント

スプリント
スプリントプランニング
デイリースクラム
スプリントレビュー
スプリントレトロスペクティブ
プロダクト計画
リリース計画

Geoffrey Moore氏のプロダクトビジョン・テンプレート

プロダクトゴールを見据えるためのテンプレートの例を、以下に示す。

<顧客ニーズの内容>がある<ターゲット顧客>のための<プロダクト名>は、<ユニークな顧客のメリットやセールスポイント>がある<プロダクトカテゴリ名>です。
<競合や代替手段名>と異なり、我々のプロダクトは<主な差別化ポイント>に強みがあります。

日本のSaaSにはまだ足りない…急成長を支える「プロダクトビジョン」を作るための8つのポイント - ALL STAR SAAS BLOG

同意形成のテクニック

難しそうなテクニックはなるべく避ける、簡単な合意にツールは必要ない。

抵抗ポイント

項目を複数並べ、各項目に対し、0=喜ばしい〜9=本当に嫌、の10段階で各人にポイントを振り分けてもらう
合計し、最も数値が低いものを選ぶ

5本指投票

5=素敵！〜1=反対で進めてはいけない、までを片手で出してもらう
項目を順に出していって、全員が3以上ならその数字で確定する

見積り手法

相対見積り

見積りポーカー
1. 最初にアンカー（指標）となるプロダクトバックログアイテムを開発者全員で選択し、5と仮定する
2. それと比較し、開発者に数字を提示してもらう（プロダクトオーナーとスクラムマスターは出さない）
3. 差がない場合は、その数値で確定し、次のプロダクトバックログアイテムを選択する
4. 差がある場合
  1. 最小数値を出した人と最大数値を出した人に意見を伺う
  2. 3回やってもまとまらない場合は、手順2. に進む
  3. 手順1.2. に戻る
5本指投票：Fist of Five
1. 全員が出した数字を大きい（小さい）順に出していく
2. 全員が3以上ならその数字で確定する
3. そうで無いなら、手順2.1に戻る

類似性に基づく見積り

大量のチケットを捌く時に役立つ。

MS, S, M, L, XLに相当するチケットを、それぞれに代表して1つずつ開発者が選ぶ
全チケットを、MS, S, M, L, XLに開発者が当てはめる（ここは手分けしてで良い）
全チケットを開発者が参照し、気になったチケットについて議論してもらう
プロダクトオーナーにチケットサイズをレビューしてもらう

スクラムでよく使用されるが、スクラムでは規定されていないもの

3つの役割／3つのアーティファクト／5つのイベント以外の全ては、スクラムでは規定されていないと考えて良い。
例えば、次の項目はスクラムでは無い。

プロダクトロードマップ
リリース計画
ユーザーストーリー
プランニングポーカー
デイリースクラムにおけるスタンドアップミーティング
- 補足：朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)

大規模なスクラムチームの運用

スクラムオブスクラムズ

スクラムチームの開発者に1人、開発者のスクラムオブスクラムズを用意する。同様に、スクラムマスターをスクラムオブスクラムズとする
全スクラムチームのデイリースクラムを、同じ時間に（もちろん各スクラムチーム毎に）対応する
デイリースクラム完了後、スクラムチームの代表者として、開発者のスクラムオブスクラムズとスクラムマスターのスクラムオブスクラムズを、それぞれの会議体として用意し、スクラムチーム間の内容を調整する
終わったら、各スクラムチームに戻って伝える（ここは会議体にする必要はない）