CSPO研修を受けた件

先月、CSPO (Certified Scrum Product Owner)研修を受けてきたので、その時のメモを書き残します。 ※個人的に気になったキーワードについて、ただただメモしておくだけなので、取り留めはありません。

目次

CSPO研修とは?

講師の方

日本人とデンマーク人がタッグで研修を行ってくれました。

とても印象的なお二方でした。

サンダルとTシャツというラフなスタイルで、質問するとチョコレートを投げてくれたり。。笑

メモ

プロダクトバックログリファイメントミーティング

  • 次のスプリントに向けて、バックログの追加や並び替えを行う
  • DEVからもPOにFBする
  • チーム全員でバックログの見積もりを行う

価値駆動

  • インクリメンタル開発で少しずつつくる
  • 例えば、UI~DBスキーマを各層でサイロ的にしっかりとつくるのではなく、横串で必要最低限を少しずつつくる

スプリント期間の考え方

  • 日本は1週間がある
  • 日本以外はだいたい2週間
  • 1時間という考えの人もいる

プロダクトバックログ Ready

  • Top3のスプリントがReadyならReady Ready
  • 参考: ジェフ・サザーランド "Ready-Ready"

単体テスト

  • 単体テストはやめよう
  • UIテスト(エクスプロイトテスト)に時間を割くべき

完成の定義

障害リスト

  • 100個くらい書きだしてもよい

テストの網羅性

  • TDD will kill you
    • 要件を知らなくてもUTはできてしまう
  • POが出すテストケースがDEVが行うテストケース
  • テストカバレッジが正というのはウォーターフォールの概念
  • 優先すべきはプロダクトの要求と完了条件
  • 大事なのは今起きているバグを把握し、どういうプロセスでバグが再発しないようにするか!
  • 非企能もPBIとして積まれたものをこなす
    • PBIにのってこなければ、いつまでも対応されない

アジャイルへの投資

  • 銀行はリーンではないため難しい ⇒ Scrumはあきらめた
  • トヨタは経営層がリーンを理解しているため、できる
  • 製品の終了条件を明確化しておくことが大事 (Googleは45のサービスを殺した)

POチーム

  • プロダクトを説明するために何が必要かを考える

開発チーム

  • 1番大事なのは学ぶことができる人
  • 研修でチームが育ち、プロダクトの価値に繋がるとしたら、それはバックログに入れるべき

スクラムマスター

  • スクラムマスターはフルタイムで働くべき
  • DEVとの兼任はNG

SAFe is bullshit

Scrum Scaleが良くない理由

  • 個人と個人のやり取りホップ数が(大)
  • ハブとなるマネージャが入れ歯成り立つが結果、それは非スクラム化する

Value (価値)の定量評価

  • Business Value = 儲かる金額とか相対評価 (仮説)
  • ROI = Business Value / Complexity (Velocity)

タスクボード

  • スプリント内でチームで選択したPBIを任意の順序でデリバリーできる
  • スフォーミング「1つのPBIに群がって集中的に片付けること」を推奨
  • 手づまったり、1人作業になっていたら、SCMがもっと上手いやり方がないか聞く
  • ほとんどWIPで止まっている状態はよくない

レスポンシブデリバリー

  • 実利用環境のバグは前スプリントが完了していないことを意味する

デイリースクラムの目的

  • スプリントゴールの確認とリプラン
  • 残りの期間をどう使うか確認

スプリントゴール

  • DEVが自分たちで定めるのが望ましい

プロダクトバックログ

  • 必ずしもユーザーストーリーでなくてもい
  • ただ機能を書くだけでもよい

PBIの見積もり

  • 作業量はチームの言い値 ⇒ チームごとに比較できるものではない

ユーザーストーリー

  • 元々Featureと言われていた (本来は手書きのもの)
  • POが要件を明確化していくための対話ツール