こんにちは。 AZPower クラウドサービス開発本部 森です。
先日、Microsoft資格試験 AZ-400:Designing and Implementing Microsoft DevOps Solutionsを取得しました。
せっかくですので、これらの取得の際に作成した学習リソースを共有したいと思います。
長期にわたっての記事となりますので、大変ですがお付き合いのほどをよろしくお願いします。
なお、この前の記事は「AZ-400学習リソースを共有します 1-3 [DevOps プラクティスを発展させる –ソフトウェア開発のアジャイルアプローチを選択する]」です
AZ-400 とは
AZ-400は開発プロセスで必要となるさまざまなツール(簡単にいうとAzure DevOpsとGit, VSCodeあたり)やプラクティスの知識を持っていて、Azureの管理・開発に精通しているということを試される試験です。
そのため、受験資格としてAZ-103, AZ-104(Microsoft Azure Administrator)またはAZ-203, AZ-204(Developing Solutions for Microsoft Azure)の資格を保有している必要があります。
AZ-400とMS Learn
私がAZ-400の取得に活用したのが、MS Learnです。
簡単にいえば、こちらを一通り覚えておけば、取得できるのではないかと思います。
ただ、2020年8月6日時点でAZ-400のラーニングパスにある記事はすべて英語でした。
そのため、この学習リソースを利用するには少しハードルが高いこともあり、資格取得の学習のため、これらをすべて翻訳しました。
翻訳は専門ではないので、微妙な翻訳になっているかもしれませんが、ご容赦のほどを…。
あと、記事中のリンクは記事のソースと同じになるように設定しましたので、リンク先は英語の記事になっています。
加えて、本家の記事では解説記事の最後に知識確認のためのテスト問題が出題されるのですが、この部分に関しては翻訳していません。（勉強用のリソース以外でしたので…）
現在のラーニングパス
2020年8月11日時点で確認したところ、AZ-400用ラーニングパスが新しく更新されていました。
こちらは古いラーニングパスに基づくコンテンツですが、内容が古くなっているということはないので引き続き投稿しています。
DevOps プラクティスを発展させる
DevOpsとは、エンド ユーザーに対する価値を継続的に届けることを可能にする、人、プロセス、製品の総称です。
その価値の継続的デリバリーに必要なツールを与える一連のサービスがAzure DevOpsです。
Azure DevOpsを利用すれば、あらゆるアプリケーションをビルドし、テストし、クラウドまたはオンプレミスにデプロイできます。
透明性、共同作業、継続的デリバリー、継続的デプロイを可能にするDevOpsプラクティスは、今後のソフトウェア開発ライフサイクルとして広がることでしょう。
このラーニング パスでは、DevOpsの旅を始めることになります。 このチュートリアルの内容は次のとおりです。
- 現在のプロセスとテクノロジを評価する場合に利用する、Value Stream Map(バリュー・ストリーム・マップ）がどのように役立つかを確認する
- Azure DevOps Organizationに無料でサインアップする
- Azure Boardsを使った作業項目の計画および追跡方法を学習する
- 複数のアジャイル チームにわたるスプリント ワークロードの最適化
チーム間でアジャイルソフトウェアの配信計画を管理する
チームにおける作業計画の可視性を向上させることで、デリバリー効率を最適化する方法を学びます。
このモジュールでは、以下のことを学びます。
- デリバリープランによって、複数のチームが作業を計画、スケジュール、調整できるようになる方法を学びます。
- Azure DevOps projectsにDelivery Plans 拡張機能をインストールします。
- デリバリープランを作成し、チームのスプリント作業量を調整してデリバリー効率を最適化します。
Introduction
Azure DevOpsは、チームが開発プロセスをスケールアップして、大きく野心的なプロジェクトを実現するために役立ちます。
Tailspin Toysチームに再び参加して、組織が成長する際に直面する共通の問題に取り組んでみましょう。
一緒に、複数のチームにまたがる仕事のスケジュールを効果的に管理するために必要なことを発見しましょう。
あなたは、この学習パスの最初の段階で、テールスピン・トイズのチームに会いました。
前のモジュールでは、彼らがAzure Boardsを使って仕事のスケジュールを管理し始めた様子を確認しました。
すぐに、彼らの初期の成功の言葉が広まり始め、今では他のチームも同じメリットを享受する方法を模索しています。
より多くのチームがAzure Boardsを採用するようになると、組織は一貫したプロセスを中心に計画を統合することによるネットワーク効果を実感し始めます。
かつてはビジネスを行う上でのコストとして書き捨てられていた問題が、今では達成可能な解決策を手に入れることができます。
チームが組織を進化させていく様子を見てみましょう。
このモジュールでは、以下のことを学びます。
- デリバリープランによって、複数のチームがどのように作業を計画、スケジュール、調整することができるかを学びます。
- Azure DevOps ProjectsにDelivery Plans 拡張機能をインストールします。
- 配信計画を作成し、チームのスプリント作業量を調整して配信効率を最適化します。
前提条件
このモジュールは段階的にラーニングパスを構成しています。
そのため、このモジュールに取り組む前に、Evolve your DevOps practicesのラーニングパスから始めることをお勧めします。
このモジュールだけを行いたい場合は、Azure DevOps Organizationをセットアップが必要になるので、Get started with Azure DevOps を実施してください。
開発チームと再開
あらためて、以前のモジュールでも登場した、Tailspin ToysのSpace Gameウェブチームを紹介しよう。
開発リードのアンディ
開発者として入社したばかりのマーラはアンディの部下です。
マーラはDevOpsの経験があり、Azure DevOps を使用してチームがより合理化されたプロセスを採用するのを支援しています。
デリバリープラン(Delivery plans)とは？
開発組織が成長するにつれ、分割された作業単位を効率的に管理できるように、より小さなチームに再編成する必要があります。
これらの個々のチームは通常、組織の大きな目標の中で、それぞれのニーズを満たすそれぞれの作業スケジュールやボード、その他のプロセスを持つことになります。
時間が経つにつれて、一貫性のあるフレームワークの周りにプロセスを統合することで、ネットワークのメリットを享受できることに気づくかもしれません。
デリバリープランは、1つまたは複数の作業スケジュールを可視化したものです。
これは、各チームがいつ、何を生産するかを全体的に見ることができるように、チームと経営陣に提供することを目的としています。
これにより、組織全体の投資を最適化するための意思決定を行うことができます。
自分たちの作業スケジュールが他のチームのスケジュールと一致していることを確認するために、チームが定期的にデリバリープランを見直すことが重要です。これらのレビューでは、次のような質問をする必要があります。
現在のスケジュールで約束したことを確実に実現できるか？
私たちが依存しているチームは、現在のスケジュールで必要なものを提供できると確信しているか？
我々のスケジュールの中には、我々が仕事で埋めることができる小康状態があるのか？
デリバリープランは、プロジェクトのライフサイクルのどの時点でも価値を付加します。
チームのバックログに基づいて動的に生成されるので、常に最新の情報が得られ、最新の洞察を提供します。
Tailspinのウェブチームのディスカッションに参加してみましょう。
アンディ: さっき、エンジニアリング管理者との素晴らしい会議ができました。
私はAzure Boardsで行っている作業をデモしましたが、みんな、Azure Boardsを利用して作業を始めるようです。
マーラ: すごいですね。では、彼らはいつから始めそうですか？
アンディ: それがすぐにわかるところがいいですよね！
昨晩、ゲームエンジンプロジェクトのリーダーが、いくつかのスプリントを持つチームを作り、Work Itemを追加し始めました。
今朝、ざっと見てみましたが、うまくいっていますね。
彼らが何をしようとしているのか、お見せしましょう。
アンディはゲームエンジンの現在のスプリントボードに移動します。
アンディとマーラは興味深く彼らのWork Itemを確認します。
アンディ: うーん…今気づいたんだけど、彼らはこのスプリントの終わりまでにベータ版をデプロイする予定はないみたいだね。
次のスプリントの間にリーダーボードをベータデータベースに統合することを期待していないのでしょうか？
彼らが先にベータ版をリリースしてくれないと、実現できないんだけど･･･。
マーラ: それはするどい指摘ですね。
私たちは、そのチームが成果物を作ることに依存して、自分たちの成果物を作ることができます。
アンディ: これは次のスプリントの生産性に大きなダメージを与える可能性があります。
何が起こっているのか、彼らに電話をして確認してみます。
残念ながら、より洗練されたチーム構造では、コミュニケーションのギャップやラグが生じることがあります。
あるチームがブロックされると、別のチームが頼りにしている何かを生み出すことができなくなるかもしれません。
これは、関係者全員が毎日ミーティングを行うような少人数のチームにとっては、大きな問題ではないかもしれません。
しかし、チームの規模や場所が大きくなればなるほど、どこで何が起こっているのかを全員が知ることができなくなってしまうこともあります。
この時点で、組織は純粋な「プッシュ」モデル（対面やメールでのアナウンスなど）から「プル」モデル（チームがお互いのスケジュールを確認したり追跡したりできる）に移行する必要があります。
アンディ: さっき、開発者のリードと話をしました。
彼女は、アートチームがCliffchellaから戻るまでベータ版の出荷をブロックしていると言っていました。
マーラ: CliffchellaってThe mountaintop音楽祭のこと？
アンディ:そう、デザイン業界では大盛り上がりのイベントらしいのですが、チーム全員が参加するためにまる一週間休暇を取っているそうです。
ゲームエンジンチームは、予定が3週間遅れてしまったので、かなり動揺していました。
彼らはそれが来ることを知っていたなら、前もって必要な成果物を手に入れるようにしていたでしょう。
また、このことをもっと早く知らせなかったことを謝罪してくれました。
彼らは、私たちがベータ版の出荷を待っているとは知らなかったのです。
マーラ: 少なくとも、ゲームエンジンチームがスプリントプランを公開してくれているのは不幸中の幸いですね。
この依存性の問題を早期に発見して、スケジュールを調整するのに役立ちました。
アンディ: 私はただ、これらの潜在的なリスクをもっと簡単に把握する方法があればいいのにと思っています。
私たちのチームは会社全体で多くの依存関係を抱えているので、すべてのミーティングに出席したり、すべての配信グループに参加したりすることはできません。
マーラ: チームのスプリントを横に並べて見ることができるように、配信計画を作成すべきです。
そうすれば、両方のチームが、自分たちのスケジュールがお互いにどのように影響しているかをより簡単に把握することができるようになります。
そして、このような調整に便利なAzure DevOpsの拡張機能があります。
複数のアジャイルチームを管理するための推奨事項
アジャイルなアプローチは、Azure DevOpsとともに、プロジェクトの透明性と予測可能性を大幅に向上させることができます。
しかし、プロジェクトは、人員やミスコミュニケーションに関連した従来の課題に直面することもあります。
ここでは、アジャイルの取り組みをスケールアップする際に考慮すべきことをいくつか紹介します。
人とプロセスの信頼を築く
アジャイル導入の早期には、チームのパフォーマンスを向上させることができるのか懐疑的になることが多くあります。
組織内のオピニオンリーダーが、ツールやプロセスがどのように結果を生み出すかを示すことで信頼を築くことが重要です。
その結果が生産性の向上である場合もあるし、定量化するのは容易です。
しかし、回避可能なスケジュールのずれや品質問題などの潜在的な問題を回避することで得られるチームの勝利を強調することも忘れてはいけません。
人々が利益を達成したプロセスと関連付けるようになれば、あなたはより多くの熱意を得ることができます。
チーム(および個人)の上の組織を高めなさい
新しいプロセスやポリシーが提案されると、一部のチームや個人は縄張り意識を持つようになります。
新しいポリシーが特定のチームや個人のパフォーマンスを否定的にさらけ出していると考えるのではなく、組織全体の新しい透明性がどのように期待されているかを全員に伝えることを強調しましょう。
誰もが自分の仕事が組織の目標達成にどのように関係しているかを追跡できる場所を一箇所に持つことで、プロセスへのコミットメントの重要性を再認識させることができます。
透明性の文化を醸成する
残念なことに、「透明性」という言葉は悪い意味で使われています。
すべてがうまくいっているときに、誰ももっと透明性を求めません。
その代わり、チームが苦戦しているときには、透明性（または透明性の欠如）が非難されることがよくあります。
アジャイルチームに与えられたすべての透明性の機会があっても、それは個人とチームの正直さに左右されます。
透明性の理由の1つは、手遅れになる前に潜在的な問題を特定して対処できるようにすることであることを強調してください。
誰もが、スケジュールの締め切りに間に合わない状況に陥ることがあることを理解しています。
しかし、可能な限り最後の瞬間まで失望したニュースを報告することに安心感がなければ、それははるかに破壊的な影響を与える可能性があります。
透明性のある快適なレベルを築くには、予想される遅延を可能な限り早く報告してくれた人々に感謝することから始めることができます。
デリバリープランって何？
Delivery PlansはAzure DevOps用の拡張機能で、組織が複数のチームにまたがって作業スケジュールを計画し、レビューするのに役立ちます。
Tailspinチームはこの拡張機能を使用して、自分たちの作業が他のチームが作成する作業とどのように関連しているかを把握します。
マーラは、チームのAzure DevOps組織にDelivery Plansをインストールしました。
その後、彼女はデリバリープランを作成し、自分のチームとゲームエンジンチームのスプリントを追加しました。
その可能性に興奮した彼女は、アンディを招いて簡単なデモを行いました。
マーラ: 前回の会話の後、私はデリバリープランを管理するための方法がないか調べたところ、Azure DevOps 拡張機能を見つけました。
アンディ：それは気になりますね。
ベータスリップについては組織全体でストレスがたまっているので、スケジュールの効率を改善するためにできることは何でも大歓迎です。
マーラ: こちらです。
マーラ: デリバリープラン拡張機能では、「デリバリープラン」を作成できます。
一度作成したら、組織内のチームのバックログを追加できます。
各チームがカレンダーを背景に何を納品するかを確認できるように、並行して表示されるようになっています。
アンディ: これは素晴らしいですね。
これで、頼りにしているものがいつ間に合わないかがわかります。
また、他の作業や依存関係のあるチームがどれくらいの量の仕事を引き受けているかに基づいて、遅延の可能性を評価することもできます。
これで、チーム間でときどき見られる「スケジュールチキン」となる行動を軽減するのに役立つはずです。
注意
スケジュールチキンとは、2つ以上のチームが納期に間に合わないリスクにさらされているとき、いずれのチームもそれを認めたくない状態となります。
その際、いずれかのチームが先にスケジュールをずらしてしまうのを待って、他のチームがそれを口実にして自分達のチームの納期を遅らせてしまうことを指した用語です。
どちらが先にスケジュール遅延を切り出すかということをチキンレースに例えています。
マーラ：そうですね、他のチームが頼りにしているスケジュールをずらしてしまうことがあったら、それを他のチームに知らせる方法としても利用できます。
そうすることで、人とプロセスの信頼を築くことができます。
アンディは同意してうなずく。チームがお互いをもっと信頼し合えるようになるといいですね。
アンディ: さて、ベータ版の遅延がわかったので、関連する作業を将来のスプリントに移さなければなりません。
いい面もありますが、それに代わる新しい作業を引っ張ってくる機会を与えてくれます。
統合作業をこの2つのリーダーボードのバグと入れ替えてみましょう。
マーラさんは統合作業の項目を次のスプリントに移動させてください。
そして、2つのリーダーボードにあったバグを、今回のスプリントの利用可能な作業容量を埋めるために再び引き込みます。
マーラ：マイルストーンとして、現在のβ版の日付も入れてみました。
これで、私たちが計画している作業の基準点として、常に手元に置いておくことができるようになりました。
アンディ: Cliffchellaや年に一度の会社のパーティーのようなイベントも追加すべきですね。
マーラ: なぜ会社のパーティーを？
スケジュールに影響がありますか？
アンディ: 影響するかもしれません。
毎年DBAはパイ食いコンテストに参加しているのですが、翌日にはみんな病欠の電話をしてしまいます。
今年もそうなることを期待しているわけではありませんが、準備はしておくべきだと思います。
そして、そのためのツールを手に入れたしね。
Exercise – Set up your environment
ここからは、このモジュールの残りの部分を完了するために、Azure DevOps organizationの設定方法を確認します。
この目的を達成するために、以下を行います。
- このモジュールの Azure DevOps プロジェクトを設定します。
Azure DevOps プロジェクトを取得する
ここでは、このモジュールの残りの部分を完了するために、Azure DevOps organizationが設定されていることを確認します。
Azure DevOps でプロジェクトを作成するテンプレートを実行して設定します。
この学習パスのモジュールは、進行の一部です。あなたは、Tailspin ウェブチームの DevOps journeyを通して、彼らの作業方法を体験します。
今回の学習のために、各モジュールには関連するAzure DevOps プロジェクトを使用します。
テンプレートを実行する
Azure DevOps organizationを設定するテンプレートを実行します。
Azure DevOps Demo Generatorのサイトで、以下の手順に従ってテンプレートを実行します。
- サインインを選択し、使用条件に同意します。
-
[新規プロジェクトの作成]ページで、Azure DevOps 組織を選択します。つづけて、Space Game – web – Delivery plans などのプロジェクト名を入力します。
- Create Projectを選択します。
テンプレート作成の実行完了までしばらく時間がかかります。 -
Navigate to projectを選択して、Azure DevOps のプロジェクトに移動します。
重要
このモジュールの Clean up your Azure DevOps environmentページには、重要なクリーンアップ手順が含まれています。このモジュールを完了していなくても、クリーンアップ手順に必ず従ってください。
Exercise – Delivery Plansを利用してsprintを計画する
ここではデリバリープランを作成し、Azure DevOpsでスプリントを計画するために使用します。
Tailspinチームは、Delivery Plans拡張機能がどのように機能するのか確認しようとしています。
彼らはすでにAzure DevOpsでスプリントを設定した2つのチームを持っているので、作業スケジュールを見直して最適化することができるようになりました。
ここでは、以下の作業を行います。
- Delivery Plans 拡張機能をインストールします。
- デリバリープランを作成します。
- チームのスプリントとマイルストーンを追加します。
- 全体のスケジュールに合わせて作業項目を再配置します。
Marketplaceよりextensionをインストールする
Delivery Plans Marketplace拡張機能は、デリバリープランの作成と管理に必要な機能を提供します。
Azure Boardsと統合して、作業計画を立てる際にシームレスな体験を提供します。
- 新しいブラウザタブから、marketplace.visualstudio.com にアクセスします。
-
Azure DevOpsタブに切り替えて、”Delivery Plans”を検索します。
-
結果から”Delivery Plans”を選択します。
- “Delivery Plans”を選択し、遷移先のページで”Get it free”を選択します。
-
ドロップダウンボックスから導入対象となるAzure DevOps organizationを選択します。
-
Installをクリックします。
デリバリープランを作成する
Delivery Plansを追加すると、Azure Boardsに新しい”Plans”タブが追加されます。
組織のさまざまな側面を管理するために必要な数だけデリバリープランを作成することができます。
- Azure DevOps から、プロジェクトに移動します。
-
Boardsの下にある “Plans” を選択します。
-
New Plan をクリックします。
-
表示されたフォームにある以下のフィールドを入力します。
- Name: Space Game Delivery Plan
- Team: Space Game Web Teamを選択, Backlog levelでBacklog itemsを選択します。
- Add team でSpace Game Engine Team を追加し、Backlog levelをBacklog itemsを選択します。
- [Create]を選択します。
注意
このモジュールのために生成されたチームプロジェクトは、この学習パスの他のモジュールで使用されているBasicプロセスではなく、Scrumプロセスを使用します。
Basic プロセスが Issues を使用するのに対し、Scrum プロセスは Backlog 項目を使用しますが、このモジュールの目的では機能的には同じです。どちらのプロセスでもデリバリープランを使用することができます。
### schedule milestone markersを追加する
マイルストーンマーカーは、デリバリープランに参照ポイントを追加できます。
これらは、重要な日付のマーキングや他の日付のコンテキスト内で作業を計画するのに役立ちます。
- Configure plan settingsの歯車をクリックします。
- Markersタブから Add markerをクリックします。
-
表示されたフォームの以下のフィールドを入力します。
- Dateには本日の日付から1週間後の日付を選択します。
- LabelはCliffchellaと入力します。
- ColorはRedを選択します。
- 続けてAdd markerをクリックし、以下のマーカーを追加します。
- Bata：本日から5週間後の日付を選択し、青を設定します。
- 会社の懇親会：本日から6週間後の日付を選択し、緑を設定します。
入力が完了したらSaveをクリックします。
- デザインプランの上部にある青いマーカーを選択します。拡大して、ベータ版のマイルストーンを表していることを示します。
作業スケジュールの最適化
- Webチームの作業項目の[Integrate with beta DB]がEngineチームの[Push beta]が完了する前にあります。この作業項目はそのbetaが完了することに依存しているため、問題になります。
-
この統合作業項目をSprint 3からSprint 4にドラッグして、その依存関係が利用可能になるようにします。
-
この変更により、Sprint 3の作業容量の空きが大幅に広がります。その時間が他の作業に使えるようになったので、Sprint 4から2つのFix作業項目をSprint 3にドラッグして戻します。
これで最終的なスプリント計画は、次のようになります。
あなたは、組織に意味のある形で影響を与える貴重な仕事を完了しました。
経営陣は、予見可能な遅延なく作業が進むことに自信を持つことができます。
また、依存関係のある仕事の納品を待つのではなく、チームは常に生産性の高い仕事を引き受けることができます。
確かに、状況の変化に応じて状況は変化するかもしれませんが、少なくとも今では誰もが最新の情報を得るためにどこに行けばいいのかを理解できるようになります。
Exercise – Clean up your environment
これでこのモジュールのタスクは終了です。ここではAzure DevOps環境をクリーンアップします。
Optional – Delete your project
このモジュールは、モジュールのクリーンな環境を作成するために実行するテンプレートを用意しました。
ここでは、Azure Boards にあるものも含めて、Azure DevOps プロジェクトを削除します。
今後のモジュールでは、このモジュールが終了した状態で新しいプロジェクトを起動する別のテンプレートを実行することができます。
ただし、今後このDevOps プロジェクトが必要ない場合は、以下を実施します。
プロジェクトを削除するには
- Azure DevOpsで、プロジェクトに移動します。前の手順でこのプロジェクトにSpace Game – web – Delivery plansなどの名前を付けました。
-
このプロジェクト名の横にある歯車のアイコンをクリックします。
アイコンは、プロジェクト名が表示されている領域の横にマウスポインタを移動しないと表示されない場合があります。
- [Project details]をスクロールした下部にある[Delete] を選択します。
- 表示されたウィンドウで、プロジェクト名を入力し、再度Deleteをクリックします。
これでプロジェクトが削除されました。
まとめ
このモジュールでは、Tailspinチームは、ソフトウェアデリバリーに関する一般的な組織における課題に取り組み、それらをより良く処理するためにプロセスを適応させました。
Azure DevOpsで学んだことの中には、次のようなものがあります。
- Delivery Plans拡張機能をインストールする
- デリバリープランを作成する
- チームのスプリントとマイルストーンをデリバリープランに追加する
- 全体のスケジュールに合わせて作業項目を再配置
ラーニングパスのまとめ
おめでとうございます。あなたは、DevOps実践を進化させる学習パスの最終モジュールを完了しました。
この学習パスでは、以下のことを学びました。
- バリュー・ストリーム・マップが、既存のプロセスとテクノロジーの検証にどのように役立つかを理解しました。
- DevOps とは何か (そして何ではないか) を理解し、Azure DevOps organizationを作成しました。
- Azure Boards がどのようにチームが必要な作業を計画するのに役立つかを学びました。Basicプロセスを使用して、今後のモジュールで作業するタスクの基本的なBacklogを設定しました。
- 複数のアジャイルチームにまたがるスプリントワークロードを最適化する方法を学びました。
旅を続ける
チームが最優先の問題を特定しているのを見てきましたが、どのように解決していくのでしょうか？
チームと一緒に作業し、アプリケーションを継続的にビルド、テスト、検証するビルドパイプラインの構成方法を学びたい場合は、 Azure DevOps でアプリケーションをビルドする を参照してください。
Azure DevOps の周りで自分のペースで実践的な学習をするには、Azure DevOps Labsが利用できます。
さらに学ぶには
このモジュールでは、複数のチームにまたがって作業スケジュールを管理する際に、デリバリープランがどのように役立つかに焦点を当てました。しかし、スケールでプロジェクトを調整する際には、考慮すべきことがたくさんあります。
チーム階層、プロジェクトポートフォリオ管理、ダッシュボードなど、チームプロジェクトをスケーリングするために Azure DevOps が提供するその他の機能の詳細については、計画 (アジャイル・アット・スケール) を参照してください。
