Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法

5,178 views

Published on

これから本格的に Visual Studio Team Services (旧Visual Studio Online) や Team Foundation Server を使い始めるチーム(マネージャ・リーダー・メンバー)向けに、画面操作のデモ含めて約2時間の研修用の資料です。

Published in: Technology
  • Login to see the comments

ウォーターフォール・アジャイル・DevOps どんなチームでも開発・テスト・リリースでVSTS/TFSをフル活用する方法

  1. 1. 開発・テスト・リリースで VSTS/TFSをフル活用する方法 ウォーターフォール・アジャイル・DevOps どんなチームでも 1 アバナード株式会社 シニアコンサルタント( Microsoft MVP )古賀 慎一 2016年11月21日(月) Copyright© 2016 Shin-ichi Koga All Rights Reserved.
  2. 2. このセッションのゴール  Work の使い方をイメージする Test と WorkのBug の使い方を決めることができる Build と Release の使い方とCodeに必要な条件を理解する VSTS / TFSをフル活用して、低コストで高品質な開発・運用を! 2 工程管理・進捗管理・開発 シナリオテスト管理 バグ管理 自動ビルド 承認ワークフローによるデプロイ ウォーターフォール・アジャイル・DevOps それぞれのチームにあった 自動テスト・分岐
  3. 3. 自己紹介 3 古賀 慎一 Microsoft MVP for Visual Studio and Development Technologies アバナード株式会社 シニアコンサルタント  前職ではクラウドサービス開発で TFS 導入事例 http://tech.surviveplus.net/archives/1114  某大手 情報サイトのデータ入稿システム のフレームワークを開発  「仕組み」作りで 如何に高品質・低コストで早い開発を実現できるか?  書籍執筆 日経BP社より発売中
  4. 4. アジェンダ  VSTS/TFSで出来ることはDevOps  Work による工程管理・進捗管理  Test によるシナリオテスト管理  Work の Bug によるバグ管理  Code によるソースバージョン管理  Build & Release による継続的デリバリー(自動ビルド・自動テスト・自動デプロイ) 4 このスライドは SlideShare で共有します ( http://www.slideshare.net/shinichikoga355/ )
  5. 5. VSTS/TFSで出来ることはDevOps ウォーターフォールとアジャイルに継続的デリバリーをプラスする 5
  6. 6. VSTS/TFSで何ができますか? Visual Studio Team Services のメニューを見るとわかります  Home ⇒ ダッシュボード・見える化  Code ⇒ ソースバージョン管理  Work ⇒ タスク管理・工程管理・進捗管理・バグトラッキングシステム  Build & Release ⇒ 自動ビルド・自動テスト・自動デプロイ(継続的デリバリー)  Test ⇒ シナリオテスト管理・バグトラッキングシステム 6
  7. 7. VSTS/TFSで出来ることは DevOps  アジャイル(≒Dev) + 継続的デリバリー(≒Ops) = DevOps  開発向けの機能と運用向けの機能を分けずに1つのサービスとして提供  全ては 開発 と 運用 を繰り返す ためにある(早く安く高品質で) 7 中投資 中投資 時代の変化とニーズに応じて常にアップデート 数年で基礎から見直す
  8. 8. DevOps と各機能のバランス  Home ダッシュボード・見える化 (Dev = Ops)  Code ソースバージョン管理 (Dev)  Work タスク管理・工程管理・進捗管理・バグトラッキングシステム (Dev ≧ Ops)  Build & Release 継続的デリバリー (Ops)  Test シナリオテスト管理・バグトラッキングシステム ( Dev ≦ Ops ≒ QA ) 8 Dev Ops
  9. 9. VSTS/TFSはウォーターフォールでは活用できない?  メニューと用語がアジャイル・DevOps向け  そのままでは旧来のウォーターフォールでは使い方がわからない  Codeしか使われていない現場が多い 10年前の Visual SourceSafe と同じ使い方になりがち 9
  10. 10. 考え方は「前提として」ちゃんとつながっている  約40年前 ウォーターフォール (書類で管理、Windowsやパソコンが生まれる前)  約15年前 アジャイル (.NET 登場、Java が普及し始めた頃)  7年前 DevOps ( TFS 2010 DevOps対応に生まれ変わる )  現在 DevOps 2.0 へ (VSTS、Azure、クロスプラットフォーム、マイクロサービス) ※Microsoft Tech Summitより 作る物の機能・規模・複雑さの増大、スピードも求められる 書類で頑張る方法から、システムの支援を受けて効率化・自動化へ 10
  11. 11. 実は日本のウォーターフォールはもはやアジャイル!  要件、機能、実装、テストの繋がりを保って開発するも(WBS段階的詳細化)  テスト駆動開発などの開発手法を取り入れて、後工程を出来るだけ前倒し  最後まで顧客に見せないことはなく、早い段階で細かく動作をデモ  後工程になって明らかになる顧客の要望もできるだけ取り入れる  V字ではなく、WOOO... ≒ アジャイル ならば、より “アジャイルらしいウォーターフォール” で効率よくやろう! 11
  12. 12. 文書での管理からTFS画面での管理に変更できる PMBOKに出てくる文書で、  日々更新・集計するものは Work / Test に対応する画面がある 簡単入力・リアルタイムで見える化 ⇒ 報告時に書類にエクスポート  あまり変わらないものは Code に保存する Markdownはダッシュボードに表示可能 ⇒ Wordに変換可能 ウォータフォール式文書が報告や納品に必要なら その時エクスポート・変換して作成できる!(普段はTFS画面で見える化) 12
  13. 13. 開発手法・用語と人の役割の違い  アジャイル開発手法をウォーターフォールにも追加可能  単体テスト、テスト駆動開発、カンバン (必要に応じて効率化可能)  完全に対応するものは 用語 の違いに慣れるだけ  人の役割の違い • WBSの作成・設計・実装・テスト・デプロイを違う人がやる • 実質同じ人がやる • チームで適切に分担してやる  どの管理でも予定と実績の比較が必要(チームメンバーの使い方はほぼ同じ) 13
  14. 14. VSTS/TFSをウォーターフォールでも活用できる! この後、具体的に解説・・・  アジャイル・DevOps向けのメニューと用語に慣れる  TFS 簡単入力・リアルタイム見える化、報告時や納品時に文書ファイル化  人の役割に応じて、WorkとTestの使い方を明確にする  アジャイル開発手法を取り入れて、Build や Home を活用する ウォーターフォール + 継続的デリバリー ≒ DevOps だって可能 14
  15. 15. どんなチームでも VSTS/TFSの機能を フル活用して DevOps ができる! 15
  16. 16. Work による工程管理・進捗管理 ウォーターフォールとアジャイルの違いは、いつ誰がタスクを作るか? 16
  17. 17. Workの基本は「その期間に何をするか?」  誰が Assigned To  この期間(週)に Iteration  何を Task  あとどれくらいの時間で Remaining Work  やるか? やっているか? To Do / Doing / Done ( Proposed / Active / Resolved / Closed ) 開発者は自分のタスクを完了させていく 17
  18. 18. イテレーション期間は  進捗報告・確認 ・カイゼンの最小単位  ウォーターフォールなら週次報告 etc...  アジャイル・スクラムならプロダクトをリリースする最小リードタイム  開発者(チームメンバー)は期間中にタスクを完了させる  管理者は期間ごとにレポートを取得し、報告と改善を実施できる  リリース、仕掛の進捗、チームの生産性の実績、EVMの元となる実績値  バーンダウンチャート 18
  19. 19. タスクを誰が作るか?  開発者にとって「自分のタスクを完了させる」のは同じ  そのタスクを誰が・いつ・洗い出して・見積もるか? ウォーターフォールとアジャイル・スクラムでは大きく違う ここに注意すれば、どちらでもうまくWorkを使いこなせる 19
  20. 20. ウォーターフォールのタスクの管理方法(全体) プロジェクトの開始時  WBS(日付なし)階層構造で一覧化した作業項目の一覧 +見積もり工数  スケジュールとリリース (WBSに日付と人を設定) 開発中  毎日 作業を実施して、実績工数・進捗状況 を入力・集計  週次など EVM (予実の比較、CPI・SPIなどインデックス値による評価)  課題の解決・改善(問題の発見が遅れる程、対応は困難) 20
  21. 21. ウォーターフォールのタスクの管理方法(開始時1) WBS(日付なし)階層構造で一覧化した作業項目の一覧 +見積もり工数  Project でタスクの一覧を作成  大分類・中分類・小分類・・とタスクを詳細化していく  親子関係を必ず維持、 WBS番号(1.1.1など)でタスクを識別  過去の実績から、タスクの見積もり工数(時間・日数)を設定 21
  22. 22. ウォーターフォールのタスクの管理方法(開始時2) スケジュールとリリース (WBSに日付と人を設定)  タスクにリソース(作業者)をアサインする  リソースの一日の作業量をみて、 タスクに日付を設定  マイルストーン、クリティカルパスの確認  ガントチャート完成  リソースの単価とタスクの工数から見積もり金額が確定 受託開発の場合、この内容で提案&契約できれば開発開始 22
  23. 23. ウォーターフォールのタスクの管理方法(開発中1) 毎日 作業を実施して、実績工数・進捗状況 を入力・集計  作業者はガントチャートで「今日やるタスク」を確認  自分で一日の作業したタスクと作業時間と記録  作業完了後に Project Server で自分の作業時間を登録  Project Server が無いときは、Excelなどで収集して、 PMがProjectファイルに全員分の進捗を登録する(これがすごく大変) 23
  24. 24. ウォーターフォールのタスクの管理方法(開発中2) 週次など EVM (予実の比較、CPI・SPIなどインデックス値による評価)  ガントチャートのイナズマ線ではタスクごとの遅れを確認  EVMでは全体を数値で把握 日付、PV: 完了しているべきタスクの見積もり工数、EV : 完了している工数、 SPI : 予定より遅いか?早いか?、CPI : 予定より工数がかかっているか?かかっていないか? 課題の解決・改善(問題の発見が遅れる程、対応は困難)  顧客に説明してベースラインの変更(再スケジュール)これは本当にすごく大変  ウォーターフォールでもできるだけ早く問題に気づいて対応したい 24
  25. 25. ウォーターフォールのタスクを VSTS / TFS を使用して 管理するには・・・ 25
  26. 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. 27. ウォーターフォールでは Work をこう使う(開始時2) スケジュールとリリース (WBSに日付と人を設定)  これまで通りProjectで計画  タスクが、TFSのイテレーション期間のどれにあたるか?  該当するIteration Pathを設定してTFSにインポート  タスクがそのイテレーション期間に表示される  担当者もAssigned Toに設定してインポート Project ファイルをマスタースケジュールとして保管しておく 27
  28. 28. ウォーターフォールでは Work をこう使う(開発中1) 毎日 作業を実施して、実績工数・進捗状況 を入力・集計  作業者は Workで「この期間でやるタスク」を確認  Taskを開始・完了させる  作業したら Completed Workに時間を足して、Remaining Workを減らす  PMの登録作業は不要  誰でもカンバンボードで進捗をリアルタイムに確認 開発者もPMもすごく楽!それでいて、より正確な記録! 28
  29. 29. ウォーターフォールでは Work をこう使う(開発中2) 3段階でインポートしたときは、Task の作成をチームメンバーに任せる  作業者はWorkで「この期間で完成させるバックログ」を確認  バックログを完成させるために必要な全てのタスクを洗い出し、見積もる  Taskを追加  見積もり工数をTask の Remaining Work と Original Estimate に入れる PMはバックログの見積もり工数と、タスクの合計工数を比較してチェック 29
  30. 30. ウォーターフォールでは Work をこう使う(開発中3) TaskをProjectで作成するとちょっとした作業が追加で必要になったときに困る (Project の最小タスクが TFSの Task)  ウォーターフォールでタスクを足すのは変更報告が必要な場合が多い  Projectでタスクを登録しなおして、承認を得て、TFSに再インポート・・・  必ずやらなくなる・やれなくなる TFSにタスクを追加しないで作業する癖がつく、実績と乖離、TFSが使われなくなる Taskをメンバーが追加できる3段階のインポートがお勧め (Projectの最小タスクは、TFSのBacklog)  TFSタスクの追加は、Projectのタスク追加ではない(作業用の詳細化) 30
  31. 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
  32. 32. Work をインポート・エクスポートするにはクエリ  方法をスライドで解説 バックログとタスクをインポート・エクスポート Team Foundation Server と Excel・Project との連携 http://www.slideshare.net/shinichikoga355/ss-43464369 32
  33. 33. VSTS/TFS + Power BI で EVMレポートを作成できる VSTS/TFS を使いながらウォーターフォールらしい管理・報告が可能 33
  34. 34. アジャイル・スクラムでは Work をこう使う(1)  事前にバックログに要件・作業を登録  プロダクトオーナーから優先度をつけてやるべきことを挙げておく  期間の最初に「この期間でやるべきバックログ」を決める  過去の実績からバックログに見積もり時間を登録すると、TFSが計算  工数時間ではなく、チーム内で使う相対見積もりの数値  しばらく同じチームで開発すると、1期間にできる数値が分かってくる(ベロシティ)  プロダクトオーナーにバックログを宣言して期間開始 34
  35. 35. アジャイル・スクラムでは Work をこう使う(2)  毎日、チームメンバー全員で、 バックログを完成させるために必要な全てのタスクを洗い出し、見積もる (こちらは工数で良い)  Taskを追加し、見積もり工数をTask の Remaining Work に入れる  Taskを 開始・完了させる  チーム全体でタスク全部を完了できるか?毎日セルフチェックする  期間内に完成させられる工夫をチームで考える(自立した組織)  無理なことは無理と宣言する 35
  36. 36. 期間内に終わらないときはどうするか?  ウォーターフォールではそのまま  以前のIterationの作業であっても、実際に作業したときに Task を完了させる(遅延)  遅れがEVMレポートとして報告される。最終的にどこかで取り返す。  アジャイル・スクラムでは、未完成であっても完了  期間の完了時に、プロダクトオーナーにその期間で完成したものを正確に報告する  終わらなくて続けたいバックログも、 新しい別のバックログとして次の期間以降に作業する  次の期間で、他のバックログと優先度を比較する 36
  37. 37. タスクが足されて見積もりより遅延するんだけど?  チームの事実として受け入れよう  見積もりが甘い  無理なスケジュールをハラスメントで無理やり終わらせていなかったか?  スキルが不足しているメンバーをアサインした?  引継ぎが不足していた?引継ぎのコストをそもそも見積もっていなかった?  これらが顕在化 ・見える化された と理解しよう  例えば「人を足せば早くできるわけじゃない」が明確に見える化されてしまう 正しく見積もって出来ることをしよう!そのうえで工数を下げる工夫を! 37
  38. 38. Test によるシナリオテスト管理 テストケースを作成、テストを実施して、結果を記録する 38
  39. 39. Test は手動テストを扱う コードによる単体テストは Test ではなく、Code に保存して Build で扱う(※後述)  Testでは 手動テストの計画・実行・結果の記録を扱う  最新結果のチャートをHomeに表示して見える化  Test にテスト計画を追加するには Test Manager 拡張機能 ( Visual Studio Enterprise or Test Professional サブスクリプション※ or 支払い ) が必要 ※ユーザーの設定で Basic になっていないか?確認 39
  40. 40. テストケースと結果の管理  タスクが完了させて無くしていく作業  バックログが完成していく成果物・納品物(実際のファイルはCodeに保存)  テストはテストケースの一覧 + 結果の一覧 = 「今、製品は正常か?」の一覧表  必要に応じてテストを実施、再実施して、最新結果の一覧を更新していく 40
  41. 41. 要件ベースのテストスイートを作る  ウォーターフォールV字モデルを思い出してみる 後工程〇〇テストは、前工程□□をテストする・・  Work に登録されているテスト対象の機能や要件の Backlog に対応する テストスイート(テストケースの親)を作れる(一括で作成可能)  テスト計画(テストスイートの親)に 「単体テスト」や「結合テスト」などを作成  開発・修正でどの範囲をテストする・しなおすか?(トレーサビリティ) 41
  42. 42. Grid表示で簡単にテストケースとステップを登録  Excelの表のように一覧で登録できる  テストケース テストステップ アクション(操作) 期待される結果(そうならなかったら失敗とする条件) 42
  43. 43. テスト実行(成功時の流れ)  Webでも、クライアント(Test Manager)でも  テストケースを選んで開始  ステップ(アクションと期待される結果)の一覧画面が表示される  ステップのアクションに従って順に操作  期待される結果通りならステップを成功に  必要に応じてコメントを追加、画像(エビデンス)を添付 (※後述)  全ステップ成功になるとテストケースが成功になる 43
  44. 44. 期待される結果にならなかったら  ステップの結果を失敗にする その時点でテストケースは失敗になる  ステップの結果にコメントを追加 どういう結果か?詳細を記載する  ステップの結果に画像を添付  エビデンスとしてスクリーンキャプチャを保存  Windows標準のスニッピングツール、Light Cutter、OneNoteのツールなど  右クリックメニューからステップの結果に画像を添付できる  間違ってステップ(計画)に添付してしまう人が多いので注意 44
  45. 45. テストが失敗したら  バグを起票する(※後述)  開発作業中のテスト実施の場合にはバグを起票しなくてもいい  バグ起票のルールはチームで決めて、README.mdなどに書いておく  テストケースのステップの間違い・更新が必要でないか?確認  要件ベースのテストスイートなら、WorkとCodeのチェンジセット(※後述)を確認  バックログやタスクを追加して問題を解決する 45
  46. 46. テスト結果チャートをダッシュボードに表示  何パーセントが成功しているか?で、全体として正常かどうか?を判断  Homeに表示すると毎日見える  「壊れた窓効果」にならないように、テストの失敗を放置しない  テスト結果(ケースの結果、ステップの結果とコメント)のTSV形式エクスポートと 添付画像の一括ダウンロードができる Visual Studio 拡張機能あります(納品物の作成に) ※現在作成中でほぼ完成。公開準備が間に合っていないので、すぐに必要ならご連絡ください。 46
  47. 47. Work の Bug によるバグ管理 取り扱いを最初にチームで決めておく 47
  48. 48. バグの扱い方はプロジェクトでルールを決める  イテレーション期間に属する・属さない  表示の仕方を設定で変更できる  ボードのイテレーション期間に表示するかどうか?  表示はバックログと同様か?タスクと同様か?  いつバグを起票するか?(テスト失敗時常に?テストフェーズのみ?)  そのバグをどう解決するか?(次の期間?その期間?期間に関係なし?) 48
  49. 49. Work の Bug と Backlog・Taskの違い  タスク・バックログは予定のイテレーション期間内に完了させることが目的  バグは期間内・あるいは期間に関係なく追加して、完了させることが目的  開発者の使用方法はほぼ同じ  バグに直接時間を入れて完了させてもいい、  バグに関連する別のタスクを追加して完了させてもいい  管理者の集計の仕方が変わるので、チームでどちらかに決めておく必要がある 49
  50. 50. バグ チャートをダッシュボードに表示する  バグがすべて解決されているか?で、全体として正常かどうか?を判断  Homeに表示すると毎日見える  「壊れた窓効果」にならないように、テストの失敗を放置しない  Bug は Work の Backlog や Task 同様、クエリでエクスポートできる  Bug に時間を入れるときは、EVM でBacklog や Task の集計と同等に扱う (クエリを準備するときに Bug がないと忘れがち) 50
  51. 51. Code によるソースバージョン管理 継続的デリバリーのために、改めてルールを見直しておく 51
  52. 52. Work・Testと共にCodeを使用する  ソースバージョン管理  チェックインするときに、タスクに関連付ける(強制もできる)  変更セットとタスクが関連付けられるので、何のための修正なのか?明確  コメントを強制するだけでは、人の努力に依存してしまう。  仕組みでミスできなくする。  Testが失敗したとき、WorkとCodeのチェンジセットから原因をたどれる 52
  53. 53. Build & Release と共にCodeを使用する  ソースを分岐する  「テストと開発を並行で行う時は分岐必須」が常識だが...  DevOps2.0 では チェックイン 即 自動テスト&リリース  これだとメインブランチしか要らない  そうでなければ開発・メイン・自動リリース用のブランチを用意する  メインブランチにマージすると自動的に単体テスト(※後述)  開発とテストが完了して、マージしたら自動的にデプロイ(※後述) 53
  54. 54. Build & Release による継続的デリバリー 自動ビルド・自動テスト・自動デプロイを実現する 54
  55. 55. DevOpsのためにBuild & Releaseを使う  Work・Test をうまく扱える(Dev)前提で、継続的デリバリー(Ops)を実現  ソース管理に保存すると、自動ビルド・自動テストされる状態を保つ  リリースにかかる時間を限りなく0に近づける  問題が発見された時に、前のバージョンに戻すことも自動化された状態を保つ  運用やリリースに関わる課題の解決も全て Work バックログの管理で行う。  プロダクトを継続的に開発 新機能の開発・リリースを2週間程度で繰り返して、競争力を保つ 55
  56. 56. 継続的デリバリーがなければ 早いリリースを 繰り返すことは 不可能 56
  57. 57. いや、ウォータフォールでは そんなに繰り返して リリースすること ないし… 57
  58. 58. ウォータフォールでの継続的デリバリー  開発したらすぐに検証用サーバー・Azure にリリースして動作確認  テストチームにテストを依頼するときに、必ず最新のプログラムにしたい  週次の定例会議で、ちょっとお客様に動きを見てもらいたい(≒アジャイル) V時の最後のリリースだけが継続的デリバリーの対象ではない! 58
  59. 59. 自動テスト(コードによる単体テスト)が前提  C#/Visual Basic 全てのメソッドに単体テストを作成  Codeに保存  DevOpsでは必須  プログラムを書き換えて自分でテストを実行すると、壊れていないか?確認できる  チーム開発で、メインブランチにマージしたときに、壊れていないか?確認できる  単体テストが無ければ、壊れたまま自動リリースされてしまう可能性 あるいは全シナリオテストをやりおなおし必須に 59
  60. 60. 単体テストに求められること  引数と期待される結果の全バターンを網羅的にテスト  メソッドを使う機能や画面のシナリオテストで、パターン網羅は現実的でない  VSTS/TFS で動作する必要がある  SQL Server、SharePoint サーバーなどに接続可能なテスト  あるいは接続しないで実行できる設計(依存性の注入)  Fakes(DateTime.Now を置き換える など)  実行順に依存しない・どの単体テストも単独で実行できること 60
  61. 61. 単体テストが作れる開発の方法  単体テスト出来るアプリの作り方を スライド&サンプルで解説しています 「ちゃんとした C# プログラムを書けるようになる実践的な方法 ~ Visual Studio を使った 高品質・低コスト・保守性の高い開発」 http://www.slideshare.net/shinichikoga355/starting-c-sharp  技術イケメン(経験者)にチームに参加してもらって 一緒に2ヶ月程度開発できるとマスターできるはず! 61
  62. 62. ビルドとリリースをこう使う  ビルド定義で自動ビルド・自動テスト (よりDev側)  どのソースコードをビルドするか?  単体テストを実行するか?  パッケージの作成や検証サーバーなどへのデプロイも可能  リリース定義でビルド後に承認ワークフロー・デプロイ(よりOps側)  承認すると検証⇒ステージング⇒本番 62
  63. 63. まとめ  VSTS / TFS で出来るのはDevOps = ウォータフォール or アジャイル(≒Dev)+ 継続的デリバリー(≒Ops)  ウォーターフォールでは Projectをマスターとして Work / Test を使う  アジャイル・スクラムでは Work / Test をマスターとして使う  Work / Test / Code と単体テストを使いこなしている前提で、 Build & Releaseを使うと継続的デリバリーが実現できる 63
  64. 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 64
  65. 65. Copyright© 2016 Shin-ichi Koga All Rights Reserved. 65

×