kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure DevOps 2020/3/16の更新

Azure DevOps Sprint 166(と書かれなくなったな…)のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

なんかものすごい小幅な更新ですね…複数organizationの課金が一つのサブスクリプションにまとめられる機能、まだリリースされてなかったんですね…Ignite The Tourでちょっと早まったことを言ってしまった気がする(ごめんなさい)。

今回から下訳に話題のdeeplを使ってみました。Google翻訳やみらい翻訳よりもさらに洗練された文書になってびっくりです。ほとんど手を入れる必要がなくて楽ですね。これからこれ使っていこうかな。

ではまた三週間(?)後。

Translate to Japanese to Azure DevOps release note ...

Azure Boards - 何使えばいいの?

はじめに

Azure Boardsについて、よく聞かれるのが「どれ使えばいいの?」とか「複数行ったり来たりがめんどくさい」という話です。

f:id:kkamegawa:20200315103029p:plain

  • Work Items
  • Boards
  • Backlogs
  • Sprints
  • Queries
  • Plans

(一番下のDependency Trackerは拡張機能なので標準では入っていません)

特にBoards/Backlogs/Sprintsの違いって何よ?と思われるでしょう。どんな使いわけになるのか、簡単に紹介しようと思います。私の主観なので「こんな風に使ってるよ」みたいな話があれば教えてください。

Work Items

f:id:kkamegawa:20200315183233p:plain

Work Itemを作成、一覧で見るための画面です。この画面はおそらくみんなが使う画面で、現在のタスクが一覧で表示されるのでとりあえず見るだけならわかりやすいですね。左上のRecently updatedと書かれているところに複数の選択肢がありますが、これはまた別のエントリーで紹介します。

  • 自分のタスクもしくは自分のアクティビティを見る
  • 関心のあるタスクを見る
  • 自分がメンションされたタスクを見る
  • 直近で変更されたタスク一覧を見る
  • 直近で完了したタスク一覧を見る
  • 直近で作成されたタスク一覧を見る

というように、タスクの扱いにフォーカスした画面です。作成するときやざっくり見るにはいいのですが、今何をしなければならないのかというフォーカスではないので、スプリント中の作業を行うときはあまり見る必要はない画面になります。

CSVを使ったタスクの一括インポートもこの画面からできます。

Boards

f:id:kkamegawa:20200315103038p:plain

チーム単位でBacklog ItemやFeatures単位で切り替えて進捗を確認するための画面です。Backlog Itemから直接タスクやテストの登録ができます。

View as Backlogをクリックすると、Backlogsに遷移します。バックログ単位でどの状況になっているのか、ミーティングでチームごとにざっくりチェックするときに向いていますね。

デフォルトではNew, Approved, Committed, Done(スクラムの場合)ですが、これは増やせます。慣れてきたら分割も検討すればいいと思いますが、具体的な方法は別途解説します。

Backlog

f:id:kkamegawa:20200315103042p:plain

Backlog Itemの状況を見るのはBoards画面でいいのですが、現在のスプリントで何をやるのよとか、次のスプリントで何やるのよという状況確認には不向きです。

それを補うのがこのBacklog画面です。現在のIterationでどのタスクがあるのか、タスクのコスト(タスクごとに作業コストを見積もって入力しておきます)がどのくらいあるのか、次のスプリントはどうなるのか、そしてついでにスプリントの作成といったこともできます。

チームごとで実際に開発作業期間中のタスクを見る場合はこの画面が向いています。

この画面でView as Boardをクリックすると、BacklogからBoardへ遷移します。

Sprints

次はSprintsです。これはIteration(Sprint)単位でのカンバンとなります。おそらく世の中のカンバン形式で表示しているタスク管理ツールと最も似た表現形式です。

f:id:kkamegawa:20200315102950p:plain

最もよく使われるのはこのバックログ配下のタスクの状態を確認するビューでしょう。これはバックログでグループ化していますが、人単位でのグループ化(管理者はこれが見やすいですね)、View Optionsでサイドバーを表示させれば、チームアクティビティがどれだけ残っているか、分類された作業(Development, Test, Documentなど)がどれだけ割り当てられているかという状況も一眼でわかります。

f:id:kkamegawa:20200315102956p:plain

そのサイドバーで誰がどのくらい作業をしているか、チームとしてどのくらい作業を割り当てられるか設定するための重要な項目がこの画面にあるCapacityです。

名前の隣からDays offActivityCapacity per dayです。最初の頃は入れなくてもいいと思いますが、慣れてきてチームとしての作業見積もりを正確にやっていきたいと考えるならば入力をお勧めします。

Days offはそのIteration内で仕事をしない日です。土日は基本考えないので(有効にもできます)、日本で言えば祝日や予定されている休暇などを考えればいいでしょう。個人単位でもいいですが、祝日のように全員必ずいないとわかっている場合は一番下のTeam day offに指定すればチーム全体でのおやすみとなります。

ActivityはIteration内でどの種類の作業を何時間やるか、という枠の設定です。画面では一つのActivityのみ指定していますが、Documentを3、Deploymentを3といったように複数指定も可能です。

Capacity per dayはその作業を1日あたり何時間作業できるか、ということです。1日の労働時間が8時間といっても、実際は会議などがあるので8時間丸々使えることはないので、せいぜい5-6時間というところでしょうか。

Iteration内の1日あたりの作業時間なので、サービスイン直前だからたくさん頑張るという場合は8以上の値を指定しても問題はありません。勤怠とは別ということを忘れずに。

Queries

今まではタスクの表示結果を中心に見ていましたが、タスクが終わったかどうかだけではなく、何日間進捗が出ていないかとか、複数チームにわたってクローズされたタスクの一覧を見たいとかそういう要求は責任者を中心によくあります。

そのような要件で使うのがこのQueries画面で定義する検索クエリです。ここで定義した検索クエリは個人だけではなく、チームで共有して使えます。また作成したクエリはこの画面だけではなく、ダッシュボードのウィジェットのソースとしても使えます。

f:id:kkamegawa:20200315103007p:plain

このようにGUIで検索用のクエリを組み立てます。クエリの構文などはこちらをご覧ください。

docs.microsoft.com

REST APIでもクエリを組み立てて、特定のタスクの抽出ということができます。

f:id:kkamegawa:20200315103003p:plain

作成したクエリは保存して、お気に入りとして登録しておけばいつでも呼び出せます。

f:id:kkamegawa:20200315103012p:plain

保存先は階層で指定できます。

この保存したクエリはOffice Integrationを使ってExcelからの一括登録、編集も可能です。こういうツールを使い始めるとき、必ず言われるのが「Excelで見たいんだよね」ということですが、そういう人にはOffice Integrationをすすめてみてください。Azure DevOpsに接続できるライセンスを持っている方であれば無償で使用可能です。Visual Studioインストールするときにも追加できますが、標準では入らないので、明示的にコンポーネントで追加してください。

Plans

複数のチームが作業しているとき、権限のあるチームであればカンバンを切り替えればどのIterationで何をやっているかというのはわかるのですが、切り替えが面倒です。そういう時に便利なのがPlansです。複数のチームがどのIterationを実行しているか、その中で何をやろうとしているのか、ということがわかりやすいです。

Planは複数作成できるので、視点を変えたり、特定のチームの関連だけ見たいというときは複数作ってください。でもよほどの規模にでもならない限り、一つか二つで充分だとは思います。

f:id:kkamegawa:20200315103021p:plain

新規作成します。名前を付けて、対象のプロジェクト、チーム、バックログのレベルを選ぶだけです。Field Criteriaは歯車アイコンからも設定するのですが、バックログのタスクが多くなるとここで表示するのも大変です。なので、「状態がCommittedになっているもののみ表示する」という設定を行うためですね。また解説します。

f:id:kkamegawa:20200315103025p:plain

こんな風に構築したPlanが一気通貫で見えるようになりました。チームごとに異なるIterationを作っていたとしても、時間軸で何をやるのかわかりやすくなっています。

おまけ:タスクのAnalysis

f:id:kkamegawa:20200315103017p:plain

タスクどのくらいやったか、可視化されるとわかりやすくなります。Analysisでは自分でチャートを作って、貼り付けられます。これは自分の作業を集計したものですが、例えば、チームメンバーがどれくらいタスクを抱えているかとか、今週Doneになったタスクはどのくらいあるのかといった情報が可視化されます。

同じものはDashboardでもQuery Tileというウィジェットで用意されています。

今はBurndown chartやOverviewにあるAnalytics Viewを使ってPower BIでの可視化もできるようになっているので、そちらも活用してください。外部に見せるにはAzure DevOpsのアクセスを考える必要もないので、Power BI使ったほうがいいでしょうね。

終わりに

Azure Boards内にはいろいろ見るビューが用意されていて「どれ使えばいいの?」となりやすいですが、シチュエーション別に設計されているので、実際立場によってつかうものは1-2種類くらいで終わると思います。ほとんどがBacklogsかSprintsでしょう。

うちではこんな活用している!みたいな話があればぜひ教えてください。

Azure Boards - 設定その1

はじめに

Azure Pipelinesに関しては割と書いてくれる人が多いですが、Boardsはそうでもない…と思います。なんとなくというか、スモールスタートのまま使っていてもいいのですが、ある程度規模が大きくなってくるとそうもいかない場面が出てきます。Boardsはとっつきにくいかもしれないですが、大きなチーム規模になってもかなりスケールする作りになっているので、是非活用してほしいと思っています。余すところなく、とはいかないかもしれないですが、もう一段階活用するためにはどうすればいいか、ということでまとめてみます。結構長くなりそうなので(というか、これはKDPの書籍の元ネタにしようかなぁと目論んでいる感じだったりしますが)何回かにわけて書きます。

Azure DevOps Servicesで書いていますが、大半の内容はAzure DevOps Server 2019.1でも適用可能です。

チームプロジェクトとしてのバックログやイテレーション設定

Azure DevOpsのチームプロジェクトを作ると、次はバックログやイテレーションの設定を行います。やらなくても使えることは使えるのですが、Basicプロセス以外の場合、カンバンにバックログが永遠に残ってしまい、かなり賑やかなことになります。「このバックログ終わったのにいつまでも表示されてうざい」ということがないように、面倒ですが最初にしっかりやりましょう。

設定はhttps://dev.azure.com/{organization}/{Project}/_settings/workから行います。

イテレーション

f:id:kkamegawa:20200310213623p:plain (画像内にtypoがあるけど見逃して)

バックログの作業を行うとき、どこの期間で実施するか登録します(いつやるか未定、とりあえず積み上げておくみたいなものもありますが)。この「いつやるか」というイテレーション(スクラムではSprint)を構築します。チームプロジェクトで最初と最後の日付を決めておいて、その配下に子ツリーとして複数階層で構築できます。正直ここのUIなんとかならんのかと思うんですが…。どんどん追加していくと、下にしか出てこないので、長期間やるようなチームプロジェクトだと追加が大変なんです。ここREST APIもなくて結構困ってます。

話がそれましたが、ツリーとして作る場合、二つ考え方があると思います。ひとつは上のように「年」などを上位にして、その配下にイテレーションの具体的な期間を切っていくやり方。もうひとつはざっくりfeature(機能)とかrequirementで作ってしまって、その下にイテレーションを切っていくとか。

前者はカレンダーの通りに切っていくのでみんなにわかりやすいですね。指定の期限までにきっちりタスクを消化していくタイプのプロジェクトだとわかりやすいです。

後者は特定の要求事項でまとめていくのでそこまでやっていくということで区切りがわかりやすくなるかなと思います。特にお客さんからのマイルストーンが提示されているような場合に便利かなと思います。これは開発チーム全体の意向となるので、みんなで合意したほうがいいかなと思います。

ここには載せてないですが、単純にiteration xxでシンプルに一階層だけでいくという方法もありますね。自社のサービスなんかでは便利でしょう。

エリア

f:id:kkamegawa:20200310213627p:plain

次はAreaです。これはちょっと説明が難しいですが、次に説明するチームプロジェクト内のチームにも影響します。ある程度の規模になっていくと、日々生産されるバグやタスクで全体が見づらくなってきます。GitHubではリポジトリとissueが一対一ですが、Azure DevOpsのGitリポジトリの場合一対多の関係になるので、ざっと全件見ると大変なことになります。

それでは困るので、ある程度の単位で分割する必要があります。GitHubのissueにラベルをつけるように、タスクにタグをつけることもできるのですが、それよりは予めAreaを定義しておいて、「このタスクはこのArea」としておく運用が便利です。このAreaは次で紹介するチームに直接紐づけられるので、チームで作業すべきタスクが明確になり、他のチームと混在して表示されることがなくなります。

Areaもイテレーションどうように親子階層が作れるので、特定のチームの中でさらにバッチであるとか、HTML関係の修正であるとかさらに細分化もできます。細分化しすぎるのもよくないですが、しておけばAnalytics Viewを使ってタスク数や負荷状態の可視化にもつながるので、Areaはチームを分割しなくても使うことを意識しておいた方がいいでしょう。

チームとは

前段落まででチーム、という言葉が何回か出てきました。Azure DevOpsでチームプロジェクトを作ると、必ずデフォルトのチームが作られます。おそらく多くの方や使い始めた方はこのチーム一つで運用されていると思います。

その前にチームプロジェクトどういう単位で作ればいいのよ?という話がありますが、これはリリースする単位で作ると考えてもらえればわかりやすいです。リリースする単位の中には単一もしくは複数のリポジトリがありますが、それぞれで依存していることが多いはずです。

リポジトリの閲覧権限はなくても、成果物を共有し、成果物に対するissueやバックログを見て、お互いの進捗状況を確認できるようになっているような関係性が期待されています。

では、チームプロジェクトの中のチームとはなんでしょう。このくらいの開発者や利害関係者であればさほど気にすることはないと思います。

  • メンバーは大体10人くらいまで
  • 全員で開発、運用全てのライフサイクルになんらかの関わりがある
  • 成果物はソース含めてみんな見てもよく、信頼できる
  • みんなで同じビルド/リリース状況を確認したい

問題はこの範囲を超えるような場合です。

  • 10人を超えるような人員がいる(11人だからわけないといけない、ということではないですが、10人超えると多分加速度的に増えていくんじゃないかなと思います)
  • 自然にある程度の開発領域の分割が行われている
  • 利害関係者と開発者は明確にわけたい
  • 独自でビルドやリリース状況を監視しなければならない

ひとつのプロダクトを提供するためのチームではあるものの、あまりに情報が多くなると人間が受け止めるのが難しくなってきます。そういう状況で情報を整理する単位で分担するためのチームを作っていくといいのではないかなと思います。

もちろんできないこともあります。

  • TFVC(Subversionのような中央管理式のバージョン管理)はチームプロジェクトに一つだけなので、複数のチームでも共有
  • チームごとに開発プロセスを変更したい

二番目は特に、「うちのチームはこのテンプレートでは合わないんだよね、うちのチームだけはScrumにちょい足しした開発テンプレート使いたい」なんてことはできません。それはチームプロジェクト全体の設計です。チームは違っても開発プロセスは同じやり方を使う必要があります。

f:id:kkamegawa:20200310213610p:plain

そんなことで、このチームプロジェクトには3つのチームが作られています。新規チームを作るには、右上のNew Teamをクリックします。

f:id:kkamegawa:20200310213617p:plain

チームの名前、追加するメンバー(チームプロジェクトへ事前に追加しておく必要があります。もちろんAzure DevOpsグループを追加しても構いません)、チームの説明(任意)、管理者、権限(Azure DevOpsセキュリティグループなど)を指定します。

最後のCreate an area path with the name of the teamはあとで出てきますが、チームの名前がついたarea pathをこのタイミングで作っておくかどうかということです。これを作っておくとチームが分担する作業がどれかバックログとしてすぐわかり、莫大バックログの中から「うちのチームの作業どれだっけ」と迷子になることを防ぎます。

管理職やプロダクトオーナーの立場ではこのArea path単位で見ることにより、チームがどれくらいのタスクを抱えているのか、どのくらいのバックログを消化しているのかAnalytics Viewで見やすくなります。他のチームと混同しなくてもいいように、最初のうちはチームの名前でArea pathを作るとわかりやすいです。

チームで効率的に作業するための設定

チームプロジェクトでイテレーションとAreaを決めました。しかし、全チームのイテレーションやエリアが見えてしまうとせっかく情報を整理しようとしたのに、全部見えてしまって困ります。

f:id:kkamegawa:20200310213638p:plain

そのようなチームだけが見えればいいバックログを整理するためにTeam Iteration/Areaだけをカンバンに表示できます。やり方はTeamアイコンのIterations and Area Pathsをクリックして、編集します。

チームエリア設定

f:id:kkamegawa:20200310213732p:plain

まずはAreaを設定しましょう。初期状態ではチームプロジェクトのデフォルトで設定されているAreaのみ表示されます。

f:id:kkamegawa:20200310213724p:plain

Select areaをクリックして、チームプロジェクトで登録されているAreaを選択します。複数選択可能です(余計なものが見えてますが気にしないで…)。チームプロジェクトで定義されているAreaから自分のチームの担当のAreaを追加します。なので、チーム作成時に使ったCreate New Teamの画面にあるCreate an area path with the name of the teamにチェックを入れておけば、作ったチームのArea Pathができているので、そのAreaを追加するだけで最初は事足りることが多いです。

イテレーション設定

f:id:kkamegawa:20200310213710p:plain

同様にチーム独自のイテレーションを登録します。デフォルトではチームプロジェクトの最上位のイテレーションが登録されているので、選ぶのも大変ですし、カンバンに表示されるバックログも多くなります。ここでチームのイテレーションを設定しておくことで、カンバンに表示されるバックログの件数を少なくできます。

f:id:kkamegawa:20200310213718p:plain

こんな感じで必要なイテレーションのみ登録すると、カンバンには選択したイテレーションのタスクやバックログのみ表示されます。「新しくバックログ登録したのに、カンバンに表示されない」という場合、バックログのイテレーションをここで登録していないことが原因なので、確認してください。

f:id:kkamegawa:20200310213704p:plain

このDefault iterationはバックログやタスクを作るときに既定で選択されるIterationの値です。スプリントが切り替わったときに管理者がここを切り替えてあげるとタスク作るときに初期状態で選ばれるため、楽といえば楽です。現在のAzure DevOpsではカレンダー上の日付や登録状況から「このイテレーションじゃないかな?」と提案してくれますが、これをやっとくとみんなが楽になります。

おわりに

まずはチームとしての設定編で書きました。次はBoardsのカンバン関係の設定について紹介予定です。

Microsoft Teamsの長いURLをできるだけ短くしたい

独自検証なので、将来にわたってこの仕様が維持されるとは限りません。ご注意を。

以前から思っていたのですが、TeamsのURLって長いんですよね。共有するときも長いんですが、Excelのセルに貼り付けるのも長くて貼り付けられないという相談が来ました。

Teamsクライアントにおいて、リンクをコピーで作成されるURLはこんなのです。

https://teams.microsoft.com/l/message/19:aaaaaaa999999999@thread.skype/11111111111111?tenantId=00000000-0000-0000-aaaa-aaaaaaaaa&groupId=bbbbbb-cccc-dddd-eeee-fffffffff&parentMessageId=11111111111111&teamName=hoge&channelName=channel&createdTime=111111111111

これを貼り付けたくてもExcelのセルに普通にコピペだと250文字くらいまで。VBAを使えばもっと行けるらしいのですがそこまでしたくない。

私も割と困っていたので、公式ドキュメント探してみたのですが、どうもない?最初のメッセージの場合、URLに含まれるparentMessageIdとthread.skypeの次に続くリソースIDがどうも同じようなので、もしかしてこれだけで識別できるのではないかと思ってこんな風に切り出してみたら正解でした。

https://teams.microsoft.com/l/message/19:aaaaaaa999999999@thread.skype/11111111111111

これだけで指定の会話がポイントできました。ただ、いちいち切り取るのもめんどくさいので苦手だけど正規表現書いてみたらこんな感じ。もっといいのがあれば教えてください。

https://teams.microsoft.com/l/message/.*?@thread.skype/[0-9]+

今のところ会話のIDは数値のみですが、もしかしたら英文字が将来はいるかもしれないので、その時は良しなに直してください。

Teamsの拡張機能でこういう短いURLに切り出せるやつ誰か作りません?