Azure DevOps - ソフトウェア開発にアジャイルなアプローチを選択する Part.1

概要

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

docs.microsoft.com

Learn to foster the DevOps values of transparency and team cooperation with Azure Boards.

Azure Boardsで透明性とチーム連携というDevOpsの価値観を醸成することを学びます。

In this module, you will:
・Create an Azure DevOps project
・Add work items to Azure Boards by using the Basic process
・Assign work items to team members

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

  • Azure DevOpsプロジェクトを作成する
  • Basic プロセスを使用してAzure Boardsに作業項目を追加する
  • チームメンバーに作業項目を割り振る

はじめに

You've met the Tailspin team and learned a bit about their problems. Mara, the newest team member, is trying to convince her teammates that a DevOps approach, using the services in Azure DevOps, is a great way to solve them. She's taken it upon herself to do a value stream mapping (VSM) exercise, and she's shown everyone the results.

あなたはTailspinチームに出会い、彼らの問題について少し学びました。新人のチームメンバーであるマーラは、Azure DevOpsのサービスを利用したDevOpsアプローチが問題を解決するための素晴らしい方法であることをチームメイトに説得しようとしています。彼女は、バリューストリームマッピング(VSM)のエクササイズを自ら行い、その結果をみんなに見せています。

Her next goal is to convince the Tailspin team to take their first DevOps steps by using an Agile approach and Azure Boards, a part of the Azure DevOps suite. Azure Boards helps teams collaborate and plan their work better. This module shows how the team creates its first board.

彼女の次の目標は、アジャイルアプローチとAzure DevOpsスイートの一部であるAzure Boardsを使用して、TailspinチームがDevOpsの最初のステップを踏むように説得することです。Azure Boardsは、チームがコラボレーションし、より良い仕事の計画を立てるのに役立ちます。このモジュールでは、チームが最初のボードを作成する方法を示します。

In this module, you will:
・Create an Azure DevOps project
・Add work items to Azure Boards by using the Basic process
・Assign work items to team members

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

  • Azure DevOpsプロジェクトを作成する
  • Basic プロセスを使用してAzureボードに作業項目を追加する
  • チームメンバーに作業項目を割り振る

前提条件

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 ラーニングパスの最初から始めることをお勧めします。

docs.microsoft.com

mappie-kochi.hatenablog.jp

このモジュールだけを実行したい場合は、Get started with Azure DevOpsに進んで、最初にAzure DevOpsを使ってAzure DevOps組織をセットアップしてください。

docs.microsoft.com

チームの紹介

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

前のモジュールで、Tailspin ToysのスペースゲームWebチームに会った。再確認として、このモジュールで一緒に働く人を紹介しよう。

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/amita.png

Amita is in QA.

アミタはQA担当です。

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

Tim is in operations.

ティムは運用担当です。

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を使用してチームがより合理化されたプロセスを採用するのを支援しています。

アジャイルとは何か?

Agile is a term that's used to describe approaches to software development, emphasizing incremental delivery, team collaboration, continual planning, and continual learning. Agile isn't a process as much as it is a philosophy or mindset for planning the work that a team will do. It's based on iterative development and helps a team better plan for and react to the inevitable changes that occur in software development. Let's listen in on Mara's discussion with Andy after the latest release.

アジャイルとは、ソフトウェア開発へのアプローチを説明するために使われる用語で、増分配信、チームコラボレーション、継続的な計画、継続的な学習を強調しています。アジャイルはプロセスではなく、チームが行う作業を計画するための哲学や考え方です。アジャイルは反復開発に基づいており、ソフトウェア開発で起こる避けられない変化に対してチームがより良い計画を立て、対応するのに役立ちます。最新リリース後のアンディとのマーラのディスカッションを聞いてみよう。

Mara felt she'd made a few small steps toward interesting the team in DevOps, but progress has stalled. The team has been too busy fixing bugs in the last release to think about anything else.

マーラは、DevOpsのチームに興味を持ってもらうための小さな一歩を踏み出したと感じていましたが、進捗は停滞していました。チームは最後のリリースのバグ修正で忙しく、他のことを考えることができなかったのです。

Recall that Irwin, the product manager, provided the team with some rather critical customer feedback about the racing game website. Resolving these issues wasn't fun. Andy and Mara would write code and then hand it to Amita, the tester. Amita always seemed to find new bugs and had to hand the code back. The build server failed. Tim couldn't get the game's website to work in production, even after it worked in dev and test. Everyone worked long hours and lost a couple weekends.

思い起こせば、プロダクトマネージャーのアーウィンは、レーシングゲームのウェブサイトについて、かなり批判的な顧客からのフィードバックをチームに提供していました。これらの問題を解決するのは楽しいことではありませんでした。アンディとマーラはコードを書き、それをテスターのアミタに渡していました。アミタはいつも新しいバグを見つけて、コードを返さなければなりませんでした。ビルドサーバーは故障しました。ティムはゲームのウェブサイトが開発サーバとテストサーバで動作した後でも、本番環境で動作させることができませんでした。誰もが長時間働き、週末の数日を失っていました。

After they shipped the release, Mara and Andy sat down for coffee. They were both tired. Mara was discouraged but Andy had a different attitude.

リリース後、マーラとアンディはコーヒーを飲むために座りました。二人とも疲れていました。マーラは落胆していたが、アンディは違う態度をとっています。

Andy: I don't know why you're surprised. Getting software out the door is hard. It's always a slog. Have you ever done it differently?

アンディ: 驚く理由がわからない。ソフトウェアを世に出すことは難しいんだ。いつも大変なんだよ。今までとは違うことをしたことは?

Mara: I have and I think we could make things easier here, too. I really believe DevOps can help us.

マーラ: ありますし、ここでももっと簡単にできると思いますよ。私は本当にDevOpsが私たちを助けてくれると信じています。

Andy: I remember we did a value-stream mapping exercise, but now what? We've got to get started on the new release. I thought we were done with DevOps.

アンディ: バリューストリームマッピングの練習をしたのは覚えているが、さてどうする?新しいリリースに取り掛からないと。もうDevOpsは終わったんじゃないの?

Mara: There's a lot more we can do. I think we should take the first step and do some Agile planning. We can use Azure Boards to help us.

マーラ: まだまだできることはたくさんあります。最初の一歩を踏み出して、アジャイルプランニングをするべきだと思います。Azure Boardsを利用してもいいと思います。

Andy: What do you mean by Agile?

アンディ: アジャイルってどういうこと?

Mara: Agile is an approach to software development. The term "Agile" was coined in 2001 in the Agile Manifesto. The manifesto established some guiding principles for a better approach to software development. The manifesto says:

マーラ: アジャイルとは、ソフトウェア開発へのアプローチのことです。「アジャイル」という用語は、2001年にアジャイルソフトウェア開発宣言によって提唱されました。アジャイルソフトウェア開発宣言は、ソフトウェア開発へのより良いアプローチのためのいくつかの指導原則を確立しています。アジャイルソフトウェア開発宣言には次のように書かれています。

We value:
・Individuals and interactions over processes and tools
・Working software over comprehensive documentation
・Customer collaboration over contract negotiation
・Responding to change over following a plan

私たちは以下を価値とします:

  • プロセスやツールよりも個人と対話を
  • 包括的なドキュメントよりも動くソフトウェアを
  • 契約交渉よりも顧客との協調を
  • 計画に従うことよりも変化への対応を

Andy: Look, if you know some magic way to make life easier, I'm all for it. My kids are always asleep by the time I get home. But this sounds very touchy-feely without any concrete solutions.

アンディ: みてくれ、人生を楽にする魔法の方法を知ってるなら私は大歓迎だよ。子供たちはいつも私が帰る頃には眠っている。でも具体的な解決策がなくて、感情的な話に聞こえるな。

Mara: It's not magic, but we can do it bit by bit, and Azure DevOps gives us the tools we need to implement Agile practices. For now, when we want to plan, we can use Azure Boards. First, can you explain the build process to me and help me identify the big problems?

マーラ: 魔法ではありませんし、少しずつではありますが、Azure DevOpsはアジャイルラクティスを実装するために必要なツールを提供してくれています。今のところ、計画を立てたいときにはAzure Boardsを使うことが可能です。まず、ビルドプロセスを説明して、大きな問題点を特定するのに役立てませんか?

After lots of coffee, Mara and Andy identify the biggest problems in the build process. All the issues came up during the last release. After Andy leaves, Mara looks at her scribbled notes and decides to do a little Agile planning herself. On her own, she uses the Basic process on Azure Boards to get all the problems in one place.

たくさんコーヒーを飲んだ後、マーラとアンディはビルドプロセスにおける最大の問題点を特定することにしました。すべての問題は前回のリリース中に出てきたものです。アンディが去った後、マーラは走り書きしたメモを見て、自分で少しだけアジャイルな計画を立てることにしました。自分でAzure BoardsのBasicプロセスを使って、すべての問題を一箇所にまとめます。

Her next step is to show the board to the team and get them involved.

彼女の次のステップは、ボードを見せてチームを巻き込むことです。

アジャイルを採用するための推奨事項

The team is getting ready to take their first steps toward adopting Agile. Here are some general recommendations that any team can use to incorporate Agile into their organization.

チームは、アジャイルを採用するための最初の一歩を踏み出す準備をしています。ここでは、どのチームでもアジャイルを組織に取り入れるための一般的な推奨事項をいくつか紹介します。

アジャイルラクティスを支える組織体制を作る

For most organizations, adopting Agile can be difficult. It requires a mind-shift and a culture-shift that challenges many existing policies and processes within the organization. Traditionally, most companies use a horizontal team structure. In practice, this means teams correspond to the software architecture. For example, there might be a team responsible for an application's user interface, another team responsible for data, and another team responsible for the service-oriented architecture.

ほとんどの組織にとって、アジャイルを採用することは難しいことです。それは、組織内の多くの既存のポリシーやプロセスに挑戦するマインドシフトとカルチャーシフトを必要とします。伝統的に、ほとんどの企業は水平的なチーム構造を使用しています。実際には、これはチームがソフトウェアアーキテクチャに対応していることを意味しています。例えば、アプリケーションのユーザーインターフェースを担当するチーム、データを担当する別のチーム、そしてサービス指向アーキテクチャを担当する別のチームがあるかもしれません。

However, vertical teams provide better results for Agile projects. Vertical teams span the architecture and are aligned with product outcomes. For example, there might be a team responsible for the email portion of the app and team members come from all three of the abovementioned disciplines. Another benefit of the vertical team structure is that scaling occurs by adding teams.

しかし、アジャイルプロジェクトでは、縦型チームの方がより良い結果が得られます。垂直的なチームは、アーキテクチャにまたがっており、製品の成果物と一致しています。例えば、アプリのメール部分を担当するチームがあり、チームメンバーは上述の3つの分野のすべてから来ているかもしれません。バーティカルチーム構造のもう一つの利点は、チームを追加することでスケーリングが可能になることです。

アジャイル技術と実践についてチームメンバーを指導する

When they first start to adopt Agile techniques and practices, some teams decide to hire external coaches. Coaches may even work with multiple teams to help remove organizational roadblocks and silos, so they often have both teaching and managerial skills. They can also train team members in Agile techniques such as how to run stand-up and review meetings. Over time though, it's important for team members to develop an ability to mentor each other. This means that most work should be done collaboratively and not by individuals who spend most of their time working alone.

アジャイルのテクニックやプラクティスを採用し始めると、外部のコーチを雇うことを決めるチームもあります。コーチは、組織の障害やサイロを取り除くために複数のチームと一緒に仕事をすることもあるので、指導と管理の両方のスキルを持っていることが多いです。また、コーチはチームメンバーにスタンドアップミーティングやレビューミーティングの運営方法などのアジャイルテクニックをトレーニングすることもできます。しかし、時間が経つにつれて、チームメンバーがお互いを指導する能力を身につけることが重要になってきます。これは、ほとんどの仕事は、ほとんどの時間を一人で過ごす個人ではなく、共同で行うべきだということを意味しています。

チーム内およびチーム横断のコラボレーションを可能にする

If collaboration is the key to becoming successful at Agile, what are some of the ways you can encourage it? Here are some ideas.

アジャイルで成功するためにはコラボレーションが鍵だととしたら、それを奨励する方法は何かありますか?いくつかのアイデアをご紹介します:

文化の変化

When changing a culture, keep a few things in mind. It's important that team members have a quiet, comfortable place to work. They need spaces where they can focus, without a lot of distractions and noise.

カルチャーを変えるときには、いくつかのことを心に留めておきましょう。チームメンバーが静かで快適に仕事ができる場所を確保することが重要です。気晴らしや騒音のない、集中できるスペースが必要です。

Meetings are a fact of life and they can feel like they take over a person's working life. To give team members more control, meetings need an agenda and strict time frames.
Asynchronous communications, such as email and messages, can feel overwhelming and people often feel they have to be answered right away. Make it clear that not all of these communications need an immediate response.

会議は生活の一部であり、人の仕事人生を支配しているように感じることもあります。チームメンバーがよりコントロールできるようにするためには、会議にはアジェンダと厳格な時間枠が必要です。
メールやメッセージのような非同期のコミュニケーションは、圧倒されてしまい、すぐに返事をしなければならないと感じてしまうことがよくあります。これらのコミュニケーションのすべてがすぐに返事が必要なわけではないことを明確にしましょう。

Remote team members are now the norm in many companies. Everyone needs to feel comfortable with all their team members and to treat them equally, whether they're in the office or working offsite. Collaboration via communication should become part of the organization's DNA.

今や多くの企業では、リモートチームメンバーが当たり前になっています。誰もがすべてのチームメンバーを快適に感じ、彼らがオフィスにいてもオフサイトで仕事をしていても、平等に扱う必要があります。コミュニケーションを通じたコラボレーションは、組織のDNAの一部になるべきです。

The importance of good communication can't be overemphasized, even when there are disagreements. Conflict resolution is a good skill for any Agile team to have.

意見の食い違いがあっても、良好なコミュニケーションの重要性を強調しすぎることはできません。紛争解決は、どんなアジャイルチームにとっても持っていて損はないスキルです。

機能横断的なチーム

Just as it's important for team members to work collaboratively, it's also important for teams to collaborate with each other. Cross-functional teams add new skills and perspectives that can broaden everyone's ability to solve challenges creatively. Cross-functional teams also make the entire organization more cohesive. They reduce turf wars and increase the sense that everyone is working toward a common goal.

チームメンバーが協力して仕事をすることが重要であるように、チームにとってもお互いに協力し合うことが重要です。機能横断的なチームは、新しいスキルや視点を追加し、全員が創造的に課題を解決する能力を広げることができます。機能横断的なチームはまた、組織全体の結束力を高めます。縄張り争いを減らし、全員が共通の目標に向かって仕事をしているという意識を高めます。

コラボレーションのためのツール

Good tools can help your Agile team members collaborate more effectively, both within the team and with other teams. Here are a few suggestions to help you get started.

良いツールは、チーム内でも他のチームでも、アジャイルチームのメンバーがより効果的にコラボレーションするのに役立ちます。ここでは、あなたが始めるのに役立つものをいくつか紹介します。

Microsoft Teams. This is an application that provides a workplace for chat, meetings, notes, and file storage.
Skype. Skype is easy to use and a good general-purpose tool. Many people have it already installed.
・Slack. Slack provides many separate communication channels, all from a single interface. These can be organized in many ways, such as by project, team, or topic. Conversations are retained and are searchable. It is very easy to add both internal and external team members. Slack directly integrates with many third-party tools, like GitHub for source code.

  • Microsoft Teams チャットや会議、メモ、ファイル保存などの作業場を提供するアプリです。
  • Skype Skypeは使いやすく、汎用性の高い良いツールです。すでにインストールされている方も多いと思います。
  • Slack Slackは多くの個別のコミュニケーションチャネルを提供しており、そのすべてが単一のインターフェースから提供されています。これらのチャンネルは、プロジェクト別、チーム別、トピック別など、さまざまな方法で整理することができます。会話は保持され、検索も可能です。社内外のチームメンバーを簡単に追加することができます。Slackは、ソースコード用のGitHubのような多くのサードパーティ製ツールと直接統合しています。

Other common tools include Google Hangouts, Asana, Trello, GoToMeeting and monday.com. Try to familiarize yourself with the options to see which of them suit the needs of your team and your company.

その他の一般的なツールには、Google Hangouts、Asana、Trello、GoToMeeting、monday.comなどがあります。どれがあなたのチームや会社のニーズに合っているかを確認するために、これらのオプションに慣れ親しんでみてください。

mappie-kochi.hatenablog.jp