ソフトウェア開発ライフサイクルのデータテンプレート

Azure DevOps
ソフトウェア開発ライフサイクルのデータテンプレート

ソフトウェア開発ライフサイクルのデータテンプレート

このテンプレートでは、ソフトウェア開発ライフサイクルのデータをプロセスマイニングに適した形で準備するための手順を示します。収集すべき基本的なデータ属性、追跡すべき主要なアクティビティ、Azure DevOpsから情報を抽出する方法を説明しています。この資料を使ってデータを正しく整え、プロセスを詳しく分析し、改善につなげてください。
  • 収集を推奨する属性
  • SDLCで追跡すべき主要なアクティビティ
  • Azure DevOpsからデータを抽出する詳しい手順
イベントログを初めて扱いますか。学ぶ プロセスマイニングのイベントログを作成する方法.

ソフトウェア開発ライフサイクルの属性

ソフトウェア開発ライフサイクルを詳細に分析・最適化するため、イベントログに含めることを推奨するデータ項目です。
5 必須 7 推奨 6 任意
名前 説明
アクティビティ名
ActivityName
作業項目の開発ライフサイクルにおいて、特定の時点で発生したイベントまたはタスクの名称です。
説明

アクティビティ名は、「Development Started」、「Pull Request Created」、「Deployed to Production」など、プロセス内の具体的なステップまたはマイルストーンを表します。作業項目の状態変更、ビルドやPull Requestなどの関連イベント、またはカスタムイベントから生成されます。

この属性は、ワークフローを視覚的に表すプロセスマップの作成に欠かせません。アナリストはイベントの順序を把握し、一般的な経路を特定し、特定のアクティビティ間のボトルネックを見つけ、各ステップの頻度を分析できます。

重要な理由

プロセス内のステップを定義し、プロセスマップの基盤となります。ワークフロー、ボトルネック、逸脱を分析できます。

入手先

通常は、作業項目の「State」フィールドの変更、またはビルド、コミット、Pull Requestなどの関連イベントから生成されます。これらのイベントの生のデータは、Work Item Historyから取得されます。

開発を開始Pull Requestを完了QAテスト失敗本番環境にデプロイ済み作業項目クローズ
イベント時刻
EventTime
開発項目で特定のアクティビティまたはイベントが発生した正確なタイムスタンプです。
説明

イベント時刻には、開発ライフサイクルにおける各アクティビティの日付と時刻が記録されます。このタイムスタンプは、イベントを時系列に並べ、イベント間の期間を算出するための基本的な時間情報です。

分析では、サイクルタイム、処理時間、待ち時間など、時間に基づくすべての指標を算出するうえで重要です。時間順に並んだイベントログを作成できるため、あらゆるプロセスマイニング分析に必要な入力になります。遅延の原因を特定し、SLAに対するパフォーマンスを測定し、時間の経過に伴う傾向を追跡する際にも使われます。

重要な理由

イベントの時系列を示します。期間に基づくすべてのKPIを算出し、プロセスフローとボトルネックを把握するうえで欠かせません。

入手先

作業項目の履歴にある各更新の「Changed Date」です。ビルドやデプロイなどの外部イベントでは、そのイベントの完了時刻です。

2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
開発項目
DevelopmentItem
機能、バグ、ユーザーストーリーなど、1つの作業単位を識別する一意の識別子です。プロセスではケース識別子として使用されます。
説明

開発項目は、Azure DevOpsで追跡される個別の作業単位を表します。一意のIDで識別される各項目は、作成と計画から開発、テスト、デプロイまで、すべてのプロセスアクティビティの中心となるオブジェクトです。

プロセスマイニング分析では、この属性が関連するすべてのイベントを1つのケースに関連付ける基盤になります。各作業項目のエンドツーエンドのライフサイクルを再構成できるため、項目ごとのサイクルタイム、プロセス逸脱、手戻りループを分析できます。

重要な理由

すべてのプロセスステップを一貫したケースに結び付ける中核識別子です。ソフトウェア開発ライフサイクルをエンドツーエンドで分析できます。

入手先

Azure DevOps Boardsの作業項目にある「ID」フィールドに対応します。Work Item Tracking用のAzure DevOps REST APIから取得できます。

10234102351023610237
ソースシステム
SourceSystem
プロセスデータを抽出したシステムです。この場合はAzure DevOpsです。
説明

データの取得元システムを識別する属性です。複数のシステムからのデータを統合し、より広いプロセスの全体像を把握する環境で特に役立ちます。このモデルでは、値は常にAzure DevOpsです。

単一システムの分析では固定値に見える場合がありますが、データの出所に関する重要なコンテキストを提供します。データガバナンス、トラブルシューティング、ServiceNowやSAPなど他のシステムとの将来的な統合に欠かせません。

重要な理由

データの出所に関する重要なコンテキストを提供します。データガバナンス、検証、複数システムにまたがるプロセス分析に役立ちます。

入手先

データの抽出・変換処理で追加し、データセットを識別する静的な値です。

Azure DevOps
最終データ更新
LastDataUpdate
ソースシステムからこのプロセスのデータが最後に更新された時刻を示すタイムスタンプです。
説明

データセットがAzure DevOpsから最後に抽出・更新された時刻を記録します。データの鮮度と、分析対象となる期間を明確に示します。

プロセス分析では、データがいつ更新されたかを把握することが、適切な意思決定に欠かせません。このタイムスタンプにより、リアルタイム情報を見ているのか、過去のスナップショットを見ているのかを判断できます。これは分析結果の有効性に影響します。

重要な理由

データの鮮度を示し、把握した期間に基づいて分析と意思決定を行えるようにします。

入手先

データの抽出、変換、ロード(ETL)処理で生成・保存されるメタデータのタイムスタンプです。

2024-05-20T08:00:00Z
チーム名
TeamName
作業項目を担当する開発チームの名称です。
説明

作業項目が割り当てられている特定のチームを識別します。Azure DevOpsでは、より大きなプロジェクトの一部としてチーム単位で作業を整理することがよくあります。

この属性により、チーム別にプロセスを分析できます。異なるチームのプロセスとパフォーマンスを比較し、高い成果を上げているチームのベストプラクティスを特定し、特定のチームに必要な支援やプロセス改善の領域を見つける際に役立ちます。

重要な理由

チーム間の比較分析が可能になり、パフォーマンスの違いを特定し、組織全体でベストプラクティスを共有できます。

入手先

多くの場合、作業項目の「Area Path」から導出されます。Azure DevOpsでは、通常、チームと特定のエリアパスが対応付けられています。

Team PhoenixOmega SquadPlatform CoreFrontend Crew
作業項目の種類
WorkItemType
Bug、Feature、User Story、Taskなど、開発項目の分類です。
説明

作業項目の種類は、実施する作業の性質を分類します。種類によって異なるプロセス経路やパフォーマンス目標、SLAが設定されることがあります。たとえば、「Bug」は「Feature」よりも優先度の高い経路で処理される場合があります。

この属性は比較分析に欠かせません。作業項目の種類でプロセスマップやKPIを絞り込み、バグと機能のどちらのプロセスが効率的かを比較したり、作業カテゴリごとの過去のサイクルタイムの傾向を追跡したりできます。

重要な理由

プロセス分析を分割し、バグや機能など、作業カテゴリごとのワークフローとパフォーマンスを比較できます。

入手先

Azure DevOpsの作業項目にある「Work Item Type」フィールドに対応します。

バグ機能ユーザーストーリータスク
優先度
Priority
他の項目と比較した、開発項目の重要度を示す数値または説明的な順位です。
説明

優先度は、作業項目をスケジュールする際の重要度を示します。優先度が高い項目ほど、優先度の低い項目よりも早く対応することが期待されます。一般的には1、2、3、4などの数値で表し、1が最も高い優先度です。

この属性は、Priority-Based Throughput & Cycle Timeダッシュボードに欠かせません。この属性でデータを分析すると、優先順位付けの仕組みが機能しているか、つまり優先度の高い項目が実際に低い項目よりも速くプロセスを通過しているかを確認できます。

重要な理由

優先度の高い項目をプロセス内で適切に優先処理できているかを分析できます。優先順位付けの施策が成功しているかを評価するうえで重要です。

入手先

Azure DevOpsの作業項目にある「Priority」フィールドに対応します。

1234
手戻りかどうか
IsRework
開発項目がライフサイクルの以前の段階に再び戻ったかどうかを示すブール値のフラグです。
説明

作業項目に手戻りループがある場合にtrueになります。たとえば、「QA Testing Completed」から「Development Started」に戻った場合です。ケース内のアクティビティの順序を分析し、直線的でない進行を検出して算出されます。

この属性は、Rework and Retesting FrequencyダッシュボードとRework Loop Frequency KPIに欠かせません。手戻りを簡単に絞り込み、定量化できるため、非効率につながる品質問題、コミュニケーション不足、テスト不足を特定できます。

重要な理由

手戻りを直接特定・定量化し、サイクルタイムを長期化させる品質問題やプロセスの非効率を明らかにします。

入手先

各ケースのイベントログにあるアクティビティの順序を分析して導出する計算属性です。

truefalse
担当者
AssignedTo
開発項目を現在担当しているユーザーまたはチームメンバーです。
説明

プロセスの各段階で作業項目を担当する個人を識別する属性です。項目のライフサイクルを通じて、開発者からテスター、さらにリリースマネージャーへと、担当者が何度も変わる場合があります。

「担当者」による分析は、Developer and Tester Workload Overviewダッシュボードに欠かせません。リソース配分を把握し、負荷が高いチームメンバーを特定し、個人またはチーム間のパフォーマンスの違いを分析できます。

重要な理由

リソース単位の分析が可能になり、作業負荷の分布を把握し、リソース固有のボトルネックを特定し、チームのキャパシティを管理できます。

入手先

Azure DevOpsの作業項目にある「Assigned To」フィールドに対応します。各イベントの値は、作業項目の履歴から取得されます。

jane.doe@example.comjohn.smith@example.com未割り当て
状態
State
「New」、「Active」、「Resolved」、「Closed」など、ワークフロー内における開発項目の現在のステータスです。
説明

状態属性は、プロジェクトのプロセステンプレートで定義された、作業項目の時点ごとの正式なステータスを表します。これらの状態間の遷移が、イベントログのアクティビティを生成する主な情報源です。

「Activity」属性は状態変更をより詳しく表すことが多い一方、生の「State」属性も絞り込みや分析に役立ちます。項目が特定の状態に滞在した時間を把握でき、Stage Durationダッシュボードの作成や引き継ぎの分析に欠かせません。

重要な理由

ライフサイクルにおける作業項目のステータスを示します。プロセスフローを把握し、各段階で費やした時間を算出するための基盤になります。

入手先

Azure DevOpsの作業項目にある「State」フィールドに対応します。

新規アクティブQA中解決済みクローズ
終了時刻
EndTime
アクティビティが完了した時刻を示すタイムスタンプです。アクティビティの処理時間を算出するために使われます。
説明

終了時刻は、アクティビティの完了時点を示します。多くのイベントログでは、次のアクティビティの開始時刻を前のアクティビティの終了時刻として扱います。ただし、独立した終了時刻があれば、アクティビティの処理時間とアクティビティ間のアイドル時間をより正確に算出できます。

この属性は、ProcessingTime KPIの算出と詳細なボトルネック分析に欠かせません。タスクに実際に取り組んでいた時間と、次のステップの開始を待っていた時間を区別できます。これは、Stage Handoff Analysisダッシュボードにおける重要な分析要素です。

重要な理由

アクティビティの処理時間とアイドル時間を正確に算出できます。ボトルネック分析と効率改善の基盤になります。

入手先

多くの場合、導出される値です。同じケースの後続イベントの開始時刻を使うことも、ソースシステムがタスクの開始時刻と終了時刻の両方を記録している場合は、その値を直接使うこともできます。

2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
イテレーションパス
IterationPath
作業項目が割り当てられている開発スプリントまたは期間です。
説明

イテレーションパス、つまりスプリントは、開発を行う特定の期間を表します。作業項目は、その期間内に完了するようイテレーションに割り当てられます。

イテレーションパスで分析すると、スプリント単位でプロセスのパフォーマンスを把握できます。スプリントを重ねるごとにサイクルタイムが改善しているか、持ち越し作業がどの程度あるか、スプリント計画の予測可能性がどの程度かを評価できます。

重要な理由

スプリント単位の分析が可能になり、チームが時間の経過に伴うパフォーマンスを評価し、アジャイルプラクティスを改善できます。

入手先

Azure DevOpsの作業項目にある「Iteration Path」フィールドに対応します。

E-Commerce Platform\Sprint 12E-Commerce Platform\Sprint 13Mobile App Relaunch\Phase 2\Sprint 4
ステージ引き継ぎ時間
StageHandoffTime
主要ステージの完了から次のステージの開始までに発生するアイドル時間の長さです。
説明

ステージ引き継ぎ時間は、連続するプロセスステージ間の待ち時間を測定します。たとえば、「Development Completed」から「QA Testing Started」までの時間です。主要な遷移を特定し、最初のアクティビティの終了から次のアクティビティの開始までの時間差を測定して算出します。

この指標は、Stage Duration and Handoff Analysisダッシュボードの中心となります。引き継ぎ時間を切り分けて測定することで、リソース不足、コミュニケーションの遅れ、非効率なプロセスなどによって作業が滞留する、見えにくいボトルネックを特定できます。

重要な理由

プロセスステージ間の待ち時間を定量化し、実作業に含まれない隠れたボトルネックや遅延を直接明らかにします。

入手先

計算属性です。引き継ぎを表す連続したアクティビティの組み合わせを特定し、その間の時間差を算出する必要があります。

2時間15分1日4時間30分
プルリクエストID
PullRequestId
開発項目に関連付けられたPull Requestの識別子です。
説明

コード変更を提出・レビューする仕組みである特定のPull Requestと作業項目を関連付ける属性です。1つの作業項目に複数のPull Requestが関連付けられる場合があります。

Pull Request IDがあれば、ライフサイクルにおけるコードレビューと統合の工程をより詳細に分析できます。Pull Requestの作成から完了までの時間を測定し、Pull Requestが却下された頻度や大幅な変更を必要とした頻度を分析できます。これは、コード品質や要件の不明確さを示す指標になる場合があります。

重要な理由

開発作業を具体的なコードレビューアクティビティに結び付け、コード統合と品質保証プロセスを詳細に分析できます。

入手先

Azure DevOpsの作業項目にある「Links」または「Development」セクションで確認できます。

452145334589
プロジェクト名
ProjectName
開発項目が属するAzure DevOpsプロジェクトの名称です。
説明

作業項目が存在するAzure DevOps組織内の特定のプロジェクトを識別します。多数のプロジェクトを持つ組織では、全体像を把握するために特に役立ちます。

プロジェクト名は、絞り込みと比較に使う重要な分析軸です。Historical Cycle Time Trendsダッシュボードでプロジェクト別に分析できるため、特定のプロジェクトの効率が他より高いか低いか、またはあるプロジェクトでのプロセス改善が良い影響をもたらしたかを確認できます。

重要な理由

分析における大分類を提供し、プロジェクト間のパフォーマンス比較と傾向分析を可能にします。

入手先

Azure DevOpsの作業項目にある「Team Project」フィールドに対応します。

E-Commerce PlatformMobile App RelaunchData Warehouse Modernization
承認待ち時間
ApprovalWaitingTime
承認を依頼してから、開発項目が承認を待っている時間です。
説明

作業項目が承認待ちになっている特定の期間を測定します。代表的な例は、「UAT Started」から「UAT Approved」までの時間です。ケース内のこの2つのアクティビティ間の時間を測定して算出します。

この計算属性は、Approval Waiting Time Analysisダッシュボードと対応するKPIを直接支援します。こうした遅延を切り分けることで、チームはコミュニケーションと意思決定のプロセスを改善し、アイドル時間を減らしてライフサイクル全体を短縮できます。

重要な理由

意思決定や承認を待つことによる遅延を具体的に測定し、コミュニケーションと意思決定プロセスを改善する機会を明らかにします。

入手先

イベントログから承認に関する特定の開始アクティビティと終了アクティビティ(例:「UAT Started」と「UAT Approved」)を見つけ、その時間差を算出します。

3日2時間1日8時間30分4時間
重大度
Severity
バグまたは問題がシステムやエンドユーザーに与える影響を示します。
説明

重大度は、重大なシステム障害から軽微な外観上の問題まで、バグの影響を分類するために使われます。作業の順序を決める優先度とは異なります。たとえば、回避策がすぐに利用できる場合、重大度の高いバグでも優先度が低くなることがあります。

この属性は、特にPriority-Based Throughput & Cycle Timeダッシュボードで、別の分析軸を提供します。「最も重大なバグから修正できているか」といった問いを検証し、処理中の作業が抱えるリスクの傾向を把握できます。

重要な理由

作業項目を業務への影響度で分類し、影響の大きい問題にチームがどれだけ効果的に対応しているかを分析できます。

入手先

通常はバグに対して使用される、Azure DevOpsの作業項目にある「Severity」フィールドに対応します。

1:重大2:高3:中4:低
必須 推奨 任意

ソフトウェア開発ライフサイクルのアクティビティ

正確なプロセス発見とボトルネック特定を行うため、イベントログに記録すべき主要なプロセス手順とマイルストーンです。
7 推奨 8 任意
アクティビティ 説明
Pull Requestを作成
開発者が初期コーディングを完了し、Pull Requestを通じて変更をレビューに提出したことを示します。このイベントにより、作業項目とAzure Repos内の特定のコード変更が関連付けられます。
重要な理由

開発からコードレビューへの重要な引き継ぎです。これを追跡することで、コーディングにかかった時間を測定し、コードがピアレビューに進める状態になった時点を把握できます。

入手先

Azure Reposのデータから、Pull Requestの作成イベントを関連する作業項目に紐付けて取得します。通常は開発者が明示的にリンクします。

取得

作業項目にリンクされたAzure ReposのPull Request作成イベントから取得されます。

イベントタイプ explicit
Pull Requestを完了
コードレビューが正常に完了し、Pull Requestが承認され、コードが対象ブランチにマージされたことを示します。このイベントはAzure Reposに明示的に記録されます。
重要な理由

一般的なボトルネックであるコードレビュー工程の終了を示します。Pull Requestの作成から完了までの時間を分析することで、レビューサイクルの効率を把握できます。

入手先

作業項目にリンクされたAzure ReposのPull Requestの完了またはマージイベントから取得されます。

取得

作業項目にリンクされたPull Requestのマージイベントから取得されます。

イベントタイプ explicit
QAテストを開始
正式な品質保証テスト工程の開始を示します。作業項目の状態が「QA中」、「テスト中」などの値に変更された時点から推定します。
重要な理由

QAサイクルの開始を示します。この工程の所要時間を分析することは、テストのボトルネックと効率を把握するうえで重要です。

入手先

作業項目の履歴を確認し、System.Stateフィールドが「In QA」または指定された別のテスト状態に変更されたことから推定されます。

取得

Stateフィールドが「In QA」または「Testing」に変更されたことから推定されます。

イベントタイプ inferred
UAT承認
ユーザー受け入れテスト後に、業務部門の関係者が変更内容を承認したことを示します。通常は、「In UAT」から「UAT Approved」または「Ready for Release」への状態変更から推定されます。
重要な理由

作業項目が業務要件を満たし、本番環境へのデプロイ準備が整ったことを確認する、重要な承認マイルストーンです。

入手先

作業項目の履歴で、System.StateフィールドがUAT状態から承認済みまたはリリース準備完了の状態に変更されたことを検出して推定されます。

取得

Stateフィールドが「In UAT」から「Ready for Release」に変更されたことから推定されます。

イベントタイプ inferred
作業項目を作成
このアクティビティは開発ライフサイクルの開始を示し、ユーザーストーリー、バグ、タスクなどの新しい作業項目の作成を表します。Azure DevOps Boardsで新しいレコードが保存された時点で明示的に記録されます。
重要な理由

このイベントはプロセスの主要な開始イベントです。エンドツーエンドの開発サイクルタイムを測定し、作業が発生した最初の要因を把握するために欠かせません。

入手先

このイベントは、作業項目自体の「作成日」から取得されます。作業項目の履歴テーブルにも、この初期状態への遷移が記録されます。

取得

作業項目の「作成日」フィールドから取得されます。

イベントタイプ explicit
本番環境にデプロイ済み
作業項目に関連付けられたコードが本番環境に正常にデプロイされたことを示します。Azure Pipelinesのリリースログから明示的なイベントとして記録されます。
重要な理由

価値の提供を示す重要なマイルストーンです。リードタイムとサイクルタイムを算出する際の終点になります。

入手先

Azure Pipelinesのリリースパイプラインデータから取得されます。具体的には、作業項目に関連付けられた「Production」ステージへのデプロイ完了イベントです。

取得

リリースパイプラインのデプロイ完了イベントから取得されます。

イベントタイプ explicit
開発を開始
開発者が作業項目に着手したことを示します。作業項目の状態が「アクティブ」、「進行中」、「コミット済み」などに変更されたことから推定します。
重要な理由

アクティブな開発工程の開始を示します。「作成」から「開発を開始」までの時間を分析することで、バックログの待ち時間を把握できます。

入手先

作業項目の履歴で、System.Stateフィールドが「新規」または「承認済み」から「進行中」に変更された時点から推定します。

取得

Stateフィールドが「アクティブ」または「進行中」に変更されたことから推定します。

イベントタイプ inferred
QAテスト失敗
作業項目が品質保証テストに失敗し、開発に差し戻されたことを示します。テスト状態から「In Progress」または「Active」状態に戻る状態変更によって記録されます。
重要な理由

このアクティビティは、手戻りループを特定するうえで欠かせません。このイベントの頻度が高い場合、コード品質、要件、またはテストプロセスに問題がある可能性があります。

入手先

作業項目の履歴を確認し、「In QA」のような状態から「Active」または「In Progress」のような状態へ移行したことから推定されます。

取得

Stateフィールドが「In QA」から「Active」に変更されたことから推定されます。

イベントタイプ inferred
QAテスト完了
品質保証フェーズが正常に完了したことを示します。テスト状態から「Ready for UAT」または「QA Approved」のような状態に変更された場合に推定されます。
重要な理由

項目がユーザー受け入れテストまたはリリースの準備を整えたことを示す、重要な品質ゲートです。この後に遅延が発生している場合、UATまたはリリース計画にボトルネックがある可能性があります。

入手先

作業項目の履歴で、System.Stateフィールドが「In QA」から「Ready for UAT」や「Done」などの後続状態に変更されたことから推定されます。

取得

Stateフィールドが「In QA」から「Ready for UAT」に変更されたことから推定されます。

イベントタイプ inferred
UAT開始
業務部門の関係者が機能を検証する、ユーザー受け入れテストの開始を示します。通常は、状態が「In UAT」または同様のステータスに変更されたことから推定されます。
重要な理由

リリース前に行う最終検証の開始時点を測定します。プロセスを効率化するには、UATの期間と承認待ち時間を分析することが重要です。

入手先

作業項目の履歴で、System.Stateフィールドが「In UAT」など、UATを表すカスタム状態に更新されたことから推定されます。

取得

Stateフィールドが「In UAT」に変更されたことから推定されます。

イベントタイプ inferred
ビルドに成功
新しい変更を含むソースコードが、ビルドパイプラインによって正常にコンパイルおよびパッケージ化されたことを確認するアクティビティです。Azure Pipelinesが明示的に記録するイベントです。
重要な理由

新しいコードが正しく統合され、ビルドを壊していないことを確認する重要な品質ゲートとして機能します。この段階での失敗は、統合上の問題を示す可能性があります。

入手先

Azure Pipelinesのビルド完了イベントから取得します。ビルドは、直接または関連するPull Requestを介して、作業項目にリンクされている必要があります。

取得

Azure Pipelinesのビルド完了イベントから取得されます。

イベントタイプ explicit
作業項目キャンセル
作業項目がキャンセルされ、完了またはデプロイされないことを示します。「Removed」、「Cancelled」または同様の状態への変更によって記録されます。
重要な理由

プロセスが正常に完了しない場合の、別の終点を示します。キャンセルされた項目を分析すると、計画、優先順位付け、または要件定義に関する問題を明らかにできます。

入手先

作業項目の履歴で、System.Stateフィールドが「Removed」カテゴリの終端状態に変更されたことから推定されます。

取得

Stateフィールドが「Removed」または「Cancelled」に変更されたことから推定されます。

イベントタイプ inferred
作業項目クローズ
デプロイとデプロイ後の検証を終え、作業項目を最終的にクローズしたことを示します。「Closed」または「Done」への状態変更によって記録されます。
重要な理由

作業項目に関するプロセス全体が正常に完了したことを示す、最終アクティビティです。ライフサイクルの確定した終点になります。

入手先

作業項目の履歴で、System.Stateフィールドが「Closed」または「Completed」カテゴリの同様の終端状態に変更されたことから推定されます。

取得

Stateフィールドが「Closed」に変更されたことから推定されます。

イベントタイプ inferred
作業項目を承認
作業項目が正式に承認され、内容が明確で開発に進める状態であることを示します。通常は、「状態」フィールドが「承認済み」や「開発準備完了」などの値に変更されたことから推定します。
重要な理由

承認を追跡することで、アイデアの提出から開発着手の決定までにかかる時間を分析できます。計画やバックログの整理における遅延の可能性も明らかになります。

入手先

作業項目の履歴でSystem.Stateフィールドが「承認済み」または類似するカスタム状態に変更されたことを検出して推定します。

取得

Stateフィールドが「承認済み」に変更されたことから推定します。

イベントタイプ inferred
開発を完了
開発と単体テストのすべてのアクティビティが完了し、正式なテストに進める状態であることを示します。通常は、作業項目の状態が「解決済み」または「テスト準備完了」に変更されたことから推定します。
重要な理由

開発チームからQAチームへの主要な引き継ぎを示します。「QAテストを開始」までの時間を測定することで、引き継ぎの遅延を特定できます。

入手先

作業項目の履歴で、System.Stateフィールドが「解決済み」や、QAの準備完了を示すカスタム状態などに変更されたことから推定します。

取得

Stateフィールドが「解決済み」に変更されたことから推定します。

イベントタイプ inferred
推奨 任意

抽出ガイド

Azure DevOpsからデータを取得する方法

準備はできましたか?

ソフトウェア開発ライフサイクルの改善を、今日から始めてください。このテンプレートが、プロセスに関する価値ある情報を得るための第一歩になります。

Azure DevOpsでSDLCを最適化しましょう。今すぐ開始できます。

サイクルタイムを30%短縮し、SDLCワークフローのボトルネックを解消します。

無料トライアルを開始

クレジットカードは不要です。数分で始められます。