開発キックオフ時にマネージャが行うべき

１１のことVisual Studio Online & TFS 使い始めと HOME 画面の構成

1

ソフトバンク・テクノロジー株式会社（シニアエンジニア）古賀慎一

2015年3月版

Copyright© 2015 Shin-ichi Koga All Rights Reserved.

実務で Visual Studio Online(VSO)・TFS を使う時

最初に何をすればいいの？とりあえず使ってみたいんだけど

2

キックオフミーティングを省いてはいけない様に

実務で VSO・TFS を使うなら

省いてはいけないことがあります

3

キックオフに間に合わせよう

このスライドのゴール

※本スライドの対象者は プロジェクト・マネージャ、リーダー、あるいはその候補者

VSO・TFS を使い始める具体的な準備 のイメージを持つ

少人数での練習が出来るようになる

自社案件でVSO・TFSを「とりあえず」採用しても失敗しない

十分に準備してキックオフをむかえよう！4

Visual Studio Online / Team Foundation Server

アジェンダ：最初にやるべき１１のこと＋１

1. VSO・TFSプロジェクトの作成

2. Welcomeページの作成

3. イテレーション期間の作成

4. Current クエリの修正

5. 構成管理（分岐）の初期準備

6. チェックインポリシーの設定

7. VSプロジェクトの作成・分岐

8. 自動ビルド・自動テストを構成

9. クエリの作成とチャートの表示

10.ユーザーの登録

11.チーム開発開始

☆スプリントが終了したらやること

5

1. VSO・TFSプロジェクトの作成新しい開発のための Team Foundation Server を用意する

6

練習用に TFS を用意しましょう！

いきなり本番の VSO・TFS でプロジェクト用の準備をするのは危険です

練習のためのクラウド VSO かオンプレTFS を用意

リーダーだけで無く、メンバーが慣れるためにも

新規案件の TFS とは別に、自由に使って試せる TFSを用意しましょう

このスライドでは新たに VSO を使うシナリオで説明します 7

Visual Studio Online / on-premises Team Foundation Server

VSOアカウントを作成

「アカウント = URL サブドメイン部分」つまり１サイトが作られます

https://TfsAccountName.visualstudio.com/

※既に名前が使われていたら、もちろん作れません

https://visualstudio.com/ にアクセスして「無料アカウントを今すぐ作成」

※ 5名まで無料で使えます

※ MSDNユーザーは何人でも無料で使えます 8

本番用サイトでは練習したくない

TFSプロジェクトを検討

アカウントの下に複数プロジェクトが作れます

https://TfsAccountName.visualstudio.com/

ProjectName1・・・案件１用

ProjectName2・・・案件２用https://TfsAccountName.visualstudio.com/DefaultCollection/ProjectName/

VSOではオンプレと違ってプロジェクトコレクションは増やせません（※DefaultCollection の１つだけ）

9

どう分けるか？練習しながら決めよう！

TFSプロジェクトを３つ以上作ろう

開発プロセステンプレートを選択して TFSプロジェクトを作成

３種類、それぞれ作って練習に使いましょう

10

※テンプレートの違いはこのスライドを参考に

スクラム開発を始めよう！TFS を使った日常コミュケーションとチームワーク

http://www.slideshare.net/shinichikoga355/102-ver4

この名前は TFSアカウント（プロジェクトコレクション）内で重複しなければ使えます

2. Welcomeページの作成READM.md ファイルにキックオフ資料の内容を記載して共有し続ける

11

HOME - Overview と Welcome の役割

最初のページ Overview は

現在を「見える化」するダッシュボード 隣の Welcome ページはこの TFS の「使い方やルール」を示す

12

README.md ファイルをソース管理直下に追加

作成は README.md をテキストで作るだけ

Markdown 構文（Wiki 形式）

以下のサンプルをテンプレートとして使ってください

TFS Project Welcome pages（README.md）とチェックインポリシーに指定する静的コード分析ルールセットhttps://code.msdn.microsoft.com/Welcome-pagesREADMEmd-75566110

13Welcome ページに何を記載するか？

Welcome ページに載せるべき内容は

キックオフ資料の内容です

14

キックオフ資料のアジェンダ例

プロジェクトの目的

システム概要

プロジェクトの日程・コスト

プロジェクト体制

プロジェクトメンバーの自己紹介

プロジェクト管理方法

レポーティングシステム

各種会議体

Q&A

15

プロジェクト・マネージャの「やってはいけない」

［計画編］キックオフ・ミーティングを省いてはいけない より引用http://itpro.nikkeibp.co.jp/article/COLUMN/20080523/303900/

オープンソース README.md の役割も参考に

何が出来るのか？

どうやって使うのか？

どうやって参加するのか？

ライセンスは？

Document

Ticket

Deploy

Test

16

SOTA

わかりやすいREADME.mdを書く より引用

http://deeeet.com/writing/2014/07/31/readme/

キックオフ資料と同等の情報をいつでも誰でも

最新の情報で「見える化」しておくことが Welcome ページの役割

社外向けの内容：お客様がそうだと思っている事

社内向けの内容：開発メンバー全員がそうだと思っておくべき事

開発スコープ・体制などに変更があったら、キックオフ資料を更新して共有しますよね？

そのときに Welcome (README.md) も更新します

17

途中参加者に古い資料を渡していませんか？

3. イテレーション期間の作成スクラム開発でもウォーターフォールでも、開発期間を明確に示す

18

タスクの期限はイテレーション期間で扱う

実はバックログ・タスクには

期間（期日）がない

イテレーション期間の子供

＝期間内に終わらせる

「スクラム開発を始めよう！

TFS を使った日常コミュケーションと

チームワーク」３５ページを参照

http://www.slideshare.net/shinichikoga355/102-ver4 19

クエリで「現在の○○」を取得するために必要

標準で共有クエリに登録されているクエリ

現在のアクティブなバグ, タスク・・・

を取得するための条件として

「イテレーション期間」が使用されます

20

Shared Queries

Iteration Path

お奨めは Current / Future / Past 内に @001

Current / Future / Past を作成

Future 内に @001 から連番で作成

（数ヶ月分、あるいは全期間分作ります）

現在の期間を Current の内に移動

（最初は @001）

※イテレーション期間は HOME の

Configure schedule and iterations... を押して設定 21

必要があれば土日を開発可能な日に変更する

イテレーションの設定より先

に変更しましょう

（※デフォルトだと土日を避けて、

日付の候補が自動入力されるため）

完了見込みの計算にも使用されます

22

※管理者で（右上の歯車のアイコン）を押して Control panel に入り、Team Name のリンクをクリック、

Members が表示されているので、隣の Settings をクリックすると変更出来ます

期間は一定、ウォーターフォールならフェイズ

ウォーターフォールならフェイズ（WBSの大・中項目）に合わせます

アジャイル・スクラム開発では１週間～３週間の固定

個人の趣味の開発であれば「月毎」にするのもおすすめです

入力した期間よりも先の期間を作成するのを忘れないために、Outlook 繰り返し予定を作成しましょう

23

4. Current クエリの修正いつでも「現在」のタスクやバグが「見える化」されていること

24

クエリのイテレーションパスを指定を親に変更

標準では ProjectName＼Release 1＼Sprint 1 特定の期間が指定されている

25

ProjectName＼Current に変更

Current の子が変更されても

（@001から@002になっても）

常に「現在の○○」が取得できる

最初の機能・バックログ・タスク・バグを登録

イテレーション期間に追加

「現在の○○」クエリが動作しているか？確認

「スクラム開発を始めよう！

TFS を使った日常コミュケーションと

チームワーク」36~55ページを参照

http://www.slideshare.net/shinichikoga355/102-ver4

26

5. 構成管理（分岐）の初期準備最初にフォルダを作成して、意図を示しておく

27

お奨めの「分岐」は D・M・P＼@001

ソースバージョン管理では開発用に分岐、リリース用に分岐が必須

28

M : メインブランチ

D＼@001 : 開発用ブランチ

P＼@001 : リリース用ブランチ

マージ ( merge )

分岐 ( branch )

分岐 ( branch )

最新ソースコード（VSO・TFSで自動ビルド・自動テスト）

リリースに使うソースコードリリース毎に新しいブランチ

開発するソースコード

名前はなぜ M や D＼@001 がお奨めか？(1)

分岐のパスは、そのまま Visual Studio の作業フォルダに

（C:\users\UserName\FolderNameが先頭に追加され、さらに bin\Debug 内にビルドされる）

パスが長いとビルド出来ない

ビルド出来ても Azure 発行が出来ない事がある（一時生成ファイルの名前が長い）

ビルドサーバーでのビルドや、Release Management でリリース出来ない事がある

パスは出来るだけ短くしておきたい

M/SolutionName ⇒ P/@001/SolutionName 29

名前はなぜ M や D＼@001 がお奨めか？(2)

「自由に名前をつけて良い」とするとわかりにくい

TFS や Visual Studio で ABC 順に並ぶ画面が多く、新旧がわかりにくい

人によって名前の付け方が違うと何の開発か？わからない

命名規則を作らなければならない

イテレーション期間と同じにすると時期がわかりやすい

（D\@001 が何の開発だったか？は、WORK でバックログ・タスクを見ればわかる）

30

M全体を分岐するのがお奨め

Mの中にソリューションフォルダを作成

M全体を D＼@001 や P＼@001に分岐

メリット

サブフォルダを分岐すると、親フォルダ全体でマージできない

操作回数が少なくてすむ、分岐漏れ・マージ漏れを防げる

コード分析ルール（RuleSets）など相対パスが維持しやすい（※後述）

31

TFS Project Name

BuildProcessTemplets

D

@001

@002

@003

@003-2

M

Solution Name

Solution Name

P

@002

@004

Solution Name

RuleSets

RuleSets

RuleSets

なんとしても最初に D・M・P フォルダを作成

一番最初に M を作っておかないと、

ソース管理直下にソリューションが乱立して、

全体を１回で分岐できなくなる

リリース事故のリスク

分岐フォルダとソリューションフォルダが混ざって名前順に

一度に分岐・マージできないので漏れが起きる

相対パスのずれによる事故 32

TFS Project Name

BuildProcessTemplets

Solution Name1

RuleSets

Solution Name2

Solution Name3

Solution Name4

最初の D・M・P を作成して、サンプルの分岐を

まず最初にM・D・Pフォルダを作成

Mの中にサンプルソリューションを作成

M全体を D＼@001 と P＼@001に分岐

コード分析ルールセットも分岐（※後述します）

ソースバージョン管理について、最初にこれだけは絶対準備しましょう！

33

TFS Project Name

BuildProcessTemplets

D

@001

M

Solution Name

Solution Name

P

@001

Solution Name

RuleSets

RuleSets

RuleSets

6. チェックインポリシーの設定メモリーリークするソースコードを VSO・TFS にチェックインさせない

34

静的コード分析を有効にすれば

メモリーリークなど重大なバグを防げる

スペルミスや名前の付け方のバラツキによる誤解や事故を防げる

わかりやすい設計が身につき、バグが起きやすい構造や開発工数が減る

その代わり、最初にちょっと勉強しなければならない（抵抗がある）

守らない人がいると、警告がいわゆる「オオカミ少年」になってしまう

どうやってチームに根付かせるか？

35

チェックインポリシーで強制できる

チェックイン前にコード分析必須

チェックインコメント必須

タスクとの関連づけ必須

ソリューションに含まれないファイルはチェックイン出来ない

「TFS Project Welcome pages（README.md）とチェックインポリ

シーに指定する静的コード分析 ルールセット」参照

https://code.msdn.microsoft.com/Welcome-pagesREADMEmd-75566110 36

最初にチェックインポリシー違反の検知を！

ソースコードがある程度チェックインされた後から追加は困難・無理

ビルド出来ない、修正が膨大、無視するのが横行する（言い訳しやすい）

最初にチェックインポリシーを必ず設定する

チェックインポリシー違反（オーバーライド）の検知

チェックインポリシーは、緊急時にコメントを入れれば無視してチェックイン出来る

無視されたらメールが送信されるように設定を（※前述URL 最後を参照）

37

7. VSプロジェクトの作成・分岐構成管理・チェックインポリシーが機能しているか？

38

チェックインポリシーが動作しているか？

Mの中にソリューションを作成（※前述のもので可）

プロジェクトにチェックインポリシーを適用

パスは ..\..\..\RuleSets\CheckInPolicy.ruleset

３つ上がって RuleSets フォルダに入った中のファイル

ビルドしてチェックイン出来ることを確認

39

TFS Project Name

BuildProcessTemplets

M

Solution Name

RuleSets

D

P

Project Name

Visual Studio Project

CheckInPolicy.ruleset

ルールセットを D・P直下に分岐しておく

RuleSetsを D＼RuleSets と P＼RuleSets に分岐

M・D・P どのプロジェクトからも同じ相対パスで

チェックインポリシーファイルが見つかる

ルールセットを先に分岐しておかないと、D・Pでは

Visual Studio が勝手に直下の RuleSets のファイルを見つける

Mにマージするときに相対パスがずれて、無用なマージが発生

（このマージを間違えると M の自動ビルドに失敗する）

40

TFS Project Name

BuildProcessTemplets

D

@001

M

Solution Name

Solution Name

P

@001

Solution Name

RuleSets

RuleSets

RuleSets

構成管理は妥当か？発行やリリース手順を試す

M・D・P にアクセス出来るユーザーを制限することができる

ユーザーの作成は後述。ここでは他のユーザーになったつもりで試してみる。

Pからのリリースを試験

Azure に Webサイト・クラウドプロジェクトを発行

いわゆる「Hello World 」をリリースできるか？確認

他に必要な社内向けの手順書・チェックリストを準備

41

ここでリリース出来ないと

完成後も・・・

8. 自動ビルド・自動テストを構成単体テストをどこまで作るか？議論するには効果を「見える化」する必要がある

42

サンプルを実行・壊して効果を実感しよう

単体テストをどこまで作るか？

VSO・TFSで毎日ビルド・テストするか？

まず、サンプルを登録して

効果を見ながらディスカッション！

「TFS・VSO・ローカルで動作するデータベースを使った単体テス

トの作り方・量産方法」参照

https://code.msdn.microsoft.com/TFSVSO-dc7b8c9d

43

単体テストをどこまで作れるか？

単体テストは約10年前から普及

NUnit, Visual Studio 標準機能

テスト駆動開発は普通の作り方

デスクトップアプリをF5デバッグしながら作るのと同じ

もはや「無し」では開発出来ない

ただしメンバーのスキルと慣れに依る

強制すると返ってスピード・質を落とす人も 44

自動ビルド・自動テストをどこまで実現するか？

自動ビルド・自動テストを設定すると

開発者のローカル PC でしか動作しないコードが発見できる

バグはテストしていないのではなく「テストしたが他の環境で動かない」方が多い

難しいクリーンなDBでテストするライブラリ・サンプルを用意

「TFS・VSO・ローカルで動作するデータベースを使った単体テストの作り方・量産方法」https://code.msdn.microsoft.com/TFSVSO-dc7b8c9d

Surviveplus.UnitTestPlushttps://www.nuget.org/packages/Surviveplus.UnitTestPlus/ 45

VSO自動ビルドは無料枠を超えると有料

前述のサンプルを作るために５日で１ヶ月の無料枠を使い切りました

チェックインの度にビルド・テストを実行する

「ゲートチェックインビルド」では無料枠は全く足りません

通常のプロジェクトでは、変更後のみの日次ビルドでも足りないはず

有料枠を使う、あるいは、週次でビルドするなどの検討が必要

46

高くはないですがお金を使うので

マネージャの仕事ですね

ビルド・テスト結果を HOME Overview にピン

自動ビルドを設定したら、ビルド定義の Pin to homepage

ホームに結果を「見える化」

ビルドに失敗したら自動的に「バグ」が作成されるように設定することも可能

対応するフローも決めておきます

47

9. クエリの作成とチャートの表示誰がどれだけ働いているか？グラフで見えれば「やる気」スイッチを押せる

48

HOME – Overview に表示出来るもの

タスクの進捗バーンダウン（標準）

ビルド結果

作業項目（バックログ・タスク・バグ）のクエリ結果数とそのグラフ

テスト結果数とそのグラフ

標準の操作、最初に表示される How to

49

クエリできればチャートをホームにピンできる

WORK Queries のチャート TEST テストスイートのチャート

50

細かいことですが・・・

クエリ結果が 0 件の時も（エラー画面ではなく）

可愛いイラストが表示されるようになりました

51

実は重要！

ブロークン・ウィンドウにしない！

ブロークン・ウィンドウ理論では

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」※Wikipedia より引用

HOME に「日次ビルド」が失敗している結果が毎日ずっと表示されていれば

このプロジェクトはバグっていていいんだというメッセージになる

タスクが進捗し、ビルドは毎日成功し、テストも消化されるプロジェクト

管理の「見える化」だけではなく、チームのモチベーションを考えよう

52

Broken Windows Theory

10. ユーザーの登録十分に準備が出来てからメンバーを招待する

53

ここまで準備してからユーザーを追加します

管理者の追加・変更

開発者の追加

ステークホルダーの追加（出来ないことの確認）

前述までの準備が「守っている事」や「意図」を伝える前に触らせない

54

管理者（オーナー）にはユーザーアカウントを

マイクロソフトアカウントは、長期間サインインしないと消えます

Windows Azure は課金に関わるユーザーが消えると、

その瞬間に環境が消えるようです

（VSOで試したことはありませんが Azure 上で動作しているので同じかもしれません）

管理者（特にオーナー）にするマイクロソフトアカウントは、

毎日サインインして使っている開発者ユーザーのアカウントにしましょう

専用アカウントを作ってしばらく使っていないと、数年後に環境ごと全部突然消えるかもしれません 55

開発者をサンドボックスにも招待しましょう

最初に３種類、練習用の TFSプロジェクトを作成

自分の練習が終わったら、開発者をサンドボックスに招待して

使い方を説明しましょう

サンドボックス（砂場）＝自由に使って壊しても問題ない環境

HOME Overview や Welcome ページにフィードバックをもらいましょう

56

ステークホルダーでは Welcome が見られない

Welcome は README.md の閲覧権限 = ソース管理が見られないと

表示されないみたいです

ステークホルダーライセンスは HOME Overview はみられますが

ソースコードは見られません = Welcome が見られない

今後バージョンアップで改善されるかもしれませんが、確認が必要です

57

11. チーム開発開始最初の数週間

58

さぁ！

いよいよチーム開発開始です

59

フル機能は使わなくて大丈夫

ここまで準備していれば、使えるところから使っても

問題になりません逆に準備しないで使い始めると、後からはどうしようも無くなって「TFS 使えねぇ」になるかも

60

最初のタスクの割り当て・見積もり・作業開始

最初のイテレーション期間では、

「ベロシティによる予測」など

絶対にわからないことがあります

何週間かチームで経験しないと

わからないことを確認します

「スクラム開発を始めよう！TFS を使った

日常コミュケーションとチームワーク」参照

http://www.slideshare.net/shinichikoga355/102-ver4 61

開発者は「担当作業」から作業開始の流れを

Visual Studio チームエクスプローラの「担当作業」

自分に割り当てられたタスクを開始できます

担当作業でタスクを「開始」し、開発出来たら

保留中の変更と共に「チェックイン」して完了します

実は「中断」も出来る優れもの

Visual Studio の作業中の内容を全て一時保存し、

別の作業をして、また戻ってくることが出来ます 62

Team Explorer My Work

Suspend

スプリントが終了したらやること未完了のタスクを処理して翌営業日の朝を迎える

63

イテレーション期間 Current を @002 に変更

現在の期間を Current に移動

Feature＼@002 から

Current＼@002 に

直前の期間を Past に移動

Current＼@001 から

Past＼@001 に

64

イテレーション期間に終わらなかったタスクは？

必ず終わらせます

完了にして、次のイテレーションに新しいバックログ・タスクを作成する

全く着手していない場合は移動しても可

一部着手しているときは、分割したことがわかる名前をつけて分割する

期間中は「バーンダウンチャート」で進捗している事を確認

期間終了時は、必ず残り作業が 0 で終わるようにする

65

残りタスクを放置すると

チームのベロシティ（１期間にこなせる作業量）がわからなくなる

実績を次の見積もりに活かすために、この範囲は全部終わった、とする

メンバーが、何が完了して何が完了していないか？確認・判断する必要

完了していないものは次期間に移っていることで判断不要

区切りなくダラダラと作業することが蔓延するなど、「壊れた窓」になる

「なんだ TFS 使えねぇ」はタスクの放置から始まります66

意図を理解したメンバーで運用・維持する

翌朝（次のイテレーション期間の最初）に、

HOME Overview が誰が見てもわかりやすい綺麗な状態になっていること

タスクの完了・分割・移動など地味に作業がある

VSO・TFS の使い方の意図を理解したメンバーで運用する

初めてソースバージョン管理を導入したときと同じ：「なぜフォルダコピーじゃダメなんですか？」

効果を全員が感じられるまで、工夫して使い続けよう 67

Appendix補足資料

68

単体テストとスライドで取り扱わなかった TEST

単体テスト（C#コードでメソッドをテスト）

テストケース・テストスイート（手動テスト, テスト結果の記録）

コード化された UI テスト（画面操作の自動テスト -テストケースの手動の代わりに）

ロードテスト Web（簡単なWeb負荷テスト）

ロードテスト Visual Studio（シナリオを想定したWeb負荷テスト）

ラボ（手動テスト・コード化されたUIテストを仮想PCで実行しやすくする） 69

Unit Test (※ Visual Studio では単に Test とも）

Test Case, Test Suite

Coded UI Test

Load Test (※Simple Load Test という表記も)

Load Test with Visual Studio

Lab Management

チームルーム (Team Room) とは

Lync, Skype, LINE, Facebook チャット, SMS などのテキスト会話と同様

VSO・TFS サイト上でチャット出来る

記録目的ではなく（過去の会話を探すのは少し難あり）

遠隔地でのとっさの会話に使用を想定

Lync（Skype for Business) が使えない場合に使うと良い

VSO・TFS プロジェクト用の他、作成も出来る

70

ソフトウェア構成管理の教科書

IT Architects’ Archive―ソフトウェア開発の課題

パターンによるソフトウェア構成管理

http://goo.gl/2yF1N1

2006年出版で VSO/TFS を含む最近のツールについては

全く触れられていませんが、ソフトウェア構成管理の

考え方・基礎知識を勉強できます。お奨めです。

「何となく分岐・マージしている」人は是非一読を 71

担当作業からチェックインの流れと「中断」

Visual Studio Ultimate 2012:

担当作業での複数タスクの処理方法

http://goo.gl/s5nouX

「中断」の説明のビデオですが、

担当作業からタスクを開始し、

チェックインするまでの作業の流れ

を実感することが出来ます。72

使用したサンプル・ライブラリ・スライド

スクラム開発を始めよう！TFS を使った日常コミュケーションとチームワーク

http://goo.gl/NpUfRi

TFS Project Welcome pages（README.md）と

チェックインポリシーに指定する静的コード分析ルールセット

http://goo.gl/7mrcw0

TFS・VSO・ローカルで動作するデータベースを使った単体テストの作り方・量産方法

http://goo.gl/RStNCw

Surviveplus.UnitTestPlus

http://goo.gl/g2n2fX 73

Plus Programming .net 勉強会

http://www.facebook.com/PlusProgramming.net

74