認定スクラムマスター研修とは
複数ありますが、今回受講したのはOdd-e主催のCSMです。
講師は江端さんで250人?の中で唯一の日本人トレーナーです。
250人は常に入れ替わるらしい。
やったこと
午前は座学、午後はディスカッションでした
座学
具体的なことは後述しますが、スクラムやスクラムマスターについてポイントで教えてもらいました。
予習がある前提だったので、ただ受講をすればスクラムを知れると言うものではありません。
予習の教材
Scrum Primer
Agile Manifesto
Agile Principles
座学の内容
スクラム
Projectの現状を把握するためのフレームワーク
スクラムをやっている人が現状を把握できている
- スクラムはFBA、FBI、非営利団体（赤十字）でも使用されている
- スクラムは学術的に考える
- 組織学や心理学の理解が必要
- スクラムは必要ない場合がある
- スクラムは目的を達成できる場合に使用するのであれば正しい
- 達成できない場合に、スクラムが正しいか正しくないかを論点にするのは、考え方が間違っていて、スクラムは一つの選択肢として使用するものである
- 目的に対して達成すべき事柄が、スクラムで実現できる効果的な手法であれば使用する
- 成果を上げるためにスクラムを使用するものではない、現状を把握するために使用する
- スクラムはバッファを容認しない
- 特定できない何かをスプリント持ち込まない
プロジェクトとプロダクト
- Goalは明確でも不明確でも良い
- Goalを完遂するための活動全体がプロジェクト
- 活動を通して、対象に提供したいもの（有形・無形問わず）はプロダクト
(例えばFB、ドキュメントも含む)- 1つのプロジェクトに複数のプロダクトが発生する
- スクラムには定量化できないものがあっても良い
- 論理的に適切であるかどうかで判断する
ウォーターフォール
統制を取るためのフレームワーク
- 日本社会はウォーターフォール（中央集権型）
中央集権型組織とチーム中心型組織
中央集権型組織の社会の中でチーム中心型組織のスクラムが発生しており、モデルが違うため軋轢がうまれる
インサイドステークホルダー（協力者）が軋轢を緩衝する
- SM、POなど
権力者はアウトサイドステークホルダーに属している
状況把握理解度
- Team
- SM、PO
- アウトサイドステークホルダー
モデルの構造上、理解度が上記のようになる
- SMやPOが状況を理解しようとTeamに問いかけると、統制（中央集権型）になる恐れがある
- SMは中央集権型組織とスクラムを行き来する必要がある
- チームに状況を聞くとウォーターフォールになる
- チームが気づいてないことをSMが発言しても良いが、決定権はTeamにある
- Teamが誤ったことを使用しようとしているときはSMが止める
Teamの人数と構成
Teamは7+-2人で構成する
Team+SMが複数あっても良い
SMについて
SMは他の役割を兼任しない
SMは権利と責任について戦っていかなければいけない
SMのスキル
- ティーチング
- ファシリテーリング
- メンタリング
- コーチング
- シチュエーショニング（上記の4つを選択するスキル）
役割
Product Owner（PO）
スクラムチームのROIの最大化に責任を負う
ROIにはメンバーの育成など付加価値も含む
Team
Teamの生産性の最大化
バグやリコールが起こる、発生していない不完全な状態は生産性が低いと言える
生産性とは生産量とは異なる
KPIやKGIのように分子を負うのがスクラムではなく分数を負うのがスクラム
つまり、分母を下げ、分子を上げることを目指す
ROIを追うPOと生産性を追うTeamでは、分母・分子が異なるので、衝突が発生する
管理
プロジェクトマネージメントで行なっていた管理は、スクラムでどう扱うか？
比重は違えど、POとTeamに分断される
Teamから発信していくのが理想で、POから発信されるのはおかしい
プロダクトバックログはTeamから発生するもの
ベロシティ
リリースできるかの算出方法
リリースポイント <= ベロシティ（期待値 or 実績値） * 残スプリント数
- ベロシティとスプリント数からリリースポイントを算出できる
- ベロシティは伸びるものではない
- ベロシティが読めるので、チームを固定したくなる
- 期待と実績を図るツールがベロシティ
- ベロシティを上げ、高い状態を保つ
- ベロシティも生産性
- ベロシティを上げ続けろというは、理解できていないということ
- termがあるので、安定させるのは難しい
- 1スプリントでベロシティ（期待と実績）が乖離していないか図る
- うまくいけば、スプリントの回数を上げ、乖離していないか図る
見積り
- 絶対見積り
- 相対見積り
違いは測定する幅を変更できるかどうか
絶対見積りだとcmやmlのように変わらない
相対見積り
- メリット：丸めて推測しやすい
- デメリット：論理的に破綻する
人は絶対見積りを苦手としている
スクラムでは、得意な相対見積りを使用する（例えば、このテーブル何個分）
見積りは絶対値を知りたいわけではない
間に合うか間に合わないか、現状把握するために知りたい
重要なのはアクションなので、見積りが早い相対見積りを使用する
絶対見積りだと、少しの誤差が発生して時間がかかる
相対見積りは、アバウトの見積りをするので、破綻する危うさはある
スプリントバックログとプロダクトバックログ
スプリントバックログ...短期
プロダクトバックログ...長期
- 見積りでは複雑度合いを測定するもので、時間を見積もるものではない
- 13ptや21ptになると、ボラティリティ（乖離）が発生する
- つまり、予測している工数より大きくなったり小さくなったりするということ
- ボラティリティを下げたいので、複雑度合いを下げる
- 複雑度合いを下げると、Teamメンバー間の認識の齟齬が減る
- スプリントバックログは決まったベロシティに、プロダクトバックログで明確になっているタスクを積んでいく
- ベロシティを20ptとするなら、19ptとか18ptを設定する
- 追加タスクはカレントスプリントバックログに入れる
左下に近づけると複雑度合いが下がる
Doneについて
Done...プロダクトを対象に提供できる状態のものを指す
全てをDoneすることは世界中のスクラムチームでできていない
- undoneは指数的に増えていくので、溜め込まないこと
- undoneは技術的負債など
- undoneを溜め込むと提供が遅くなり、機会損失を行う。costとも言える
- 自分たちで制限を入れることはundone。バージョンの制限など