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

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

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

このテンプレートでは、プロセスマイニングに向けてソフトウェア開発ライフサイクルのデータを準備する手順を示します。収集が必要なデータ属性や追跡する主要なアクティビティを説明し、Azure DevOpsからデータを抽出する方法も案内します。分析に適した形式にデータを整え、プロセスの改善に役立てるためにご利用ください。
  • 収集を推奨する属性
  • SDLCで追跡する主要なアクティビティ
  • Azure DevOpsからのデータ抽出手順
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

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

ソフトウェア開発ライフサイクルを詳しく分析し、改善するために、イベントログへの追加を推奨するデータ項目です。
5 必須 7 推奨 6 任意
名前 説明
アクティビティ名
ActivityName
作業項目の開発ライフサイクルにおいて、特定の時点で発生したイベントまたはTaskの名前です。
説明

アクティビティ名は、「開発開始」「プルリクエストの作成」「本番環境へのデプロイ」など、プロセス内の具体的なステップやマイルストーンを表します。作業項目の状態変更、ビルドやプルリクエストなどの関連イベント、またはカスタムイベントから導出されます。

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

重要な理由

プロセスの各ステップを定義し、プロセスマップの基盤となります。ワークフロー、ボトルネック、逸脱の分析にも役立ちます。

入手先

通常は、作業項目の「状態」フィールドの変更、またはビルド、コミット、プルリクエストなどの関連イベントから導出されます。作業項目の履歴が、これらのイベントの生のデータとなります。

例
開発開始プルリクエストの完了QAテスト失敗本番環境へのデプロイ作業項目のクローズ
イベント時刻
EventTime
開発項目に関する特定のアクティビティまたはイベントが発生した正確な日時です。
説明

イベント時刻には、開発ライフサイクルにおける各アクティビティの日時が記録されます。このタイムスタンプを基準にイベントを時系列に並べ、イベント間の所要時間を算出します。

サイクルタイム、処理時間、待ち時間など、時間に関するすべての指標を算出するうえで、この属性は欠かせません。時系列に並んだイベントログを作成できるため、プロセスマイニング分析に必要なデータを整えられます。また、遅延の原因調査、SLAに対するパフォーマンスの測定、経時的な傾向の追跡にも使います。

重要な理由

イベントの時系列を示すタイムスタンプです。所要時間に基づくすべての重要業績評価指標(KPI)の算出や、プロセスの流れとボトルネックの把握に欠かせません。

入手先

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

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

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

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

重要な理由

すべてのプロセスステップを1つのケースとして結び付ける基本の識別子であり、ソフトウェア開発ライフサイクルのエンドツーエンド分析を可能にします。

入手先

Azure DevOps Boardsの作業項目にある「ID」フィールドに対応します。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では、プロジェクト内の作業をチームごとに整理することが多く、チームは大規模なプロジェクトの一部として編成される場合もあります。

この属性を使うと、チーム別にプロセスを分析できます。チーム間のプロセスやパフォーマンスを比較し、成果を上げているチームの取り組みを見つけたり、特定のチームに必要な支援や改善点を把握したりするのに役立ちます。

重要な理由

チーム間の比較分析が可能になり、組織内のパフォーマンスの違いを把握して、優れた取り組みを共有できます。

入手先

Azure DevOpsではチームを特定のエリアパスに割り当てることが多いため、作業項目の「エリアパス」から取得する場合があります。

例
チーム・フェニックスオメガ・スクワッドプラットフォーム・コアフロントエンド・クルー
作業項目の種類
WorkItemType
バグ、機能、ユーザーストーリー、Taskなど、開発項目の分類です。
説明

作業項目の種類は、実施する作業の内容を分類します。種類によってプロセスの経路やパフォーマンスの目標、SLAが異なることがあります。たとえば、「バグ」は「機能」よりも迅速に処理する経路をたどる場合があります。

この属性は比較分析に欠かせません。作業の種類ごとにプロセスマップや重要業績評価指標(KPI)を絞り込み、バグと機能のどちらをより効率的に処理できているかを把握したり、カテゴリ別に過去のサイクルタイムの傾向を追跡したりできます。

重要な理由

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

入手先

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

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

優先度は、作業項目の着手順を決める際の重要度を示します。優先度が高い項目は、低い項目より早く対応する必要があります。一般的には1、2、3、4などの数値で表し、1が最も高い優先度です。

この属性は、優先度別スループットとサイクルタイムのダッシュボードに欠かせません。属性ごとにデータを分析すると、優先順位付けが適切に機能しているか、つまり優先度の高い項目が低い項目より実際に速くプロセスを進んでいるかを確認できます。

重要な理由

優先度の高い項目がプロセス内で優先的に処理されているかを分析でき、優先順位付けの有効性を評価するうえで役立ちます。

入手先

Azure DevOpsの作業項目にある「優先度」フィールドに該当します。

例
1234
割り当て先
AssignedTo
現在、開発項目が割り当てられているユーザーまたはチームメンバーです。
説明

この属性は、プロセスの各段階で作業項目を担当する人を示します。ライフサイクルの途中で、開発者からテスター、リリースマネージャーへと、担当者が何度も変わることがあります。

「割り当て先」で分析すると、開発者・テスターの作業負荷概要ダッシュボードに役立ちます。リソース配分の把握、チームメンバーの負荷集中の特定、個人やチーム間のパフォーマンスの違いの分析に使えます。

重要な理由

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

入手先

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

例
jane.doe@example.comjohn.smith@example.com未割り当て
手戻りの有無
IsRework
開発項目がライフサイクルの前の段階に戻ったかどうかを示す真偽値です。
説明

作業項目に手戻りのループが見られる場合、このフラグはtrueになります。たとえば、「QAテスト完了」から「開発開始」に戻るケースです。ケース内のアクティビティの順序を分析し、直線的でない進行を検出して算出します。

この属性は、手戻りと再テスト頻度のダッシュボード、および手戻りループ頻度のKPIに欠かせません。手戻りを簡単に絞り込み、件数を把握できるため、非効率につながる品質上の問題、連携不足、テスト不足の特定に役立ちます。

重要な理由

手戻りを直接特定して件数を把握でき、サイクルタイムを延ばす品質上の問題やプロセスの非効率を明らかにできます。

入手先

ケースごとのイベントログに記録されたアクティビティの順序を分析して算出する属性です。

例
truefalse
状態
State
ワークフロー内における開発項目の現在の状態です。「新規」「アクティブ」「解決済み」「クローズ」などがあります。
説明

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

「アクティビティ」属性は状態の変化をより詳しく表すことが多い一方、生の「状態」属性もフィルタリングや分析に役立ちます。各状態に費やした時間を把握できるため、ステージ所要時間ダッシュボードの作成や引き継ぎの分析に欠かせません。

重要な理由

ライフサイクルにおける作業項目の状態を示します。プロセスの流れを把握し、各段階にかかった時間を算出するうえで基本となる情報です。

入手先

Azure DevOpsの作業項目にある「状態」フィールドに該当します。

例
新規アクティブQA中解決済みクローズ
終了時刻
EndTime
アクティビティが完了した日時です。アクティビティの処理時間の算出に使います。
説明

終了時刻は、アクティビティの完了時点を示します。多くのイベントログでは、次のアクティビティの開始時刻を前のアクティビティの終了時刻として扱います。一方、終了時刻を個別に記録すると、アクティビティの処理時間とアクティビティ間の待ち時間をより正確に算出できます。

処理時間の重要業績評価指標(KPI)の算出や、詳細なボトルネック分析に欠かせない属性です。Taskに実際に取り組んだ時間と、次のステップが始まるまでの待ち時間を区別できます。これは、工程間引き継ぎ分析ダッシュボードで重要な情報です。

重要な理由

アクティビティの処理時間と待ち時間を正確に算出できます。ボトルネック分析や効率改善の基礎となる情報です。

入手先

多くの場合、値は導出されます。同じケースの次のイベントの開始時刻を使う方法と、ソースシステムがTaskの開始時刻と終了時刻の両方を記録している場合に、その値を使う方法があります。

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

イテレーションパス(スプリント)は、期間を区切って開発を進める単位です。作業項目は、期間内に完了するようイテレーションに割り当てられます。

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

重要な理由

スプリント単位で分析できるため、チームの経時的なパフォーマンスを評価し、アジャイル開発の進め方を改善できます。

入手先

Azure DevOpsの作業項目にある「イテレーションパス」フィールドに該当します。

例
ECプラットフォーム\スプリント12ECプラットフォーム\スプリント13モバイルアプリのリニューアル\フェーズ2\スプリント4
プルリクエストID
PullRequestId
開発項目に関連付けられたプルリクエストの識別子です。
説明

この属性は、作業項目と特定のプルリクエストを関連付けます。プルリクエストは、コード変更を提出してレビューするための仕組みです。1つの作業項目に複数のプルリクエストが関連付けられる場合があります。

プルリクエストIDがあれば、ライフサイクルのうちコードレビューと統合の部分を詳しく分析できます。プルリクエストの作成から完了までの時間を測定したり、却下されたり大幅な変更が必要になったりする頻度を調べたりできます。こうした情報は、コードの品質や要件の明確さを判断する手がかりになります。

重要な理由

開発作業と個々のコードレビューを関連付け、コードの統合や品質保証のプロセスを詳しく分析できます。

入手先

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

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

この属性は、作業項目が属するAzure DevOps組織内のプロジェクトを特定します。多数のプロジェクトを持つ組織では、全体を把握するための情報になります。

プロジェクト名は、フィルタリングや比較に欠かせない分析軸です。過去のサイクルタイム推移ダッシュボードでプロジェクトごとに分析できるため、プロジェクト間の効率の違いや、あるプロジェクトでの改善が成果につながったかを確認できます。

重要な理由

分析対象を大きく分類でき、プロジェクト間のパフォーマンス比較や傾向分析に役立ちます。

入手先

Azure DevOpsの作業項目にある「チームプロジェクト」フィールドに該当します。

例
ECプラットフォームモバイルアプリのリニューアルデータウェアハウスの近代化
承認待ち時間
ApprovalWaitingTime
開発項目が承認を申請してから、承認を待つ時間です。
説明

この指標は、作業項目が承認待ちとなっている特定の期間を測定します。たとえば、「UAT開始」から「UAT承認」までの時間です。対象のケースで、この2つのアクティビティ間の時間を測定して算出します。

この属性は、承認待ち時間分析のダッシュボードと対応するKPIに直接役立ちます。こうした遅延を切り分けることで、チームは連絡や意思決定の進め方を見直し、待ち時間を減らしてライフサイクル全体を短縮できます。

重要な理由

意思決定や承認を待つことによる遅延を測定し、連絡や意思決定のプロセスを改善できる箇所を明らかにします。

入手先

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

例
3日2時間1日8時間30分4時間
段階間の引き継ぎ時間
StageHandoffTime
主要な段階の完了から次の段階の開始までに発生する待ち時間です。
説明

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

この指標は、段階所要時間と引き継ぎ分析のダッシュボードで確認できます。引き継ぎ時間を切り分けて測定すると、リソース不足、連絡の遅れ、非効率なプロセスなどによって作業が止まっている、見えにくいボトルネックを特定できます。

重要な理由

プロセスの段階間に生じる待ち時間を数値化し、作業そのものにかかる時間とは別の、見えにくいボトルネックや遅延を明らかにします。

入手先

引き継ぎに該当する連続したアクティビティの組み合わせを特定し、その間の時間差を算出する属性です。

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

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

この属性を加えることで、特に優先度別スループットとサイクルタイムのダッシュボードで、分析の切り口を増やせます。「最も重大なバグから修正できているか」といった問いを検証し、処理中の作業に伴うリスクを把握できます。

重要な理由

作業項目をビジネスへの影響度で分類し、影響の大きい問題にチームがどれだけ適切に対応しているかを分析できます。

入手先

Azure DevOpsの作業項目、通常はバグにある「重大度」フィールドに該当します。

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

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

プロセスを正確に把握し、ボトルネックを特定するために、イベントログに記録する主要なプロセスの段階とマイルストーンです。
7 推奨 8 任意
アクティビティ 説明
QAテスト開始
正式な品質保証テストの開始を示します。作業項目の状態が「QA中」「テスト中」などに変わったことから判断します。
重要な理由

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

入手先

作業項目の履歴で、System.Stateフィールドが「QA中」または指定された別のテスト状態に変わったことを追跡して判断します。

記録

Stateフィールドが「QA中」または「テスト中」に変わったことから判断します。

イベントタイプ inferred
UAT承認
ユーザー受け入れテスト後に、業務関係者が変更を承認したことを示します。通常は、状態が「UAT中」から「UAT承認済み」または「リリース準備完了」に変わったことから判断します。
重要な理由

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

入手先

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

記録

Stateフィールドが「UAT中」から「リリース準備完了」に変わったことから判断します。

イベントタイプ inferred
プルリクエストの作成
開発者が初期のコーディングを終え、プルリクエストを通じて変更をレビューに提出したことを示します。このイベントによって、作業項目とAzure Repos内の特定のコード変更が関連付けられます。
重要な理由

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

入手先

Azure Reposのデータから、プルリクエストの作成イベントを関連する作業項目に紐付けて取得します。多くの場合、開発者が明示的にリンクします。

記録

作業項目に紐付けられたAzure Reposのプルリクエスト作成イベントから取得します。

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

ボトルネックになりやすいコードレビュー工程の終了を示します。プルリクエストの作成から完了までの時間を分析すると、レビューサイクルの効率を把握できます。

入手先

作業項目に紐付けられたAzure Reposのプルリクエストについて、完了またはマージのイベントから取得します。

記録

作業項目に紐付けられたプルリクエストのマージイベントから取得します。

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

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

入手先

作業項目自体の「作成日」から取得します。作業項目の履歴テーブルにも、最初の状態遷移が記録されます。

記録

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

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

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

入手先

Azure Pipelinesのリリースパイプラインデータから取得します。具体的には、作業項目に紐付けられた「本番」ステージへのデプロイ完了イベントを使用します。

記録

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

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

開発の実作業が始まった時点を示します。「作成」から「開発開始」までの時間を分析すると、バックログでの待ち時間がわかります。

入手先

作業項目の履歴で、System.Stateフィールドが「新規」または「承認済み」から「進行中」に変わったことを検出して判断します。

記録

Stateフィールドが「アクティブ」または「進行中」に変わったことから判断します。

イベントタイプ inferred
QAテスト失敗
作業項目が品質保証テストに不合格となり、開発に差し戻されたことを示します。テスト状態から「進行中」または「アクティブ」に戻った状態変更によって記録されます。
重要な理由

手戻りの繰り返しを特定するうえで欠かせないアクティビティです。このイベントが頻繁に発生する場合、コード品質、要件、テストプロセスに問題がある可能性があります。

入手先

作業項目の履歴で、「QA中」などの状態から「アクティブ」や「進行中」などに戻った遷移を検出して判断します。

記録

Stateフィールドが「QA中」から「アクティブ」に戻ったことから判断します。

イベントタイプ inferred
QAテスト完了
品質保証工程が正常に完了したことを示します。作業項目の状態がテスト状態から「UAT準備完了」や「QA承認済み」などに変わったことから判断します。
重要な理由

ユーザー受け入れテストまたはリリースに進める状態になったことを示す重要な品質ゲートです。この後の遅延は、UATやリリース計画のボトルネックを示している可能性があります。

入手先

作業項目の履歴で、System.Stateフィールドが「QA中」から「UAT準備完了」や「完了」などの次の状態に変わったことから判断します。

記録

Stateフィールドが「QA中」から「UAT準備完了」に変わったことから判断します。

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

リリース前の最終検証が始まった時点を測定します。プロセスを改善するには、UATの所要時間と承認待ち時間の分析が欠かせません。

入手先

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

記録

Stateフィールドが「UAT中」に変わったことから判断します。

イベントタイプ inferred
ビルド成功
新しい変更を含むソースコードが、ビルドパイプラインで正常にコンパイルされ、パッケージ化されたことを示します。このイベントはAzure Pipelinesに明示的に記録されます。
重要な理由

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

入手先

Azure Pipelinesのビルド完了イベントから取得します。ビルドは、作業項目に直接、または関連するプルリクエストを通じて紐付ける必要があります。

記録

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

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

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

入手先

作業項目の履歴で、System.Stateフィールドが「削除済み」カテゴリの最終状態に変わったことから判断します。

記録

Stateフィールドが「削除済み」または「キャンセル済み」に変わったことから判断します。

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

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

入手先

作業項目の履歴で、System.Stateフィールドが「完了」カテゴリの「クローズ」または同様の最終状態に変わったことから判断します。

記録

Stateフィールドが「クローズ」に変わったことから判断します。

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

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

入手先

作業項目の履歴から、System.Stateフィールドが「承認済み」または同様のカスタム状態に変わったことを検出して判断します。

記録

Stateフィールドが「承認済み」に変わったことから判断します。

イベントタイプ inferred
開発完了
開発と単体テストがすべて完了し、正式なテストに進める状態になったことを示します。通常は、作業項目の状態が「解決済み」や「テスト準備完了」に変わったことから判断します。
重要な理由

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

入手先

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

記録

Stateフィールドが「解決済み」に変わったことから判断します。

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

データ抽出ガイド

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

始める準備はできていますか?

ソフトウェア開発ライフサイクルの改善を今日から始めましょう。このテンプレートは、プロセスに関する有用なインサイトを得るための第一歩です。

Azure DevOpsでSDLCを改善しましょう。今日から始められます。

サイクルタイムを30%短縮し、SDLCのワークフローからボトルネックをなくしましょう。

無料トライアルを開始しましょう

クレジットカードは不要です。数分で利用を開始できます。