1.
開発キックオフ時に
マネージャが行うべき
１１のこと
Visual Studio Online & TFS 使い始めと HOME 画面の構成
1
ソフトバンク・テクノロジー株式会社（シニアエンジニア）古賀 慎一
2015年3月版
Copyright© 2015 Shin-ichi Koga All Rights Reserved.

2.
実務で Visual Studio Online(VSO)・TFS を使う時
最初に何をすれば
いいの？
とりあえず使ってみたいんだけど
2

3.
キックオフミーティングを省いてはいけない様に
実務で VSO・TFS を使うなら
省いてはいけない
ことがあります
3
キックオフに
間に合わせよう

4.
このスライドのゴール
※本スライドの対象者は プロジェクト・マネージャ、リーダー、あるいはその候補者
VSO・TFS を使い始める具体的な準備 のイメージを持つ
少人数での練習が出来るようになる
 自社案件でVSO・TFSを「とりあえず」 採用 しても失敗しない
十分に準備してキックオフをむかえよう！
4
Visual Studio Online / Team Foundation Server

5.
アジェンダ：最初にやるべき１１のこと ＋１
1. VSO・TFSプロジェクトの作成
2. Welcomeページの作成
3. イテレーション期間の作成
4. Current クエリの修正
5. 構成管理（分岐）の初期準備
6. チェックインポリシーの設定
7. VSプロジェクトの作成・分岐
8. 自動ビルド・自動テストを構成
9. クエリの作成とチャートの表示
10.ユーザーの登録
11.チーム開発開始
☆スプリントが終了したらやること
5

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

7.
練習用に TFS を用意しましょう！
 いきなり本番の VSO・TFS でプロジェクト用の準備をするのは危険です
 練習のための クラウド VSO か オンプレTFS を用意
リーダーだけで無く、メンバーが慣れるためにも
新規案件の TFS とは別に、自由に使って試せる TFSを用意しましょう
このスライドでは新たに VSO を使うシナリオで説明します
7
Visual Studio Online / on-premises Team Foundation Server

8.
VSOアカウントを作成
 「アカウント = URL サブドメイン 部分」つまり１サイト が作られます
https://TfsAccountName.visualstudio.com/
※ 既に名前が使われていたら、もちろん作れません
 https://visualstudio.com/ にアクセスして「無料アカウントを今すぐ作成」
※ 5名まで無料で使えます
※ MSDNユーザーは何人でも無料で使えます 8
本番用サイトでは
練習したくない

9.
TFSプロジェクトを検討
 アカウントの下に複数プロジェクトが作れます
https://TfsAccountName.visualstudio.com/
ProjectName1・・・案件１用
ProjectName2・・・案件２用
https://TfsAccountName.visualstudio.com/DefaultCollection/ProjectName/
 VSOではオンプレと違ってプロジェクトコレクションは増やせません
（※DefaultCollection の１つだけ）
9
どう分けるか？
練習しながら
決めよう！

10.
TFSプロジェクトを３つ以上作ろう
 開発プロセス テンプレート を選択して TFSプロジェクト を作成
 ３種類、それぞれ作って練習に使いましょう
10
※ テンプレートの違いはこのスライドを参考に
スクラム開発を始めよう！
TFS を使った日常コミュケーションとチームワーク
http://www.slideshare.net/shinichikoga355/102-ver4
この名前は TFSアカウント（プロジェクトコレクション）内で重複しなければ使えます

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

12.
HOME - Overview と Welcome の役割
 最初のページ Overview は
現在を「見える化」するダッシュボード
 隣の Welcome ページはこの TFS の
「使い方やルール」を示す
12

13.
README.md ファイルをソース管理直下に追加
 作成は README.md をテキストで作るだけ
 Markdown 構文（Wiki 形式）
 以下のサンプルをテンプレートとして使ってください
TFS Project Welcome pages（README.md）と
チェックインポリシー に指定する静的コード分析 ルールセット
https://code.msdn.microsoft.com/Welcome-pagesREADMEmd-75566110
13Welcome ページに何を記載するか？

14.
Welcome ページに載せるべき内容は
キックオフ資料
の内容です
14

15.
キックオフ資料のアジェンダ例
 プロジェクトの目的
 システム概要
 プロジェクトの日程・コスト
 プロジェクト体制
 プロジェクトメンバーの自己紹介
 プロジェクト管理方法
 レポーティングシステム
 各種会議体
 Q&A
15
プロジェクト・マネージャの「やってはいけない」
［計画編］キックオフ・ミーティングを省いてはいけない より引用
http://itpro.nikkeibp.co.jp/article/COLUMN/20080523/303900/

16.
オープンソース README.md の役割も参考に
 何が出来るのか？
 どうやって使うのか？
 どうやって参加するのか？
 ライセンスは？
 Document
 Ticket
 Deploy
 Test
16
SOTA
わかりやすいREADME.mdを書く より引用
http://deeeet.com/writing/2014/07/31/readme/

17.
キックオフ資料と同等の情報をいつでも誰でも
最新の情報で「見える化」しておくことが Welcome ページの役割
社外向けの内容：お客様がそうだと思っている事
社内向けの内容：開発メンバー全員がそうだと思っておくべき事
開発スコープ・体制などに変更があったら、キックオフ資料を更新して共有しますよね？
そのときに Welcome (README.md) も更新します
17
途中参加者に
古い資料を渡し
ていませんか？

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

19.
タスクの期限はイテレーション期間で扱う
 実はバックログ・タスクには
期間（期日）がない
 イテレーション期間の子供
＝期間内に終わらせる
「スクラム開発を始めよう！
TFS を使った日常コミュケーションと
チームワーク」３５ページを参照
http://www.slideshare.net/shinichikoga355/102-ver4 19

20.
クエリで「現在の○○」を取得するために必要
 標準で 共有クエリ に登録されているクエリ
 現在のアクティブなバグ, タスク・・・
を取得するための条件として
「イテレーション期間」が使用されます
20
Shared Queries
Iteration Path

21.
お奨めは Current / Future / Past 内に @001
 Current / Future / Past を作成
 Future 内に @001 から連番で作成
（数ヶ月分、あるいは全期間分 作ります）
 現在の期間を Current の内に移動
（最初は @001）
※ イテレーション期間は HOME の
Configure schedule and iterations... を押して設定 21

22.
必要があれば 土日 を開発可能な日に変更する
 イテレーションの設定より先
に変更しましょう
（※デフォルトだと土日を避けて、
日付の候補が自動入力されるため）
 完了見込みの計算にも使用されます
22
※管理者で（右上の歯車のアイコン）を押して Control panel に入り、Team Name のリンクをクリック、
Members が表示されているので、隣の Settings をクリックすると変更出来ます

23.
期間は一定、ウォーターフォールならフェイズ
 ウォーターフォールなら フェイズ（WBSの大・中項目）に合わせます
 アジャイル・スクラム開発では１週間～３週間の固定
 個人の趣味の開発であれば「月毎」にするのもおすすめです
入力した期間よりも先の期間を作成するのを忘れないために、Outlook 繰り返し予定を作成しましょう
23

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

25.
クエリのイテレーションパスを指定を親に変更
 標準では ProjectName＼Release 1＼Sprint 1 特定の期間が指定されている
25
 ProjectName＼ Current に変更
 Current の子が変更されても
（@001から@002になっても）
常に「現在の○○」が取得できる

26.
最初の機能・バックログ・タスク・バグを登録
 イテレーション期間に追加
 「現在の○○」クエリが動
作しているか？確認
「スクラム開発を始めよう！
TFS を使った日常コミュケーションと
チームワーク」36~55ページを参照
http://www.slideshare.net/shinichikoga355/102-ver4
26

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

28.
お奨めの「分岐」は D・M・P＼@001
 ソース バージョン管理 では 開発用に分岐、リリース用に分岐 が必須
28
M : メインブランチ
D＼@001 : 開発用ブランチ
P ＼@001 : リリース用ブランチ
マージ ( merge )
分岐 ( branch )
分岐 ( branch )
最新ソースコード
（VSO・TFSで自動ビルド・自動テスト）
リリースに使うソースコード
リリース毎に
新しいブランチ
開発するソースコード

29.
名前はなぜ M や D＼@001 がお奨めか？(1)
 分岐のパスは、そのまま Visual Studio の作業フォルダに
（C:usersUserNameFolderName が先頭に追加され、さらに binDebug 内にビルドされる）
 パスが長いとビルド出来ない
ビルド出来ても Azure 発行が出来ない事がある（一時生成ファイルの名前が長い）
ビルドサーバーでのビルドや、Release Management でリリース出来ない事がある
 パスは出来るだけ短くしておきたい
M/SolutionName ⇒ P/@001/SolutionName 29

30.
名前はなぜ M や D＼@001 がお奨めか？(2)
 「自由に名前をつけて良い」とするとわかりにくい
TFS や Visual Studio で ABC 順に並ぶ画面が多く、新旧がわかりにくい
人によって名前の付け方が違うと何の開発か？わからない
命名規則を作らなければならない
 イテレーション期間と同じにすると時期がわかりやすい
（D@001 が何の開発だったか？は、WORK でバックログ・タスクを見ればわかる）
30

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

32.
なんとしても最初に D・M・P フォルダを作成
 一番最初に M を作っておかないと、
ソース管理直下にソリューションが乱立して、
全体を１回で分岐できなくなる
 リリース事故のリスク
分岐フォルダとソリューションフォルダが混ざって名前順に
一度に分岐・マージできないので漏れが起きる
相対パスのずれによる事故 32
TFS Project Name
BuildProcessTemplets
Solution Name1
RuleSets
Solution Name2
Solution Name3
Solution Name4

33.
最初の 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

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

35.
静的コード分析を有効にすれば
 メモリーリークなど重大なバグを防げる
 スペルミスや名前の付け方のバラツキによる誤解や事故を防げる
 わかりやすい設計が身につき、バグが起きやすい構造や開発工数が減る
 その代わり、最初にちょっと勉強しなければならない（抵抗がある）
 守らない人がいると、警告がいわゆる「オオカミ少年」になってしまう
どうやってチームに根付かせるか？
35

36.
チェックインポリシーで強制できる
 チェックイン前に コード分析 必須
 チェックインコメント 必須
 タスクとの関連づけ 必須
 ソリューションに含まれないファイルは
チェックイン出来ない
「TFS Project Welcome pages（README.md）とチェックインポリ
シー に指定する静的コード分析 ルールセット」参照
https://code.msdn.microsoft.com/Welcome-pagesREADMEmd-75566110
36

37.
最初にチェックインポリシー違反の検知を！
 ソースコードがある程度チェックインされた後から追加は困難・無理
ビルド出来ない、修正が膨大、無視するのが横行する（言い訳しやすい）
最初にチェックインポリシーを必ず設定する
 チェックインポリシー違反（オーバーライド）の検知
チェックインポリシーは、緊急時にコメントを入れれば無視してチェックイン出来る
無視されたらメールが送信されるように設定を（※前述URL 最後を参照）
37

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

39.
チェックインポリシーが動作しているか？
 Mの中にソリューションを作成（※前述のもので可）
 プロジェクトにチェックインポリシーを適用
パスは ......RuleSetsCheckInPolicy.ruleset
３つ上がって RuleSets フォルダに入った中のファイル
 ビルドしてチェックイン出来ることを確認
39
TFS Project Name
BuildProcessTemplets
M
Solution Name
RuleSets
D
P
Project Name
Visual Studio Project
CheckInPolicy.ruleset

40.
ルールセットを 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

41.
構成管理は妥当か？発行やリリース手順を試す
 M・D・P にアクセス出来るユーザーを制限することができる
ユーザーの作成は後述。ここでは他のユーザーになったつもりで試してみる。
 Pからのリリースを試験
Azure に Webサイト・クラウドプロジェクトを発行
いわゆる「Hello World 」をリリースできるか？確認
他に必要な社内向けの手順書・チェックリストを準備
41
ここでリリース
出来ないと
完成後も・・・

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

43.
サンプルを実行・壊して効果を実感しよう
 単体テストをどこまで作るか？
 VSO・TFSで毎日ビルド・テストするか？
 まず、サンプルを登録して
効果を見ながらディスカッション！
「TFS・VSO・ローカルで動作するデータベースを使った単体テス
トの作り方・量産方法」参照
https://code.msdn.microsoft.com/TFSVSO-dc7b8c9d
43

44.
単体テストをどこまで作れるか？
 単体テストは約10年前から普及
NUnit, Visual Studio 標準機能
 テスト駆動開発は普通の作り方
デスクトップアプリを
F5デバッグしながら作るのと同じ
もはや「無し」では開発出来ない
 ただしメンバーのスキルと慣れに依る
 強制すると返ってスピード・質を落とす人も 44

45.
自動ビルド・自動テストをどこまで実現するか？
 自動ビルド・自動テストを設定すると
開発者のローカル PC でしか動作しないコードが発見できる
バグはテストしていないのではなく「テストしたが他の環境で動かない」方が多い
 難しいクリーンなDBでテストするライブラリ・サンプルを用意
 「TFS・VSO・ローカルで動作するデータベースを使った単体テストの作り方・量産方法」
https://code.msdn.microsoft.com/TFSVSO-dc7b8c9d
 Surviveplus.UnitTestPlus
https://www.nuget.org/packages/Surviveplus.UnitTestPlus/
45

46.
VSO自動ビルドは無料枠を超えると有料
 前述のサンプルを作るために５日で１ヶ月の無料枠を使い切りました
 チェックインの度にビルド・テストを実行する
「ゲート チェックイン ビルド」では無料枠は全く足りません
 通常のプロジェクトでは、変更後のみの日次ビルド でも足りないはず
 有料枠を使う、あるいは、週次でビルドするなどの検討が必要
46
高くはないですが
お金を使うので
マネージャの仕事ですね

47.
ビルド・テスト結果を HOME Overview にピン
 自動ビルドを設定したら、
ビルド定義の Pin to homepage
 ホームに結果を「見える化」
 ビルドに失敗したら自動的に
「バグ」が作成されるように
設定することも可能
対応するフローも決めておきます
47

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

49.
HOME – Overview に表示出来るもの
 タスクの進捗 バーンダウン（標準）
 ビルド結果
 作業項目（バックログ・タスク・バグ）
のクエリ結果 数とそのグラフ
 テスト結果 数とそのグラフ
 標準の操作、最初に表示される How to
49

50.
クエリできればチャートをホームにピンできる
 WORK Queries のチャート  TEST テストスイートのチャート
50

51.
細かいことですが・・・
 クエリ結果が 0 件の時も（エラー画面ではなく）
可愛いイラストが表示されるようになりました
51
実は重要！

52.
ブロークン・ウィンドウにしない！
 ブロークン・ウィンドウ理論では
「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、
やがて他の窓もまもなく全て壊される」※Wikipedia より引用
 HOME に「日次ビルド」が失敗している結果が毎日ずっと表示されていれば
このプロジェクトはバグっていていいんだというメッセージになる
 タスクが進捗し、ビルドは毎日成功し、テストも消化されるプロジェクト
 管理の「見える化」だけではなく、チームのモチベーションを考えよう
52
Broken Windows Theory

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

54.
ここまで準備してからユーザーを追加します
 管理者の追加・変更
 開発者の追加
 ステークホルダーの追加（出来ないことの確認）
前述までの準備が「守っている事」や「意図」を伝える前に触らせない
54

55.
管理者（オーナー）にはユーザーアカウントを
 マイクロソフト アカウントは、長期間サインインしないと消えます
 Windows Azure は課金に関わるユーザーが消えると、
その瞬間に環境が消えるようです
（VSOで試したことはありませんが Azure 上で動作しているので同じかもしれません）
 管理者（特にオーナー）にするマイクロソフトアカウントは、
毎日サインインして使っている開発者ユーザーのアカウントにしましょう
専用アカウントを作ってしばらく使っていないと、数年後に環境ごと全部突然消えるかもしれません 55

56.
開発者をサンドボックスにも招待しましょう
 最初に３種類、練習用の TFSプロジェクトを作成
 自分の練習が終わったら、開発者をサンドボックスに招待して
使い方を説明しましょう
 サンドボックス（砂場）＝自由に使って壊しても問題ない環境
 HOME Overview や Welcome ページにフィードバックをもらいましょう
56

57.
ステークホルダーでは Welcome が見られない
 Welcome は README.md の閲覧権限 = ソース管理が見られないと
表示されないみたいです
 ステークホルダー ライセンスは HOME Overview はみられますが
ソースコードは見られません = Welcome が見られない
今後バージョンアップで改善されるかもしれませんが、確認が必要です
57

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

59.
さぁ！
いよいよチーム
開発開始です
59

60.
フル機能は使わなくて大丈夫
ここまで準備していれば、
使えるところから使っても
問題になりません
逆に準備しないで使い始めると、後からはどうしようも無くなって「TFS 使えねぇ」になるかも
60

61.
最初のタスクの割り当て・見積もり・作業開始
 最初のイテレーション期間では、
「ベロシティによる予測」など
絶対にわからないことがあります
 何週間かチームで経験しないと
わからないことを確認します
「スクラム開発を始めよう！TFS を使った
日常コミュケーションとチームワーク」参照
http://www.slideshare.net/shinichikoga355/102-ver4 61

62.
開発者は「担当作業」から作業開始の流れを
 Visual Studio チームエクスプローラの「担当作業」
 自分に割り当てられたタスクを開始できます
担当作業 でタスクを「開始」し、開発出来たら
保留中の変更と共に「チェックイン」して完了します
 実は「中断」も出来る優れもの
Visual Studio の作業中の内容を全て一時保存し、
別の作業をして、また戻ってくることが出来ます 62
Team Explorer My Work
Suspend

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

64.
イテレーション期間 Current を @002 に変更
 現在の期間を Current に移動
 Feature＼@002 から
 Current＼@002 に
 直前の期間を Past に移動
 Current＼@001 から
 Past＼@001 に
64

65.
イテレーション期間に終わらなかったタスクは？
 必ず終わらせます
完了にして、次のイテレーションに新しいバックログ・タスクを作成する
全く着手していない場合は移動しても可
一部着手しているときは、分割したことがわかる名前をつけて分割する
 期間中は「バーンダウンチャート」で進捗している事を確認
 期間終了時は、必ず残り作業が 0 で終わるようにする
65

66.
残りタスクを放置すると
 チームのベロシティ（１期間にこなせる作業量）がわからなくなる
実績を次の見積もりに活かすために、この範囲は全部終わった、とする
 メンバーが、何が完了して何が完了していないか？確認・判断する必要
完了していないものは次期間に移っていることで判断不要
 区切りなくダラダラと作業することが蔓延するなど、「壊れた窓」になる
「なんだ TFS 使えねぇ」はタスクの放置から始まります
66

67.
意図を理解したメンバーで運用・維持する
 翌朝（次のイテレーション期間の最初）に、
HOME Overview が誰が見てもわかりやすい綺麗な状態になっていること
 タスクの完了・分割・移動など地味に作業がある
 VSO・TFS の使い方の意図を理解したメンバーで運用する
初めてソースバージョン管理を導入したときと同じ：「なぜフォルダコピーじゃダメなんですか？」
効果を全員が感じられるまで、工夫して使い続けよう 67

68.
Appendix
補足資料
68

69.
単体テストとスライドで取り扱わなかった 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

70.
チームルーム (Team Room) とは
 Lync, Skype, LINE, Facebook チャット, SMS などのテキスト会話と同様
 VSO・TFS サイト上でチャット出来る
記録目的ではなく（過去の会話を探すのは少し難あり）
遠隔地でのとっさの会話に使用を想定
Lync（Skype for Business) が使えない場合に使うと良い
 VSO・TFS プロジェクト用の他、作成も出来る
70

71.
ソフトウェア構成管理の教科書
 IT Architects’ Archive―ソフトウェア開発の課題
パターンによるソフトウェア構成管理
 http://goo.gl/2yF1N1
 2006年出版で VSO/TFS を含む最近のツールについては
全く触れられていませんが、ソフトウェア構成管理の
考え方・基礎知識を勉強できます。お奨めです。
 「何となく分岐・マージしている」人は是非一読を 71

72.
担当作業 からチェックインの流れと「中断」
 Visual Studio Ultimate 2012:
担当作業での複数タスクの処理方法
 http://goo.gl/s5nouX
 「中断」の説明のビデオですが、
担当作業からタスクを開始し、
チェックインするまでの作業の流れ
を実感することが出来ます。
72

73.
使用したサンプル・ライブラリ・スライド
 スクラム開発を始めよう！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

74.
Plus Programming .net 勉強会
http://www.facebook.com/PlusProgramming.net
74