単なる役割。上下関係ではないことに注意。
- プロダクトオーナー
- 作成するプロダクトに対する最終決定権を持つ人
- プロダクトバックログを作る人。開発チームに何を実現して欲しいか伝える人
- スプリントのゴールを決める人
- スプリントレビューをする人
- スクラムマスター
- スクラムを円滑に進めるために尽力する人
- プロダクトオーナーの支援
- チームの自律的な行動を支援
- 開発チーム
- プロダクトバックログに従い成果物を作る人
- 相互支援。チーム一丸となって目的を達成する人たち
基本は下記のイベントがある
- プロダクトバックログを作る(プロダクトオーナー)
- スプリント計画ミーティング(出席者：全員)
- デイリースクラム(朝会)
- スプリントレビュー(出席者：全員)
- スプリントレトロスペクティブ(出席者：全員)
-
機能、目的、詳細、見積もり や
-
ストーリー、デモ手順、見積もり 等のもの
-
作ったら優先順位をつける
-
開発チームがプロダクトバックログを見積もる
-
基準を決めて、相対見積もりする、見積もり時に対話するのが重要
今回のスプリントで達成するプロダクトバックログの項目はどれかを決定する
- 何を実現して欲しいのか
- 気になる事の質問
- 各項目が終わったことをどう確認するのかを決める
- タスクを見積もる。時間で見積もる
- 1日で使える時間は5 -6 時間
- なんの割り込みもなく作業完了できる時間で見積もる(理想時間)
- このタスクはまとめておく。これをスプリントバックログと言う(これは開発チームの持ち物。誰からも干渉を受けてはならない)
- スプリントのゴールを設定しておく
- 終わったと判断できる材料が明確か
- タスクいっぱいになったら黄色信号。スクラムチームが確実な計画を立てられない場合がある
- タスクは具体的でなければならない。ここでもタスクの具体化のために対話が重要となる
- 開発チームが何のためにそこにいるのか、自分たちはどう言うことを大事にして仕事を進めていくのかの確認
- 報告すること
- 前回のデイリースクラムからやっていたこと
- 次回のデイリースクラムまでにやること
- 問題点
- 15分制限
- 進捗報告ではなく、問題を見つける場
- 問題があれば、別途関係者を集めて別でやる
- こうすれば必要な時だけ話し合う場が作られる
そのスプリントで実現したものを確認していく
- 開発チームが実現したものをPOにデモする
- 完了定義が明確である必要あり。POがどこまで終わって欲しいかざっくり伝え、スクラムチームが基準を設ける
スプリント中に終わらないタスクがあれば、次のスプリントに回す 回すときに、そのタスクをそのまま継続するか、やめるか、完了にして別タスクに起こすかを決める
- アジャイルボードを見て、仕事が遅れてないか、誰かにタスクが集中してないか等をチェック
- スプリントバーンダウンチャート。最終日までに残タスクの見積もり時間が全て0になるようになっているか。レポートをクリックし、次にバーンダウンチャートを選択
Good, Keep, Problem, Tryの4点を話し合う。1週間スプリントの場合1時間
- プロダクトオーナーが忙しくてレビューに参加できない -> 都合のつく時間帯にリスケ。それが難しければ仕事を手伝う
- <どういったユーザーや顧客> が
- <どんな機能や性能>が欲しい
- それは<どんなことが達成したい> ためだ
- わざと短く端的に書く。そうすることで話し合いが生まれるようにする
- 無論短く書くと言うのは手抜きをすると言うことではない
- 開発チームがリモートの場合ユーザーストーリーだけでは不十分。画面イメージや受け入れ基準といったことをドキュメントにまとめる必要あり
スプリントを停止する場合もありうる
- コードが荒れに荒れてレビューがしにくくなりベロシティが落ちたなど
- ソースコードのリファクタリングをするための対策を打つためにスプリント停止
チームのどこに問題があるか深掘りする
- スプリント計画レビューの時点で無理な作業になっていないか
- 残業過多による品質悪化
- テスト不足
- 定形作業が増えている
- 割り込みが多くなっている
- モチベーションが低くなっている。悩みがある
こう言うのを解決する仕組み作りが必要。言うだけだったり、叱責だけしても無意味。
バッチが得意な人、画面が得意な人、調整が得意な人、色々いる。リーダー以外にその都度得意な人がリーダーシップをとるべき