SAFe4.0のエッセンス - kshirotori/dokusyo GitHub Wiki
- 第１部 概要
- 第２部 SAFeの基礎
- 第３部 プログラムとチームレベル
- 第４部 価値のストリームレベル
- 第５部 ポートフォリオ
今日の変化の早いデジタル社会でビジネスを持続させるためには技術やマーケットの変化に 迅速に対応する必要があるから。
チームはユーザーストーリーとイネイブラーを実装する。両方ともフィーチャーを開発するのに必要な機能の小さな部分を表すもの
- フィーチャー = ビジネスフィーチャー = ユーザー機能
- イネイブラー = イネイブラーフィーチャー = 技術的な基盤 チームの形態はスクラムやカンバン
Agile Release Trainは
- 通常5~12チームのアジャイルチームで構成
- アジャイルチームは一つのARTに属する
- SAFeでは複数のARTが価値を納品する
- ARTはプロジェクトやプログラムとは異なりチームが存続する
ARTの役割
- アジャイルチーム
- プロダクト管理
- システムアーキテクト/エンジニア
- Release Train Enginner(ARTのチーフスクラムマスター)
全てのチームのスプリントは同期（２週間）され各チームはシステムレベルのインクリメントを納品 Program IncrementはSAFeにおけるもっとも大きいPDCAサイクル、固定時間枠を設けて計画策定、実行、検査する。
- アジャイルチーム
- 3つの主要な役割
-
リリース列車エンジニア
- プログラムレベルのプロセスを推進、実行し、障害をエスカレーションする。（ARTのスクラムマスタ）
-
プロダクト管理
- ビジョン、ロードバップ、プログラムバックログの新たなフィーチャーによって定義される「構築されるもの」に対する責任を担う。
- 顧客やプロダクトオーナーと共に仕事をして、それらの人たちのニーズを理解し、伝える。
- ソリューションの妥当性確認に参加する
-
システムアーキテクト/エンジニア
- 個人またはチーム
- システムの全体的なアーキテクチャを定義する
- チームやコンポーネントよりも高い抽象度で仕事をし、非機能要求、主要なシステム要素、サブシステム、インターフェースを定義する
-
リリース列車エンジニア
- その他
- ビジネス責任者
- ARTの中心的な利害関係者で、列車のビジネス成果に対する最終的な責任を担う
- ビジネス責任者
- 顧客
- ソリューションの最終的な購入者
- システムチーム
- 開発とテスト環境を構築、維持するための支援を提供する
- アジャイルチームからの資産の統合の実施
- チームが実行できないエンドツーエンドのソリューションテスティングの実施
- 継続的なインテグレーション、テストの自動化の実施
- 共有されたサービス
- データセキュリティ、情報セキュリティ、DBA、技術ライターなどの専門家のことで特定のARTには属さない
- より頻繁はソリューションの納品は通常より良い経済的な成果をもたらすが、システムの制約によっては現実的ではないこともあり、 ビジネスの柔軟性のために開発のリズムとリリースを分けることもある。
- フィーチャーはユーザーのニースを満たすより大きなシステムの振る舞いを記述するために用いられる
- フィーチャーは単一のPIで納品可能な規模
- ユーザーストーリーと同様に受け入れ基準がある。
- フィーチャーやその他のマイルストーンと共に一連のPIからなる
- 既存の確約されたPIの納品物を示す
- 後続する２回のPIの内容を見えるようにする
- ビジョンや納品戦略が変わると、プロダクト管理によりロードマップが作成、更新される
- 分解されたフィーチャー
- 意図さらたシステムの振る舞いを交渉可能な形で表現したもの。
- ビジネスと技術両方の人たちがわかるちょうど十分な情報を提供する。
- 受け入れ基準は受け入れテストに取り込まれ自動化できる。
- ユーザーはエンドユーザー、デバイス、他のシステムなどが考えられる
- 行いたいことの一覧であり確約ではな。
- ユーザーストーリー、イネイブラー、改善ストーリーが含まれる
- 責任者はプロダクトオーナー
- 新しい機能の追加だけに集中すると技術的負債が増加しベロシティが低下する。
- 欠陥、リファクタリング、ユーザーストーリーは似て非なるもので比較は困難でプロダクトオーナーの混乱を招く
- 与えられた期間に各活動にどの程度を割り当てるかを予め決める
組織のベクトル合わせ効果的な行動をできるようにするには、ビジョンやビジネスの状況などの上位の情報に定期的に触れる機会をつくり、 計画策定などの自分たちの行動に直接関わるものをつくる道具として実際に使う必要がある。
- 役員の概況説明
- 役員や事業責任者によりビジネス状況が明確になっている
- プロダクト/ソリューションビジョンの概要説明
- プロダクトマネージャーが用意
- ビジョンとプログラムバックログの上位10個のフィーチャーを含む
- フィーチャーはDoDを満たすことを立証するために用いられる受け入れ基準を備える
- アーキテクチャビジョンの概要説明
- CTO、エンタープライズアーキテクト、システムアーキテクト/エンジニアリングによって用意
- 新たなイネイブラーや非機能要求として捉えられたアーキテクチャ戦略を伝える
- 役員や事業責任者がビジネスの状況を説明しPI計画策定の方向性を作る
- プロダクト管理が現在のビジョン、次のPIに対する目標、フィーチャーの優先順位を説明する
- システムアーキテクト/エンジニアリングがアーキテクチャに対するビジョンを説明する。
- 共通インフラの新たなアーキテクチャエピック、検討中の大規模リファクタリング、システムレベルの非機能要求が含まれる
- チームに分かれての検討
- フィーチャーと優先順位のためにプロダクトマネージャーや利害関係者と話をする
- 各スプリントでチームが達成するであろうベロシティを見積もる
- PIの目的とフィーチャーを満たすすべてのストーリーを明らかにする。（詳細化とAC付はしない）
- アーキテクチャ上の取り組みのストーリーを明らかにする
- 改善バックログ項目を組み込む
- 自チームや他チームに対する依存性を明らかにする
- ストーリーを見積もり、各スプリントに配置する
- 時間的に達成できる延期する必要のあるバックログを補足する。 - 一時間毎にSoSチェックポイントをもうけて計画策定の状況を確認する
- 各チームの計画をレビューする全体セッションを設ける
- 各チームの計画は未完成でよい。
- 上役とチームリーダーが１日目の計画策定に基づきスコープや目標の調整を行う。
- 上級のマネージャーが前日の最終調整の結果を説明する
- 優先順位の変更
- 計画とマイルストーンの調整
- スコープの調整
- 人やチームの移動
- チームに分かれて検討する
- スプリント計画とPI目標を仕上げる
- 背伸び目標を設定する
- ビジネス責任者がチームの目標にビジネス価値を割り当てる
- チームがプロダラムリスク、障害、依存性を集約する
- チームはプログラムボードをすべてのフィーチャーとチームの依存で更新する
- １時間毎にSoSで計画の状況を確認する
- 最終的な計画のレビュー
- 残存するプログラムレベルのリスクが議論されROAM分類される
- 確信度投票をする。
- 計画策定の振り返り
- PJ管理ツールへのPI目標やユーザーストーリーの取り込みを行い、プログラムカレンダーやスプリント計画の場所を再確認する。
- PI目標を使うことでチームからビジネス責任者への即座のフィードバックが可能となり、望まれた成果に対するチームの理解を確認する手段となる。
- リスクや不確定が大きすぎるためにチームが確約できない目標を識別するために使う
- ARTが納品できないかもしれない目標に対する早期の警告を上役に提供する。
- チームのおおよそできそうな仕事量よりも多くの仕事を担わせる手段ではない。
- 計画策定に先立ってRTEによって準備され、計画策定の間にチームにより更新される
- フィーチャーの納品日、マイルストーン、チーム間あるいは他のARTに対する依存性を明らかにする
PIの流れ
- 計画策定セッション
- 4回（デフォルト）のスプリント
- 計画策定（IP）スプリント
仕事の到着タイミングのムラ、優先順位の変化の速さ、計画の価値が低いような状況においてはカンバンをチームが採用することがあるが、 カンバンの採用時でも一定のルールを適用する
- PI計画策定、重要なサブシステムのデモ、検査と適応（I＆A）を含むARTの作業とイベントに参加しリズムを合わせる
- 仕事を見積もる
- ベロシティーを算出する
ARTはカンバンシステムを用いてフィーチャーを分析し実装できるように準備する。 実装にむけて承認されたフィーチャー（or イネイブラー)はプログラムバックログに維持される カンバンシステムは以下の2つの要素で構成される
- プログラムエピックセッション
- プログラムエピックを分析、承認、実装するためにフィーチャーに分割する。
- ワークフローはポートフォリオカンバンのステップ例と等価なステップ群に従う
- フィーチャーセッション
- フィーチャーの実装に向けて分析、承認、準備ができている状態にする
- フィーチャーの多くはローカルARTから生まれるがその他のフィーチャーはポートフォリオまたはプログラムエピックを分解することで生まれる
- プログラム管理、システムアーキテクト/エンジニアは各々フィーチャーとイネイブラーの内容決定の権限を持つ
- スクラムオブスクラムズ（SoS)
- 参加者はRTE、スクラムマスター、その他の人たち
- ARTの依存性の調整
- 進捗と障害の可視化
- 通常毎週開催
- POシンク
- 参加者はPO
- PI目標達成に向け進捗を可視化する
- フィーチャーの開発に付随する課題または機会の議論
- スコープの調整
- バックログの詳細化
- 通常毎週開催
- ARTシンク
- SoSとPOシンクの合同開催
状況を評価し現在の障害に対応するために毎週開催される。 この打ち合わせは近く予定されているリリースや他のマイルストーンに対して上級の上役に定期的に状況を把握できるようにするためのもの。 参加者は以下の人たちを含む代表者で行われる
- RTEとVSE
- ビジネス責任者とPdMやソリューション管理者
- 営業とマーケティング
- 社内IT、本番運用や配置の担当者
- 開発マネージャー、システムやソリューションレベルのQA
- CTOや、システムやソリューションアーキテクト/エンジニアリング
IPスプリントは「自分たちのバッテリーを充電し、道具を磨く」ための通常の開発スプリントに収めるのが難しい活動に取り組む定期的な時間である。 さらに見積もりのバッファーを提供するが、仕事の完了のためにこの時間を用いることは失敗パターンでもある。 IPスプリントには以下の活動が含まれる
- （PIの区切りでリリースする必要があれば）フルのソリューションの統合、検証、妥当性確認。リリース用文書の作成
- イノベーション、調査、ハッカソン
- PIシステムデモを含むI＆Aワークショップ
- プログラムとチームのバックログの詳細化
- 技術的なインフラ、ツール、その他のシステム的な障害への取り組み
- 継続的な教育を育む
- PI計画策定
各PIの終わりに実施する振り返り、改善項目は直ちにPI計画策定に組み込むことができる。 3~4時間のワークショップで以下の3部で構成される
- PIシステムデモ
- 定量的な測定
- 問題解決ワークショップ
PIの過程で蓄積された全てのフィーチャーを見せる。 普段のデモより参加者が多く、より公式となる場合がある。 目的は重要な利害関係者からのフィードバックを得ること。 デモは１時間以下に保ち、抽象度を高く保つ
RTEとVSEは情報を収集し、分析し、測定結果を発表できるようにする。 重要な測定項目の一つとしてPI予測性測定があり達成したビジネス価値と計画との予実を明らかにするものである
step1: 振り返り
- 30分の振り返りで対処したい問題を洗い出す。
- 振り返りの出席者は自主的に問題解決の規模を選択する
- チームレベル
- プログラムレベル（こちらが一般的）
- 自主的に選択をすることで、問題の影響を受けそうな人や問題対処のモチベーションの高い人を問題解決チームに含めることができる。
- ビジネス責任者や顧客、経営陣といった利害関係者も参加する
- チームの制約外の問題を解決できるのは彼らだけ。
step2: 問題解決ワークショップ
- ２時間の問題解決ワークショップで問題の解決方法を考える
- 問題解決ワークショップの進め方
- どの問題を解決するか合意する
- 根本原因分析を行う
- なぜなぜ分析
- フィッシュボーン図
- 石川ダイアグラム
- もっとも大きな根本原因を特定する
- パレート分析
- 新しく問題を記述し直す
- 解決方法のブレストをする
- 改善バックログ項目を作成する
規模の大きな価値のストリームの場合は利害関係者が多く一度に全ては呼べない。 追加でワークショップが必要な場合もある。
レベル4のSAFeの説明 国防システムような重要で複雑なシステムの構築のために設計されたもの。 外部のサプライヤーや複数のARTが必要になる。 価値のストリームレベルでも３つの代表的な役割がある。
- VSE
- ソリューション管理
- ソリューションアーキテクト/エンジニアリング
予算の範囲での迅速な意思決定の枠組みに必要な３要素
- 財務的な制約と意思決定のルールの理解
- ドメインに対する知識
- 意思決定の権限委譲
プラクティス
- リーン-アジャイルな予算計画
- エピックの予算づけとガバナンス
- 分散された意思決定
- CoDとWSJFを用いた順序付け
価値のストリームのカンバンは以下を管理するために用いる
- 価値のストリームエピック
- システム能力
複雑で高度なソリューションには大量の技術情報が必要となる場合があり、本章では管理のための以下の概念を説明する
- ソリューション
- ソリューションの意図
- ソリューションコンテキスト ソリューションの意図は初めは変更可能だが構築が進むに連れて確定する必要がある。
サプライヤーとARTをどのように連携さるかを説明した章