はじめに

この記事は、Microsoft Learn の下記のモジュールの中から重要と思われる内容を(筆者が勝手に抽出して)書き残しているものです。

Manage Agile software delivery plans across teams

上記のモジュールは、2020/5/10 現在、英語でのみ提供されています。日本語の内容を確認されたい方は、こちらを参照してください。※公式のものではありません

Azure DevOps - チーム全体でアジャイルソフトウェアの配信計画を管理する Part.1

開発規模が大きくなることによる弊害

配信計画は定期的にチェックが必要

企業の組織規模が大きくなるにつれて、チーム数も多くなり、各チームがさまざまな機能を開発することになります。そうなると、あるチームが開発した新機能をベースに別のチームがその機能に依存する別の新機能を開発するといった、開発の依存関係が生まれます。モジュール内でも言及されているように、

As development organizations grow, they need to reorganize into smaller teams that can efficiently manage portioned units of work. These teams will usually have their own work schedules, boards, and other processes that meet their unique needs within the context of the larger goals of the organization.
開発組織が成長するにつれ、分割された作業単位を効率的に管理できるように、より小さなチームに再編成する必要があります。これらのチームは通常、組織の大きな目標の中で独自のニーズを満たす独自の作業スケジュール、ボード、その他のプロセスを持つことになります。

とあり、チーム間で依存関係のある開発を行った結果、新しい機能やサービスが生まれる、ということです。(例えば、フロントエンドチームとバックエンドチームがそれぞれ新機能を開発してリリースする、など)

その中で課題になるのが、この依存関係です。チームが分かれるほど、それぞれのチームにおける独自のスケジュールが存在するようになり、各チームがそれぞれスプリントを設定し、自分たちの計画の中で機能をリリースするようになります。つまり、他チームのリリースする機能に依存関係がある開発を自チームのスプリントのタスクに組み込む際は、注意が必要になるわけです。機能のリリースが遅れればスプリントの生産性に影響を与えますし、最悪の場合、スプリントで設定したタスクを消化できない事案に陥るからです。これは回避しないといけないですね。

プッシュモデルからプルモデルに移行する

This might not be a major issue for a small group of teams that have daily meetings for all concerned. However, as teams scale in size and location, it can become untenable for everyone to know everything going on everywhere.
これは、関係者全員が毎日ミーティングを行うような少人数のチームにとっては、大きな問題ではないかもしれません。しかし、チームの規模や場所が大きくなればなるほど、どこで何が起こっているのかを全員が知ることができなくなってしまうこともあります。

はい、これはあるあるですよね。日系企業の場合は特に！！ (決して自分の組織が...とかではないですよ...)

リーダーや上司だけでミーティングをして情報を下に落とさない、とか、リーダーたちが自チームの情報をきちんと把握できていないために生産性がないミーティングしか開催されず、結果チーム間で喧嘩になる、とかそういうやつです。
(モジュール内では、スケジュールチキンの話についても言及されていましたね。日本だけでなく欧米でもそういうことはあるんでしょうね。。)

決して誤解して欲しくないのは、上記のような会議が全てにおいて不必要で無駄と切り捨てているわけではありません。DevOps に限らず、機能を開発していくプロセスの観点から見たときに、上記のようなものがチーム全体に大きな影響を与えてしまうことが無駄だ、と言っている訳です。
(なんで1日もかからない話を週次のミーティングまで待たないといけないのか、という話です。その間の作業は無駄になってしまう可能性がありますよね。SIerの開発現場とかではよくみる光景です。)

なので、プッシュモデルの情報共有からプルモデルの情報共有に移行する ことが大切になるわけです。
ここでいうプッシュモデルとプルモデルというのは、以下の通りです。

名前	説明
プッシュモデル	各チームが対面や電子メールでのアナウンスのような形で情報を送信し合う
プルモデル	各チームが常にお互いのスケジュールを確認したり追跡したりできる

いわゆるメールで連絡し合う、リーダー同士が週次で集まってミーティングを開くというのは、プッシュモデルに当てはまります。
そして、DevOps を行う上では特に、このプッシュモデルは非常に開発プロセスにマッチしないと思っています。スプリントという短いサイクルで機能を開発しリリース可能なものに仕上げることが求められている中において、週次でしかリーダーから情報をフィードバックされなかったり、相手から情報を共有してもらうための待ち時間が発生することは無駄でしかないと思っています。スプリントの生産性を下げる行為は非常に厄介です。
(そして残念なことに、こういった部分についてリーダーや上司が気付いてくれることは稀です。)

そのため、プルモデルでいつでも最新情報を確認・共有できる体制を作った方がいいということですね。それを Azure DevOps の拡張機能で実現できるということです。

複数のアジャイルチームを管理するための推奨事項

これは実際に翻訳記事をみてください。かなり重要なことが書かれていると思います。

従業員とプロセスの信頼を構築する
チーム（と個人）よりも組織を高める
透明性のある文化を醸成する

Delivery Plans 拡張機能

この拡張機能は、Azure Boards 上にて、チームやプロジェクト間でカレンダーベースのビューを使用して作業のポートフォリオを管理できるようにしてくれるものです。ここでは、VisualStudio Marketplace から Delivery Plans 拡張機能を取得して、Azure DevOps 組織の中にある Organization に対して適用することになります。

※ちなみにですが、Azure DevOps の拡張機能もたくさんあるので、どこかのタイミングでいろいろ試してみたいものですね。。

チームの都合などもありますが、それとは別に、(日本の暦では特に)不定期な形で祝日や会社休日をスプリント内に組み込まないといけない事例が多くあります。GW やシルバーウィークなどですね。デフォルトで使用しているだけだと、そういった暦によって、単一スプリントの全体的な生産性が左右されてしまう事例も多いので、Delivery Plans のような拡張機能を使用して、いつでも把握できるようにするといいと思います。

Delivery Plans の詳細については、実際に演習を実践したり、先述の拡張機能のページを参照するといいと思います。演習の中では、

Delivery Plans拡張機能をインストール
配信計画(delivery plan)を作成
チームのスプリントとマイルストーンを追加
全体のスケジュールに合わせてワークアイテムを再配置

の4つを行っていく内容になっています。

さいごに

このモジュールの完了で、DevOps プラクティスを発展させるというラーニングパスの最後の内容になります。Azure Boards の基本的な使い方を知った上で、実際の実務上で課題となる、開発の依存関係についてどう対応できるか、といった内容を知ることができました。

より詳細な内容については、Microsoft Docs の内容を読み進めるといいと思います。(英語しかまだありませんが...)
また、より実践的な内容を知りたい場合は、Azure DevOps Labs をみてみるといいと思います。ハンスオン形式でいろいろ学習することができます。(こちらも英語しかまだありません...)

ちなみに、こちらは両方リポジトリが GitHub で公開されているので、次回以降で、私がフォークしたリポジトリ内にて日本語訳を実施、随時紹介していく予定です。　

みなさんも、ぜひ、Azure DevOps を試してみてくださいね。