【勉強会メモ】スクラム道関西 第105回オープン・ジャム
- 日時：2018/05/23(水) 19:00 〜 21:00
- 場所：株式会社リアズ
メンバーが増えたらチームを分けるか？
- 本来はまず増員からチームを守るべき
- リソースを増やせばたくさん作れるというのはWFの発想でスクラムには当てはまらない
- チームを機能単位に分割するのはリスクが高い
- Doneにするためには結合テストが必要
- 1つのユーザーストーリーをチームで分担してWFっぽく進めることになる
- クロスファンクショナルなチームを複数作る方がよい
- 星取表を作って各チームのできることを可視化
- LeSSというFWがある
LeSSについて補足
チームを分割する前に大規模アジャイルのFWの特性を理解したうえで最適な方法を選ぶのが良さそう。
LeSS以外のFW
ふりかえりの時間管理
- データ集めでは議論しない
- 意見の本質を問うのは議論
- 問題と感じるレベルの深さは人それぞれ
- 60分のKPTなら15分ぐらいで出し切る感覚
- ふりかえりでなんでも解決しようとしない
- 日々の改善も大切でふりかえりはその延長
- スクラムと同じでタイムボックスの中で結果を出す
リファインメントについて
- スプリントプランニングで質問や議論があるのはReadyではない⇒リファインメント
- 定例化、イベント化して時間を確保する方法もある
- POがしっかり理解して完成をイメージできていることが一番
- 開発Tから反論があるならPOの理解不足
- （POができる／できないというよりチームでPOが役割を満たすような状態を作ることが大事なのかと）
メモ
スクラムガイドより
リファインメントは、開発チームの作業の10%以下にすることが多い
スクラムのKPI
- チームのベロシティを目標にするべきではない
- 本来は戦略マップがあって組織階層の中で組織のKGI・KPIが割り当てられる
- 組織がゴールを満たすための数字が何かを考えてみる
- 組織はそれぞれの担当範囲の中でゴールを設定するがアジャイルはそれを飛び越えて顧客に対してコミットしようとするので矛盾する部分はある
- 扱えそうな指標
- 品質
- ストーリーポイントに対するコード量
- 手戻りの少なさ
- リードタイム
