CSPO研修受けてきました

概要

CSPO(認定スクラムプロダクトオーナー)とは

• Scrum Aliance認定の資格
• 講師は唯一の日本人のCST(認定スクラムトレーナー)である 江端一将（ebacky）さん
• 参加者は20人くらい。わりと全国から来てた。たぶん東京の人半分くらい
• 研修を通じてCSTに認められたら認定
  • CSM(認定スクラムマスター)とは違ってテストとかない。連絡来るまでドキドキ。。

CSPOは、スクラムのプロダクトオーナーとして必要とする基礎内容を理解していることを示します。らしい。

水〜金で受けましたが月曜に認定のお知らせ頂きました＾＾

研修内容ざっくり

PPTとかアジェンダとか用意しないスタイル。
一定のスキル認められた人に限って許された研修スタイルらしい

ホワイトボード使いながらこちらに質問を投げかけてくれる。
そのあと、参加者同士でディスカッションさせて解を出させることが多い。

「何聞きたいですか？みなさんで決めてください。」
から始まり、講師の方から何を引き出すのかディスカッションを始める。

常にPO(プロダクトオーナー)としての振る舞いを期待されている。
この研修のROIを高めるために自分たちで考えて答えを出しなさいってスタンス。
最初めっちゃ迷走した。。

二日目以降は講師の方からうまく引き出せるようになりPBL(プロダクトバックログ)の作り方など、具体的なスクラムの話しに進めた

以下は備忘録もかねてやったことベース

Day1

午前中はPOとは何かの話しでざっくりInputタイム

プロダクトオーナーに求められるスキル

「決断力」と「情報収集力」

ROIを高めるために効果・価値を最大化させること、コストを最小化させることが必要。
そのバランスを考える。
ざっくり言うと価値を考慮するための「情報収集力」、コスト、リスクを考慮するための「決断力」が必要

Whatを考える

POに求めらるのはwhat。howはチームメンバーにできるだけ委譲したい
whatに関してはチームメンバーの質問に対して3秒で答えられるくらいに考え抜くこと

POの一日

午後一で「何聞きたいですか？みなさんで決めてください。」と問われ意見があまりにまとまらず数時間メンバーでディスカッション
そのディスカッションの中で自分たちがいかにhowを考えてしまっていたかを突きつけられる。
この講義中ではどんな場面でもPOとして振る舞うべきであることを学ぶ。
最後の二時間くらいで「POの一日」について講義頂く。

• チームのコンディションを確認する。メンバーと話す。歩き回る。
• PBLチェック
  • チームが項目を入れたくなるコミュニケーションを取る
• SMとインプリメントリストについて話す
  • SMは組織について考える。POはチームとの関係性を築く

Day2

ROIを最大化するための思考のプロセスについて考え続ける。

##各セレモニーでのPOの役割

• Whatのセレモニー
  • スプリントプランニング
    • スプリントのROIを最大化するための計画
  • プロダクトバックログリファインメント
    • 過去に対する評価、未来に対する見通し
    • プランニングとレビューの間は毎日やってもいいくらい
    • 次のスプリントのための準備、ゴール地点の明確化
  • スプリントレビュー
    • 今のプロダクトをもっとよくするためのアイデアをみんなで出す
    • アイデアが出にくい状態であればインプリメントリストに入れてSMと協力して対応

POは常にN+1を見る

スプリントプランニングが終わったタイミングで次のスプリントについて考える
半歩先を常に見ておく

実際にPBL(プロダクトバックログ)を作成するワーク

自分で考えてきたアプリor共通課題についてPBLを作成する
実際に課題を特定するために街に出て街頭インタビュー。外寒いし秋葉原は中国人だらけ。
ヒアリングの中にhowを入れてしまう傾向があったので改めて境界難しいなと実感。。

プロダクトバックログ作成の流れ

1. 価値定義
2. ターゲット意思決定方法の見極め
3. 課題の特定
4. 制約条件の追加
5. Definition of Done
   • 作業終了ではなくtechnical品質に関するもの
     • technical品質を満たしているものがDone
   • PBLに入れてPOが管理
   • undoneをどの程度コントロールしているかが大きな障害を起こさないポイント
6. PBLItem作成
   • AC(acceptance criteria)が重要
     • それを見える化するためにPBLItemはWebではなくてはがきがおすすめ
   • PBLItemの１つ１つをコントロールすることでプロダクトのクオリティーをコントロール
   • PBLはとにかく書く。書き続けることで精度が上がる
   • 形容詞、形容動詞はNG。チームが見てわかるように
   • 見通しをたてるために多少依存が発生してもサイズを落とした方が良い
7. INVESTでcheck
   • 依存しない(少ない)、交渉可能、価値、見積り、手頃なサイズ、検証可能
8. PBLItemの見積り
   • １つのアイテムに3パターンくらいのACを設けていて見積もり次第で調整する
9. まほうの方程式で確認
   • リリースポイント ≦ ベロシティ × 残Sprint数
   • この式で遅れてるかどうかの判断をする

Day3

PBL続き。Day2に書いてるプロダクトバックログ作成の流れの後半

whatとhowの境界線

ユーザーにとって見えるかどうかが基準
DBのバックアップとっておく・・how
落ちても5分以内に復旧できる・・what

マルチタスキングゲーム

マルチタスクが以下に非効率かのワーク
うぅ。。。

情報の伝え方・teaching

人のモチベーションは「危機感」「飢餓感」の2パターン
話してる人が今どちらのモチベーションに傾いているのかを常に見る
それによってコミュニケーションの仕方を変える、モチベーションに振れることが必要
見分けるためにその人の行動、言動をとにかく観察することが大事
これがうまくなると電車乗ったときにその人がすぐ降りるかわかるらしい

その他学び

• Scrumはプロジェクト現状を把握するためのフレームワーク。課題の解決案は提案しない
• 25%、50%、25%の黄金比。難しいこと簡単なことは25%にする。PJを通しても一日の中でも、１つの会議の中でも
• 一般的に人に情報を伝えても伝わるのは10%程度

所感ざっくり

• POとしてどう振る舞うべきかの基本スタンスを学べる
• 何を考え続けるべきかについてめちゃくちゃ考えまくる時間
• 一緒に研修を受けてる方々や、講師のebackyさんとずっとスクラムについて細かいところも含めディスカッションし続けてるような3日間
• 濃厚な時間をみっちり過ごせるので改めてスクラム、POについて現場から離れて考える期間として有意義だった