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

概要

この記事は、Microsoft Learn の下記のモジュールを日本語訳した記事です。

docs.microsoft.com

Learn to optimize delivery efficiency by improving work plan visibility across teams.

チーム全体の作業計画の可視性を向上させることで、配信効率を最適化する方法を学びます。

In this module, you will:
・Learn how delivery plans enable multiple teams to plan, schedule, and coordinate their work.
・Install the Delivery Plans extension for your Azure DevOps project.
・Create a delivery plan and adjust a team's sprint workload to optimize delivery efficiency.

このモジュールでは、以下のことを行います:

  • 複数のチームがどのようにして配信計画を立て、スケジュールを立て、作業を調整するのかを学ぶ。
  • Azure DevOps プロジェクト用の Delivery Plans 拡張機能をインストールする。
  • 配信計画を作成し、チームのスプリント作業量を調整して配信効率を最適化する。

はじめに

Azure DevOps can help your team scale their development processes to deliver bigger and more ambitious projects. Let's rejoin the Tailspin Toys team as they tackle a common problem organizations face as they grow. Together, we'll discover what it takes to effectively manage work schedules across multiple teams.
You met the team at Tailspin Toys earlier in this learning path. In the previous module , you watched as they began to manage their work schedule through Azure Boards. Soon, word of their early success began to spread, and now other teams are exploring how they can enjoy the same benefits.
As more teams adopt Azure Boards, the organization begins to see the network effects of having their planning consolidate around a consistent process. Problems that were once written off as a cost of doing business now have achievable solutions. Let's watch the team as they lead their organization in its evolution.

Azure DevOpsは、チームが開発プロセスをスケールアップして、より大がかりなプロジェクトを実現するのに役立ちます。Tailspin Toysチームに再び参加して、組織が成長する際に直面する共通の問題に取り組んでみましょう。一緒に、複数のチームにまたがる作業スケジュールを効果的に管理するために必要なことを発見しましょう。
この学習パスでは、以前、Tailspin Toysのチームに会いました。前のモジュール では、彼らがAzure Boardsを使って仕事のスケジュールを管理し始めたのを確認しました。すぐに、彼らが早期の成功を収めたという言葉が広まり始め、今では他のチームも同じメリットを享受する方法を模索しています。

In this module, you will:
・Learn how delivery plans enable multiple teams to plan, schedule, and coordinate their work.
・Install the Delivery Plans extension for your Azure DevOps project.
・Create a delivery plan and adjust a team's sprint workload to optimize delivery efficiency.

このモジュールでは、以下のことを行います:

  • 複数のチームがどのようにして配信計画を立て、スケジュールを立て、作業を調整するのかを学ぶ。
  • Azure DevOps プロジェクト用の Delivery Plans 拡張機能をインストールする。
  • 配信計画を作成し、チームのスプリント作業量を調整して配信効率を最適化する。

前提条件

The modules in this learning path form a progression. We recommend you start at the beginning of the Evolve your DevOps practices learning path before you work on this module.
If you'd rather do only this module, go through Get started with Azure DevOps first to set up your Azure DevOps organization.

この学習パスのモジュールはプログレッションを形成しています。このモジュールを始める前に、Evolve your DevOps practices ラーニングパスの最初から始めることをお勧めします。
このモジュールだけを実行したい場合は、Get started with Azure DevOps に進んで、最初にAzure DevOpsを使ってAzure DevOps組織をセットアップしてください。

docs.microsoft.com

mappie-kochi.hatenablog.jp

mappie-kochi.hatenablog.jp

チームの紹介

You met the Space Game web team at Tailspin Toys in previous modules. As a refresher, here's who you'll work with in this module.

あなたは以前のモジュールで、Tailspin Toysのスペースゲームウェブチームに会いました。再確認として、このモジュールで一緒に働く人を紹介します。

https://docs.microsoft.com/ja-jp/learn/azure-devops/shared/media/andy.png

Andy is the development lead.

アンディは開発のリーダーです。

https://docs.microsoft.com/ja-jp/learn/azure-devops/shared/media/mara.png

Mara just joined as a developer and reports to Andy.

マーラは開発者として参加したばかりで、アンディに報告をしています。

Mara has prior experience with DevOps and is helping the team adopt a more streamlined process by using Azure DevOps.

マーラはDevOpsの経験があり、Azure DevOpsを使用してチームがより合理化されたプロセスを採用するのを支援しています。

配信計画とは?

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. Over time, organizations may find that they enjoy network benefits by consolidating their processes around a consistent framework.

開発組織が成長するにつれ、分割された作業単位を効率的に管理できるように、より小さなチームに再編成する必要があります。これらのチームは通常、組織の大きな目標の中で独自のニーズを満たす独自の作業スケジュール、ボード、その他のプロセスを持つことになります。時間の経過とともに、組織は一貫性のあるフレームワークの周りにプロセスを統合することで、ネットワークのメリットを享受していることに気づくかもしれません。

A delivery plan is a visualization of one or more work schedules. It is intended to provide teams and management an overall view of what each team is planning to produce and when. This allows decisions to be made that optimize the investments across the organization.

配信計画は、1 つまたは複数の作業スケジュールを可視化したものです。これは、各チームがいつ、何を計画しているのかをチームと経営陣に全体像を提供することを目的としています。これにより、組織全体の投資を最適化する意思決定が可能になります。

It's important that teams regularly review their delivery plans in order to make sure that their work schedule aligns with the schedules of other teams. These reviews should ask questions like:
・Are we sure we can deliver what we have committed to on our current schedule?
・Are we confident that the teams we depend on will deliver what we need on their current schedule?
・Are there lulls in our schedule that we could fill with work?

チームの作業スケジュールが他のチームのスケジュールと一致していることを確認するために、チームが定期的に配信計画をレビューすることが重要です。これらのレビューでは、次のような質問をする必要があります:

  • 今のスケジュールで公約したことを本当に実現できるのか?
  • 頼りにしているチームが、現在のスケジュールで必要なものを提供してくれる自信があるのか?
  • 仕事でいっぱいなスケジュールで一時的に安定している状態はありませんか?

Delivery plans add value at any point in a project's lifecycle. Since they are dynamically generated based on team backlogs, they're always up-to-date and offer the latest insights.

Let's join the Tailspin web team in their discussion.

Andy: I just had a great meeting with engineering management. I demoed the work we're doing with Azure Boards and they're excited about the prospect of getting other teams on board.

アンディ: 私はちょうどエンジニアリング管理者との素晴らしい会議をしました。私はAzure Boardsでの作業をデモしましたが、彼らは他のチームの参加を期待して興奮しています。

Mara: Awesome! When will they get started?

マーラ: すごい!いつ始まりますか?

Andy: That's the best part - they already have! Last night the game engine project lead created a team with some sprints and began adding work items. I took a quick look this morning and it's shaping up nicely. Let me show you what they're up to.

アンディ: それが一番いいところで、すでにあるんだよ!昨晩、ゲームエンジンプロジェクトのリーダーがいくつかのスプリントでチームを作り、作業項目を追加し始めました。今朝、ざっと見てみましたが、うまくいっています。彼らが何をしようとしているのか、お見せしましょう。

Andy navigates to the game engine's current sprint board. He and Mara review the work items with great interest.

アンディはゲームエンジンの現在のスプリントボードにナビゲートします。彼とマーラは興味津々で作業項目を確認します。

Andy: Hmm...I just noticed that they're not planning to deploy their beta by the end of this sprint. Aren't we expecting to integrate our leaderboard with the beta database during our next sprint? We can't do that if they don't ship the beta first.

アンディ: うーん...今気づいたんだけど、このスプリントの終わりまでにベータ版をデプロイする予定はないみたいだね。私たちは次のスプリントの間にリーダーボードをベータ版データベースに統合することを期待していなかったっけ?先にベータ版を出荷してくれないとこれは無理なんだよな。

Mara: That's a good point. We have a dependency on that team to produce that deliverable so that we can produce one of our own.

マーラ: それは良い点ですね。自分たちはその成果物を作れるように、そのチームに依存をしています。

Andy: This could have really hurt our productivity next sprint. I'm going to give them a call to find out what's going on.

アンディ: これは次のスプリントの生産性を下げることになります。何が起こっているのか確認するために、彼らに電話してみるか。

Unfortunately, more sophisticated team structures can result in gaps or lags in communication. When one team is blocked, they might not be able to produce something another team is dependent on. 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. It's at this point where organizations need to transition from a pure "push" model (like in-person or email announcements) to a "pull" model (where teams can review and track each other's schedules).

残念ながら、より洗練されたチーム構造では、コミュニケーションのギャップやラグが生じることがあります。あるチームがブロックされると、別のチームが頼りにしているものを作ることができなくなるかもしれません。これは、関係者全員が毎日ミーティングを行うような少人数のチームにとっては、大きな問題ではないかもしれません。しかし、チームの規模や場所が大きくなればなるほど、どこで何が起こっているのかを全員が知ることができなくなってしまうこともあります。この時点で、組織は純粋な「プッシュ」モデル(対面や電子メールでのアナウンスのような)から「プル」モデル(チームがお互いのスケジュールを確認したり追跡したりできる)に移行する必要があります。

Andy: Okay, I just spoke with the dev lead. She told me that their team is blocked on shipping the beta until the art team returns from Cliffchella.

アンディ: よし、今、開発リーダーと話したんだけど、彼女の話では、アートチームが Cliffchella から戻るまでは、ベータ版の出荷は停止されているそうだ。

Mara: The mountaintop music festival?

マーラ: 山頂の音楽祭のこと?

Andy: Yeah, apparently it's a huge deal in the design community and their entire team just drops off the grid for a whole week to attend. The game engine team is pretty upset because it slipped their schedule by three weeks. Had they known it was coming, they would have made sure to get the artifacts they needed ahead of time. They also apologized for not letting us know sooner. They didn't realize we would be waiting on their beta to ship our part.

アンディ: そうそう、デザイン業界では大騒ぎらしくて、チーム全員が参加するために丸一週間の休暇を取ったらしい。ゲームエンジンチームはかなり動揺していたよ。彼らは事前にそれを知っていたなら、前もって必要なアーティファクトを手に入れるようにしていただろうな。また、もっと早く知らせなかったことを謝罪してくれたよ。彼らは、私たちがベータ版の出荷を待っているとは知らなかったみたいだ。

Mara: Well at least we can be glad that the game engine team is publishing their sprint plans. It helped us find this dependency issue early enough to adjust our schedule.

マーラ: 少なくとも、ゲームエンジンチームがスプリント計画を公開していることは喜ばしいことでしたね。この依存性の問題を早期に発見できて、スケジュールを調整するのに役立ちました。

Andy: I just wish there was a way to see these potential risks coming more easily. Our teams have so many dependencies across the company that there's no way we can attend every meeting and subscribe to every distribution group.

アンディ: これらの潜在的なリスクがもっと簡単にわかる方法があればいいのにと思うよ。私たちのチームは会社全体で多くの依存関係を持っているから、すべての会議に出席したり、すべての配布グループを定期的に確認したりすることはできないよ。

Mara: We should create a delivery plan so that we can see our team sprints side-by-side. This will help both teams more easily identify how our schedules impact each other. And I know the perfect Azure DevOps extension for the job.

マーラ: チームのスプリントを横に並べて見ることができるように、配信計画を作成する必要がありますね。そうすれば、両チームのスケジュールがお互いにどのように影響しているかをより簡単に把握することができます。そして、この仕事に最適な Azure DevOps の拡張機能を知っています。

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

An Agile approach, along with Azure DevOps, can substantially improve project transparency and predictability. However, projects may still run into traditional challenges, often related to personnel or miscommunication. Here are a few things to consider as you scale your Agile efforts.

アジャイルなアプローチは、Azure DevOpsとともに、プロジェクトの透明性と予測可能性を大幅に向上させることができます。しかし、プロジェクトは、人員やミスコミュニケーションに関連した従来の課題に直面することもあります。ここでは、アジャイルの取り組みをスケールアップする際に考慮すべきことをいくつか紹介します。

従業員とプロセスの信頼を構築する

Early detractors from Agile implementations are often skeptical about their ability to improve team performance. It's important for thought leaders within the organization to build trust by illustrating how the tools and processes produce results. Sometimes these results are improvements in productivity, and those are easy to quantify. However, don't forget to highlight the team wins that occur by circumventing potential problems, such as avoidable schedule slips or quality issues. As people begin to associate the benefits with the process that achieved them, you will get more enthusiasm.

アジャイル実装の早い段階では、チームのパフォーマンスを向上させる能力に懐疑的になることが多いです。組織内のオピニオンリーダーが、ツールやプロセスがどのように結果を生み出すかを示すことで信頼を築くことが重要です。その結果が生産性の向上につながる場合もあるし、定量化させるのは容易なことです。しかし、回避可能なスケジュールのズレや品質問題などの潜在的な問題を回避することで得られるチームの勝利を強調することも忘れてはいけません。人々が利益を達成したプロセスと関連付けるようになれば、あなたはより多くの熱意を得ることができるでしょう。

チーム(と個人)よりも組織 を高める

Some teams and individuals get territorial when new processes or policies are proposed. Rather than framing new policies as negatively exposing the performance of specific teams or individuals, highlight how the new transparency across the organization informs everyone of expectations. Having a single place where anyone can trace how their work relates to the organization meeting its goals will drive home the importance of their commitment to the process.

新しいプロセスやポリシーが提案されると、一部のチームや個人は縄張り意識を持つようになります。新しいポリシーが特定のチームや個人のパフォーマンスを否定的にさらけ出していると考えるのではなく、組織全体の新しい透明性がどのように期待されているかを全員に伝えることを強調しましょう。誰もが自分の仕事が組織の目標達成にどのように関係しているかを追跡できる場所を一箇所に持つことで、プロセスへのコミットメントの重要性を再認識させることができます。

透明性のある文化を醸成する

Unfortunately, the term "transparency" gets a bad wrap. Nobody asks for more transparency when everything is going great. Instead, transparency (or lack thereof) is often blamed when teams are struggling. Even with all of the opportunities for transparency afforded for Agile teams, it's still subject to the honesty of individuals and teams. Emphasize that one of the reasons for transparency is to be able to identify and address potential issues before it's too late. Everyone understands that people sometimes run into circumstances that prevent them from meeting schedule deadlines. But if they don't feel safe in reporting disappointing news until the last possible moment, it can have a much more destructive impact. Building a comfort level with transparency can start with thanking people for reporting expected delays as early as possible.

残念なことに、「透明性」という言葉は悪い意味で使われています。すべてがうまくいっているときに、誰もさらなる透明性を求めたりしません。その代わりに、チームが苦戦しているときには、透明性(または透明性の欠如)が非難されることがよくあります。アジャイルチームに対する透明化のためのあらゆる機会があっても、それは個人とチームの正直さに左右されてしまいます。透明性の理由の1つは、手遅れになる前に潜在的な問題を特定して対処できるようにすることであることを強調してください。誰もが、スケジュールの締め切りに間に合わない状況に陥ることがあることを理解しています。しかし、可能な限り最後の瞬間まで、失望したニュースを報告することに対する安心感がなければ、それははるかに破壊的な影響を与える可能性があります。透明性のある快適なレベルを築くための第一歩は、予想される遅延を可能な限り早く報告してくれた人々に感謝することからです。

mappie-kochi.hatenablog.jp