Weitere ähnliche Inhalte Ähnlich wie ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法 (20) Kürzlich hochgeladen (11) ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法2. このセッションのゴール
Work の使い方をイメージする
Test と WorkのBug の使い方を決めることができる
Build と Release の使い方とCodeに必要な条件を理解する
VSTS / TFSをフル活用して、低コストで高品質な開発・運用を!
2
工程管理・進捗管理・開発
シナリオテスト管理 バグ管理
自動ビルド 承認ワークフローによるデプロイ
ウォーターフォール・アジャイル・DevOps それぞれのチームにあった
自動テスト・分岐
3. 自己紹介
3
古賀 慎一
Microsoft MVP for Visual Studio and Development Technologies
アバナード株式会社 シニアコンサルタント
前職ではクラウドサービス開発で TFS 導入事例
http://tech.surviveplus.net/archives/1114
某大手 情報サイトのデータ入稿システム のフレームワークを開発
「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか?
書籍執筆 日経BP社より発売中
4. アジェンダ
VSTS/TFSで出来ることはDevOps
Work による工程管理・進捗管理
Test によるシナリオテスト管理
Work の Bug によるバグ管理
Code によるソースバージョン管理
Build & Release による継続的デリバリー(自動ビルド・自動テスト・自動デプロイ)
4
このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )
6. VSTS/TFSで何ができますか?
Visual Studio Team Services のメニューを見るとわかります
Home ⇒ ダッシュボード・見える化
Code ⇒ ソースバージョン管理
Work ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム
Build & Release ⇒ 自動ビルド・自動テスト・自動デプロイ(継続的デリバリー)
Test ⇒ シナリオテスト管理・バグトラッキングシステム
6
8. DevOps と各機能のバランス
Home ダッシュボード・見える化 (Dev = Ops)
Code ソースバージョン管理 (Dev)
Work タスク管理・工程管理・進捗管理・バグトラッキングシステム (Dev ≧ Ops)
Build & Release 継続的デリバリー (Ops)
Test シナリオテスト管理・バグトラッキングシステム ( Dev ≦ Ops ≒ QA )
8
Dev Ops
10. 考え方は「前提として」ちゃんとつながっている
約40年前 ウォーターフォール (書類で管理、Windowsやパソコンが生まれる前)
約15年前 アジャイル (.NET 登場、Java が普及し始めた頃)
7年前 DevOps ( TFS 2010 DevOps対応に生まれ変わる )
現在 DevOps 2.0 へ (VSTS、Azure、クロスプラットフォーム、マイクロサービス)
※Microsoft Tech Summitより
作る物の機能・規模・複雑さの増大、スピードも求められる
書類で頑張る方法から、システムの支援を受けて効率化・自動化へ
10
17. Workの基本は「その期間に何をするか?」
誰が Assigned To
この期間(週)に Iteration
何を Task
あとどれくらいの時間で
Remaining Work
やるか? やっているか?
To Do / Doing / Done ( Proposed / Active / Resolved / Closed )
開発者は自分のタスクを完了させていく
17
18. イテレーション期間は
進捗報告・確認 ・カイゼンの最小単位
ウォーターフォールなら週次報告 etc...
アジャイル・スクラムならプロダクトをリリースする最小リードタイム
開発者(チームメンバー)は期間中にタスクを完了させる
管理者は期間ごとにレポートを取得し、報告と改善を実施できる
リリース、仕掛の進捗、チームの生産性の実績、EVMの元となる実績値
バーンダウンチャート 18
26. ウォーターフォールでは Work をこう使う(開始時1)
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 に 26
27. ウォーターフォールでは Work をこう使う(開始時2)
スケジュールとリリース (WBSに日付と人を設定)
これまで通りProjectで計画
タスクが、TFSのイテレーション期間のどれにあたるか?
該当するIteration Pathを設定してTFSにインポート
タスクがそのイテレーション期間に表示される
担当者もAssigned Toに設定してインポート
Project ファイルをマスタースケジュールとして保管しておく
27
28. ウォーターフォールでは Work をこう使う(開発中1)
毎日 作業を実施して、実績工数・進捗状況 を入力・集計
作業者は Workで「この期間でやるタスク」を確認
Taskを開始・完了させる
作業したら Completed Workに時間を足して、Remaining Workを減らす
PMの登録作業は不要
誰でもカンバンボードで進捗をリアルタイムに確認
開発者もPMもすごく楽!それでいて、より正確な記録!
28
29. ウォーターフォールでは Work をこう使う(開発中2)
3段階でインポートしたときは、Task の作成をチームメンバーに任せる
作業者はWorkで「この期間で完成させるバックログ」を確認
バックログを完成させるために必要な全てのタスクを洗い出し、見積もる
Taskを追加
見積もり工数をTask の Remaining Work と Original Estimate に入れる
PMはバックログの見積もり工数と、タスクの合計工数を比較してチェック
29
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が集計に苦労しないでチームの状況を把握できるのですぐに手を打てる 31
34. アジャイル・スクラムでは Work をこう使う(1)
事前にバックログに要件・作業を登録
プロダクトオーナーから優先度をつけてやるべきことを挙げておく
期間の最初に「この期間でやるべきバックログ」を決める
過去の実績からバックログに見積もり時間を登録すると、TFSが計算
工数時間ではなく、チーム内で使う相対見積もりの数値
しばらく同じチームで開発すると、1期間にできる数値が分かってくる(ベロシティ)
プロダクトオーナーにバックログを宣言して期間開始 34
35. アジャイル・スクラムでは Work をこう使う(2)
毎日、チームメンバー全員で、
バックログを完成させるために必要な全てのタスクを洗い出し、見積もる
(こちらは工数で良い)
Taskを追加し、見積もり工数をTask の Remaining Work に入れる
Taskを 開始・完了させる
チーム全体でタスク全部を完了できるか?毎日セルフチェックする
期間内に完成させられる工夫をチームで考える(自立した組織)
無理なことは無理と宣言する
35
39. Test は手動テストを扱う
コードによる単体テストは Test ではなく、Code に保存して Build で扱う(※後述)
Testでは 手動テストの計画・実行・結果の記録を扱う
最新結果のチャートをHomeに表示して見える化
Test にテスト計画を追加するには Test Manager 拡張機能
( Visual Studio Enterprise or Test Professional サブスクリプション※ or 支払い ) が必要
※ユーザーの設定で Basic になっていないか?確認 39
49. Work の Bug と Backlog・Taskの違い
タスク・バックログは予定のイテレーション期間内に完了させることが目的
バグは期間内・あるいは期間に関係なく追加して、完了させることが目的
開発者の使用方法はほぼ同じ
バグに直接時間を入れて完了させてもいい、
バグに関連する別のタスクを追加して完了させてもいい
管理者の集計の仕方が変わるので、チームでどちらかに決めておく必要がある
49
53. Build & Release と共にCodeを使用する
ソースを分岐する
「テストと開発を並行で行う時は分岐必須」が常識だが...
DevOps2.0 では チェックイン 即 自動テスト&リリース
これだとメインブランチしか要らない
そうでなければ開発・メイン・自動リリース用のブランチを用意する
メインブランチにマージすると自動的に単体テスト(※後述)
開発とテストが完了して、マージしたら自動的にデプロイ(※後述) 53
55. DevOpsのためにBuild & Releaseを使う
Work・Test をうまく扱える(Dev)前提で、継続的デリバリー(Ops)を実現
ソース管理に保存すると、自動ビルド・自動テストされる状態を保つ
リリースにかかる時間を限りなく0に近づける
問題が発見された時に、前のバージョンに戻すことも自動化された状態を保つ
運用やリリースに関わる課題の解決も全て Work バックログの管理で行う。
プロダクトを継続的に開発
新機能の開発・リリースを2週間程度で繰り返して、競争力を保つ
55
59. 自動テスト(コードによる単体テスト)が前提
C#/Visual Basic 全てのメソッドに単体テストを作成
Codeに保存
DevOpsでは必須
プログラムを書き換えて自分でテストを実行すると、壊れていないか?確認できる
チーム開発で、メインブランチにマージしたときに、壊れていないか?確認できる
単体テストが無ければ、壊れたまま自動リリースされてしまう可能性
あるいは全シナリオテストをやりおなおし必須に 59
63. まとめ
VSTS / TFS で出来るのはDevOps
= ウォータフォール or アジャイル(≒Dev)+ 継続的デリバリー(≒Ops)
ウォーターフォールでは Projectをマスターとして Work / Test を使う
アジャイル・スクラムでは Work / Test をマスターとして使う
Work / Test / Code と単体テストを使いこなしている前提で、
Build & Releaseを使うと継続的デリバリーが実現できる
63
Hinweis der Redaktion DEMO DEMO DEMO DEMO
DEMO
DEMO DEMO