kkamegawa's weblog

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

Azure Boards - カンバンの高度な設定

はじめに

Azure Boardsのカンバンを標準のまま使ってもいいのですが、多くのバックログを管理するとか、もうちょっとこう言う感じで使いたいなと思うときがあると思います。カンバンの設定を使えばより便利になります。

初期状態

f:id:kkamegawa:20200420061258p:plain

カンバンを一か所以外特にいじっていない状態です。右上の歯車アイコンをクリックすれば詳細設定画面が表示されます。歯車の隣のアイコンはカンバンを全画面表示させます。モニターとかに出してみんなで見るときに便利です。

Fields

f:id:kkamegawa:20200420061303p:plain

たくさん並んでいますが、最初はFields設定です。私は必ずShow IDにチェックを付けてます。これでバックログにタスクのIDが表示されるようになります。バックログ、Bugそれぞれに同じ設定があるので、BugのShow IDもチェックします。私は作業用のブランチをこのIDで作っているので、ブランチとも結びついています。

Fieldは表示させたいField(例えばArea Pathなど)を追加すると、カードに追加表示されます。また、追加したFieldはカード上で直接編集ができるようになります。

個人的なおすすめとしてはWork Itemをカスタマイズして、Due Date(対応期日)を記入させるようにしておいて、このボード上に表示させておけば期日からどのくらい遅れているのかわかりやすくなります。

後述する色変える機能でも似たことはできます。

Styleでカードの色を変える

f:id:kkamegawa:20200420070104p:plain

これはちゃんと覚えておくと非常に便利だと思います。カンバン上のカードの色を特定のルールに基づいて変更します。カンバンを毎日見ていれば気づくかもしれませんが、あまりに多いと「これちゃんとやってたっけ?」と見落としてしまうこともあります。管理職が「Excelで状態が変わった一覧がほしい」とかいうのがこの辺の理由ですね。

そういう時、Styleでカンバンのカードの色が変わるルールを作っておきます。Rule criteriaに変更するルールを指定して、Stylingに色、書式を指定します。

ここではChanged Date@Today - 7未満を指定しているので、「今日から7日前以上に変更した」(つまり7日以上何も動いていない)タスクをえんじ色背景、白抜き文字で表示させます。

f:id:kkamegawa:20200420061313p:plain

すると、条件に一致するタスクがこんな風に変わります。@Todayなどの値はWIQLと同じマクロが使えるので参考にしてください。

docs.microsoft.com

タグの色付け

f:id:kkamegawa:20200420061318p:plain

Work Itemにタグを活用している方は便利だと思います。タグで色付けしてるとわかりやすいですね。

カンバンに列を追加する

f:id:kkamegawa:20200420061323p:plain

ScrumやAgileのテンプレートで作った場合、4列のカンバンができます。ただ、会社のプロセスによってはもう一段階増やしたい、ということもよくあります。

そういう時はColumnで列を増やせます。また、既定では一つの列に格納可能なWIP Limit(WIP=Work In Progress)は5までですが、チームによってはここを変更させることで上下可能になります。

「WIPが5しか入らないから列を増やせばいいんだ!」とかにはならないようにしてください。また、なんでもかんでもApprovedに突っ込めるようにWIPの値を大きくするようなプロジェクトはたぶん終わってます。充分な経験のあるコーチの指導を受けたほうがいいと思います。

参考までに、GitHubのProjectではルールに基づいてこの列の間をバックログが移動しますが、Azure DevOpsの場合Doneへの移行以外は自動移行しません。

GitHub Projectの場合、既定ではルールで移行するので、逆に4列以上増やすのが難しいです。列に関してはやたらと増やしても混乱するだけなので、最初はいじらないほうがいいでしょう。

しかし、列は増やしたくないけど、受け入れ前後を区別したい、という要求があると思います。そんな時はSplit column into doing and doneをチェックします。

f:id:kkamegawa:20200420061329p:plain

Approvedにチェックしたので、ApprovedがさらにDoingDoneに分割されました。例えば仕様のレクチャーを受けているときはDoing、レクチャーが終わったら(Approvedの)Doneに移行させる、という運用をすればプロダクトオーナーと開発者の齟齬がなくなることが期待できます。

同様にCommitedでも開発者が開発中、開発が終わった(受け入れ待ち)時もCommited列のSplit column into doing and doneをチェックして分割すれば今受け入れ中なのかどうかわかりやすくなります。

たくさんあるバックログをグループ化したい

f:id:kkamegawa:20200420061333p:plain

結構大きいチームだけど、一つのカンバンで見たい、でもごちゃごちゃして大変…という場合があります。そんな時はSwimlanes(プールなんかでコースを区切ってるあれ)を使います。

上の+をクリックすると、レーンの追加ができます。好きな名前でいいですが、グループ化したいようなまとまりがわかる名前がいいでしょう。

f:id:kkamegawa:20200420083658p:plain

作成すると、カンバンがこんな風にSwimlanesで分割されます。作る場合のわかりやすい例としてはこんな感じでしょうか。

  1. Area Path単位に分割する
  2. ビジネスインパクトが高いものを分割する
  3. 遅れ気味のものを分割する

カンバンのレベルを追加する

f:id:kkamegawa:20200420061338p:plain

Backlogsの設定でカンバンに表示させたい管理レベルを選択できます。これはScrumテンプレートなので、Epic, Features, Backlog Itemsの三段階で初期状態はBacklog Itemsのみです。

Featuresもカンバンで見たい場合はFeaturesにチェックを付けます。

f:id:kkamegawa:20200420061342p:plain

するとこんな風にカンバンの管理レベルを切り替えられます。

初期状態でも十分使えるAzure Boardsですが、さらに設定を工夫すればもっと使いやすくなるので、ぜひ活用してみてください。

Azure DevOps 2020/4/13の更新

Azure DevOps Sprint 167のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

コロナウィルスの影響で4/7まで機能開発を停止していたとのことなので、いつもよりも一週間リリースが延びましたね。久しぶりにそこそこ量がある機能追加になりました。

GitHubのissueをAzure Boardsに転記するActionをリリースしたそうです。これは便利というかなんというか…今までもMSの中でTFVCがメインで、issue管理は内部が正みたいな環境だった時代、GitHubであげられたissueは適宜botが転記していたはずですが、Action使って同じようなことができるという感じですね。Googleも一部はGitHubは交流用で、内部では別管理してるとかそういう運用してるはず。

Pull Requestのレビューを山盛りしないといけないような人にはフィルタリングは便利だと思います。

今まで承認はClassic Editor(GUIでできるやつ)ではサポートしていたのですが、Multi-stageパイプラインではできませんでした。ようやくサポートするようになったということですね。それに伴いMulti-Stageパイプラインをpreview featureで無効化できなくなっています。これでいよいよ正式版ということなのでしょう。

Artifactsはお金に絡むところなので監査ログも便利ですね。

ではまた三週間後。

Translate to Japanese to Azure DevOps release note ...

GitHub Enterprise CloudのProject初期設定

GitHub Enterprise CloudのProject

Azure DevOpsではチームプロジェクトができたら自動的にカンバンが用意され、チームプロジェクト内に作られたGit, TFVCレポジトリが自動的に管理されます。対して、GitHubではレポジトリ単位にissueで管理、優先順位をもうちょっと俯瞰的に見たい場合はProjectを作るという流れになるようです。

小規模なソフトではともかく、ある程度大きなものや、複数のレポジトリをまたいで管理したい場合、レポジトリごとのissueだけでは困ります。GitHubではorganizationを作って、Projectで管理すればそれぞれのレポジトリのissueを俯瞰してみることができるので便利です。では、ちょっとやってみましょう。今回はGitHub Enterprise Cloudを使っています。

Organizationを作成後、Projectsタブを選ぶとCreate a new projectから作成します。Project templateは四種類から選べます。これはテンプレートなので作った後の変更はできませんが、カードの移動の自動化に関する初期設定なので、列単位で変更できるはずです…たぶん。

f:id:kkamegawa:20200407212557p:plain

Linked repositoriesにorganization内のレポジトリを指定すると自動的にカンバン内でissueがトラッキングされるようになります。

f:id:kkamegawa:20200407212602p:plain

追加したレポジトリにsample issueを作るとopen状態のissueが自動的にAdd cardsに表示されます。

f:id:kkamegawa:20200407212606p:plain

こんな感じですね。チュートリアル的なカードも出ているので、最初はぜひ読んでください。

今回はAutomated kanban with reviewテンプレートで作ったので最初はIn progress, Review in Progress, Reviewer Approved, Doneと4列表示されています。テンプレートによってはもっと少なくなります。

f:id:kkamegawa:20200407212616p:plain

増やしたい場合は、Add a Columnで追加できます。

f:id:kkamegawa:20200407212621p:plain

AutomationにはNone, To do, In progress, Doneから選べます。私が最初に選んだのはAutomated Kanban with reviewersで、これらのタイプがすべて追加されています。なので、None以外を選ぼうとすると

f:id:kkamegawa:20200407212626p:plain

こんな警告が表示されます。今回はTo doを選んでいるので、To doの列を上書きしちゃうけどいい?という確認ですね。新規で一からカンバンを作るときはこのように追加して、自動移動ルールの設定ができます。To doとか名前ではなく、自分の会社のプロセスにあった名前で変えたいと思ったらこの機能で書き換えることになります。

f:id:kkamegawa:20200407212631p:plain

列を使わなくなった時とか、設定変更したいときは…からいろいろ選べます。最初は作ったけど、やっぱりいらないというときはArchive all cardsですべてアーカイブできるようですね。

f:id:kkamegawa:20200407212636p:plain

場所はドラッグ&ドロップで自由に移動できます。

f:id:kkamegawa:20200412120317p:plain

menuをクリックすると、リンクしているレポジトリおよび、このProjectのアクティビティがこんな風に表示されます。

f:id:kkamegawa:20200407212611p:plain

だれがいつどんな変更したかわかりやすくていいですね。

Azure Boardsと比べて

軽く使ってみた感じでは、成果物中心主義のAzure Boardsと比べて、レポジトリの状況を横断で見るためのものって感じですね。Projectはいくらでも作れるのかな。Azure Boardsのクエリとカンバンを足したような形でビジュアライズされている感じですね。

個人で作ってもいいけど、やはりみんなで共有するような感じですかね。Azure Boardsは基本的にはプロジェクト配下のレポジトリに対する管理ってところで違いますね。管理スパンも違うかんじですね。

GitHub Enterprise Cloud使うときは活用していこうと思います。

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 ...