ソフトウェア開発ライフサイクルデータ``テンプレート
ソフトウェア開発ライフサイクルデータ``テンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Jira Softwareのデータ抽出ガイド
ソフトウェア開発ライフサイクル属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
アイテムの開発ライフサイクルで発生した特定のイベントまたはステータス変更の名前。 | ||
|
説明
この属性は、ソフトウェア開発プロセスにおける明確なステップまたはマイルストーンを表します。これらのアクティビティは、Jira課題のステータスフィールドの変更、またはコードコミットやレビューなどのその他の重要なイベントから派生します。 プロセスマイニングでは、これらのアクティビティのシーケンスがプロセスマップを形成します。アクティビティを分析することは、プロセスフローを特定し、特定のステージの期間を測定し、手戻りループやスキップされた品質ゲートなど、標準ワークフローからの逸脱を検出するのに役立ちます。
その重要性
アクティビティはプロセスのステップを定義し、そのシーケンスはプロセスフローの可視化、ボトルネックの特定、プロセスバリエーションの分析に不可欠です。
取得元
通常、Jira課題の履歴または変更ログにおける「ステータス」フィールドの遷移から派生します。接続された開発ツールからのデータで強化することもできます。
例
開発開始コードレビュー実施済みQAテスト完了本番環境にデプロイ済み
|
|||
|
イベント日時
EventTime
|
特定の開発活動またはイベントが発生した正確な日付と時刻。 | ||
|
説明
イベントタイムは、アクティビティが発生した日時を記録するタイムスタンプです。これはすべてのプロセスマイニング分析の時間的基盤であり、各ケースのイベントの時系列順序を提供します。 この属性は、サイクルタイム、処理時間、アクティビティ間の待機時間を含むすべての時間ベースのメトリックを計算するために不可欠です。時間の経過に伴うプロセスパフォーマンスの分析を可能にし、開発ライフサイクル内でいつ、どこで遅延が発生するかを特定するのに役立ちます。
その重要性
このタイムスタンプは、イベントを正しく順序付けし、プロセス効率を理解し遅延を特定するための鍵となる、すべての期間ベースのメトリックを計算するために不可欠です。
取得元
これは、課題の変更履歴または履歴における各エントリの「作成済み」タイムスタンプに対応します。
例
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
|
|||
|
開発アイテム
DevelopmentItem
|
Jira Software内のストーリー、バグ、タスクなどの単一の作業単位に対する一意の識別子。 | ||
|
説明
開発アイテムは、機能、バグ修正、タスクなどの個別の作業単位を表す主要なケース識別子として機能します。これは、特定のアイテムの最初の概念化と計画から開発、テスト、デプロイまでのすべての活動をリンクします。Jiraでは、これは通常、課題キー(例:'PROJ-123')に対応します。 この属性を分析することで、各作業アイテムのエンドツーエンドのライフサイクル全体を追跡できます。これは、プロセスマップの構築、サイクルタイムの計算、および異なるアイテムが開発プロセスを流れる方法のバリエーションを特定するための基盤となります。
その重要性
これは、関連するすべての開発活動をリンクするための不可欠なキーであり、単一の作業アイテムの開始から終了までの過程を追跡することを可能にします。
取得元
これは、Jira Software課題APIオブジェクト内の課題の標準「key」フィールドです。
例
PROJ-101CORE-5432API-789
|
|||
|
ソースシステム
SourceSystem
|
開発ライフサイクルデータが抽出されたシステム。 | ||
|
説明
この属性はデータの出所を識別します。このプロセスでは常に「Jira Software」となりますが、より大規模な分析で複数のソースシステムが結合される場合にデータを区別するのに役立ちます。 より広範なITランドスケープにおいて、ソースシステムを指定することで、データ系統が明確になり、異なるプラットフォーム間でのデータ品質と統合努力の管理に役立ちます。
その重要性
明確なデータ来歴を提供します。これは、複数のシステムからデータを統合する場合や、データガバナンスおよび監査の目的で不可欠です。
取得元
これは、データ抽出および変換プロセス中に加えられるべき静的な値です。
例
Jira Software
|
|||
|
最終データ更新
LastDataUpdate
|
このプロセスのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。 | ||
|
説明
この属性は、Jira Softwareからの最新のデータ抽出日時を記録します。これは分析中のデータの鮮度に関するコンテキストを提供します。 最終更新時刻を知ることは、プロセスインサイトの適時性を理解する上で重要です。アナリストやビジネスユーザーが現在のデータを見ていることを確認し、分析に含まれるイベントの区切り点を知らせるのに役立ちます。
その重要性
データの鮮度を示し、分析やダッシュボードがプロセスの最新の状態を反映していることを保証するために不可欠です。
取得元
このタイムスタンプは、データ抽出、変換、ロード(ETL)プロセスの最後に生成され記録されます。
例
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
|
|||
|
Assignee
Assignee
|
現在、開発アイテムの処理に割り当てられているユーザー。 | ||
|
説明
担当者は、現在のステージで作業アイテムに責任を持つ個人です。Jiraでは、これはアイテムが異なる人やチーム間を移動するにつれて変化する標準フィールドです。 担当者を分析することは、リソースの割り当て、ワークロードの分散、および引き渡しポイントを理解する上で重要です。これにより、どの開発者やチームが特定のステージに関与しているか、誰がボトルネックになっているか、そして組織全体でどのように作業が分散されているかについての疑問に答えるのに役立ちます。
その重要性
アクティビティの担当ユーザーまたはリソースを特定し、ワークロード分析、リソース管理、および個人間の引き継ぎの理解を可能にします。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「assignee」フィールドです。
例
Alice SmithBob Johnson未割り当て
|
|||
|
アイテム優先度
ItemPriority
|
開発アイテムに割り当てられた優先度レベル。その緊急性を示します。 | ||
|
説明
アイテム優先度とは、作業アイテムの相対的な重要度または緊急度を定義するものです。Jiraは、「最高」、「高」、「中」、「低」などの設定可能なレベルを持つ標準の「優先度」フィールドを提供します。 優先度を分析することは、重要アイテムのコンプライアンスチェックやボトルネックの特定に不可欠です。例えば、「優先アイテムコンプライアンスチェック」ダッシュボードは、この属性に依存して、優先度の高いアイテムが期待どおりに迅速化されているか、それとも優先度の低いアイテムと同じキューで滞留しているかを検証します。
その重要性
優先度の高いアイテムが低いアイテムよりも速く処理されているか、より効率的なパスをたどっているかを分析するのに役立ち、SLAが満たされていることを保証します。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「priority」フィールドです。
例
最高高中低
|
|||
|
チーム名
TeamName
|
作業アイテムに責任を持つ開発チーム。 | ||
|
説明
開発アイテムに割り当てられた特定のアジャイルチームまたはフィーチャーチームを表します。Jiraでは、これはカスタムフィールドとして実装されることが多く、またはプロジェクトや特定のコンポーネントなどの他の情報から派生させることもできます。 この属性は、チームレベルのパフォーマンス分析に不可欠です。これにより、個々のチームのサイクルタイム、手戻り率、スループットなどの指標を表示するようにダッシュボードをフィルタリングできます。これは、「フェーズ間引き渡し効率」および「開発者ワークロードとアイテム進捗」ダッシュボードにとって重要です。
その重要性
異なる開発チーム間のパフォーマンス測定と比較を可能にし、高パフォーマンスなチームを特定し、ベストプラクティスを共有するのに役立ちます。
取得元
これはJiraでカスタムフィールドであることがよくあります。特定のフィールド名(「チーム」、「スクワッド」など)を特定するには、Jira管理者に相談してください。
例
チーム・フェニックスコアサービスUI/UXアベンジャーズ
|
|||
|
プロジェクト名
ProjectName
|
開発アイテムが属するJiraプロジェクトの名前。 | ||
|
説明
Jiraでは、すべての作業アイテムがプロジェクトに編成されます。プロジェクト名は、特定の製品、チーム、またはイニシアチブにしばしば対応する高レベルのコンテキストを提供します。 この属性は、フィルタリングと比較のための強力なディメンションです。これにより、異なるプロジェクトや製品間でSDLCプロセスを分析およびベンチマークできます。これにより、どのプロジェクトがより効率的か、どのプロジェクトで手戻りが多いか、異なるチームが異なるプロセスバリアントに従っているかどうかを明らかにできます。
その重要性
プロジェクト、製品、またはチームごとにプロセス分析をセグメント化でき、パフォーマンスの比較とベストプラクティスの特定を可能にします。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「project」フィールドです。
例
モバイルアプリ開発コアプラットフォームデータサイエンス
|
|||
|
品目ステータス
ItemStatus
|
ワークフロー内での開発アイテムの現在のステータス。 | ||
|
説明
この属性は、特定の時点での開発アイテムの特定のステージ(「進行中」、「レビュー中」、「完了」など)を反映します。時間の経過に伴うステータス変更のシーケンスが、プロセスマイニングのアクティビティを生成します。 「アクティビティ」属性が変更イベントを表すのに対し、「アイテムステータス」はアイテムの状態を提供します。これはフィルタリングと分析のディメンションとして役立ち、特定の状態にあるアイテムの数を確認したり、特定のステータスに長期間留まるアイテムの特性を分析したりできます。
その重要性
アイテムがライフサイクルのどの段階にあるかを示すスナップショットを提供し、ステータスベースの分析や進行中の作業の現状を理解するために不可欠です。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「status」フィールドです。
例
To Do進行中審査中完了
|
|||
|
明細タイプ
ItemType
|
バグ、ストーリー、タスク、エピックなど、開発アイテムの分類。 | ||
|
説明
アイテムタイプは、実行されている作業の性質を分類します。Jiraは、異なる種類の作業アイテム(多くの場合、固有のワークフローを持つ)を区別するために、標準の「課題タイプ」フィールドを使用します。 この属性は比較分析に不可欠です。特定の種類の作業でプロセスをフィルタリングし、例えば「バグ」と「ストーリー」のライフサイクルを比較することができます。これにより、特定の種類の作業が遅延、手戻り、または標準プロセスからの逸脱により脆弱であるかどうかを特定するのに役立ちます。
その重要性
バグと新機能のように異なる種類の作業がどのように処理され、どこでプロセスが異なるかを比較するために、プロセス分析をセグメント化できます。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「issuetype」フィールドです。
例
ストーリーバグタスクEpic
|
|||
|
アイテム解決
ItemResolution
|
開発アイテムをクローズする最終的な結果または理由。 | ||
|
説明
解決策は、アイテムがクローズ状態に移動された理由を説明します。ステータスが「クローズ済み」であっても、解決策は「完了」、「実施しない」、「重複」、または「再現不可」である可能性があります。これにより、作業の結果に関する重要なコンテキストが提供されます。 解決策を分析することは、正常に完了した作業とキャンセルまたは却下されたアイテムを区別するのに役立ちます。これは、品質分析や、最終的に破棄されたアイテムに費やされた労力と比較して、価値のある作業の真のスループットを理解する上で重要です。
その重要性
正常に完了したアイテムと、その他の理由でクローズされたアイテムを区別します。これは正確な生産性および品質分析にとって不可欠です。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「resolution」フィールドです。通常、課題がクローズされた場合にのみ入力されます。
例
完了実行しない重複再現不可
|
|||
|
イベントの終了時刻
EventEndTime
|
アクティビティまたはステータスが完了した日時を示すタイムスタンプ。 | ||
|
説明
この属性はアクティビティの完了時刻をマークします。これは、特定のケースのシーケンスにおける次のアクティビティのタイムスタンプです。 「EventTime」(開始時刻)がアクティビティの開始をマークするのに対し、EventEndTimeは終了をマークします。これら2つのタイムスタンプの差がそのアクティビティの処理時間です。これは、「平均ステージ処理時間」KPIを計算し、アクティビティ期間を分析するダッシュボードを構築するために不可欠です。
その重要性
アクティビティの終了点を定義し、プロセスの各ステップの期間を計算できるようにします。これはボトルネック分析に不可欠です。
取得元
これは派生属性です。特定のイベントの場合、その終了時間は同じケースの次のイベントの開始時間です。
例
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
|
|||
|
コンポーネント
Component
|
アイテムが属するプロジェクトのサブセクションまたは機能領域。 | ||
|
説明
コンポーネントはJiraで、プロジェクト内の課題をより小さく、管理しやすい部分にグループ化するために使用されます。これは、「ユーザー認証」のような機能領域、「バックエンドAPI」のような技術層、「レポート」のようなモジュールを表すことがあります。 コンポーネント別に分析することで、開発プロセスをより詳細に把握できます。これにより、アプリケーションの特定の部分でより多くのバグが発生するか、開発サイクルが長くなるか、手戻りが多くなるかを特定し、技術的負債や複雑性の領域を指摘するのに役立ちます。
その重要性
製品の機能領域または技術領域によってプロセスをセグメント化でき、どのコンポーネントが遅延や品質問題の原因であるかを特定するのに役立ちます。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の標準の「components」フィールドです。
例
ユーザーインターフェースデータベースAPI Gateway認証
|
|||
|
スプリント名
SprintName
|
開発アイテムが割り当てられているアジャイルスプリントの名前。 | ||
|
説明
スクラムを使用するチームにとって、スプリントは一連の作業が完了するまでの時間枠です。この属性は、アイテムが属するスプリントの名前または識別子をキャプチャします。 スプリントによる分析は、アジャイルに焦点を当てたプロセスマイニングにとって基本的です。個々のスプリントのパフォーマンスを評価し、持ち越し作業を理解し、スプリント目標に対する進捗を追跡するのに役立ちます。一般的な日付範囲よりも具体的な時間ベースのコンテキストを提供します。
その重要性
アジャイルチームにとって重要なコンテキストを提供し、スプリントごとのプロセス効率とスループットの分析を可能にします。
取得元
この情報は通常、Jira Software(Agile)によって管理される「スプリント」カスタムフィールドに保存されます。データは課題APIを介してアクセス可能です。
例
PROJスプリント12023年第4四半期スプリント311月 PIスプリント2
|
|||
|
ハンドオフ待ち時間
HandoffWaitTime
|
2つの連続するアクティビティ間のアイドル時間。 | ||
|
説明
このメトリックは、あるアクティビティの完了から次のアクティビティの開始までの待機時間またはキュー時間を計算します。これは、作業が誰かに取り上げられるのを待ってアイドル状態にある時間を表します。 これは、「平均引き渡し待機時間」KPIと「フェーズ間引き渡し効率」ダッシュボードにとって重要なメトリックです。高い引き渡し時間は、多くの場合、調整の問題、リソースの制約、または開発チームとQAチーム間の非効率なコミュニケーションを示します。このアイドル時間を最小限に抑えることは、全体的なサイクルタイムを削減するための重要な手段です。
その重要性
プロセス内のアイドル時間やキュー時間を強調表示し、チーム間または個人間の引き継ぎにおける非効率性を露呈させ、調整上の問題を明らかにします。
取得元
これは計算されたメトリックです。これは、アクティビティの開始時間から同じケースの前の活動の終了時間を引いたものです。
例
017280043200
|
|||
|
修正バージョン
FixVersion
|
開発アイテムが実際に解決されリリースされたソフトウェアバージョン。 | ||
|
説明
Jiraの「修正バージョン」は、アイテムの完了した作業を含むリリースを示します。これは開発努力の具体的な成果をマークします。 この属性は、実際のリリースコンテキストを提供し、「計画リリースバージョン」と比較してデリバリーパフォーマンスを分析できます。また、特定のリリースでデリバリーされたすべてのアイテムをグループ化し、達成されたことの統合ビューを表示するためにも使用されます。
その重要性
作業がどのリリースに含まれたかを確認し、リリース分析と提供された機能の追跡のための信頼できる情報を提供します。
取得元
これは、Jira課題APIレスポンスの「fixVersions」フィールドに対応します。
例
v2.1.1ホットフィックスv3.0.0メジャーリリースv2.2.0
|
|||
|
処理時間
ProcessingTime
|
特定のアクティビティに費やされた総アクティブ時間。 | ||
|
説明
処理時間とは、アイテムが特定のステータスまたはアクティビティに費やす期間です。これは、ログ内の単一イベントのEventEndTimeとEventTimeの差として計算されます。 このメトリックはボトルネック分析の主要な構成要素であり、「平均ステージ処理時間」KPIで直接使用されます。各アクティビティの処理時間を集計することで、開発ライフサイクルのどのステージが最も時間を消費しているかを明確に把握でき、改善努力の焦点を絞るのに役立ちます。
その重要性
各アクティビティの期間を直接測定するため、どのプロセスステップが最も時間のかかるボトルネックであるかを特定するための主要な指標となります。
取得元
これは計算されたメトリックで、イベントログの各行について「EventEndTime」から「EventTime」を差し引くことによって導出されます。
例
86400360000604800
|
|||
|
合計サイクルタイム
CycleTime
|
開発アイテムのエンドツーエンドの総期間。 | ||
|
説明
サイクルタイムは、開発アイテムが作成されてから本番環境へのデプロイなどの最終的な解決に至るまでの経過時間の合計を測定します。これは、最初のイベントのタイムスタンプと最後のイベントのタイムスタンプの差としてケースレベルで計算されます。 これは、全体的なプロセス速度と効率を測定するための主要なKPIです。「平均エンドツーエンドサイクルタイム」KPIと「全体SDLCサイクルタイム分析」ダッシュボードは、この計算に直接基づいています。サイクルタイムの短縮は、プロセス改善イニシアチブの主要な目標となることが多いです。
その重要性
開発プロセスのエンドツーエンドの速度を測定し、全体の効率とデリバリー速度の主要業績評価指標(KPI)を提供します。
取得元
これはケースレベルで計算される属性です。特定の「開発アイテム」に対する最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを引いたものです。
例
12096002592000604800
|
|||
|
報告者
Reporter
|
開発アイテムを最初に作成または報告したユーザー。 | ||
|
説明
報告者とは、Jiraで課題を作成した個人です。これは開発者、QAテスター、プロダクトマネージャー、またはサービスデスク統合を介した顧客である場合もあります。 報告者を分析することで、作業の発生源に関するインサイトを得ることができます。例えば、QAチームが報告したバグが、顧客が報告したバグとは異なるライフサイクルを持つかどうかを分析できます。また、コミュニケーションパターンやプロセスの開始時の情報フローを理解する上でも役立ちます。
その重要性
作業アイテムの発生源を特定し、誰がタスクを作成したか、バグを報告したかに基づいてパターンを分析するために使用できます。
取得元
これは、Jira課題APIレスポンスの「fields」オブジェクト内の「reporter」フィールドです。
例
チャールズ・ダーウィンマリー・キュリーアイザック・ニュートン
|
|||
|
手戻り
IsRework
|
アクティビティが手戻りループの一部であるかどうかを示すフラグです。 | ||
|
説明
このブール属性は、QAテストに失敗した後「開発開始」に戻るなど、アクティビティがプロセスにおける後戻りを表す場合にtrueとなります。これは、ケースのアクティビティシーケンスを分析することで決定されます。 手戻りの特定は、プロセス効率と品質を向上させる上で基本です。この属性は、「手戻り活動率」KPIと「手戻りループの頻度とパス」ダッシュボードを直接サポートします。これにより、無駄な労力の量を定量化し、手戻りにつながる品質問題の根本原因を特定できます。
その重要性
非効率な手戻りループの一部であるアクティビティを明示的にフラグ付けし、プロセス上の無駄や品質問題の正確な測定と分析を可能にします。
取得元
これは計算された属性です。期待されるプロセスフローを定義し、その後、より早いステージに移動することで逸脱するすべてのアクティビティにフラグを立てる必要があります。
例
truefalse
|
|||
|
計画リリース
PlannedReleaseVersion
|
アイテムがデプロイされる予定のターゲットソフトウェアバージョンまたはリリース。 | ||
|
説明
この属性は、Jiraの「影響バージョン」フィールドであることが多く、機能または修正の意図されたリリースを示します。これは、作業完了の締め切りまたは目標として機能します。 これは、「オンタイムリリースデリバリー率」KPIにとって重要な属性です。実際のデプロイ日付をこのバージョンに関連付けられた計画リリース日付と比較することで、スケジュールの順守とリリースプロセスの予測可能性を測定できます。
その重要性
目標とする納期またはリリースを定義し、納期遵守率の計算とスケジュール遵守状況の分析を可能にします。
取得元
これは、Jira課題APIの「versions」または「fixVersions」フィールドに対応します。計画に使用される特定のフィールドは異なる場合があります。
例
バージョン2.12024年第1四半期リリースプロジェクトフェニックスローンチ
|
|||
ソフトウェア開発ライフサイクル活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
QAテスト完了
|
開発アイテムがすべての品質保証チェックに合格し、ユーザー受け入れテストやリリースなどの次のステージに進む準備ができたことを示します。これは、主要なテストステータスからのステータス変更によって推測されます。 | ||
|
その重要性
これは重要な品質ゲートの完了をマークします。QAフェーズの期間を分析することは、テストプロセスとリソース割り当てを最適化するのに役立ちます。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが「In QA」から「Ready for UAT」や「Ready for Release」のような次の状態に遷移したときのタイムスタンプです。
取得
ステータスが「QA中」から「UAT準備完了」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
QAテスト開始
|
このイベントは、開発アイテムの正式な品質保証テストフェーズの開始をマークします。これは、課題が「QA中」、「テスト中」、または「テスト準備完了」などのステータスに移動された際のJiraステータス変更から推測されます。 | ||
|
その重要性
これは品質検証サイクルを開始する重要なマイルストーンです。「開発完了」からこの時点までの時間を測定することで、開発チームとQAチーム間の引き渡し遅延が浮き彫りになります。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが「In QA」のような指定されたQAテスト状態に変化したときのタイムスタンプです。
取得
ステータスが「QA中」または「テスト中」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
UAT承認済み
|
ユーザー受け入れテストの成功裏の完了を表し、リリースに対する利害関係者の承認を示します。これは、ステータスが「UAT中」から「リリース準備完了」または「完了」などの状態に変化したことで推測されます。 | ||
|
その重要性
このマイルストーンは、ビジネスの承認を確認し、アイテムの本番環境へのデプロイを許可します。これは、提供された作業がユーザーの期待に応えることを保証するための重要なゲートです。
取得元
Jira課題の変更ログから推測されます。「UAT中」からワークフローの次の状態へのステータス変更のタイムスタンプであり、承認を意味します。
取得
ステータスが「UAT中」から「リリース準備完了」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
本番環境にデプロイ済み
|
このイベントは、開発アイテムに関連するコード変更が本番環境で稼働する瞬間をマークします。これは、「完了」または「リリース済み」への最終ステータス変更から推測されるか、統合されたCI/CDツールからの明示的なイベントによってキャプチャされます。 | ||
|
その重要性
これはプロセスの主要な成功エンドポイントです。エンドツーエンドの総サイクルタイムを計算し、デプロイ頻度とスループットを測定するために不可欠です。
取得元
Jira課題の変更ログでステータスが「Released」または「Done」に変更されたときに推測できます。より正確には、Jenkins、BambooなどのCI/CDツールによってプッシュされたデプロイメントイベント、またはJiraのデプロイメント機能を通じて取得できます。
取得
ステータスが「完了」または「リリース済み」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
開発アイテム作成
|
これはライフサイクルの開始をマークします。新しい開発アイテム(ストーリー、バグ、タスクなど)がJiraに正式に記録されたときです。このイベントは、すべての課題の作成タイムスタンプとともにシステムによって明示的にキャプチャされます。 | ||
|
その重要性
このアクティビティは、プロセスの決定的な開始点として機能し、エンドツーエンドのサイクルタイムを計算し、流入する作業の総量を追跡するために不可欠です。
取得元
これはすべてのJira課題の基本的なイベントです。作成タイムスタンプは、課題レコードの「created」フィールドに保存されており、Jira APIを介してアクセス可能です。
取得
Jira課題オブジェクトの「作成済み」タイムスタンプフィールド。
イベントタイプ
explicit
|
|||
|
開発開始
|
開発者が開発アイテムに積極的に作業を開始する瞬間を表します。これは、Jiraのワークフロー内のステータス変更から推測されることがほとんどで、例えば、課題のステータスが「進行中」に移行した場合などです。 | ||
|
その重要性
これは、アクティブな開発時間を測定するための重要なマイルストーンです。待機時間と付加価値のある作業を区別するのに役立ち、ボトルネックを特定するための主要なメトリックです。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが最初に「In Progress」、「In Development」、または同様のアクティブな状態に変化したときのタイムスタンプです。
取得
ステータスが「進行中」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
QAテスト失敗
|
QAチームが欠陥を発見し、開発アイテムが手戻りのために開発者に戻されたことを示します。これは、例えば「QA中」から「開発中」や「To Do」へ戻るような後方へのステータス遷移から推測されます。 | ||
|
その重要性
このアクティビティは、手戻りループを特定するために不可欠です。その頻度を追跡することで、品質の悪さによるコストを定量化し、開発や要件における改善領域を強調するのに役立ちます。
取得元
Jira課題の変更ログから推測されます。'status'フィールドがテスト状態(例:「In QA」)から以前の開発状態(例:「In Progress」)に遷移したときに捕捉されます。
取得
テストステータスから開発ステータスへのステータス変更のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
UAT開始
|
ビジネスの利害関係者やエンドユーザーが新機能の検証を開始するユーザー受け入れテストの開始を示します。これは、Jiraのステータスが「UAT中」や「ユーザー受け入れテスト」などに変更されたことで推測されます。 | ||
|
その重要性
このアクティビティは、リリース前の最終検証フェーズの開始を追跡します。その期間を分析することは、利害関係者の可用性やフィードバックサイクルによって引き起こされる遅延を理解し、削減するための鍵となります。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが「UAT中」または同様の指定されたステータスに更新されたときのタイムスタンプです。
取得
ステータスが「UAT中」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
コードレビュー実施済み
|
同僚またはリーダーがコードの品質、標準、機能性をレビューしたことを示します。これは、「レビュー中」から「QA準備完了」への移行などのステータス変更、または統合された開発ツールから明示的に推測できます。 | ||
|
その重要性
このアクティビティは重要な品質ゲートです。その期間と、手戻りなどの結果を分析することは、コード品質を向上させ、プロセスの後半で発見されるバグを減らすのに役立ちます。
取得元
Jira課題の変更ログでステータスが「Code Review」の状態から変更されたときに一般的に推測されます。BitbucketやGitHubなどのコードリポジトリツールが統合されている場合は、明示的なイベントとなることもあります。
取得
ステータスが「レビュー中」から次の状態に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
リリース準備完了
|
開発アイテムがすべてのチェックに合格し、特定のソフトウェアリリースバージョンにバンドルされ、デプロイメントを待っていることを示します。これは、課題のステータスが「リリース準備完了」に変わるか、「修正バージョン」フィールドが入力されたときにしばしば推測されます。 | ||
|
その重要性
このアクティビティは、リリース準備状況と、すべての開発およびテスト作業が完了した後、アイテムがデプロイ期間を待機する時間を追跡するのに役立ちます。
取得元
通常、Jira課題の変更ログから「リリース準備完了」へのステータス変更として推測されます。または、「修正バージョン」フィールドが設定されたときのタイムスタンプから推測することもできます。
取得
ステータスが「リリース準備完了」に変更されたとき、または「修正バージョン」が入力されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
開発アイテムキャンセル
|
開発アイテムが完了する前に終了したことを表します。これは、「キャンセル済み」、「却下済み」、「実施しない」などの終端ステータスへの変更から推測され、多くの場合、特定の解決策を伴います。 | ||
|
その重要性
このアクティビティは、成功しなかったプロセス結果を追跡します。アイテムがキャンセルされる理由を分析することで、計画、優先順位付け、または要件定義に関する問題が明らかになることがあります。
取得元
Jira課題の変更ログから推測されます。これは、課題の「ステータス」が「キャンセル済み」または「対応しない」に変更され、対応する解決策が設定されたときのタイムスタンプです。
取得
ステータスが「キャンセル済み」、「却下済み」、または「実施しない」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
開発アイテムクローズ
|
これは最終的な管理アクションであり、アイテムに関してこれ以上の作業が予定されていないことを確認します。通常、「クローズ済み」へのステータス変更と「解決策」フィールド値の設定から推測されます。 | ||
|
その重要性
アイテムのジャーニーの絶対的な終了を表します。「本番環境へデプロイ済み」と比較することで、管理上の遅延やデプロイ後の監視期間が明らかになることがあります。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが「Closed」に変更され、解決策が設定されたときのタイムスタンプです。
取得
ステータスが「クローズ済み」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
開発完了
|
このアクティビティは、開発者がコーディングを完了し、アイテムがコードレビューやテストなどの次のステージに進む準備ができたことを示します。これは、Jiraのステータスが「進行中」から「レビュー中」または「QA準備完了」に移行するなど、ステータス変更から推測されます。 | ||
|
その重要性
これは、コア開発フェーズの終了をマークし、コーディング期間と品質保証チームへの引き渡しの効率の分析を可能にします。
取得元
Jira課題の変更ログから、'status'フィールドがアクティブな開発状態から「In Review」や「Ready for QA」のような次の状態に変化したタイムスタンプを捕捉して推測されます。
取得
ステータスが「進行中」から「レビュー中」または「QA準備完了」に変更されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
開発準備完了アイテム
|
開発アイテムが完全に仕様化され、レビューされ、優先順位が付けられ、開発者が作業を開始する準備ができたことを示します。これは通常、「バックログ」から「To Do」や「開発準備完了」への移行など、ワークフローにおけるステータス変更から推測されます。 | ||
|
その重要性
これを追跡することは、バックログの準備状況と、アイテムが開発開始までに待機する時間を測定するのに役立ちます。計画および洗練の時間とアクティブな開発時間を分離します。
取得元
Jira課題の変更ログから推測されます。'status'フィールドが「Ready for Dev」、「To Do」、または「Selected for Development」のような値に変化したときのタイムスタンプを探します。
取得
開発前準備完了状態へのステータス変更のタイムスタンプ。
イベントタイプ
inferred
|
|||