スクラムオブスクラム
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」のプラクティスの一つにスクラムオブスクラムがある。
考えたことをメモ。
【元ネタ】
「塹壕よりScrumとXP」
大規模プロジェクトで複数の開発チームがScrumをベースにアジャイル開発していたとする。
その場合に注意すべき点は何だろうか?
「アジャイル開発のスケールアップ」という従来から長く指摘され続けた問題に対し、その解決のキーワードとなる概念は、アジャイルリリーストレインとスクラムオブスクラム。
まず、「アジャイルリリーストレイン」とは、複数の電車が同時刻に発車/到着するように、複数の開発チームのスプリントを同期させること。
「塹壕よりScrumとXP」では、スプリントを同期させる理由として、各チームの編成を行うタイミングが各チームのスプリントの間であること、スプリントを同期しているから他チームとスプリント計画ミーティングを一緒に実施出来ること、管理上のオーバーヘッドを減らせることの3つを指摘している。
これは重要な指摘だ。
何故なら、「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」にも書いているように、一つの開発チームのスプリントが遅れることによって、他のスプリントにも遅延が影響するからだ。
例えば、開発チームAがスプリントで作っているライブラリを他の開発チームが使う予定の場合、ライブラリの提供が遅れれば、他の開発チームにも悪影響を与えてしまう。
丁度、TOCの「作業が早く終わっても伝播しないが、遅延は伝播してしまう」言葉を思い出させる。
次に、「スクラムオブスクラム」とは、各チームのスクラムマスターが定期的に集まる課題管理会議。
「塹壕よりScrumとXP」では、Scrumマスタが集まる定期的なミーティングであり、自身のチームの進捗や問題点を他チームのScrumマスタと共有して議論する場だ。
この会議では、チームリードと呼ばれる人がいて、Scrumマスタの1個格上のリーダーが議論をコントロールする。
スクラムオブスクラムが必要な理由は、一つのチームで解決できない問題を全チームが共有して、解決する方向へ持って行くことだ。
例えば、他チームが作るライブラリを早く提供して欲しい、とか、自チームは技術ノウハウが少ないので他チームのメンバーにヘルプで来て欲しい、とか、自チームの課題が実は他チームのスプリントに影響する、とか、他チームと調整しなければ自チームの進捗が遅れる状況はよくある。
だから、課題管理会議を定期的に開き、その場で各チームの課題を棚卸する時が多いだろうと思う。
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」では、大規模なアジャイル開発チームをアジャイルコンポーネントチーム・スクラムオブスクラム・ステアリングコミッティーの3つの階層に分けて編成することを推奨している。
最終的にはこのようなチーム構造になるだろうと思う。
同様の概念は、PMBOKのCCB、ITILのCABに相当する。
PMBOKのCCBは変更管理会議と呼ばれ、プロジェクトに発生する変更作業に対し、承認作業を行う委員会。プロジェクトのスコープ、成果物、WBSの変更は、公式な手続きを踏むことによって、ステークホルダー間の合意を取り、変更のトレーサビリティを容易にするために行う。
ITILのCABは変更諮問委員会と呼ばれ、ITの運用保守において、変更管理プロセスで行われ、変更要求とその対策(開発、テスト、リリース手順など)、作業計画を承認して、レビューを行う。
スクラムオブスクラムのような中間的な組織が必要になってくるのは、アジャイル開発だからというわけではなく、PMBOKでもITILでもCMMIでも同様に発生してくる問題なのだ。
システム開発でも、非機能要件と言うものが出てくるのと同じ。
小規模な開発なら無視できた非機能要件も、たくさんのコンポーネントを結合して一つの有機的なシステムとして捉えようとすると、非機能要件と言う全体最適な観点で解決しなくてはならない問題が出てくるのと同じなのだ。
「アジャイル開発のスケールアップ」には、従来のアジャイル開発では解決できなかった問題の本質がいくつか隠されているように思う。
色々考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
コメント