ソフトウェア開発ライフサイクルデータ``テンプレート
ソフトウェア開発ライフサイクルデータ``テンプレート
- 収集を推奨する項目
- SDLCで追跡すべき主要な活動
- Azure DevOpsの詳細な抽出`ガイダンス`
ソフトウェア開発ライフサイクルの属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
ワークアイテムの開発ライフサイクル内で、特定の時点で発生したイベントまたはタスクの名前。 | ||
|
説明
アクティビティ名とは、「開発開始」、「プルリクエスト作成済み」、「本番環境へデプロイ済み」など、プロセスにおける特定のステップやマイルストーンを記述します。これらの活動は、ワークアイテムの状態変更、ビルドやプルリクエストなどのリンクされたイベント、またはカスタムイベントから派生します。 この属性は、ワークフローを視覚的に表現するプロセスマップを構築するために不可欠です。これにより、アナリストはイベントのシーケンスを理解し、共通の経路を特定し、特定の活動間のボトルネックを発見し、各ステップの頻度を分析することができます。
その重要性
プロセスの各ステップを定義し、プロセスマップの基盤を形成することで、ワークフロー、ボトルネック、および逸脱の分析を可能にします。
取得元
これは通常、ワークアイテムの「状態」フィールドの変更、またはビルド、コミット、プルリクエストなどのリンクされたイベントから導出されます。ワークアイテム履歴はこれらのイベントの生データを提供します。
例
開発開始プルリクエスト完了QAテスト失敗本番環境に`デプロイ`済みワークアイテムクローズ済み
|
|||
|
イベント日時
EventTime
|
開発アイテムの特定の活動またはイベントが発生した正確なタイムスタンプ。 | ||
|
説明
分析において、この
その重要性
このタイムスタンプはイベントの時系列順序を提供し、すべての期間ベースのKPIを計算し、プロセスフローとボトルネックを理解するために不可欠です。
取得元
これは、ワークアイテムの履歴における各更新に関連付けられた「変更日」です。ビルドやデプロイなどの外部イベントの場合、それはそのイベントの完了タイムスタンプです。
例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
開発アイテム
DevelopmentItem
|
機能、バグ、ユーザー ストーリーなど、単一の作業単位の一意の識別子であり、プロセスのケース識別子として機能します。 | ||
|
説明
開発アイテムとは、Azure DevOps内で追跡される個別の作業を表します。一意のIDによって識別される各アイテムは、作成と計画から開発、テスト、デプロイに至るまで、すべてのプロセス活動が中心となるオブジェクトです。 プロセスマイニング分析において、この属性はすべての関連イベントを単一のケースジャーニーに相関させるための基本です。これにより、各ワークアイテムのエンドツーエンドのライフサイクルを再構築し、個々のアイテムベースでのサイクルタイム、プロセス逸脱、および手戻りループの分析を可能にします。
その重要性
これは、すべてのプロセスステップを一貫したケースに連結する中核的な識別子であり、ソフトウェア開発ライフサイクルのエンドツーエンド分析を可能にします。
取得元
これは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では、作業は多くの場合チームによって編成され、これはより大きなプロジェクトのサブセットとなり得ます。 この属性により、チームごとにプロセス分析をセグメント化することができます。異なるチーム間でプロセスとパフォーマンスを比較したり、高パフォーマンスのチームにおけるベストプラクティスを特定したり、特定のチームがサポートやプロセス改善を必要とする領域を見つけたりする上で非常に価値があります。
その重要性
異なるチーム間の比較分析を可能にし、パフォーマンスのばらつきを特定し、組織全体でベストプラクティスを共有するのに役立ちます。
取得元
これは、Azure DevOpsではチームが通常特定のエリアパスにマッピングされているため、ワークアイテムの「エリアパス」から導出されることが多いです。
例
チームフェニックスオメガスコードプラットフォームコア`フロントエンド`クルー
|
|||
|
ワークアイテムタイプ
WorkItemType
|
バグ、機能、ユーザー ストーリー、タスクなど、開発アイテムの分類。 | ||
|
説明
ワークアイテムタイプとは、実行されている作業の性質を分類します。異なる種類のワークアイテムは、多くの場合、異なるプロセスパスをたどり、異なるパフォーマンス期待値やSLAを持ちます。例えば、「バグ」は「機能」と比較して迅速なパスをたどることがあります。 この属性は、比較分析に不可欠です。これにより、プロセスマップやKPIを作業の種類でフィルタリングして、特定のプロセスがバグと機能のどちらに対してより効率的であるかを理解したり、異なるカテゴリの作業に対する履歴サイクルタイムトレンドを追跡したりすることができます。
その重要性
プロセス分析のセグメンテーションを可能にし、バグや機能など異なる作業カテゴリのワークフローとパフォーマンスを比較できます。
取得元
これはAzure DevOpsのワークアイテムにおける「ワークアイテムタイプ」フィールドに対応します。
例
バグ`フィーチャー`ユーザーストーリータスク
|
|||
|
優先度
Priority
|
他のアイテムと比較した開発アイテムの重要度を示す数値または記述的な`ランキング`。 | ||
|
説明
優先度とは、ワークアイテムのスケジューリング上の重要性を示します。優先度が高いほど、低い優先度のアイテムよりも迅速に対処されるべきであることを示唆します。一般的な値は1、2、3、4のような数値で、1が最も高い優先度です。 この属性は、優先度ベースのスループット&サイクルタイムダッシュボードに不可欠です。この属性を持つデータを分析することで、優先順位付けシステムが効果的であるか、つまり高優先度のアイテムが低優先度のアイテムよりも実際にプロセスを迅速に通過しているかを判断するのに役立ちます。
その重要性
このプロセスが高優先度アイテムを効果的に迅速化しているかを分析でき、優先順位付け戦略の成功を評価する上で重要です。
取得元
これはAzure DevOpsのワークアイテムにおける「優先度」フィールドに対応します。
例
1234
|
|||
|
割り当て先
AssignedTo
|
開発アイテムが現在割り当てられているユーザーまたはチームメンバー。 | ||
|
説明
この属性は、プロセスの特定の段階におけるワークアイテムの担当者を識別します。割り当ては、アイテムのライフサイクルを通じて、例えば開発者からテスターへ、そしてリリース管理者へと複数回変更されることがあります。 「割り当て先」による分析は、開発者とテスターのワークロード概要ダッシュボードにとって極めて重要です。これにより、リソースの割り当てを理解し、過負荷のチームメンバーを特定し、個人やチーム間のパフォーマンスの違いを分析するのに役立ちます。
その重要性
リソースベースの分析を可能にし、ワークロードの分散を理解し、特定のリソースに起因するボトルネックを特定し、チームのキャパシティを管理するのに役立ちます。
取得元
これはAzure DevOpsのワークアイテムにおける「Assigned To」フィールドに対応します。値は各イベントのワークアイテム履歴から捕捉されます。
例
jane.doe@example.comjohn.smith@example.com未割り当て
|
|||
|
手戻り
IsRework
|
開発アイテムがライフサイクル内で前の段階に再`エントリー`したかどうかを示す`ブール`値の`フラグ`。 | ||
|
説明
ワークアイテムが手戻りループ、例えば「QAテスト完了」から「開発開始」へ戻る動きを示した場合、このフラグはtrueに設定されます。これは、ケースのアクティビティのシーケンスを分析し、非線形の進行を検出することによって計算されます。 この属性は、手戻りおよび再テスト頻度ダッシュボードと手戻りループ頻度KPIにとって不可欠です。手戻りを簡単にフィルタリングし定量化することを可能にし、品質問題、コミュニケーションギャップ、または非効率性につながるテスト不足を特定するのに役立ちます。
その重要性
手戻り作業を直接特定し定量化することで、品質問題やサイクルタイムを延長させるプロセス上の非効率性を浮き彫りにするのに役立ちます。
取得元
これは、各ケースのイベントログにおける活動のシーケンスを分析することで導出される計算属性です。
例
truefalse
|
|||
|
状態
State
|
「新規」、「アクティブ」、「解決済み」、「クローズ済み」など、ワークフロー内での開発アイテムの現在のステータス。 | ||
|
説明
状態属性は、プロジェクトのプロセステンプレートによって定義された、ある時点におけるワークアイテムの正式なステータスを表します。これらの状態間の移行は、イベントログ内の活動を生成するための主要なソースです。 「活動」属性が状態変更のより記述的なバージョンであることが多い一方で、生の「状態」属性はフィルタリングと分析に役立ちます。アイテムが特定の状態でどれくらいの時間を費やすかを理解するのに役立ち、ステージ期間ダッシュボードの構築と引き継ぎの分析の基礎となります。
その重要性
ワークアイテムのライフサイクルにおけるステータスを示し、プロセスフローの理解や様々なステージでの所要時間の計算に不可欠です。
取得元
これはAzure DevOpsのワークアイテムにおける「状態」フィールドに対応します。
例
新規アクティブQA中解決済みクローズ
|
|||
|
終了日時
EndTime
|
活動が完了した時点を示すタイムスタンプ。活動の処理時間を計算するために使用されます。 | ||
|
説明
終了時刻は、活動の完了を示します。多くのイベントログでは、次の活動の開始時刻が前の活動の終了時刻として機能します。しかし、明確な終了時刻を持つことで、活動の処理時間と活動間のアイドル時間の両方をより正確に計算できます。 この属性は、ProcessingTime KPIの計算と詳細なボトルネック分析を実行するために不可欠です。タスクで積極的に作業に費やされた時間と、次のステップが開始するのを待つ時間に費やされた時間を区別するのに役立ち、これはステージ引き継ぎ分析ダッシュボードにとって重要です。
その重要性
アクティビティ処理時間とアイドル時間の正確な計算を可能にし、ボトルネック分析と効率改善の基礎となります。
取得元
これはしばしば導出されます。同じケースの後続イベントの開始時間であることもあれば、ソースシステムがタスクの開始時刻と終了時刻の両方を捕捉する場合、明示的に記録されることもあります。
例
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
開発`サイクルタイム`
DevelopmentCycleTime
|
開発アイテムの作成から本番環境へのデプロイまでの経過時間の合計。 | ||
|
説明
開発 この計算された
その重要性
これは、開発プロセスの開始から終了までの全体的な速度と効率を測定する重要なKPIです。
取得元
これは、最終的なデプロイイベントのタイムスタンプから、各ケースの作成イベントのタイムスタンプを差し引くことによって計算されます。
例
10日 4時間 30分25日 8時間 0分5日 2時間 15分
|
|||
|
イテレーションパス
IterationPath
|
ワークアイテムが割り当てられている開発スプリントまたはタイムボックス。 | ||
|
説明
イテレーションパス、つまりスプリントは、開発の特定の期間を区切ったものです。ワークアイテムは、その期間内に完了するようにイテレーションに割り当てられます。 イテレーションパスによる分析は、スプリントごとのプロセスパフォーマンスを理解するのに役立ちます。これにより、サイクルタイムが連続するスプリントで改善しているかを追跡したり、持ち越し作業を分析したり、スプリント計画の予測可能性を評価したりすることができます。
その重要性
スプリントベースの分析を可能にし、チームが時間経過とともにパフォーマンスを評価し、アジャイルプラクティスを改善するのに役立ちます。
取得元
これはAzure DevOpsのワークアイテムにおける「イテレーションパス」フィールドに対応します。
例
`Eコマース``プラットフォーム`\`スプリント`12`Eコマース``プラットフォーム`\`スプリント`13モバイルアプリ再起動\フェーズ2\スプリント4
|
|||
|
ステージ引き継ぎ時間
StageHandoffTime
|
ある主要ステージの完了から次のステージの開始までのアイドル時間。 | ||
|
説明
ステージ引き継ぎ時間とは、「開発完了」から「QAテスト開始」までの時間のように、連続するプロセスステージ間の待機期間を測定します。これらの主要な移行を特定し、最初の活動の終了から次の活動の開始までの時間差を測定することで算出されます。 この指標は、ステージ期間と引き継ぎ分析ダッシュボードの焦点です。引き継ぎ時間を分離して測定することは、リソースの利用不能、コミュニケーションの遅延、または非効率なプロセスによって作業がアイドル状態になっている隠れたボトルネックを特定するために極めて重要です。
その重要性
プロセスステージ間の待機時間を定量化し、アクティブな作業の一部ではない隠れたボトルネックや遅延を直接明らかにします。
取得元
これは計算属性です。引き継ぎを表す一対の連続した活動を特定し、それらの間の時間差を計算する必要があります。
例
2時間15分1日4時間0時間30分
|
|||
|
プルリクエストID
PullRequestId
|
開発アイテムにリンクされたプルリクエストの識別子。 | ||
|
説明
この属性は、ワークアイテムを特定のプルリクエストにリンクします。プルリクエストは、コード変更を提出しレビューするためのメカニズムです。単一のワークアイテムが複数のプルリクエストに関連付けられることがあります。 プルリクエストIDを持つことで、ライフサイクルのコードレビューと統合部分のより詳細な分析が可能になります。これにより、プルリクエストの作成から完了までの時間を測定したり、プルリクエストが拒否されたり大幅な変更を必要とすることがどれくらいの頻度であるかを分析したりすることができます。これはコード品質や不明確な要件の指標となり得ます。
その重要性
開発作業を特定のコードレビュー活動と連携させ、コード統合と品質保証プロセスの詳細な分析を可能にします。
取得元
この情報はAzure DevOpsのワークアイテムの「リンク」または「開発」セクションにあります。
例
452145334589
|
|||
|
プロジェクト名
ProjectName
|
開発アイテムが属するAzure DevOpsプロジェクトの名前。 | ||
|
説明
この属性は、ワークアイテムが配置されているAzure DevOps組織内の特定のプロジェクトを識別します。特に多くのプロジェクトを抱える組織では、高レベルのコンテキストを提供します。 プロジェクト名は、フィルタリングと比較のための重要なディメンションです。プロジェクトごとに分析をセグメント化することを可能にすることで、過去のサイクルタイムトレンドダッシュボードをサポートし、特定のプロジェクトが他のプロジェクトよりも効率的であるかそうでないか、またはあるプロジェクトでのプロセス改善が好影響を与えたかどうかを明らかにします。
その重要性
分析のための高レベルなグループ化を提供し、異なるプロジェクト間でのパフォーマンス比較やトレンド分析を可能にします。
取得元
これはAzure DevOpsのワークアイテムにおける「チームプロジェクト」フィールドに対応します。
例
`Eコマース``プラットフォーム`モバイルアプリ再起動`データウェアハウス`の`モダナイゼーション`
|
|||
|
承認待ち時間
ApprovalWaitingTime
|
リクエスト後、開発アイテムが承認を待つ時間。 | ||
|
説明
この指標は、ワークアイテムが承認待ちである特定の待機期間の長さを測定します。典型的な例は、「UAT開始」から「UAT承認済み」までの時間です。これは、特定のケースについてこれら2つの特定の活動間の時間を測定することによって計算されます。 この計算属性は、承認待機時間分析ダッシュボードと対応するKPIを直接サポートします。これらの特定の遅延を分離することで、チームはコミュニケーションと意思決定プロセスをターゲットにしてアイドル時間を短縮し、全体的なライフサイクルを加速することができます。
その重要性
意思決定や承認待ちに起因する遅延を具体的に測定し、コミュニケーションと意思決定プロセスの改善機会を浮き彫りにします。
取得元
これは、イベントログ内の特定の開始および終了承認活動(例:「UAT開始」と「UAT承認済み」)を見つけ、その時間差を計算することによって算出されます。
例
3日2時間1日8時間30分4時間
|
|||
|
重大度
Severity
|
`システム`またはエンドユーザーに対する`バグ`または問題の影響を示します。 | ||
|
説明
重大度とは、致命的なシステム障害から軽微な見た目の問題まで、バグの影響を分類するために使用されます。これは、作業の順序を決定する優先度とは異なります。高重大度のバグであっても、すぐに利用できる回避策がある場合は、優先度が低いことがあります。 この属性は、特に優先度ベースのスループット&サイクルタイムダッシュボードにおいて、分析のためのもう一つの側面を提供します。「最も重大なバグから修正しているか?」といった問いを調査することを可能にし、処理されている作業のリスクプロファイルを理解するのに役立ちます。
その重要性
ビジネスへの影響度に基づいて作業アイテムを分類するのに役立ち、チームが高影響度の課題にどれだけ効果的に対処しているかを分析できます。
取得元
これはAzure DevOpsのワークアイテム、通常はバグに対する「重大度」フィールドに対応します。
例
1 - Critical2 - High3 - Medium4 - Low
|
|||
ソフトウェア開発ライフサイクルの活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
QAテスト開始
|
正式な品質保証テストフェーズの開始を表します。この活動は、ワークアイテムのステータスが「QA中」、「テスト中」または同様の値に変更されたときに推論されます。 | ||
|
その重要性
QAサイクルの開始を示します。このフェーズの期間を分析することは、テストにおけるボトルネックと効率性を理解するために不可欠です。
取得元
取得
「QA中」または「テスト中」に
イベントタイプ
inferred
|
|||
|
UAT承認済み
|
この活動は、ビジネスステークホルダーがユーザー受け入れテスト後に変更を承認したことを意味します。これは通常、「UAT中」から「UAT承認済み」または「リリース準備完了」への状態変更から推論されます。 | ||
|
その重要性
これは、ワークアイテムがビジネス要件を満たし、本番環境へのデプロイ準備が完了していることを確認する重要な承認マイルストーンです。
取得元
取得
「
イベントタイプ
inferred
|
|||
|
プルリクエスト作成済み
|
開発者が初期コーディングを完了し、`プルリクエスト`を介して変更をレビューのために提出したことを示します。この`イベント`は、`ワークアイテム`をAzure `Repos`の特定のコード変更に`リンク`します。 | ||
|
その重要性
これは開発からコードレビューへの重要な引き継ぎです。これを追跡することは、コーディングの期間を測定し、いつコードがピアレビューの準備ができたかを特定するのに役立ちます。
取得元
Azure
取得
イベントタイプ
explicit
|
|||
|
プルリクエスト完了
|
プルリクエストが承認され、コードがターゲットブランチにマージされるコードレビューの成功裡の完了を表します。このイベントはAzure Reposに明示的に記録されます。 | ||
|
その重要性
一般的なボトルネックであるコードレビューフェーズの終了を示します。PR作成から完了までの時間を分析することで、レビューサイクルの効率が明らかになります。
取得元
取得
イベントタイプ
explicit
|
|||
|
ワークアイテム作成済み
|
この活動は、ユーザー ストーリー、バグ、タスクなどの新しいワークアイテムの作成を表し、開発ライフサイクルの始まりを示します。Azure DevOps Boardsで新しいレコードが保存されたときに明示的に捕捉されます。 | ||
|
その重要性
これはプロセスの主要な開始イベントです。エンドツーエンドの開発サイクルタイムを測定し、作業の初期ソースを理解するために不可欠です。
取得元
このイベントは、ワークアイテム自体の「作成日」から捕捉されます。ワークアイテム履歴テーブルもこの初期状態移行を記録します。
取得
イベントタイプ
explicit
|
|||
|
本番環境に`デプロイ`済み
|
ワークアイテムに関連するコードが本番環境へ正常にデプロイされたことを示します。これはAzure Pipelinesのリリースログから取得される明示的なイベントです。 | ||
|
その重要性
これは価値の提供を表す重要なマイルストーンです。リードタイムとサイクルタイムを計算するための終点として機能します。
取得元
Azure
取得
イベントタイプ
explicit
|
|||
|
開発開始
|
この活動は、開発者がアイテムのアクティブな作業を開始したことを意味します。これは、ワークアイテムのステートが「アクティブ」、「進行中」、または「コミット済み」に変更されたことから推論されて捕捉されます。 | ||
|
その重要性
アクティブな開発フェーズの開始を示します。「作成済み」から「開発開始」までの時間を分析することで、バックログのキュータイムが明らかになります。
取得元
取得
「
イベントタイプ
inferred
|
|||
|
`ビルド`成功
|
この活動は、新しい変更を含むソースコードがビルドパイプラインによって正常にコンパイルされ、パッケージ化されたことを確認します。これはAzure Pipelinesによって記録される明示的なイベントです。 | ||
|
その重要性
重要な品質ゲートとして機能し、新しいコードがビルドを破壊することなく正しく統合されることを保証します。この段階での失敗は、統合の問題を示している可能性があります。
取得元
Azure
取得
Azure
イベントタイプ
explicit
|
|||
|
QAテスト失敗
|
`ワークアイテム`が品質保証テストに失敗し、開発に戻されていることを示します。これは、テスト`ステータス`から「進行中」または「`アクティブ`」`ステータス`への変更によって捕捉されます。 | ||
|
その重要性
この活動は、手戻りループを特定するために不可欠です。このイベントの頻度が高い場合、コード品質、要件、またはテストプロセスに問題があることを示しています。
取得元
取得
「QA中」
イベントタイプ
inferred
|
|||
|
QAテスト完了
|
品質保証フェーズの成功裡の完了を示します。これは、ワークアイテムのステートがテストステートから「UAT準備完了」や「QA承認済み」のようなステートに変化したときに推論されます。 | ||
|
その重要性
これは、アイテムがユーザー受け入れテストまたはリリースの準備ができたことを示す重要な品質ゲートです。この時点以降の遅延は、UATまたはリリース計画のボトルネックを示している可能性があります。
取得元
取得
「QA中」
イベントタイプ
inferred
|
|||
|
UAT開始
|
ビジネスステークホルダーが機能性を検証するユーザー受け入れテストの開始を表します。これは通常、「UAT中」または同様のステータスへの状態変更から推論されます。 | ||
|
その重要性
リリース前の最終検証の開始を測定します。UATの期間と承認待ち時間は、プロセス最適化のために分析する上で極めて重要です。
取得元
取得
「
イベントタイプ
inferred
|
|||
|
ワークアイテムキャンセル済み
|
`ワークアイテム`がキャンセルされ、完了または`デプロイ`されないことを示します。これは「削除済み」、「キャンセル済み」、または同様の`ステータス`への変更によって捕捉されます。 | ||
|
その重要性
これは代替の、失敗したプロセス終了を表します。キャンセルされたアイテムを分析することで、計画、優先順位付け、または要件定義に関する問題が明らかになることがあります。
取得元
取得
「削除済み」または「キャンセル済み」に
イベントタイプ
inferred
|
|||
|
ワークアイテムクローズ済み
|
デプロイ後およびデプロイ後の検証を経て、ワークアイテムの最終的なクローズを表します。「クローズ済み」または「完了」への状態変更によって捕捉されます。 | ||
|
その重要性
この活動は、ワークアイテムのプロセス全体の最終的な成功裡の完了を示します。これはライフサイクルの決定的な終点です。
取得元
取得
「クローズ済み」に
イベントタイプ
inferred
|
|||
|
ワークアイテム承認
|
ワークアイテムが正式に承認され、明確に定義され開発準備が完了していることを確認します。これは通常、「状態」フィールドが「承認済み」や「開発準備完了」などの値に変更されたことから推論されます。 | ||
|
その重要性
承認を追跡することは、アイデア提出から開発コミットメントまでの時間を分析するのに役立ちます。これにより、計画フェーズとバックロググルーミングフェーズにおける潜在的な遅延が浮き彫りになります。
取得元
取得
「承認済み」に
イベントタイプ
inferred
|
|||
|
開発完了
|
すべての開発および単体テスト活動が完了し、アイテムが正式なテストの準備ができたことを示します。これは通常、ワークアイテムの状態が「解決済み」または「テスト準備完了」に変更されたことから推論されます。 | ||
|
その重要性
これは開発チームからQAチームへの主要な引き継ぎを示します。「QAテスト開始」までの時間を測定することは、引き継ぎ遅延を特定するのに役立ちます。
取得元
取得
「解決済み」に
イベントタイプ
inferred
|
|||