[memo]CSMを受講するのでScrum Primerをざっと読んでみる
3月末にCSMを受けるから事前課題のScrumPrimerを読む
スクラムチーム内の役割
アーティファクトとは何？
「技能によって作り出したもの」という表現があるが、プロダクトのアウトプットに限った用語ではなく、新たに検知した課題やワーキングアグリーメントなどの更新など「活動による成果のすべて」という印象を受けた。
スクラムマスターは○○でない
-
スクラムチーム対しては、プロジェクト管理者ではなく支援者。
管理ではなく、自己組織化できるようにファシリテートする。
ステークホルダーに対してはチームがスクラムを回せるように交渉する。 -
プロダクトオーナーとは兼任できない
個人的にプロダクトオーナーは別の分野でのプロフェッショナルであってほしい。
チームに寄り添う以上に市場で勝つことに注力して、チームの健全性を保ちたい開発チームと健全な意見のぶつけ合いがしたい。
プロダクトオーナーがスクラムマスター的な振る舞いをしたときに他のメンバーは歓迎したいが、ちゃんと仕事ができているかインスペクトしたほうがいい。
機能的な管理者もいてOK
３つの役割に加え、製品を成功させる貢献者には機能的な管理者（技術管理者等）もいます。スクラム
の役割が変化する間、とても貴重な役割です。
スクラムガイドでこの記述があったか記憶があいまい。
LeSSでいうトラベラー、チームトポロジーで言うEnabling Team, Platform Teamがこのあたりに該当しそう。
現場でプロダクト開発をするなら必ず必要な専門性はこの機能で解決できる。
スクラムのイベント
リファインメントはイベントでない
スプリント計画で設計なども例示していたが、リファインメントとどう違うのだろう？と思った。
そもそもリファインメントはそもそもイベントとして定義されていない。
スクラムの活動の中でプロダクトオーナーと開発チームがPBIの優先付けと明確化ができていれば問題ない。
プロダクトバックログの更新はプロダクトオーナーが主語になっているが、チームとコミュニケーションするための叩き台を作るのが役目なのだろう。
スプリントレビュー vs スプリントレトロスペクティブ
スプリントレビューは製品の点検と適応に焦点をあてます。レビューに続き、スプリントレトロスペク
ティブ（ふりかえり）はスプリントの工程（プロセス）の点検と適応に焦点をあてます。
スクラムチームがレビューでステークホルダーに対してアウトプットの披露、レトロでは自分たちのプロセスの評価をすると認識した。
プロダクトオーナーの参加を推奨していない感じもするが、これも健全な対立構造が一種必要なのだろうなと再認識
とはいえ
リリーススプリントってなんだ？
しかし、多くの組織は、脆弱な開発手法、ツール、基盤、一定水準が完成できない、もしくは、その他
の酌量すべき事情（コンピュータが壊れた等）があります。こうした場合は、いくつかの作業が残るの
で、完成品の統合テスト等、残った作業を行う “リリーススプリント” が必要になります。
リリーススプリント = リリースまでの残務片付けスプリントと理解。(もはやスプリントではないのでは？)
スクラムというよりプロダクトバックログを使って開発をしているとリリースから逆算して計画するので、別途計画が必要ないのはわかる。
他のチームがいたら調整とかでリリース計画が必要そうであるが、一つのチームでアウトプットのリリースが完結できない状態がそもそもの課題か。
スコープを絞った中間リリースの考え方も納得。プロダクションでハッピーパスだけでも動かしておけば不確実性が大幅に減る。
現場によって呼び方は違うかもしれないが、スプリントごとにリリースができるか？という観点でインスペクトするとUndoneが見えてきそう
1スプリントでは1つのアプリケーションに集中
時限的で管理されているプロジェクトに対して、終わりのない自己組織化されているアプリケーションと解釈。
認知不可の観点から1スプリントないで1つのアプリケーションに集中したいのは理想。
とはいえ、リソース効率の観点で人に対してアプリケーション別に担当を割り振ってしまうのが現状なんだよね。
まとめ： スクラム自体の概念も変化する
ScrumPrimerは10年以上前に書かれたもので、事例とかはちょっと古めな印象。
主にエンジニアとして既存の課題解決したい人向けの内容が強めで、現在のスクラムガイドはよりプロダクトに寄って来ているなと思う。アジャイルの価値が業界に浸透し、ビジネス側との距離が近くなってきているのだろう。10年後はスクラムは一般教養になるのか？
Discussion