kkamegawa's weblog

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

VSTS/TFSでAgile/Scrumテンプレートどちらを選べばいい?

はじめに

世界のやまさがこんなことをつぶやいていました。

確かにさもありなんということで、ちょこっとまとめてみます。VSTSおよびTFSでプロジェクトを作るとき、プロセステンプレートの選択があります。

  • Agile
  • Scrum
  • CMMI

VSTSではこの三種類以外のプロセステンプレートを作ることはできません。TFSでは独自のテンプレートを作ったり、不要であれば削除したりすることもできます。詳細はCustomize a process templateを見てください。既存の項目を追加/削除するだけであれば、VSTSでも可能です。詳細はこちらを見てください。

kkamegawa.hatenablog.jp

CMMIはちょっと性格が違うので、のぞくとScrumかAgileになります。この二つは非常によく似ていて、どちらを選ぶのか悩ましいと思います。個人的な考えですが、どっちでもいいです。しいて言えばMicrosoftから出る各種サンプルではScrumを選んでいるように見えるので、いちいち読み替えなくていいからScrumを選ぶというのでもありです。

チームの設定を行う画面の用語としては歴史的な事情(Scrumのほうが後に用意された)ということもあり、Sprintではなく、Iterationで統一されているようです。

注意:この記事ではVSTS/TFSでのテンプレートの説明をするものであり、開発プロセスそのものの説明ではありません。「スクラムとはこうだ」という話ではありませんので、ご注意願います。

docs.microsoft.com

docs.microsoft.com

テンプレートの注意点

現在において、ScrumとAgileのテンプレートを相互に行き来することはできません。「継承された」テンプレートには移行できます。例えば、Scrumから継承してInheritScrumというテンプレートを作ると、ScrumからInheritScrumへの移行は可能ですが、ScrumからAgileや、Agileを継承した

テンプレートで定義されている項目の違い

https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/agile-process-work-tracking-wits.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/scrum-process-work-tracking-wits.png?view=vsts

左がAgile, 右がScrumです(引用:docs.microsoft.comより)。ScrumとAgileの違いは、Product BacklogがUser Storyになっていることくらいです。ここだけなら正直読み替えても何ら変わりません。

作業項目クエリ

https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/ic667910.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/ic665405.png?view=vsts

同様に、左がAgile, 右がScrumです(引用:docs.microsoft.comより)。デフォルトでチーム内の共有クエリで準備されているものがちょっと違いますね。これも作ってしまえばだいたい同じものにできるので、大した差ではありません。

Scrumでは「現在のスプリントで何をするか」という点にフォーカスしたクエリが用意されています。AgileではIteration中の作業の状態にフォーカスしたクエリが用意されているように見えます。

ワークフロー

docs.microsoft.com

docs.microsoft.com

f:id:kkamegawa:20180622121501p:plainf:id:kkamegawa:20180622121502p:plain

左がAgile、右がScrumのそれぞれUser Story, Product Backlogを作ったときの初期設定です。Story PointとEffortは大体同じと思っていただいて構いません。どのくらいの作業量かという相対値になります。この値をちゃんと入力しておくと、ベロシティの値を計算してくれて、バーンダウンチャートに反映されます。

Priorityはどちらもありますが、RiskのみAgileにあります。要はこのUser Storyを実現するためのリスク予想ですね。数字が小さいほどリスクが高いです。Scrumにはありません。

Acceptance Criteriaとは受け入れ基準です。どうなっていればこのバックログ/Storyが完了したとみなせるか、というところを書きます。

作業ワークフロー

https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/alm_pt_agile_wf_userstory.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/agile-bug-workflow.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/alm_pt_agile_wf_task.png?view=vsts

AgileのUser Story, Bug, Taskのワークフロー。

https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/alm_pt_scrum_wf_pbi.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/alm_pt_scrum_wf_bug.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/alm_pt_scrum_wf_task.png?view=vsts

ScrumのProduct Backlog, Bug, Taskのワークフローです。実際のカンバンではApproveの中にさらに分割するといったこともできますし、カスタマイズすればもっと多段階にできますが、最初はやらないほうがいいでしょう。ちなみにVSTS開発チームではNew/Approve/Commited/Doneだけではなく、さらに2-3段階追加して、さらにdo/doneに分割しているそうです。

Approve, Commited, Active, Resolvedといった用語を入れ替えればまぁ大体同じと考えていただいてもいいと思います。

Taskの差

f:id:kkamegawa:20180622121503p:plainf:id:kkamegawa:20180622121504p:plain

左がAgile、右がScrumでタスクを作ったときです。パッとわかる違いとしては、Agileには時間を記入するところがあります。Original Estimateは当初の見積もりですね。

Completed Workは完了までの時間。Remaining Workは見積りとの差異となります。

追跡単位

https://docs.microsoft.com/en-us/vsts/user-guide/_img/features/alm-feature-new-work-item-widget.png?view=vsts https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/_img/scrum-new-work-item-widget.png?view=vsts

左がAgile、右がScrumで新規作成するときに選べる差です。Impediment, Product Backlog, issueの有無がわかると思います。Impedimentは「障害」という意味ですね。Ryuzeeさんのすばらしい解説があるので、どうぞ。

まとめ

どちらを選んでも致命的な違いはなく、どちらでもいいのですが、テンプレートとしてみた場合、Agileはイテレーション中のタスク管理という面にフォーカスしていて、Scrumはタスクそのものの質を分析しようとしているのではないかなと感じます。

最初はAgileでやったほうが、作業時間を見たい管理職の人には受けるのかもしれませんね。

Visual Studio Team Services(VSTS)の新しいナビゲーションUI変更

UI変更

VSTSのUIは建て増しを続けていたこともあって、非常にわかりづらいものになっていました。特に管理系の機能を呼び出すUIに関してはしばしば「どこにあったっけ?」と思う始末でした。

ほかにも各機能へのナビゲーションが少しやりづらかった。

そこで、昨年からFluentデザインを取り込んだUIの刷新に取り組んでいたようです。こちらでどんな違いがあるのか紹介されています。

New Navigation for Visual Studio Team Services – Microsoft DevOps Blog

前のUIよりは今どきなって使いやすくなっているんじゃないかなと思います。試してみてください。

変更方法

f:id:kkamegawa:20180620055246p:plain

有効にするにはPreview Featuresから"New Navigation"をONにしてください。New Navigationを有効にすると、自動的にいくつかの新機能も有効になります。

トップページ

f:id:kkamegawa:20180620055247p:plain

トップページがこんな感じでフラットになります。新規プロジェクトを作るときは + からさくっと(作成時のUIは変わらないようです)。

チームプロジェクト

f:id:kkamegawa:20180620055244p:plain

チームプロジェクトを開いたところ。プロジェクトのトップページは変わりません。あくまでもナビゲーションUIの見た目だけ変わってるようです。

VSTSのロゴをクリックすればいつでもトップページに戻れます。

f:id:kkamegawa:20180620055245p:plain

Work Itemもこんな風に新しいUIの中に統合されます。

f:id:kkamegawa:20180620055243p:plain

アカウント設定だけはなぜか昔から日本語になってますw。

疑問点

いくつか疑問があると思います。知ってることで言えば。

APIのエンドポイント変わるの?

変わらないはずです。

タブとかハブに組み込む拡張機能どうなるの?

動きます。言ってみれば今まで画面上部にあったUIの場所と見た目が変わっただけなので、従来のタブやハブに組み込むSDKに影響はないはずです。

TFSにも適用されるの?

TFS 2019(時期未定)にも入るそうです。

クライアント Dev Day関西とInsider Dev Tour Tokyoを開催

connpass.com

insiderdevtour.com

土曜日に大阪でクライアント Dev Day、日曜にInsider Dev Tourを東京で実施いたしました。参加していただいたみなさん、スタッフの皆さん、スピーカの皆さん、ありがとうございました。

最初は大阪でもやるつもりだったのですが、諸般の事情で中止になってしまったので、その代わりといってはなんですが、Windows 10クライアント向けの自主イベントに振り替えさせていただきました。少々少人数でしたが、いろいろ聞けて非常に勉強になりました。

日曜のInsider Dev Tour東京は二日前くらいに参加人数がぐっと増えて、しかもいままでこのような開発向けイベントに参加されてないと思われる方がたくさんお見えになったようで非常にびっくりしました*1

実は最初に英語でもお誘いのメールを出していた*2のですが、やはり直前の日本語でのメールは効果が大きかったようです。

Q&Aコーナーでもたくさん(答えにくい)質問をいただきました。やっぱり将来のロードマップは気になるところですが、本社の社員であっても知らないことは多いので、「ごめんなさい」的な回答しかできなくて申し訳なかったです。

セッションスライドやキーノートは公開されないのか、というお問い合わせもあったようですが、我々が著作権を持っていないので、一存では公開ができません。

代わりに、今回のセッションに関するラボで一式そろっていますので、ぜひ興味のあるものを試してみてください。

*1:個人のダメFace APIによる検出なので、間違っているかもしれません

*2:ローカル開催スタッフはこの手のメールの配信に関与していないのです

iPad Pro 10.5インチを買った

三年ほどiPad mini3 64GBモデルを使っていたのですが、Kindleの本が多くなりすぎて残り500MBという攻防が続いていて疲れたので、買うことにしました。

iPadとiPad Proで悩んだのですが、やっぱり決め手はいくつかあって。

  • 256GBストレージ
  • Apple SIM内蔵(まぁ弱いけど)
  • 4スピーカー
  • 液晶快適

売り文句のスペックにまんまと乗ってます…。買ってみて気づいたのですが、やっぱり3年ほどの進歩はすごいですね。今までMVNOの回線が遅いから読めないと思っていたオンデマンド(事前ダウンロードできない)マンガアプリの画面表示がすごく早くなってます。コンテンツの暗号化(難読化)行われているはずで、今までのiPad mini3だとコンテンツ復号にCPU使いすぎてたんですかね。

画面もぬるぬるでKindleのページめくりもめちゃくちゃスムースです。うーん、これは買ってよかったなぁ。いつも通りフィルムも貼ったんですが、今回は気が向いてグレアのものにしてしまいました。明るい液晶をそのまま使うかな、と。電源がオフになっている状態では自分の顔が映りこみますが、Kindleとかアプリ開いている状態では特に気にならないので、これはこのままでいいかな。

Apple SIM使いたいので、セルラーモデル買いました。これで次シアトルいく時、いちいち物理SIMに差し替えなくてもいいから楽になりそうです。