スクラムの拡張による組織づくり ──複数のスクラムチームをScrum＠Scaleで運用する（技術評論社） [電子書籍]

スクラムの拡張による組織づくり ──複数のスクラムチームをScrum＠Scaleで運用する（技術評論社） の 商品概要

• スクラムは，今や数多くの現場で活用されています。しかし，スクラムは少人数での開発を想定しており，大規模開発で実践する際にさまざまな問題が発生します。そこで，大規模開発でスクラムを行うための手法がいくつか提唱されています。本書はその中の一つであるScrum@Scaleを解説する書籍です。Scrum@Scaleは，スクラム提唱者の一人であるJeff Sutherland博士によって作られました。本書は，筆者が所属しているチームにScrum@Scaleを実際に導入した知見をもとにしています。Scrum@Scaleをどのように日々の開発に取り入れるのか，導入事例を交えながら具体的に解説します。
  

• 目次

  第1章：スクラムのスケーリングと大規模の難しさ
  スクラムをスケールするとはどういうことか
  1つのスクラムチームから増やしていく場合
  チームを増やしたくなる動機
  人が増えることでコストは大きくなる
  スクラムをスケールしない方法を考える
  疎結合なスケールを検討する
  大規模な組織に新しくスクラムを適用する場合
  大規模組織であっても最初は小さく始める
  スクラムのスケールは安易に選択すべきではない
  さまざまなスケーリングスクラムのやり方
  LeSS──1人のプロダクトオーナーと1つのプロダクトバックログ
  Nexus──統合チームが統合の責任を持つ
  SAFe──エンタープライズ向けビジネスフレームワーク
  Scrum@Scale──プロダクトオーナーをスケールする
  大規模スクラムの導入と組織文化
  大規模スクラムの導入は組織的な支援が必要
  大規模スクラムを成功させる「動機付け」
  まとめ
  
  第2章：スクラムのおさらい
  スクラムとは
  経験主義の三本柱
  透明性
  検査
  適応
  スクラムの価値基準
  3つの作成物，スクラムチーム，5つのイベント
  スクラムにおける3つの作成物
  プロダクトバックログ
  プロダクトバックログリファインメント
  スプリントバックログ
  インクリメント
  スクラムチーム
  開発者
  プロダクトオーナー
  スクラムマスター
  スクラムチームの人数
  スクラムにおける5つのイベント
  スプリント
  スプリントプランニング
  このスプリントはなぜ価値があるのか？
  このスプリントで何ができるのか？
  選択した作業をどのように成し遂げるのか？
  デイリースクラム
  スプリントレビュー
  スプリントレトロスペクティブ
  まとめ
  
  第3章：とあるチームのScrum@Scaleでの1スプリント
  チームの紹介
  とあるチームのデイリースクラム
  さまざまなデイリースクラム
  [Column]モブワーク／モブプログラミング
  SDS
  EATのデイリースクラム
  毎日45分で問題が解決する
  プロダクトオーナーの活動
  複数のプロダクトオーナーとその仕事
  チーフプロダクトオーナーの活動とメタスクラム
  メタスクラムでの議論
  スケールされたプロダクトバックログリファインメント
  スケールされたスプリントレビュー
  まとめ
  
  第4章：スクラムマスターサイクルとプロダクトオーナーサイクル
  Scrum@Scaleの特徴
  スクラムマスターサイクル
  スクラムチームとSoS
  スクラムオブスクラムマスター
  SoSのサイズとスケール
  SoSは共通の関心事どうしで作る
  関心事をどのように分離するか
  コンウェイの法則と逆コンウェイ作戦
  Scrum@Scaleと『チームトポロジー』
  チームタイプ
  インタラクションモード
  SoSのイベント
  SDS
  スケールドレトロスペクティブ
  SoSのスプリント
  Executive Action Team（EAT）
  EATの役割
  EATに誰が参加するか
  [Column]アジャイルプラクティス
  EATも1つのスクラムチームになる
  EATのメンバーは外部のステークホルダーのようにならない
  組織構造の継続的な改善
  人が異動することによるコスト
  人ではなくチームの組み合わせを変えていく
  どのように組織を変更するか
  EATだけで人の配置を決定できるようにする
  プロダクトオーナーサイクル
  なぜプロダクトオーナーは開発チームから独立してスケールするのか
  チーフプロダクトオーナーとメタスクラム
  EMS
  EMSの役割
  EMSに誰が参加するか
  プロダクトオーナーの活動を支援するイベント
  プロダクトバックログリファインメント
  スケールされたスプリントレビューとスケールされたスプリントプランニング
  まとめ
  
  第5章：Scrum@Scaleを形成する12のコンポーネント
  習熟度を確認するために12のコンポーネントを使う
  最初に行うコンポーネント
  チームプロセス──2つのサイクルの交差点
  [Column]守破離
  Scrum@Scaleでの守破離の「破」
  スクラムマスターサイクルのコンポーネント
  継続的改善と障害の除去──開発の障害を迅速に取り除く
  チーム横断の調整──コラボレーションの合理化
  [Column]レベル2のスクラムマスター
  デリバリ──完成したプロダクトを届ける
  プロダクトオーナーサイクルのコンポーネント
  戦略的ビジョン──組織全体の方向性を作る
  [Column]EBM
  バックログの優先順位付け──価値の提供の最適化
  バックログの分割とリファインメント──チームの理解を深める
  リリースプランニング──長期的な計画を作る
  すべての機能がそろう時期の範囲を伝える
  ある時期までに完成する機能の量の範囲を伝える
  期限に確実に終わらせるためにやることを減らす
  共通のコンポーネント
  プロダクトリリースとフィードバック──プロダクトバックログの更新
  メトリクスと透明性──検査・適応のための手段
  チームのパフォーマンス
  SLI（サービスレベル指標）／SLO（サービスレベル目標）
  ビジネスを測る指標
  メトリクスは単独では意味がない
  まとめ
  
  第6章：現場へどのように導入していくか
  ステップ0：機能しているスクラムチームを作る
  スクラムチームが機能しているとはどういう状態か
  [Column]スクラムチームの成熟度
  ステップ1：SoSを立ち上げる
  単一のチームを複数に拡張する
  チーム分割の落とし穴
  人がチームを横断する
  分割後の依存関係
  SoSのスクラムイベントをスタートする
  SoSの作成物
  EATを立ち上げ，エグゼクティブメンバーを巻き込む
  ステップ2：メタスクラムを立ち上げる
  チーフプロダクトオーナーを選出する
  メタスクラムとしてのイベントを立ち上げる
  EMSを立ち上げ，エグゼクティブメンバーを巻き込む
  ステップ3：改善サイクルを回す
  12のコンポーネントと変革バックログ
  [Column]EATを一番初めに導入するパターン
  まとめ
  
  第7章：Scrum@Scaleで運用される現場 ──チャットサービスの開発現場の場合
  なぜScrum@Scaleを選択したのか
  逆コンウェイ作戦
  プロダクトオーナーチームの利点
  Scrum@Scaleの組織構造とイベントの運用
  3つのスクラムチーム
  SoSとEAT
  メタスクラム
  アジャイルプラクティス
  Scrum@Scaleのイベント
  スクラムマスターサイクルとしてのイベント
  SDS
  スケールドレトロスペクティブ
  EATとしてのイベント
  [Column]むきなおり
  プロダクトオーナーサイクルとしてのイベント
  メタスクラムのデイリースクラム
  メタスクラムのプロダクトバックログリファインメント
  1週間のカレンダーまとめ
  組織構造の変遷
  初期状態
  2チームで開始したアーキテクチャ上の理由
  CQRS
  チームをコマンドとクエリに分離
  4ヵ月目──認証・認可基盤チームが立ち上がり3チーム体制へ
  6ヵ月目──開発スコープの変更によるチーム再編
  8ヵ月目から現在──SoSの再編とEAT
  SoSの再編
  EMSからEATへ
  12のコンポーネントの自己採点と変革バックログ
  まとめ
  

スクラムの拡張による組織づくり ──複数のスクラムチームをScrum＠Scaleで運用する（技術評論社） の商品スペック