ウォーターフォール・アジャイル・DevOps...

1

開発・テスト・リリースでVSTS/TFS をフル活用する方法

ウォーターフォール・アジャイル・ DevOps どんなチームでも

アバナード株式会社 シニアコンサルタント（ Microsoft MVP ）古賀 慎一

2016 年 11 月 21 日（月）

Copyright© 2016 Shin-ichi Koga All Rights Reserved.

2

このセッションのゴール

Work の使い方をイメージする

Test と Work の Bug の使い方を決めることができる

Build と Release の使い方と Code に必要な条件を理解する

VSTS / TFS をフル活用して、低コストで高品質な開発・運用を！

工程管理・進捗管理・開発

シナリオテスト管理 バグ管理

自動ビルド 承認ワークフローによるデプロイ

ウォーターフォール・アジャイル・ DevOps それぞれのチームにあった

自動テスト・分岐

3

自己紹介古賀 慎一

Microsoft MVP for Visual Studio and Development Technologies

アバナード株式会社 シニアコンサルタント

前職ではクラウドサービス開発で TFS 導入事例http://tech.surviveplus.net/archives/1114

某大手 情報サイトのデータ入稿システム のフレームワークを開発

「仕組み」作りで　如何に高品質・低コストで早い開発を実現できるか？

書籍執筆 日経 BP 社より発売中

4

アジェンダ

VSTS/TFS で出来ることは DevOpsWork による工程管理・進捗管理

Test によるシナリオテスト管理

Work の Bug によるバグ管理

Code によるソースバージョン管理

Build & Release による継続的デリバリー（自動ビルド・自動テスト・自動デプロイ）

このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )

5

VSTS/TFS で出来ることは DevOpsウォーターフォールとアジャイルに継続的デリバリーをプラスする

6

VSTS/TFS で何ができますか？

Visual Studio Team Services のメニューを見るとわかります

Home ⇒ ダッシュボード・見える化

Code ⇒ ソースバージョン管理

Work ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム

Build & Release ⇒ 自動ビルド・自動テスト・自動デプロイ（継続的デリバリー）

Test ⇒ シナリオテスト管理・バグトラッキングシステム

7

VSTS/TFS で出来ることは DevOps

アジャイル (≒Dev) ＋ 継続的デリバリー (≒Ops) ＝ DevOps

開発向けの機能と運用向けの機能を分けずに 1 つのサービスとして提供

全ては 開発 と 運用 を繰り返す ためにある（早く安く高品質で）

中投資 中投資

時代の変化とニーズに応じて常にアップデート 数年で基礎から見直す

8

DevOps と各機能のバランス

Home ダッシュボード・見える化 (Dev = Ops)Code ソースバージョン管理 (Dev)Work タスク管理・工程管理・進捗管理・バグトラッキングシステム (Dev ≧ Ops)Build & Release 継続的デリバリー (Ops)Test シナリオテスト管理・バグトラッキングシステム ( Dev ≦ Ops ≒ QA )

Dev Ops

9

VSTS/TFS はウォーターフォールでは活用できない？

メニューと用語がアジャイル・ DevOps 向け

そのままでは旧来のウォーターフォールでは使い方がわからない

Code しか使われていない現場が多い

10 年前の Visual SourceSafe と同じ使い方になりがち

10

考え方は「前提として」ちゃんとつながっている

約 40 年前 ウォーターフォール （書類で管理、 Windows やパソコンが生まれる前）

約 15 年前 アジャイル （ .NET 登場、 Java が普及し始めた頃）

7 年前 DevOps （ TFS 2010 DevOps 対応に生まれ変わる ）

現在 DevOps 2.0 へ (VSTS 、 Azure 、クロスプラットフォーム、マイクロサービス）

※ Microsoft Tech Summit より

作る物の機能・規模・複雑さの増大、スピードも求められる

書類で頑張る方法から、システムの支援を受けて効率化・自動化へ

11

実は日本のウォーターフォールはもはやアジャイル！

要件、機能、実装、テストの繋がりを保って開発するも（ WBS 段階的詳細化）

テスト駆動開発などの開発手法を取り入れて、後工程を出来るだけ前倒し

最後まで顧客に見せないことはなく、早い段階で細かく動作をデモ

後工程になって明らかになる顧客の要望もできるだけ取り入れる

V字ではなく、 WOOO... ≒ アジャイル

ならば、より “アジャイルらしいウォーターフォール” で効率よくやろう！

12

文書での管理から TFS画面での管理に変更できる

PMBOK に出てくる文書で、

日々更新・集計するものは Work / Test に対応する画面がある

簡単入力・リアルタイムで見える化 ⇒ 報告時に書類にエクスポート

あまり変わらないものは Code に保存する

Markdown はダッシュボードに表示可能 ⇒ Word に変換可能

ウォータフォール式文書が報告や納品に必要なら

その時エクスポート・変換して作成できる！（普段は TFS画面で見える化）

13

開発手法・用語と人の役割の違い

アジャイル開発手法をウォーターフォールにも追加可能

単体テスト、テスト駆動開発、カンバン （必要に応じて効率化可能）

完全に対応するものは 用語 の違いに慣れるだけ

人の役割の違い

• WBS の作成・設計・実装・テスト・デプロイを違う人がやる

• 実質同じ人がやる

• チームで適切に分担してやる

どの管理でも予定と実績の比較が必要（チームメンバーの使い方はほぼ同じ）

14

VSTS/TFS をウォーターフォールでも活用できる！

この後、具体的に解説・・・

アジャイル・ DevOps 向けのメニューと用語に慣れる

TFS 簡単入力・リアルタイム見える化、報告時や納品時に文書ファイル化

人の役割に応じて、 Work と Test の使い方を明確にする

アジャイル開発手法を取り入れて、 Build や Home を活用する

ウォーターフォール ＋ 継続的デリバリー ≒ DevOps だって可能

15

どんなチームでも

VSTS/TFS の機能をフル活用して DevOps ができる！

16

Work による工程管理・進捗管理ウォーターフォールとアジャイルの違いは、いつ誰がタスクを作るか？

17

Work の基本は「その期間に何をするか？」

誰が Assigned To

この期間（週）に Iteration

何を Task

あとどれくらいの時間で Remaining Work

やるか？ やっているか？ To Do / Doing / Done ( Proposed / Active / Resolved / Closed )

開発者は自分のタスクを完了させていく

18

イテレーション期間は

進捗報告・確認 ・カイゼンの最小単位

ウォーターフォールなら週次報告 etc...

アジャイル・スクラムならプロダクトをリリースする最小リードタイム

開発者 ( チームメンバー ) は期間中にタスクを完了させる

管理者は期間ごとにレポートを取得し、報告と改善を実施できる

リリース、仕掛の進捗、チームの生産性の実績、 EVM の元となる実績値

バーンダウンチャート

19

タスクを誰が作るか？

開発者にとって「自分のタスクを完了させる」のは同じ

そのタスクを誰が・いつ・洗い出して・見積もるか？

ウォーターフォールとアジャイル・スクラムでは大きく違う

ここに注意すれば、どちらでもうまく Work を使いこなせる

20

ウォーターフォールのタスクの管理方法（全体）

プロジェクトの開始時

WBS （日付なし）階層構造で一覧化した作業項目の一覧 + 見積もり工数

スケジュールとリリース （ WBS に日付と人を設定）

開発中

毎日 作業を実施して、実績工数・進捗状況 を入力・集計

週次など EVM （予実の比較、 CPI ・ SPI などインデックス値による評価）

課題の解決・改善（問題の発見が遅れる程、対応は困難）

21

ウォーターフォールのタスクの管理方法（開始時１）

WBS （日付なし）階層構造で一覧化した作業項目の一覧 + 見積もり工数

Project でタスクの一覧を作成

大分類・中分類・小分類・・とタスクを詳細化していく

親子関係を必ず維持、 WBS番号（ 1.1.1 など）でタスクを識別

過去の実績から、タスクの見積もり工数（時間・日数）を設定

22

ウォーターフォールのタスクの管理方法（開始時２）スケジュールとリリース （ WBS に日付と人を設定）

タスクにリソース（作業者）をアサインする

リソースの一日の作業量をみて、タスクに日付を設定

マイルストーン、クリティカルパスの確認

ガントチャート完成

リソースの単価とタスクの工数から見積もり金額が確定

受託開発の場合、この内容で提案＆契約できれば開発開始

23

ウォーターフォールのタスクの管理方法（開発中1 ）毎日 作業を実施して、実績工数・進捗状況 を入力・集計

作業者はガントチャートで「今日やるタスク」を確認

自分で一日の作業したタスクと作業時間と記録

作業完了後に Project Server で自分の作業時間を登録

Project Server が無いときは、 Excel などで収集して、

PM が Project ファイルに全員分の進捗を登録する（これがすごく大変）

24

ウォーターフォールのタスクの管理方法（開発中2 ）週次など EVM （予実の比較、 CPI ・ SPI などインデックス値による評価）

ガントチャートのイナズマ線ではタスクごとの遅れを確認

EVM では全体を数値で把握

日付、 PV: 完了しているべきタスクの見積もり工数、 EV : 完了している工数、

SPI : 予定より遅いか？早いか？、 CPI : 予定より工数がかかっているか？かかっていないか？

課題の解決・改善（問題の発見が遅れる程、対応は困難）

顧客に説明してベースラインの変更（再スケジュール）これは本当にすごく大変

ウォーターフォールでもできるだけ早く問題に気づいて対応したい

25

ウォーターフォールのタスクを

VSTS / TFS を使用して管理するには・・・

26

ウォーターフォールでは Work をこう使う（開始時１）WBS （日付なし）階層構造で一覧化した作業項目の一覧 + 見積もり工数

これまで通り Project で作成

製品、フェーズ、機能、要件、納品物に注目

WBS を 3 階層（タスクなし） or 4 階層で TSF にインポート　（※違いは後述）

CMMI テンプレートを使用　 Epic / Feature / Requirement(Backlog) / Task 　に対応

親子関係を必ず維持してインポート WBS番号（ 1.1.1 など）もタイトルにつける

4 段階の場合 見積もり工数は Task の Remaining Work と Original Estimate に

3 段階の場合 見積もり工数は Backlog の Original Estimate に

27

ウォーターフォールでは Work をこう使う（開始時２）スケジュールとリリース （ WBS に日付と人を設定）

これまで通り Project で計画

タスクが、 TFS のイテレーション期間のどれにあたるか？

該当する Iteration Path を設定して TFS にインポート

タスクがそのイテレーション期間に表示される

担当者も Assigned To に設定してインポート

Project ファイルをマスタースケジュールとして保管しておく

28

ウォーターフォールでは Work をこう使う（開発中1 ）毎日 作業を実施して、実績工数・進捗状況 を入力・集計

作業者は Work で「この期間でやるタスク」を確認

Task を開始・完了させる

作業したら Completed Work に時間を足して、 Remaining Workを減らす

PM の登録作業は不要

誰でもカンバンボードで進捗をリアルタイムに確認

開発者も PM もすごく楽！それでいて、より正確な記録！

29

ウォーターフォールでは Work をこう使う（開発中2 ）3 段階でインポートしたときは、 Task の作成をチームメンバーに任せる

作業者は Work で「この期間で完成させるバックログ」を確認

バックログを完成させるために必要な全てのタスクを洗い出し、見積もる

Task を追加

見積もり工数を Task の Remaining Work と Original Estimate に入れる

PM はバックログの見積もり工数と、タスクの合計工数を比較してチェック

30

ウォーターフォールでは Work をこう使う（開発中3 ）Task を Project で作成するとちょっとした作業が追加で必要になったときに困る（ Project の最小タスクが TFS の Task ）

ウォーターフォールでタスクを足すのは変更報告が必要な場合が多い

Project でタスクを登録しなおして、承認を得て、 TFS に再インポート・・・

必ずやらなくなる・やれなくなるTFS にタスクを追加しないで作業する癖がつく、実績と乖離、 TFS が使われなくなる

Task をメンバーが追加できる 3 段階のインポートがお勧め（ Project の最小タスクは、 TFS の Backlog ）

TFS タスクの追加は、 Project のタスク追加ではない（作業用の詳細化）

31

ウォーターフォールでは Work をこう使う（開発中4 ）週次など EVM （予実の比較、 CPI ・ SPI などインデックス値による評価）

4 段階では Task の Original Estimate と Completed Work を比較

3 段階では Backlog の Original Estimate と、子 Task の Completed Workの合計を比較

もとの Project ファイルの実績値に入力（ TFS からエクスポートしてコピペ）

Excel にエクスポートして Power BI で分析もできる

EVM レポートを作成して進捗会議で報告する

課題の解決・改善（問題の発見が遅れる程、対応は困難）

PM が集計に苦労しないでチームの状況を把握できるのですぐに手を打てる

32

Work をインポート・エクスポートするにはクエリ

方法をスライドで解説

バックログとタスクをインポート・エクスポート

Team Foundation Server と Excel ・ Project との連携

http://www.slideshare.net/shinichikoga355/ss-43464369

33

VSTS/TFS + Power BI で EVM レポートを作成できる

VSTS/TFS を使いながらウォーターフォールらしい管理・報告が可能

34

アジャイル・スクラムでは Work をこう使う（１）

事前にバックログに要件・作業を登録

プロダクトオーナーから優先度をつけてやるべきことを挙げておく

期間の最初に「この期間でやるべきバックログ」を決める

過去の実績からバックログに見積もり時間を登録すると、 TFS が計算

工数時間ではなく、チーム内で使う相対見積もりの数値

しばらく同じチームで開発すると、 1期間にできる数値が分かってくる（ベロシティ）

プロダクトオーナーにバックログを宣言して期間開始

35

アジャイル・スクラムでは Work をこう使う（２）毎日、チームメンバー全員で、

バックログを完成させるために必要な全てのタスクを洗い出し、見積もる（こちらは工数で良い）

Task を追加し、見積もり工数を Task の Remaining Work に入れる

Task を 開始・完了させる

チーム全体でタスク全部を完了できるか？毎日セルフチェックする

期間内に完成させられる工夫をチームで考える（自立した組織）

無理なことは無理と宣言する

36

期間内に終わらないときはどうするか？

ウォーターフォールではそのまま

以前の Iteration の作業であっても、実際に作業したときに Task を完了させる（遅延）

遅れが EVM レポートとして報告される。最終的にどこかで取り返す。

アジャイル・スクラムでは、未完成であっても完了

期間の完了時に、プロダクトオーナーにその期間で完成したものを正確に報告する

終わらなくて続けたいバックログも、

新しい別のバックログとして次の期間以降に作業する

次の期間で、他のバックログと優先度を比較する

37

タスクが足されて見積もりより遅延するんだけど？チームの事実として受け入れよう

見積もりが甘い

無理なスケジュールをハラスメントで無理やり終わらせていなかったか？

スキルが不足しているメンバーをアサインした？

引継ぎが不足していた？引継ぎのコストをそもそも見積もっていなかった？

これらが顕在化 ・見える化された と理解しよう

例えば「人を足せば早くできるわけじゃない」が明確に見える化されてしまう

正しく見積もって出来ることをしよう！そのうえで工数を下げる工夫を！

38

Test によるシナリオテスト管理テストケースを作成、テストを実施して、結果を記録する

39

Test は手動テストを扱う

コードによる単体テストは Test ではなく、 Code に保存して Build で扱う（※後述）

Test では 手動テストの計画・実行・結果の記録を扱う

最新結果のチャートを Home に表示して見える化

Test にテスト計画を追加するには Test Manager 拡張機能

( Visual Studio Enterprise or Test Professional サブスクリプション※ or 支払い ) が必要※ユーザーの設定で Basic になっていないか？確認

40

テストケースと結果の管理

タスクが完了させて無くしていく作業

バックログが完成していく成果物・納品物（実際のファイルは Code に保存）

テストはテストケースの一覧 + 結果の一覧

= 「今、製品は正常か？」の一覧表

必要に応じてテストを実施、再実施して、最新結果の一覧を更新していく

41

要件ベースのテストスイートを作る

ウォーターフォール V字モデルを思い出してみる

後工程〇〇テストは、前工程□□をテストする・・

Work に登録されているテスト対象の機能や要件の Backlog に対応する

テストスイート（テストケースの親）を作れる（一括で作成可能）

テスト計画（テストスイートの親）に

「単体テスト」や「結合テスト」などを作成

開発・修正でどの範囲をテストする・しなおすか？（トレーサビリティ）

42

Grid表示で簡単にテストケースとステップを登録

Excel の表のように一覧で登録できる

テストケース

テストステップ

アクション（操作）

期待される結果（そうならなかったら失敗とする条件）

43

テスト実行（成功時の流れ）

Web でも、クライアント (Test Manager) でも

テストケースを選んで開始

ステップ（アクションと期待される結果）の一覧画面が表示される

ステップのアクションに従って順に操作

期待される結果通りならステップを成功に

必要に応じてコメントを追加、画像（エビデンス）を添付 （※後述）

全ステップ成功になるとテストケースが成功になる

44

期待される結果にならなかったら

ステップの結果を失敗にする　その時点でテストケースは失敗になる

ステップの結果にコメントを追加　どういう結果か？詳細を記載する

ステップの結果に画像を添付

エビデンスとしてスクリーンキャプチャを保存

Windows標準のスニッピングツール、 Light Cutter 、 OneNote のツールなど

右クリックメニューからステップの結果に画像を添付できる

間違ってステップ（計画）に添付してしまう人が多いので注意

45

テストが失敗したら

バグを起票する（※後述）

開発作業中のテスト実施の場合にはバグを起票しなくてもいい

バグ起票のルールはチームで決めて、 README.md などに書いておく

テストケースのステップの間違い・更新が必要でないか？確認

要件ベースのテストスイートなら、 Work と Code のチェンジセット（※後述）を確認

バックログやタスクを追加して問題を解決する

46

テスト結果チャートをダッシュボードに表示

何パーセントが成功しているか？で、全体として正常かどうか？を判断

Home に表示すると毎日見える

「壊れた窓効果」にならないように、テストの失敗を放置しない

テスト結果（ケースの結果、ステップの結果とコメント）の TSV形式エクスポートと

添付画像の一括ダウンロードができる Visual Studio 拡張機能あります（納品物の作成

に）※現在作成中でほぼ完成。公開準備が間に合っていないので、すぐに必要ならご連絡ください。

47

Work の Bug によるバグ管理取り扱いを最初にチームで決めておく

48

バグの扱い方はプロジェクトでルールを決める

イテレーション期間に属する・属さない

表示の仕方を設定で変更できる

ボードのイテレーション期間に表示するかどうか？

表示はバックログと同様か？タスクと同様か？

いつバグを起票するか？（テスト失敗時常に？テストフェーズのみ？）

そのバグをどう解決するか？（次の期間？その期間？期間に関係なし？）

49

Work の Bug と Backlog ・ Task の違い

タスク・バックログは予定のイテレーション期間内に完了させることが目的

バグは期間内・あるいは期間に関係なく追加して、完了させることが目的

開発者の使用方法はほぼ同じ

バグに直接時間を入れて完了させてもいい、

バグに関連する別のタスクを追加して完了させてもいい

管理者の集計の仕方が変わるので、チームでどちらかに決めておく必要がある

50

バグ チャートをダッシュボードに表示する

バグがすべて解決されているか？で、全体として正常かどうか？を判断

Home に表示すると毎日見える

「壊れた窓効果」にならないように、テストの失敗を放置しない

Bug は Work の Backlog や Task 同様、クエリでエクスポートできる

Bug に時間を入れるときは、 EVM で Backlog や Task の集計と同等に扱う

（クエリを準備するときに Bug がないと忘れがち）

51

Code によるソースバージョン管理継続的デリバリーのために、改めてルールを見直しておく

52

Work ・ Test と共に Code を使用する

ソースバージョン管理

チェックインするときに、タスクに関連付ける（強制もできる）

変更セットとタスクが関連付けられるので、何のための修正なのか？明確

コメントを強制するだけでは、人の努力に依存してしまう。

仕組みでミスできなくする。

Test が失敗したとき、 Work と Code のチェンジセットから原因をたどれる

53

Build & Release と共に Code を使用する

ソースを分岐する

「テストと開発を並行で行う時は分岐必須」が常識だが ...

DevOps2.0 では チェックイン 即 自動テスト & リリース

これだとメインブランチしか要らない

そうでなければ開発・メイン・自動リリース用のブランチを用意する

メインブランチにマージすると自動的に単体テスト（※後述）

開発とテストが完了して、マージしたら自動的にデプロイ（※後述）

54

Build & Release による継続的デリバリー自動ビルド・自動テスト・自動デプロイを実現する

55

DevOps のために Build & Release を使う

Work ・ Test をうまく扱える（ Dev ）前提で、継続的デリバリー（ Ops ）を実現

ソース管理に保存すると、自動ビルド・自動テストされる状態を保つ

リリースにかかる時間を限りなく０に近づける

問題が発見された時に、前のバージョンに戻すことも自動化された状態を保つ

運用やリリースに関わる課題の解決も全て Work バックログの管理で行う。

プロダクトを継続的に開発

新機能の開発・リリースを 2週間程度で繰り返して、競争力を保つ

56

継続的デリバリーがなければ

早いリリースを繰り返すことは不可能

57

いや、ウォータフォールでは

そんなに繰り返してリリースすることないし…

58

ウォータフォールでの継続的デリバリー

開発したらすぐに検証用サーバー・ Azure にリリースして動作確認

テストチームにテストを依頼するときに、必ず最新のプログラムにしたい

週次の定例会議で、ちょっとお客様に動きを見てもらいたい（≒アジャイル）

V 時の最後のリリースだけが継続的デリバリーの対象ではない！

59

自動テスト（コードによる単体テスト）が前提

C#/Visual Basic 全てのメソッドに単体テストを作成

Code に保存

DevOps では必須

プログラムを書き換えて自分でテストを実行すると、壊れていないか？確認できる

チーム開発で、メインブランチにマージしたときに、壊れていないか？確認できる

単体テストが無ければ、壊れたまま自動リリースされてしまう可能性

あるいは全シナリオテストをやりおなおし必須に

60

単体テストに求められること

引数と期待される結果の全バターンを網羅的にテスト

メソッドを使う機能や画面のシナリオテストで、パターン網羅は現実的でない

VSTS/TFS で動作する必要がある

SQL Server 、 SharePoint サーバーなどに接続可能なテスト

あるいは接続しないで実行できる設計（依存性の注入）

Fakes （ DateTime.Now を置き換える など）

実行順に依存しない・どの単体テストも単独で実行できること

61

単体テストが作れる開発の方法

単体テスト出来るアプリの作り方を

スライド＆サンプルで解説しています

「ちゃんとした C# プログラムを書けるようになる実践的な方法

　～ Visual Studio を使った 高品質・低コスト・保守性の高い開発」 http://www.slideshare.net/shinichikoga355/starting-c-sharp

技術イケメン（経験者）にチームに参加してもらって

一緒に２ヶ月程度開発できるとマスターできるはず！

62

ビルドとリリースをこう使う

ビルド定義で自動ビルド・自動テスト （より Dev側）

どのソースコードをビルドするか？

単体テストを実行するか？

パッケージの作成や検証サーバーなどへのデプロイも可能

リリース定義でビルド後に承認ワークフロー・デプロイ（より Ops側）

承認すると検証⇒ステージング⇒本番

63

まとめ

VSTS / TFS で出来るのは DevOps= ウォータフォール or アジャイル（≒Dev ）＋ 継続的デリバリー

（≒Ops ）

ウォーターフォールでは Project をマスターとして Work / Test を使う

アジャイル・スクラムでは Work / Test をマスターとして使う

Work / Test / Code と単体テストを使いこなしている前提で、

Build & Release を使うと継続的デリバリーが実現できる

64

書籍と勉強会の CM

チーム開発の教科書

http://amzn.to/2euUzrW

はじめての ASP.NET SPA 開発入門

http://amzn.to/2eQKaUa

第 11回 Plus Programming .net 勉強会

「 ASP.NET SPA ビギナー & ステップアップ」 2016 年 12 月 17 日（土）

https://atnd.org/events/82659

Copyright© 2016 Shin-ichi Koga All Rights Reserved. 65