「組織パターン」の著者、James Coplien氏のスクラムマスター研修を受けた。
認定スクラムマスタ—研修 by James Coplien
今までスクラム関係の本で読んだことや、現場で感じていたこと、推測していたことの裏付けが取れてよかった。
ほとんどの開発現場に当てはまるのはPOの役割理解、コミットが一番不足していて、支援する仕組みが必要だと感じた。
いずれProductOwnerの研修も受けたい。
印象に残ったことや質問の回答メモ
１、PO
・開発リソースのコントロールをPOが担い、ROIを最大化するのがスクラム
・フィジビリティはPOの役割
PBIの段階で実現可能性が明確であること
・採用技術の選択もPO側ですべき
※これらのタスクをDev以外のリソースで対応できるようにするか、スプリント外で対応する必要がある。
Dev以外の、POが意思決定する為のリソースも確保べきだと思うけど、こういった作業を通じてDevのプロダクトへの理解も進むはずなので悩ましいところ
参考
Product ManagerとProduct Ownerの役割の違いについて
誰がプロダクトオーナーをやるとよいのか？
２、スプリントプランニング
・Devが間違えた理解で進めているのを発見したら
Devが自発的に解決しようとしない限り失敗させる
反省なしに改善しない
失敗の要素が重要
※毎回指摘が無いと解決できないなら、POやSMがボトルネックになってしまう
PBIの仕様を伝えるのはPOの役割だけど、Dev側からギャップを埋めに行く動きも必要。
PO、Devが互いに越境するべき。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
３、場所
・PO、SM、Devが同じ場所にいることが重要
※PO、SM、Devはある意味、家族以上に密にコミュニケーションする必要がある。同じ場所にいるのが一番いい。
４、スプリントプランニング
・PBI間の依存関係の把握は重要
ただしPBIは単体でリリースできるようにすべき
・PBIはタスクではない、POが指示する為のツールではない
POとDevが会話をする為のツール
市場を向いて、ユーザーの価値に繋がるものである必要がある
・順位づけは、Must、Might、Want、ではなく、１、２、３にする
・時間で見積もらない、作業量で見積もる
・スプリントプランニングは直近３スプリント分の計画を立てる
３スプリント分見積もるのは、生産性を３倍にしたいから
前倒しで終えたらすぐに次の作業に入れるようにする
・大きな項目（EPIC）は細分化する
最も難しい点
５、科学的な根拠を持つ
・ユニットテストの効果は低い、という研究に基づいた論文がある
自動化する意味があるテストは回帰テストのみ。
・根拠無く議論をしても意味が無い
論文や統計情報をあたる
６、不確実性が無いところに俊敏性は生まれない
・予測はできるが、結果は約束できない
※同じシステム内でもSoRとSoEに分離して、品質や期限を守る部分と、試行すべき部分で、別のアプローチをとるとかが必要かも。
７、スプリントプランニング
・スプリントプランニング１
スプリントゴールを決める
スプリントバックログは作業計画
POもSMも作ってはいけない。開発チームが作る必要がある。
チームがPBIからPullする必要がある（POがPushするのではない）
・スプリントプランニング２
スプリントゴールをどう作るか考える
８、スプリントの回し方
・全員で一つのPBIに対応する
個別のメンバーが別のPBIを対応するとチームにならない
リソースの集中投下で確実に終わらせていく
・Devのメンバーはクロスファンクショナルで対応すべき
必要なことは学習する
９、ベロシティは計測できるが、計算できない
・メンバーが不在であることで、どれくらい下がるかはあらかじめ算出できない