プロセスの選択Choose a process

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

プロジェクトを作成するときは常に、使用するプロセスモデルに基づいてプロセステンプレートまたはプロセステンプレートを選択する必要があります。Anytime you create a project, you must choose a process or process template based on the process model you use.

  • プロセス は、作業項目トラッキングシステムの構成要素を定義し、Azure Boards の継承プロセスモデルをサポートします。A process defines the building blocks of the work item tracking system and supports the Inheritance process model for Azure Boards. このモデルでは、WYSIWYG ユーザーインターフェイスを使用したプロジェクトのカスタマイズがサポートされています。This model supports customization of projects through a WYSIWYG user interface.
  • プロセステンプレート では、作業項目トラッキングシステムの構成要素のほか、Azure Boards またはオンプレミスの Azure DevOps Server または TEAM FOUNDATION SERVER (TFS) を使用してアクセスするその他のサブシステムを定義します。A process template defines the building blocks of the work item tracking system as well as other sub-systems you access through Azure Boards or an on-premises Azure DevOps Server or Team Foundation Server (TFS). XML 定義ファイルの変更とインポートによってプロジェクトのカスタマイズをサポートする、ホストされた XML およびオンプレミスの XML プロセスモデルをサポートします。It supports Hosted XML and On-premises XML process models which support customization of projects through the modification and import of XML definition files.

注意

ビジネスニーズをサポートするためのプロジェクトとチームの構成とカスタマイズに関するガイダンスについては、「 Azure Boards の構成とカスタマイズ」を参照してください。For guidance on configuring and customizing your project and teams to support your business needs, review Configuration and customization of Azure Boards.

選択したプロセスを使用してプロジェクトを作成する方法の詳細については、「 プロジェクトを作成する」を参照してください。For details on creating a project using the process of your choice, see Create a project. プロセスモデルの詳細については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。To learn more about process models, see Customize your work tracking experience.

ヒント

Azure DevOps Server では、継承されたプロセスモデルとオンプレミスの XML プロセスモデルのどちらを使用するかを選択できます。With Azure DevOps Server, you can choose between using the Inherited process model or the On-premises XML process model. 詳細については、「作業追跡エクスペリエンスのカスタマイズ」を参照して、 プロジェクトコレクションのプロセスモデルを選択してください。For details, see Customize your work tracking experience, Choose the process model for your project collection. 既定のプロセスまたはプロセステンプレートの最新バージョンにアクセスするには、次の手順を実行します。To access the latest versions of the default processes/process templates:

ヒント

既定のプロセステンプレートの最新バージョンにアクセスするには、次の手順を実行します。To access the latest versions of the default process templates:

既定のプロセスとプロセステンプレートの — 基本、アジャイル、CMMI、およびスクラムに含まれる作業追跡オブジェクトは同じであり、 — 以下にまとめられています。The work tracking objects contained within the default processes and process templates—Basic, Agile, CMMI, and Scrum—are the same and are summarized below. 基本プロセスは Azure DevOps Server 2019.1 以降のバージョンから入手できます。The Basic process is available from Azure DevOps Server 2019.1 and later versions. わかりやすくするために、"プロセス" と呼ばれています。For simplicity, they are referred to as a "process."

ヒント

継承されたプロセスモデルを表示および管理するには、「 プロセスの管理」を参照してください。To view and manage Inherited process models, see Manage processes.

Basic、Agile、スクラム、CMMIBasic, Agile, Scrum, and CMMI

既定のプロセスは、主に、作業の計画と追跡のために用意されている作業項目の種類 (Wit) で異なります。The default processes differ mainly in the work item types (WITs) they provide for planning and tracking work.

Basic は最も軽量で、選択的なプレビューに含まれています。Basic is the most lightweight and is in a selective Preview. スクラムは、次の最も明るいウェイトです。Scrum is the next most light-weight. アジャイルでは多くのアジャイルメソッドがサポートされており、CMMI は能力成熟度モデルの統合を意味します。これは、正式なプロセスおよび変更管理を最も多くサポートしています。Agile supports many Agile method terms, and CMMI, which stands for Capability Maturity Model Integration, provides the most support for formal processes and change management.

注意

基本プロセスは、 Azure DevOps Server 2019 Update 1 以降のバージョンで使用できます。The Basic process is available with Azure DevOps Server 2019 Update 1 and later versions.

アジャイル、スクラム、CMMIAgile, Scrum, and CMMI

既定のプロセスは、主に、作業の計画と追跡のために用意されている作業項目の種類 (Wit) で異なります。The default processes differ mainly in the work item types (WITs) they provide for planning and tracking work. スクラムは、次の最も明るいウェイトです。Scrum is the next most light-weight. アジャイルでは多くのアジャイルメソッドがサポートされており、CMMI は能力成熟度モデルの統合を意味します。これは、正式なプロセスおよび変更管理を最も多くサポートしています。Agile supports many Agile method terms, and CMMI, which stands for Capability Maturity Model Integration, provides the most support for formal processes and change management.

チームに最適なプロセスを選択します。Choose the process that provides the best fit for your team.

注意

エピックは、Azure Boards および TFS 2015 以降のバージョンでサポートされています。Epics are supported on Azure Boards and TFS 2015 and later versions. 各チームは、「 チームのバックログナビゲーションレベルの選択」で説明されているように、アクティブなバックログレベルを選択できます。Each team can choose the backlog levels that are active as described in Select backlog navigation levels for your team.

BasicBasic

問題、タスク、およびエピックを使用して作業を追跡する最も単純なモデルをチームが希望する場合は、[ Basic ] を選択します。Choose Basic when your team wants the simplest model that uses Issues, Tasks, and Epics to track work. 注: 現在、Basic は、Azure Boards の新規ユーザーの場合にのみ、選択的プレビューになっています。Note: Basic is currently in a selective Preview for new users of Azure Boards only.

タスクは、残存作業の追跡をサポートします。Tasks support tracking Remaining Work.

Basic work item types

アジャイルAgile

スクラムを含むアジャイル計画手法をチームで使用し、開発とテストのアクティビティを個別に追跡する場合は、[ アジャイル ] を選択します。Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately. このプロセスは、かんばんボードでユーザーストーリーと (必要に応じて) バグを追跡したり、タスクボードでバグやタスクを追跡したりする場合に適しています。This process works great if you want to track user stories and (optionally) bugs on the Kanban board, or track bugs and tasks on the taskboard.

アジャイルな手法の詳細については、 アジャイルアライアンスに関するページを参照してください。You can learn more about Agile methodologies at the Agile Alliance.

タスクは、最初の見積もり、残存作業、実績作業の追跡をサポートします。Tasks support tracking Original Estimate, Remaining Work, and Completed Work.

Agile work item types

スクラムScrum

チームがスクラムを使用する場合は、 スクラム を選択します。Choose Scrum when your team practices Scrum. このプロセスは、かんばんボード上の製品バックログ項目 (Pis) とバグを追跡する場合や、タスクボード上で Pis とバグをタスクに分割する場合に適しています。This process works great if you want to track product backlog items (PBIs) and bugs on the Kanban board, or break PBIs and bugs down into tasks on the taskboard.

このプロセスは、 スクラム組織によって定義されたスクラム手法をサポートしています。This process supports the Scrum methodology as defined by the Scrum organization.

タスクは、残存作業のみの追跡をサポートします。Tasks support tracking remaining work only.

Scrum work item types

CMMICMMI

プロセスの改善と監査可能な意思決定の記録のフレームワークを必要とする、より正式なプロジェクト方法にチームが従う場合は、 CMMI を選択します。Choose CMMI when your team follows more formal project methods that require a framework for process improvement and an auditable record of decisions. このプロセスでは、要件、変更要求、リスク、およびレビューを追跡できます。With this process, you can track requirements, change requests, risks, and reviews.

このプロセスでは、 正式な変更管理アクティビティがサポートされます。This process supports formal change management activities. タスクは、最初の見積もり、残存作業、実績作業の追跡をサポートします。Tasks support tracking Original Estimate, Remaining Work, and Completed Work.

CMMI work item types

2 ~ 3 つのバックログレベルが必要な場合は、使用するプロセスモデルに基づいてさらに追加することができます。If you need more than two or three backlog levels, you can add more based on the process model you use:

既定のプロセス間の主な違いMain distinctions among the default processes

既定のプロセスは、ほとんどのチームのニーズを満たすように設計されています。The default processes are designed to meet the needs of most teams. チームで通常とは異なるニーズが発生し、オンプレミスサーバーに接続している場合は、プロセスをカスタマイズしてから、プロジェクトを作成することができます。If your team has unusual needs and connects to an on-premises server, you can customize a process and then create the project. または、プロセスからプロジェクトを作成し、プロジェクトをカスタマイズすることもできます。Or, you can create a project from a process and then customize the project.

次の表は、3つの既定のプロセスで使用される Wit と states の主な違いをまとめたものです。The following table summarizes the main distinctions between the WITs and states used by the three default processes.

追跡領域 Tracking area 基本的な Basic アジリティ Agile スクラム Scrum CMMI CMMI
ワークフロー状態Workflow states
  • 作業予定To Do
  • 実行中Doing
  • 完了Done
  • 新規New
  • アクティブActive
  • 解決済みResolved
  • 解決済みClosed
  • 削除済みRemoved
  • 新規New
  • ApprovedApproved
  • CommittedCommitted
  • 完了Done
  • 削除済みRemoved
  • 提案Proposed
  • アクティブActive
  • 解決済みResolved
  • 解決済みClosed
製品計画 (メモ 1 を参照)Product planning (see note 1)
  • 問題Issue
  • ユーザー ストーリーUser story
  • バグ (オプション)Bug (optional)
  • プロダクト バックログ項目Product backlog item
  • バグ (オプション)Bug (optional)
  • 要件Requirement
  • バグ (オプション)Bug (optional)
ポートフォリオバックログ (2)Portfolio backlogs (2)
  • エピックEpic
  • エピックEpic
  • 機能Feature
  • エピックEpic
  • 機能Feature
  • エピックEpic
  • 機能Feature
タスクおよびスプリントの計画 (3)Task and sprint planning (3)
  • タスクTask
  • タスクTask
  • バグ (オプション)Bug (optional)
  • タスクTask
  • バグ (オプション)Bug (optional)
  • タスクTask
  • バグ (オプション)Bug (optional)
バグのバックログの管理 (1)Bug backlog management (1)
  • 問題Issue
  • BugBug
  • BugBug
  • BugBug
問題とリスク管理Issue and risk management
  • 問題Issue
  • 問題Issue
  • 障害Impediment
  • 問題Issue
  • リスクRisk
  • 確認Review

注:Notes:

  1. これらの Wit は、 プロダクトバックログ または かんばんボードから追加できます。You can add these WITs from the product backlog or Kanban board. プロダクトバックログには、動的に順序を変更してグループ化できる、作業の現在のバックログの1つのビューが表示されます。The product backlog shows a single view of the current backlog of work that can be dynamically re-ordered and grouped. 製品所有者は、作業の優先順位をすばやく設定し、依存関係と関係の概要を設定できます。Product owners can quickly prioritize work and outline dependencies and relationships.

    また、各チームは、 バックログとボードにバグをどのように表示するかを構成できます。Also, each team can configure how they want bugs to show up on their backlogs and boards.

  2. ポートフォリオ バックログを使用すると、複数のバックログから成る階層を定義できます。これにより、複数のチーム間にまたがる作業のスコープを理解し、その作業がどのようにより広い構想につながるかを見定めることができます。With portfolio backlogs you can define a hierarchy of backlogs to understand the scope of work across several teams and see how that work rolls up into broader initiatives. 各チームは 、使用するポートフォリオバックログを構成できます。Each team can configure which portfolio backlogs appear for their use.

  3. スプリントバックログとタスクボードからタスクを定義できます。You can define tasks from the sprint backlog and taskboard. キャパシティプランニングを使用すると、チームはスプリントのキャパシティを超過しているか下回るかをすばやく判断できます。With capacity planning, teams can quickly determine if they are over or under capacity for a sprint.

ワークフローの状態、遷移、および理由Workflow states, transitions, and reasons

ワークフロー状態は、新規状態から終了状態または完了状態に至る、作業の状態の追跡をサポートします。Workflow states support tracking the status of work as it moves from a new state to a closed or a done state. 各ワークフローは、一連の状態、状態から状態へ有効な遷移、および選択された状態に作業項目が遷移する理由から構成されます。Each workflow consists of a set of states, the valid transitions between the states, and the reasons for transitioning the work item to the selected state.

重要

Azure DevOps Services と Azure DevOps Server 2019 の場合、既定のワークフローの遷移では、任意の状態遷移に対して任意の状態がサポートされます。For Azure DevOps Services and Azure DevOps Server 2019, the default workflow transitions support any state to any state transition. これらのワークフローをカスタマイズして、一部の遷移を制限できます。「 チームのプロセスをサポートするための作業トラッキングオブジェクトのカスタマイズ」を参照してください。You can customize these workflows to restrict some transitions .See Customize work tracking objects to support your team's processes.

また、 状態モデルの視覚化 のマークされた場所の拡張機能をインストールすることによって、各作業項目の種類に対してサポートされているワークフロー遷移を表示できます。Also, you can view the supported workflow transitions for each work item type by installing the State Model Visualization Markeplace extension. この拡張機能は、[ 状態ビジュアライザー] というラベルの付いた新しいハブを追加します。This extension adds a new hub under Boards labeled State Visualizer. このページでは、作業項目の種類を選択し、ワークフローの状態モデルを表示できます。On that page you can choose a work item type and view the workflow state model.

次の図は、3つの既定のプロセスの作業とコード障害を追跡するために使用される、これらの Wit の一般的な前進方向を示しています。The following diagrams show the typical forward progression of those WITs used to track work and code defects for the three default processes. また、以前の状態への回帰や、削除状態への遷移も示しています。They also show some of the regressions to former states and transitions to removed states. 各イメージは、遷移に関連付けられている既定の理由のみを示しています。Each image shows only the default reason associated with the transition.

エピック、懸案事項、タスク階層Epic, Issue, Task hierarchy

Basic process work item hierarchy

エピック、懸案事項、タスクワークフローEpic, Issue, Task workflow

Basic process workflow

注意

基本プロセスは、Azure DevOps Services または Azure DevOps Server 2019.1から新しいプロジェクトを作成するときに使用できます。The Basic process is available when you create a new project from Azure DevOps Services or Azure DevOps Server 2019.1. 以前のオンプレミスのデプロイでは、[アジャイル]、[スクラム]、または [CMMI プロセス] を選択します。For earlier on-premises deployments, choose Agile, Scrum, or CMMI process.

バックログとボードに表示されるアジャイルツールで使用されるほとんどの Wit は、任意の遷移をサポートします。Most WITs used by Agile tools, ones that appear on backlogs and boards, support any-to-any transitions. かんばんボードまたはタスクボードを使用して作業項目の状態を更新するには、対応する [状態] 列にドラッグします。You can update the status of a work item using the Kanban board or the taskboard by dragging it to its corresponding state column.

追加の状態、遷移、および理由をサポートするためにワークフローを変更できます。You can change the workflow to support additional states, transitions, and reasons. 詳細については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。To learn more, see Customize your work tracking experience.

削除状態、終了状態、および完了状態Removed, Closed, and Done states

作業項目の状態を「削除」、「終了」、または「完了」に変更すると、システムは次のように応答します。When you change the state of a work item to Removed, Closed, or Done, the system responds like this:

  • [終了] または [完了]: この状態の作業項目は、ポートフォリオバックログとバックログページに表示されません。Closed or Done: Work items in this state don't appear on the portfolio backlog and backlog pages. ただし、これらはスプリントバックログページ、かんばんボード、および taskboard に表示されます。However, they do appear on the sprint backlog pages, Kanban board, and taskboard. また、バックログ項目を表示するようポートフォリオ バックログ ビューを変更する場合 (たとえばプロダクト バックログ項目の機能を表示する場合)、終了状態と完了状態の項目が表示されます。Also, when you change the portfolio backlog view to show backlog items, for example, to view Features to Product Backlog Items, items in the closed and done state will appear.
  • 削除: この状態の作業項目は、どのバックログまたはボードにも表示されません。Removed: Work items in this state don't appear on any backlog or board.

プロジェクトがアクティブであれば、作業項目はプロジェクトで保持されます。Work items are maintained in a project as long as the project is active. それを終了、完了、または削除に設定した場合でも、レコードがデータ ストアに保持されます。Even if you set them to Closed, Done, or Removed, a record is kept in the data store. レコードを使用してクエリまたはレポートを作成することができます。You can use a record to create queries or reports.

作業項目を完全に削除する必要がある場合は、「 作業項目を削除または削除する」を参照してください。If you need to permanently delete work items, see Remove or delete work items.

すべてのプロセスに追加された作業項目の種類Work item types added to all processes

次の Wit は、基本プロセス以外のすべてのプロセスに追加されます。The following WITs are added to all processes except the Basic process.

Test Plans、Microsoft テストマネージャー、担当作業、およびフィードバックによって使用される作業項目の種類

チームは、対応するツールを使用して、次の種類を作成して操作します。Teams create and work with these types using the corresponding tool:

  • テスト計画、テストスイート、テストケース共有ステップ、および共有パラメーター: Microsoft Test Manager。Test Plan, Test Suite, Test Case Shared Steps, and Shared Parameters: Microsoft Test Manager.
  • フィードバック要求とフィードバック応答: フィードバックの要求。Feedback Request and Feedback Response: Request feedback.
  • コード レビューの要求とコード レビューの応答: 担当作業 (チーム エクスプローラーから) とコード レビュー要求。Code Review Request and Code Review Response: My Work (from Team Explorer) and Code Review Request.

これらの種類の定義から作成される作業項目は、手動による作成は想定されていないため、隠し型カテゴリに追加されます。Work items from these type definitions are not meant to be created manually and therefore are added to the Hidden Types category. [非表示の種類] カテゴリに追加された作業項目の種類は、新しい作業項目の作成に使用されるメニューに表示されません。Work item types that are added to the Hidden Types category don't appear in the menus used to create new work items.

注意

プロジェクトを TFS 2013 またはそれ以前のバージョンから新しいバージョンの TFS にアップグレードした場合、以前のバージョンには存在しない Wit を追加することが必要になる場合があります。If you upgraded your project from TFS 2013 or an earlier version to a later version of TFS, you might have to add WITs that didn't exist in the earlier versions. 詳細については、「 TFS のアップグレード後の機能の構成」を参照してください。For more information, see Configure features after a TFS upgrade.

次の Wit は、指定された TFS バージョンで追加されました。The following WITs were added with the indicated TFS version:

  • TFS 2013.2 で追加された共有パラメーターShared Parameters added with TFS 2013.2
  • TFS 2013.3 で追加されたテスト計画とテストスイートTest Plan and Test Suite added with TFS 2013.3

テスト エクスペリエンスをサポートする WITWITs that support the test experience

テストエクスペリエンスをサポートし、Test Manager と web ポータルを操作する Wit は、次の図に示すリンクの種類を使用してリンクされます。WITs that support the test experience and work with Test Manager and the web portal are linked together using the link types shown in the following picture.

作業項目の種類 [テスト管理]

Web ポータルまたは Microsoft Test Manager から、テストスイートに対して定義されているテストケースと、テスト計画用に定義されているテストスイートを表示できます。From the web portal or Microsoft Test Manager, you can view which test cases are defined for a test suite, and which test suites are defined for a test plan. ただし、これらのオブジェクトはリンクの種類を使用して相互に接続されていません。However, these objects aren't connected to each other through link types. 他の WIT と同様に、これらの WIT もカスタマイズできます。You can customize these WITs as you would any other WIT. チームのプロセスをサポートするための作業トラッキングオブジェクトのカスタマイズ」を参照してください。See Customize work tracking objects to support your team's processes.

テスト計画とテスト スイートのワークフローを変更する場合、ここでの説明に従ってプロセス構成の更新が必要になることがあります。If you change the workflow for the test plan and test suite, you might need to update the process configuration as described here. 各テストフィールドの定義については、「 ビルドとテストの統合フィールドに基づくクエリ」を参照してください。For definitions of each test field, see Query based on build and test integration fields.

このプロセスを使用するプロジェクトを作成する前または後に、プロセスをカスタマイズできます。You can customize a process before or after you create a project that uses the process. 使用する方法は、使用するプロセスモデルによって異なります。The methods you use depend on the process model you use. 詳細については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。To learn more, see Customize your work tracking experience.

その他の質問がある場合は、 Azure DevOps のサポートページを参照してください。If you have additional questions, see Azure DevOps support page.