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

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

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

この`テンプレート`は、`ソフトウェア`開発`ライフサイクル`を最適化するために必要な`データ`を収集するための包括的な`ガイド`を提供します。収集すべき必須`アトリビュート`、追跡すべき主要`アクティビティ`を概説し、`ServiceNow DevOps`からこの`データ`を抽出するための実践的なガイダンスを提供します。このリソースを使用して、`インサイト`に富んだプロセス分析のための堅牢な`イベントログ`を構築しましょう。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • ServiceNow DevOps向けの抽出ガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

ソフトウェア開発ライフサイクル``アトリビュート

これらは、`ソフトウェア`開発`ライフサイクル`の包括的な分析のために`イベントログ`に含めることを推奨される`データ``フィールド`です。
5 必須 8 推奨 5 任意
名前 説明
アクティビティ名
ActivityName
発生した特定の開発`ライフサイクル``イベント`の名前(「Development Started」や「Code Review Performed」など)。
説明

このアトリビュートは、ソフトウェア開発ライフサイクル内で完了した各マイルストーンまたはタスクの名前を記録します。これらのアクティビティは、作成からデプロイメントまでのプロセスの連続したステップを形成します。

これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの主要な機能です。これにより、プロセスマップの構築が可能になり、ステップ間のボトルネックの特定に役立ち、コンプライアンス違反または非効率的なプロセスバリエーションを強調します。定義されたアクティビティセットには、設計、開発、テスト、デプロイメントなどの主要なステージが含まれます。

その重要性

プロセスマップのステップを定義し、プロセスフローの分析、ボトルネックの特定、および標準SDLCからの逸脱の発見を可能にします。

取得元

これは通常、ステータス変更、イベントレコード、または監査トレイル``エントリーアクティビティ名の標準化されたリストにマッピングすることによって導出されます。例えば、「stateフィールドが「In Progress」に変更されることは、「Development Started」にマップできます。

開発開始コードコミット済み`QA` `テスト`完了本番環境へデプロイ
開始時刻
EventTime
特定の活動またはイベントが発生した日時を正確に示すタイムスタンプ。
説明

このアトリビュートは、開発ライフサイクルにおける各アクティビティが記録された日時を提供します。これは、イベントの時系列順序付けと、すべての時間ベースの分析にとって不可欠です。

プロセスマイニングでは、開始時間はアクティビティ間の期間を計算し、待機時間を特定し、プロセスの全体的なサイクルタイムを測定するために使用されます。これは、「SDLC End-to-End Cycle Time Analysis」のようなパフォーマンスを分析するダッシュボードや、「Code Review Lead Time」のような主要業績評価指標を計算するための重要なコンポーネントです。

その重要性

このタイムスタンプは、イベントを正しく順序付けし、サイクルタイム、期間、待機時間を含むすべてのパフォーマンスメトリックを計算するために不可欠です。

取得元

通常、監査トレイルまたはタスク``テーブルから、「sys_updated_on」や「sys_created_on」のようなシステム生成タイムスタンプ``フィールドに見られます。

2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
開発項目
DevelopmentItem
`機能`、`バグ`、または`タスク`など、開発`ライフサイクル`を通じて進行する単一の作業単位のユニークな`識別子`。
説明

開発アイテムは主要なケース``識別子として機能し、追跡されている個別の作業単位を表します。これにより、特定のアイテムの初期構想と計画から、開発、テスト、デプロイメントまで、すべてのアクティビティがリンクされます。

プロセスマイニング分析において、このアトリビュートは各作業アイテムエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、プロセスフローの可視化、総サイクルタイムの計算、および個々の機能バグ修正のプロセスバリアントの特定が可能になります。首尾一貫したプロセスマップを構築するには、ログ内のすべてのイベントが開発アイテムに関連付けられている必要があります。

その重要性

これは、関連するすべての開発アクティビティを単一のプロセスインスタンスに接続する中核的な識別子であり、各作業アイテムの完全なライフサイクルを分析することを可能にします。

取得元

この識別子は通常、ServiceNowストーリーバグ、またはタスクを管理するテーブル(「rm_story」、「rm_bug」、または「task」テーブルなど)のプライマリキーです。

STRY0010015BUG0034092TASK0050118
ソースシステム
SourceSystem
データが抽出されたシステムを特定します。この場合はServiceNow DevOpsです。
説明

このアトリビュートは、イベント``データの元となるシステムを指定します。このプロセスの場合、一貫して「ServiceNow DevOps」となります。

静的に見えるかもしれませんが、ソースシステムを明示的に含めることは、データ``ガバナンスにとって、またJiraAzure DevOpsのような複数のシステムからデータマージされる可能性のある環境において極めて重要です。これにより、データの出所が明確になり、データ品質や抽出の問題の診断に役立ちます。

その重要性

データのトレーサビリティを確保し、特に複数の開発ツールからデータを統合する場合に、データ整合性を維持するために不可欠です。

取得元

これは、データ抽出および変換プロセス中に加えられるべき静的な値です。

`ServiceNow DevOps`
最終データ更新
LastDataUpdate
この`イベントログ`の`データ`がソース`システム`から最後に更新された日時を示す`タイムスタンプ`。
説明

このアトリビュートは、データセットServiceNow DevOpsから最後に抽出または更新された時期を記録します。個々のイベントではなく、データセット全体に適用されます。

このタイムスタンプは、分析の鮮度を理解するために不可欠です。プロセスインサイトがどの程度最新であるかをユーザーに通知し、データ更新のスケジュール設定に役立ちます。この情報をダッシュボードに表示することで、すべてのメトリックと可視化にコンテキストを提供し、意思決定がタイムリーなデータに基づいて行われることを保証します。

その重要性

データの適時性に関する重要なコンテキストを提供し、ユーザーがプロセス分析の鮮度を理解できるようにします。

取得元

このタイムスタンプは、データ抽出プロセス中に生成および追加され、抽出がいつ実行されたかを記録します。

2023-11-15T08:00:00Z
優先度
DevelopmentItemPriority
開発`アイテム`に割り当てられた優先度レベル(「High」、「Medium」、「Low」など)。
説明

このアトリビュートは、ビジネス上の緊急度に基づいて開発アイテムを分類します。優先度レベルは、チームが最も重要なタスクに集中するのに役立ち、SLAステークホルダーの期待を管理するためによく使用されます。

プロセスマイニングでは、優先度は比較分析の重要な側面です。これにより、プロセスマップフィルタリングして、優先度の高いアイテムがより迅速なパスまたは異なるパスをたどるかどうかを確認できます。「High-Priority Feature Delivery Time」ダッシュボードおよびKPIにとって不可欠であり、重要なアイテムが本当に迅速化されているかどうかを検証するのに役立ちます。

その重要性

異なる優先度レベルのプロセスをフィルタリングおよび比較できるため、高優先度項目がより迅速かつ効率的に処理されているかを確認するのに役立ちます。

取得元

これはServiceNowタスク関連テーブルにある、しばしば「priority」と名付けられた標準フィールドです。

1 - Critical2 - High3 - Moderate4 - Low
影響を受ける`モジュール`/`コンポーネント`
ModuleComponentAffected
開発`アイテム`が関連する特定の`ソフトウェア``モジュール`、`アプリケーション`、または`コンポーネント`。
説明

このアトリビュートは、開発作業が影響を与えるシステムの部分によって作業を分類します。これは特定のマイクロサービスUI コンポーネント、またはバックエンド``アプリケーションである可能性があります。

モジュールまたはコンポーネントによるプロセスセグメンテーションは、局所的なボトルネックを特定するために重要です。「Component-Specific Bottleneck Insights」ダッシュボードおよび「Avg Stage Duration by Component」KPIは、このアトリビュートに依存して、コードベースの特定の部分がより長い開発サイクル、より高い手戻り率、またはより頻繁なデプロイメント失敗と一貫して関連しているかどうかを正確に指摘します。これにより、最も必要な場所に改善努力を集中するのに役立ちます。

その重要性

分析をアプリケーションまたはコンポーネントでセグメント化できるため、システムの特定の箇所に特有のボトルネックや品質問題を特定するのに役立ちます。

取得元

これは多くの場合、カスタムフィールドまたは構成管理``データベースCMDB)への参照であり、作業アイテムを「cmdb_ci」レコードにリンクします。ServiceNow DevOpsドキュメントを参照してください。

請求サービス`ユーザー`認証`UI`レポーティング`データベース`APIゲートウェイ
手戻り
IsRework
このアクティビティが、テスト後に開発に戻るなどの手戻りループの一部である場合にtrueとなるブール値フラグです。
説明

これは、プロセスが以前のステージループバックした後に発生するアクティビティを特定する派生アトリビュートです。例えば、同じアイテムに対して「QA Testing Completed」アクティビティの後に「Development Started」アクティビティが発生した場合、手戻りとしてフラグ付けされます。

このフラグは、手戻りを定量化し可視化するために不可欠です。「Rework and Rejection Flow Analysis」ダッシュボードを直接サポートし、「Rework Rate after Testing」KPIの計算に使用されます。これらのイベントフラグを付けることで、アナリストは手戻りの頻度、原因、および全体のサイクルタイムへの影響を簡単にフィルタリングして分析できます。

その重要性

このフラグにより、手戻りの定量化と分析が容易になり、プロセス品質の測定や繰り返される作業の根本原因特定に役立ちます。

取得元

このアトリビュートは、プロセスマイニング ツール内で、各ケースアクティビティの順序を分析し、プロセスフローにおける後方への移動を検出することで計算されます。

truefalse
担当グループ
AssignmentGroup
`アクティビティ`時に開発`アイテム`を担当していた`チーム`または`グループ`。
説明

このアトリビュートは、「Frontend Developers」、「Backend Services」、または「QA Team」などの作業アイテムに割り当てられたチームを特定します。作業アイテムが進行するにつれて、異なる割り当てグループ間で引き渡されることがよくあります。

割り当てグループを追跡することは、クロスファンクショナルコラボレーションと引き渡しを理解するために不可欠です。これにより、作業が1つのチームから別のチームに移動するときに発生するシステム的な遅延を特定するのに役立ちます。このアトリビュートは、チームレベルのパフォーマンス、ワークロードの分析、および全体のフローにおけるボトルネックとなるチームの特定をサポートします。

その重要性

どのチームが作業を担当しているかを追跡し、チームのパフォーマンス、ワークロードのバランス調整、チーム間の引き渡しの効率の分析を可能にします。

取得元

この情報は、「assignment_group」フィールドに保存されます。これはServiceNowタスク関連テーブルにおける標準フィールドです。

プラットフォームエンジニアリングモバイル`アプリ`チーム品質保証DevOps
担当開発者
AssignedDeveloper
`アクティビティ`時に開発`アイテム`に割り当てられた開発者または`ユーザー`の名前または`ID`。
説明

このアトリビュートは、特定のタスクまたはアクティビティの実行を担当する個人を特定します。これは動的であり、開発アイテムが異なるステージチーム間を移動するにつれて変更される可能性があります。

このアトリビュートは、リソース割り当て、ワークロード、および引き渡しを分析するために不可欠です。それは「Developer Workload and Handoffs」ダッシュボードおよび「Activity Volume per Developer」KPIを直接サポートします。このフィールドの変更を追跡することにより、引き渡し時間を測定し、開発者間または開発チームQA チーム間のコラボレーション``ボトルネックを特定することが可能です。

その重要性

これは、ワークロード分散、引き渡し効率、およびチーム固有のパフォーマンスパターンの特定を含む、リソースベースの分析に不可欠です。

取得元

この情報は通常、ServiceNowタスク関連テーブルの「assigned_to」フィールドに保存されます。

David Millerアナ・ウィリアムズジェームス・ブラウン
開発項目サイクルタイム
DevelopmentItemCycleTime
開発`アイテム`の作成から最終的なクローズまたはデプロイメントまでの総経過時間。
説明

このアトリビュートは、単一の開発アイテムエンドツーエンドの期間を表す計算されたメトリックです。各ケースの最初のアクティビティと最後のアクティビティタイムスタンプ間の差を求めることで計算されます。

これはSDLCプロセス全体の主要な主要業績評価指標であり、「Average SDLC Cycle Time」KPIを直接サポートします。これはプロセス速度と効率の高レベルな尺度を提供します。このメトリックを時間経過優先度やチームのような異なる側面で分析することで、プロセス改善イニシアティブの影響を追跡するのに役立ちます。

その重要性

作業アイテムエンドツーエンドの合計期間を表します。これは、プロセス全体の効率と速度を測定するための重要なメトリックです。

取得元

これはソースシステムフィールドではありません。プロセスマイニング ツール内で、各CaseIdの最大StartTimeから最小StartTimeを減算することで計算されます。

15日4時間3 days 12 hours32日8時間
開発項目ステータス
DevelopmentItemState
`イベント`発生時の開発`アイテム`の`ステータス`または`ステート`(「Open」、「In Progress」、または「Closed」など)。
説明

このアトリビュートは、ServiceNow内の開発アイテムの公式ステータスを反映しています。アクティビティは派生したプロセスステップですが、ステートシステムワークフローにおける正式なステージを表します。

ステートはしばしばアクティビティが派生するソースとなります。それはデータ検証や、プロセスのより単純な高レベルビューを作成するために使用できます。例えば、各ステートで費やされた時間を分析することは、アクティビティ間の時間を分析するのと比較して、ボトルネックの異なるビューを提供できます。また、停滞しているアイテムや解決済みのアイテムを特定するためにも役立ちます。

その重要性

作業アイテムの公式システムステータスを提供します。これはアクティビティを導出するためのソースとなることが多く、妥当性検証や高レベルのステータス分析に使用できます。

取得元

これはServiceNowタスク関連テーブルにある、通常「state」または「stage」と名付けられた標準フィールドです。

保留中進行中の作業`テスト`準備完了完了でクローズ済み
開発項目タイプ
DevelopmentItemType
作業`アイテム`の分類(「Feature」、「Bug」、「Technical Debt」、または「Task」など)。
説明

このアトリビュートは、SDLCプロセスを流れるさまざまな種類の作業を区別します。たとえば、重大なバグを修正するプロセスは、新しい機能を開発するプロセスとは異なり、より迅速である可能性があります。

作業アイテム``タイプに基づいてプロセスを分析することで、パフォーマンスをより微妙に理解できます。「バグは新しい機能よりも高い手戻り率を持っていますか?」や「技術的負債削減のためのサイクルタイムは許容できますか?」といった質問に答えるのに役立ちます。このセグメンテーションは、画一的なプロセスビューよりも深いインサイトを提供します。

その重要性

機能やバグのように異なる種類の作業を区別し、それぞれ異なるプロセスパス、優先度、および想定される期間を持つ可能性があります。

取得元

これは、レコードのソーステーブル(例: 「rm_story」対「rm_bug」)または汎用タスク``テーブルの「typeフィールドから決定できます。

機能バグタスクスパイク
コミットID
CommitId
開発作業に関連付けられたソースコード`コミット`のユニークな`識別子`。
説明

このアトリビュートは、開発アイテムからGitなどのソースコードリポジトリ内の特定のコード変更への直接リンクを提供します。「Code Committed」アクティビティが発生したときにキャプチャされます。

プロセスマイニングでは、コミット IDはプロセスデータエンジニアリング``データを接続することで分析を強化します。これにより、アナリストは問題のあるデプロイメントを正確なコード変更までさかのぼったり、コード複雑性メトリックと開発サイクルタイムを関連付けたりすることができます。これにより、より深く、より技術的なレベルでの根本原因分析が可能になります。

その重要性

プロセスイベントを特定のコード変更にリンクさせ、プロセスメトリクスとコードレベルの詳細を関連付けることで、より詳細な根本原因分析を可能にします。

取得元

これは、GitSVNのようなソースコード管理システムとのServiceNow DevOps統合によってキャプチャされます。データは開発アイテムにリンクされた関連テーブルに存在します。

a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
デプロイ状況
DeploymentStatus
デプロイ活動の結果を示し、通常は「成功」または「失敗」です。
説明

このアトリビュートは、特定の環境へのデプロイメントの結果を記録します。これは、リリースプロセスの信頼性と安定性を理解するための重要な情報です。

このアトリビュートは、「Deployment Success and Failure Trends」ダッシュボードおよび「Deployment Failure Rate」KPIにとって不可欠です。デプロイメント失敗の頻度と傾向を分析することで、組織はテストインフラストラクチャ、またはリリース調整における根本的な問題を特定できます。これにより、ソフトウェアデリバリーの品質と信頼性を向上させるための努力を集中するのに役立ちます。

その重要性

デプロイ活動の成功を直接測定し、これはデプロイ失敗率の計算とリリース安定性の分析にとって極めて重要です。

取得元

このステータスは通常、デプロイメント追跡タスクまたはServiceNow DevOpsと統合されたCI/CD パイプライン実行レコードに記録されます。

成功失敗警告付きで完了
手戻り理由
ReworkReason
開発項目がテスト後に手戻りを必要とした理由の分類または説明です。
説明

アイテムQAまたはUATに失敗した場合、このアトリビュートは失敗の理由をキャプチャします。これは、特定のバグカテゴリ、要件の誤解、または環境の問題である可能性があります。

この情報は、「Rework and Rejection Flow Analysis」ダッシュボードにとって重要なコンテキストを提供します。単に手戻りが発生したことを知るだけでなく、アナリストはそれがなぜ発生したのかを理解できます。これにより、より良い要件定義、強化された単体テスト、またはより安定したテスト環境など、的を絞った改善が可能になり、全体の手戻り率を削減できます。

その重要性

手戻りが発生する理由に関する定性的なインサイトを提供し、品質を向上させ、手戻りループを削減するための的を絞ったプロセス改善を可能にします。

取得元

これは、テストが失敗した際の「close_notes」フィールド、または専用の「rework_reason」カスタムフィールドキャプチャされる場合があります。ServiceNow DevOpsドキュメントを参照してください。

要件誤解釈`リグレッションバグ`パフォーマンステスト失敗`UI/UX`問題
終了日時
EventEndTime
`アクティビティ`が完了した正確な`タイムスタンプ`です。瞬間的な`イベント`の場合、これは`開始時間`と同じです。
説明

このアトリビュートは、開発ライフサイクルにおける各アクティビティが完了した日時を提供します。「Code Review Performed」や「QA Testing」など、測定可能な期間を持つアクティビティに特に役立ちます。

プロセスマイニングでは、開始時間と終了時間の両方を持つことで、アクティビティ処理時間を正確に計算し、アクティビティ間の待機時間と区別することができます。これにより、遅延が長いタスクによるものなのか、リソースの長い待機によるものなのかを正確に特定できます。「Build Triggered」のような瞬間的なイベントの場合、終了時間は開始時間と同じにすることができます。

その重要性

活動処理時間を正確に計算できるため、作業時間と待機時間の違いを区別するのに役立ちます。

取得元

これは派生させる必要がある場合があります。次のアクティビティの開始タイムスタンプであるか、ソースシステムで利用可能な場合は別の「end dateフィールドから取得される可能性があります。

2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
計画されたリリース`バージョン`
PlannedReleaseVersion
開発`アイテム`がデリバリーされる予定の`ターゲット``ソフトウェア`リリースまたは`バージョン`。
説明

このアトリビュートは、開発アイテムを「Version 2.3」や「Q4 2023 Release」などの特定の計画済みリリースにリンクします。これはプロジェクト管理とリリース計画にとって重要な要素です。

プロセスマイニングでは、このアトリビュートは「Release Plan Adherence Monitoring」ダッシュボードにとって極めて重要です。実際の完了日と計画されたリリース日を比較することで、チームはスケジュール順守を測定し、リリースに間に合わないリスクのあるアイテムを特定し、リリース遅延の原因を分析できます。これは、低レベルの開発プロセスと高レベルのビジネス目標との直接的なリンクを提供します。

その重要性

開発作業を特定のリリースと関連付け、スケジュール順守の分析や、プロセス遅延がリリーススケジュールに与える影響の分析を可能にします。

取得元

この情報は通常、「release」または「planned_release」フィールドに保存され、多くの場合ServiceNowのリリースマネジメントテーブルを参照します。ServiceNow DevOpsドキュメントを参照してください。

v3.4.12024年第1四半期リリース`プロジェクト` `フェニックス` `ゴーライブ`
必須 推奨 任意

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

これらは、正確な`プロセスディスカバリ`と`最適化`のために、`イベントログ`に記録すべき主要な`プロセスステップ`と`マイルストーン`です。
7 推奨 9 任意
アクティビティ 説明
`QA` `テスト`完了
品質保証`チーム`が開発`アイテム`の`テスト``アクティビティ`を正常に完了したことを示します。これは通常、`アイテム`の`ステート`が`テスト``フェーズ`から「Ready for UAT」または「Done」のような`ステータス`に遷移したときに推測されます。
その重要性

このマイルストーンは、主要な品質ゲートの完了を示します。ユーザー受け入れテストやリリース準備などの後続ステージの前提条件となります。

取得元

テストステータス(例:「In QA」)からテスト後ステータス(例:「Ready for UAT」または「Resolved」)への状態変更のタイムスタンプから推測されます。

取得

「テスト中」から後続のステータスへの変更のタイムスタンプに基づきます。

イベントタイプ inferred
`UAT`承認済み
ビジネスステークホルダーがユーザー受け入れテスト後に開発項目を正式に承認したことを示します。これは、「UAT中」から「リリース準備完了」または「承認済み」への移行など、ステータス変更から推論される重要なマイルストーンです。
その重要性

これは、アイテムが本番デプロイメントのために承認される前の最終的なビジネス承認です。これは重要な品質およびガバナンスチェックポイントです。

取得元

UATの成功裏の完了を示す開発項目レコードのステータス遷移から推論されます。これは項目のアクティビティ履歴に記録されます。

取得

「UAT」から承認済みまたはリリース準備完了ステータスへの変更から推論されます。

イベントタイプ inferred
コードレビュー実施済み
この`アクティビティ`は、通常`プルリクエスト`または`マージリクエスト`に関連する`ピアコードレビュー`の完了を示します。この`イベント`は、`DevOps`統合を通じて明示的に`キャプチャ`するか、関連レコードの`ステータス`変更から推測できます。
その重要性

これは重要な品質ゲートです。その期間を分析することは、レビュープロセスにおけるボトルネックを特定するのに役立ちます。これはSDLCにおける遅延の一般的な原因です。

取得元

ServiceNowのGit統合におけるPull Requestレコードの「Merged」または「Completed」イベントからキャプチャされるか、開発項目のステータスが「Code Review Complete」に変更されたことから推論されます。

取得

作業アイテムにリンクされたプルリクエストマージされたときにログに記録されます。

イベントタイプ explicit
デプロイ失敗
開発項目を本番環境にデプロイする試みが失敗したことを示します。これは、CI/CDパイプラインが失敗を報告した際に、ServiceNow DevOpsによって明示的にキャプチャされます。
その重要性

これは重要な失敗エンドポイントです。その頻度と原因を分析することは、リリース安定性を改善し、デプロイメント失敗率を削減するための鍵となります。

取得元

Pipeline Execution [sn_devops_pipeline_execution]レコードの「completion_status」からキャプチャされます。終了時点での「Failed」ステータスがこのイベントを示します。

取得

本番デプロイメントパイプラインが失敗ステータスを報告したときにログに記録されます。

イベントタイプ explicit
本番環境へデプロイ
この`イベント`は、本番環境へのデプロイメントが正常に完了したことを示します。`CI/CD` `ツール`が正常な`パイプライン`完了を報告したときに、`ServiceNow DevOps`によって明示的に`キャプチャ`されます。
その重要性

これはSDLCプロセスの主要な成功エンドポイントです。これによりバリューストリームが完了し、総サイクルタイムの計算に不可欠です。

取得元

Pipeline Execution [sn_devops_pipeline_execution]レコード、またはそれに関連するStage Execution Runの「completion_status」からキャプチャされます。終了時点での「Success」ステータスがこのイベントを示します。

取得

本番デプロイメントパイプラインが正常に完了したときにログに記録されます。

イベントタイプ explicit
開発開始
この`アクティビティ`は、開発者が開発`アイテム`の`コーディング`または実装を積極的に開始する`ポイント`を示します。これは通常、`アイテム`の`ステータス`が「In Progress」、「Development」、または「Coding」に変更されたことから推測されます。
その重要性

これは、付加価値のある構築フェーズの開始を示す重要なマイルストーンです。開発者のリードタイムとコードレビューサイクルタイムを測定するために不可欠です。

取得元

開発アイテムレコード(例: Story [rm_story])の「State」フィールドが「In Progress」またはそれに相当するステータスに更新されたタイムスタンプから推測されます。

取得

「進行中」または類似の値へのステータス変更のタイムスタンプに基づきます。

イベントタイプ inferred
開発項目作成
この`アクティビティ`は、`ServiceNow`内で`ストーリー`、`バグ`、`エピック`などの新しい開発`アイテム`が作成されたことを示します。この`イベント`は通常、`Story` [rm_story] `テーブル`のような関連`テーブル`に新しいレコードが挿入されたときに明示的に`キャプチャ`されます。
その重要性

これはSDLCプロセスの主要な開始イベントです。これにより、エンドツーエンドの総サイクルタイムの測定と、初期需要の取り込みの追跡が可能になります。

取得元

Story [rm_story]、Epic [rm_epic]、Defect [rm_defect] などの開発関連テーブルでレコードが作成された際に、sys_auditまたはsys_history_line テーブルに記録されます。作成タイムスタンプは通常、レコード自体にあります。

取得

開発項目レコードの作成タイムスタンプからキャプチャされます。

イベントタイプ explicit
`QA` `テスト`開始
正式な品質保証`テスト``フェーズ`の開始を示します。これは、開発`アイテム`の`ステータス`が「In QA」、「Testing」、または「Ready for Test」のような値に変わったことから、ほとんどの場合推測されます。
その重要性

このアクティビティは、開発からQA チームへの引き渡しを示します。これにより、テスト``フェーズの期間を測定し、テスト能力のボトルネックを特定できます。

取得元

開発アイテムレコード(例: Story, Defect)の「State」フィールドがQA固有のステータスに更新されたタイムスタンプから推測されます。

取得

「テスト中」またはそれに相当するステータスへの変更のタイムスタンプに基づきます。

イベントタイプ inferred
`UAT`開始
ビジネス`ステークホルダー`が`機能`を検証する`ユーザー`受け入れ`テスト`の開始を表します。この`イベント`は、「UAT」、「In UAT」、または「User Acceptance Testing」への`ステータス`変更を推測することで`キャプチャ`されます。
その重要性

このフェーズは、開発された機能がビジネス要件を満たしていることを確認するために不可欠です。その期間を分析することで、ユーザー``エンゲージメントの問題や要件の不一致を明らかにできます。

取得元

開発項目レコードのステータス遷移から推論されます。これは、UATの明確なステータスを含む顧客のステートモデルに依存します。

取得

「UAT」ステータスへの変更から推論されます。

イベントタイプ inferred
コードコミット済み
開発`アイテム`にリンクされた`バージョン`管理`システム``リポジトリ`への開発者によるコード`コミット`を表します。`ServiceNow DevOps`は、`Git`や`GitHub`などの統合された`SCM` `ツール`からこれらの`イベント`を明示的に`キャプチャ`します。
その重要性

コミットを追跡することで、開発の進捗状況とアクティビティの頻度に関する詳細な可視性が得られます。特定のコード変更を親の開発アイテムに関連付けるのに役立ちます。

取得元

統合されたソースコード管理システムからのWebフックによってデータが入力されるServiceNow DevOps Commits [sn_devops_commit]テーブルの明示的なイベントとしてキャプチャされます。

取得

SCM ツールからコミット ウェブフックが受信されたときにログに記録されます。

イベントタイプ explicit
ビルドトリガー
この`イベント`は、`CI/CD` `パイプライン``ビルド`の開始を示し、しばしばコード`コミット`によって`トリガー`されます。`ServiceNow DevOps`はこれを`パイプライン`実行としてログに記録し、元の開発`アイテム`にリンクします。
その重要性

このアクティビティは、開発と自動テストまたはデプロイメント間の橋渡しとなります。コミットビルド開始間の時間を分析することで、CI/CDプロセスにおける遅延を明らかにできます。

取得元

統合されたCI/CD ツール(例: Jenkins, Azure DevOps)でビルドが開始されたときに、パイプライン実行 [sn_devops_pipeline_execution] テーブルに明示的に記録されます。

取得

Pipeline Executionテーブルのレコードの開始時刻からキャプチャされます。

イベントタイプ explicit
リリース準備完了
この`アクティビティ`は、開発`アイテム`がすべての品質`ゲート`を通過し、特定のリリースに`パッケージ`化されたことを示します。これは、`アイテム`がリリースレコードに関連付けられている場合、またはその`ステータス`が「Ready for Deployment」に変更された場合に推測できます。
その重要性

このステップは、アイテムが技術的かつ機能的に完了したことを示します。このステートで費やされた時間は、スケジュールされたデプロイメントウィンドウ前の待ち時間を示す場合があります。

取得元

「State」フィールドが「Ready for Release」に変更された場合、または開発アイテムレコードの「Release」フィールドが入力または更新された場合を追跡して推測されます。

取得

ステータス変更またはリリースレコードとの関連付けから推論されます。

イベントタイプ inferred
手戻り特定済み
テスト中に問題が発見され、項目を開発に戻す必要があることを示します。このイベントは、「QA中」から「進行中」へのステータス変更など、プロセスフローの逆行を観察することによって推論されます。
その重要性

手戻りを追跡することは、品質問題とプロセスの非効率性を理解するために不可欠です。このアクティビティの頻度が高い場合、開発または要件の明確さに問題があることを示唆します。

取得元

「sys_audit」または「sys_history_line」テーブルの「State」フィールドの履歴を分析して推測されます。後工程のステータス(例:「Testing」)から前工程のステータス(例:「In Progress」)への変更は、手戻りを示します。

取得

逆行するステータス遷移(例:「テスト中」→「進行中」)から推論されます。

イベントタイプ inferred
本番環境へのデプロイ開始
この`アクティビティ`は、本番環境へのデプロイメント`パイプライン`の開始を示します。`ServiceNow DevOps`は、`CI/CD` `パイプライン`の本番`ステージ`が実行を開始したときに、これを明示的な`イベント`として`キャプチャ`します。
その重要性

これはライフサイクルの最終フェーズであり、しばしば最も重要となるフェーズの開始を示します。これを追跡することで、デプロイメント期間の分析や自動化の機会の特定に役立ちます。

取得元

本番環境に関連するステージフィルタリングされた、Stage Execution Run [sn_devops_stage_execution] テーブルに明示的に記録されます。

取得

パイプライン実行における本番デプロイ段階の開始時刻からキャプチャされます。

イベントタイプ explicit
設計開始
開発`アイテム`の技術設計または`ソリューションアーキテクチャ`が作成されている`フェーズ`を表します。これは通常、開発`アイテム`レコードの`ステータス`または`ステート``フィールド`が「Design」または「Solutioning」のような値に変更されたことから推測されます。
その重要性

設計フェーズの期間を分析することで、開発作業が始まる前の要件変換やソリューション計画におけるボトルネックを特定するのに役立ちます。

取得元

開発アイテムレコード(例: Story [rm_story])のステータス遷移から推測されます。「State」またはカスタムの「Stage」フィールドが設計関連の値に変更されているかを確認します。

取得

「設計中」または同様のステータスへの変更から推論されます。

イベントタイプ inferred
開発項目キャンセル
開発`アイテム`が完了する前に終了したことを表します。これは代替の終了`ステート`であり、通常、`アイテム`の`ステート`が「Cancelled」または「Closed Incomplete」に設定されたことから推測されます。
その重要性

キャンセルを追跡することで、無駄な努力を特定し、スコープ変更や再優先順位付けの理由を理解するのに役立ちます。これにより、すべての可能なプロセス結果のより完全なピクチャが提供されます。

取得元

開発アイテムレコードの「State」フィールドが「Cancelled」のような終端の、完了していないステータスに更新されたタイムスタンプから推測されます。

取得

「キャンセル済み」または同等の終了ステータスへの変更から推論されます。

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

抽出ガイド

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