Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
スクラム導入に向けて
スクラムは救世主となるのか?
@zaru
スクラムマスター
やります初心者です
みんなと一緒に
より良くしていきたい
よろしくお願いします
スクラムとは
スクラムは
銀の弾丸
ではない
スクラムは
理解は容易
習得は困難
スクラムは
チームが
共通のゴールを持つ
スクラムは
チームがプロセスと
結果に責任を持つ
スクラムは
チームで協力し
自らチームを管理する
スクラムは
リソースと期間で
総量規制をかける
スクラムはチーム
メンバーの役割
プロダクト
オーナー
プロダクトオーナー
開発チームの作業とプロダクトの価値の最大化に責任を持つ
- プロダクトバックログの管理者
- 優先順位の意思決定権限を持つ
- 製品の責任者
- 関係者と協働してバックログの作成や成果物のフィードバック
をもらう
- 開発チ...
開発チーム
開発チーム
出荷可能なものを全員でベストを尽くして作る
- チーム全員で成果物に責任を持つ
- チームの中に上下関係はない
- 個人にフォーカスしない
- 最良のやり方を自分たちで決める
- チーム全員が個人全員を助ける
- 持続可能なチームで...
スクラムマスター
スクラムマスター
スクラムの理解と成立に責任を持つ
- サーバントリーダー
- チームの成長を促す
- 障害物を排除する
- 相談にのる・一緒に考える
スプリントの流れ
スプリントの流れ
- プロダクトバックログ作成
- スプリント計画会議(第一部)
- スプリント計画会議(第二部)
- 以下繰り返し
- デイリースクラム
- 開発
- 納品チェック
- バックログリファインメント(オプション)
- スプリント...
スプリント計画会議(第一部)
- 2時間
- 参加者:PO・開発チーム・SM
- POからバックログの説明を受け、
見積もり可能な状態にする
- 優先度の高いものから開発チームが
プランニングポーカーで相対見積もりを行う
- スプリント対象のプ...
スプリント計画会議(第二部)
- 2時間
- 参加者:開発チーム・SM(POはオプション)
- バックログを細かいタスクに分割する(目安は最大1日)
- 設計や実現手法を議論する
- タスクに対して絶対見積もりをする(単位は時間)
スプリント計画会議(第二部)
- チームが必ず終わると責任をもって見積もりをする
- 1つのプロダクトバックログを1人が担当するのを避ける
- 最優先バックログを各個撃破が基本
- タスクはスプリント中に増減する
- 1日の6割程度の稼働可能時...
デイリースクラム
- 15分 毎日
- 参加者:開発チーム・SM(POはオプション)
- 話すことは3つだけ
- 昨日やったこと
- 今日やること
- 問題
- 問題があれば別途ミーティングを関係者のみで開く
- 未来のことを心配せず今日のこと...
スプリントレビュー
- 1〜2時間 スプリント終了時
- 参加者:PO・開発チーム・SM(ステークホルダー)
- プロダクトオーナーが完成したものと
完成していないものを事前に分けておく
- 進捗確認の場ではない
- プロダクトオーナーが完成品...
ふりかえり
- 1〜2時間 スプリント終了時
- 参加者:開発チーム・SM(POはオプション)
- チーム・プロセスの振り返りと改善
- 抱えている問題は何か
- 良かったことは何か
- 前回のプラクティスの効果はどうか
ツールや手法
プロダクトバックログ
プロダクトバックログ
- 要求事項の一覧
- 顧客の価値が何かが記載されていると良い
- 誰でも追記ができる
- 順番はプロダクトオーナーが決定する
- 開発チームやスクラムマスターは作成に協力する
- 各スプリント開始前に都度優先度修正
プランニングポーカー
相対見積もり
プランニングポーカー
- ポイント制で相対的に見積もる
- 最初に基準となる2ポイントのバックログを選ぶ
- それと比較して何ポイントかを見積もる
- 全員が一致したら完了
- 不一致の場合、一番少ない人と一番多い人から
見解を聞く。それを元に...
完了の定義
完了の定義
- チーム全員が合意する納品物の完了の定義
- リリースされた状態なのか
- QAテストが通った状態なのか
- テストコードが通った状態なのか
- コードレビューが通った状態なのか
- 一貫した完了の定義を守る
- フェーズによって...
ベロシティで予測
ベロシティ
- チームがスプリント中に完了した
プロダクトバックログの見積もりポイント合計
- スプリントでどれくらいの成果が出せるか
予測に使われる
- 安定した値にならないと予測しにくい
- 残業でめっちゃ頑張ったなどは異常値
- 成長と共...
バーンダウンチャート
状態の可視化
サンプル バーンダウンチャート
Don't just Do agile. Be agile.
スクラム導入に向けて:スクラムは救世主となるのか?
スクラム導入に向けて:スクラムは救世主となるのか?
Upcoming SlideShare
Loading in …5
×

スクラム導入に向けて:スクラムは救世主となるのか?

3,225 views

Published on

新米スクラムマスターがスクラムを導入するための導入スライド

Published in: Technology
  • Be the first to comment

  • Be the first to like this

スクラム導入に向けて:スクラムは救世主となるのか?

  1. 1. スクラム導入に向けて スクラムは救世主となるのか?
  2. 2. @zaru
  3. 3. スクラムマスター やります初心者です
  4. 4. みんなと一緒に より良くしていきたい
  5. 5. よろしくお願いします
  6. 6. スクラムとは
  7. 7. スクラムは 銀の弾丸 ではない
  8. 8. スクラムは 理解は容易 習得は困難
  9. 9. スクラムは チームが 共通のゴールを持つ
  10. 10. スクラムは チームがプロセスと 結果に責任を持つ
  11. 11. スクラムは チームで協力し 自らチームを管理する
  12. 12. スクラムは リソースと期間で 総量規制をかける
  13. 13. スクラムはチーム
  14. 14. メンバーの役割
  15. 15. プロダクト オーナー
  16. 16. プロダクトオーナー 開発チームの作業とプロダクトの価値の最大化に責任を持つ - プロダクトバックログの管理者 - 優先順位の意思決定権限を持つ - 製品の責任者 - 関係者と協働してバックログの作成や成果物のフィードバック をもらう - 開発チームの成果物を評価する
  17. 17. 開発チーム
  18. 18. 開発チーム 出荷可能なものを全員でベストを尽くして作る - チーム全員で成果物に責任を持つ - チームの中に上下関係はない - 個人にフォーカスしない - 最良のやり方を自分たちで決める - チーム全員が個人全員を助ける - 持続可能なチームである
  19. 19. スクラムマスター
  20. 20. スクラムマスター スクラムの理解と成立に責任を持つ - サーバントリーダー - チームの成長を促す - 障害物を排除する - 相談にのる・一緒に考える
  21. 21. スプリントの流れ
  22. 22. スプリントの流れ - プロダクトバックログ作成 - スプリント計画会議(第一部) - スプリント計画会議(第二部) - 以下繰り返し - デイリースクラム - 開発 - 納品チェック - バックログリファインメント(オプション) - スプリントレビュー - ふりかえり
  23. 23. スプリント計画会議(第一部) - 2時間 - 参加者:PO・開発チーム・SM - POからバックログの説明を受け、 見積もり可能な状態にする - 優先度の高いものから開発チームが プランニングポーカーで相対見積もりを行う - スプリント対象のプロダクトバックログを決定する (*) スプリントが2週間の場合
  24. 24. スプリント計画会議(第二部) - 2時間 - 参加者:開発チーム・SM(POはオプション) - バックログを細かいタスクに分割する(目安は最大1日) - 設計や実現手法を議論する - タスクに対して絶対見積もりをする(単位は時間)
  25. 25. スプリント計画会議(第二部) - チームが必ず終わると責任をもって見積もりをする - 1つのプロダクトバックログを1人が担当するのを避ける - 最優先バックログを各個撃破が基本 - タスクはスプリント中に増減する - 1日の6割程度の稼働可能時間で見積もる - タスク合計時間が総キャパシティを超えたら POに相談して優先度の低いプロダクトバックログを外す
  26. 26. デイリースクラム - 15分 毎日 - 参加者:開発チーム・SM(POはオプション) - 話すことは3つだけ - 昨日やったこと - 今日やること - 問題 - 問題があれば別途ミーティングを関係者のみで開く - 未来のことを心配せず今日のことに集中する
  27. 27. スプリントレビュー - 1〜2時間 スプリント終了時 - 参加者:PO・開発チーム・SM(ステークホルダー) - プロダクトオーナーが完成したものと 完成していないものを事前に分けておく - 進捗確認の場ではない - プロダクトオーナーが完成品のデモを行う - 質問やフィードバックで改善と協力を引き出す
  28. 28. ふりかえり - 1〜2時間 スプリント終了時 - 参加者:開発チーム・SM(POはオプション) - チーム・プロセスの振り返りと改善 - 抱えている問題は何か - 良かったことは何か - 前回のプラクティスの効果はどうか
  29. 29. ツールや手法
  30. 30. プロダクトバックログ
  31. 31. プロダクトバックログ - 要求事項の一覧 - 顧客の価値が何かが記載されていると良い - 誰でも追記ができる - 順番はプロダクトオーナーが決定する - 開発チームやスクラムマスターは作成に協力する - 各スプリント開始前に都度優先度修正
  32. 32. プランニングポーカー 相対見積もり
  33. 33. プランニングポーカー - ポイント制で相対的に見積もる - 最初に基準となる2ポイントのバックログを選ぶ - それと比較して何ポイントかを見積もる - 全員が一致したら完了 - 不一致の場合、一番少ない人と一番多い人から 見解を聞く。それを元に再度見積もる - 3回繰り返して一致しない場合は 大きい方を採用する
  34. 34. 完了の定義
  35. 35. 完了の定義 - チーム全員が合意する納品物の完了の定義 - リリースされた状態なのか - QAテストが通った状態なのか - テストコードが通った状態なのか - コードレビューが通った状態なのか - 一貫した完了の定義を守る - フェーズによって変更する
  36. 36. ベロシティで予測
  37. 37. ベロシティ - チームがスプリント中に完了した プロダクトバックログの見積もりポイント合計 - スプリントでどれくらいの成果が出せるか 予測に使われる - 安定した値にならないと予測しにくい - 残業でめっちゃ頑張ったなどは異常値 - 成長と共にベロシティが上がるのは喜ばしい
  38. 38. バーンダウンチャート 状態の可視化
  39. 39. サンプル バーンダウンチャート
  40. 40. Don't just Do agile. Be agile.

×