HCL Accelerate: DevOps メトリクスの重要性。なぜ、どれを、どのように
2020/7/15 - 読み終える時間: 4337 分
https://blog.hcltechsw.com/accelerate/devops-metrics-matter-why-which-ones-and-how-2/
DevOps Metrics Matter: Why, Which Ones, and How
HCL Accelerate: DevOps メトリクスの重要性。なぜ、どれを、どのように
2020年7月14日
著者: John Gelo / Senior Technical Architect
「自分が話していることを測定して、それを数字で表すことができれば、それについて何かを知ることができる」(
ウィリアム・トムソン・ケルビン (物理学者・数学者・エンジニア))
もっと簡単に言えば、測定できないものは管理できないということです。DevOps (または何でも)をより良くするためには、自分が何をしてきたかを振り返り、現在の位置となりたい位置を比較する必要があります。そこにバリューストリームマネジメントの出番です。
アジャイルは、積極的な顧客とのコラボレーション、ダイナミックな変更対応、短い開発サイクル、頻繁な納品、継続的な対面チームコミュニケーション(スクラムとスプリント)、継続的な学習など、ソフトウェア開発製品とプロセスを改善し、管理するための基礎的な基盤を提供しました。リーンの主な推力は、顧客価値を最大化せずに資源、時間、スペースを消費する活動である無駄の識別と排除でした。
バリューストリームマネジメント(VSM)は、これらの概念に基づいて、製品、価値、時間のエンドツーエンドの全体的なワークフローの能力を可視化し、分析し、現在の状態(アイデアやコンセプト)から生産の流れを経て納品された状態に至るまでの時間を可視化します。VSMは、最高の品質を約束する効率的な運用環境を確保しながら、フローの改善とビジネス価値の継続的な最適化、アイデア(コード)から現金化までの生産、製品/開発管理会議への参加に焦点を当てています。
とてもパワフルに聞こえますよね?しかし、VSM ツールは、測定するメトリクスによってのみ効果を発揮します。メトリクスは、ソフトウェア開発チームがソフトウェアのライフサイクルの段階で、製品やプロセスの流れを理解し、評価し、コントロールし、情報に基づいた意思決定を行い、予測するのに役立ちます。別の言い方をすれば、以下のようになります。
「応用ソフトウェア測定の目標は、ソフトウェア管理者や専門家に、ソフトウェアプロジェクトのサイズ決定、見積もり、管理、制御を厳密かつ正確に行うための有用で具体的なデータポイントのセットを提供することである」(C.ジョーンズ、応用ソフトウェア測定。生産性と品質のグローバル分析)
メトリクスが重要であることをもっと納得させる必要がありますか?ここでは、時間をかけて正しいことを測定し、正しいことを測定するための 5 つの理由を紹介します。
- ソフトウェア・プロセスの問題を解決する(問題の特定、改善の機会)
- 品質の把握・向上(品質レベルの把握、品質向上、テストの徹底
- 問題の回避・修正(レスポンスの高速化、不具合の修正、挙動の変化、問題の実現を防ぐ
- アジャイル進捗管理(スプリントの進捗状況、可視性の向上、目標達成、ワークフローのバランス調整
- アジャイル計画(優先順位付け、スコップ、リソーシング
DevOps パフォーマンスの測定についての理解が深まったところで、何を測定すべきかについて説明しましょう。HCL Accelerate には、ソフトウェアデリバリパイプラインの多くの側面を追跡する機能がありますが、どの指標に注目するかは、組織独自の主要パフォーマンス指標に依存します。ほとんどの場合、注目したいメトリクスは以下のとおりです。
- リードタイム
- 待ち時間
- スループット
- ワークアイテムの配布
- 不良率の変化
- ロード
リードタイム
リードタイムとは、仕事の単位としてのアイデアが受け入れられてから、その仕事の価値が実現するまでに必要な時間であり、付加価値のある処理時間と付加価値のないサブプロセス間の待ち時間の両方を含む。作業項目の処理時間は、その活動に人またはチームが費やした時間の持続時間である。理想的には、市場投入までの時間を短縮し、顧客満足度を向上させるために、リードタイムの値は1日の傾向にあるべきです。
待ち時間
待ち時間(キューイングまたは無駄)は、ワークアイテムがバリューストリームで処理されている間、非生産的な状態のままアイドル状態で過ごす時間の推定値です。ソフトウェア製品のカスタマイズ(SPC)は、現在のソフトウェアリリースでの実装を必要とする顧客に合わせたソリューション(通常、優先度の高い)です。バリューストリーム管理者は、顧客と製品の価値を最大化するために、SPCの待ち時間を最小限にしたり、排除したりすることが求められています。
スループット
価値の流れのスループットは、ある期間に完了した作業単位項目の平均レートであり、流れの中の納品価値のレベルを定量化する。ある期間にあるステージで処理された作業単位の率は、そのステージのスループットとして表現されることがある。顧客要求への対応力を向上させるために、スループットの改善を識別する目標を設定し、それを実行することで、固定負荷容量を持つ価値の流れのリードタイムを短縮することができます。
ワークアイテムの配布
作業項目分布は、与えられたセット(同じ項目タイプ)の作業項目の総数に対する完了した作業項目の割合である。セットはユーザーが指定し、プロセスベース(リリースまたはスプリント)または時間ベース(所定の期間に完了した項目)の項目を含むことができます。この指標は、予測される業績に合わせて特定の作業タイプに優先順位をつけるために使用されます。
不良率の変更
バリューストリームでは、変更欠陥率は、バリューストリーム内に統合された欠陥の数が、所定の時間間隔内に完成したアイテムに占める割合で表される品質指標です。変更欠陥率は、バリューストリームの運用の予測可能性を理解するのに役立ち、以下の質問に対する洞察を提供します。
* 不具合は開発プロセスの初期段階で発見されているか。
* 顧客やビジネスに影響を与えることなく、本番環境で一貫性のある信頼性の高い納品が行われているか。
変更の欠陥率が高いチームは、迅速な進歩の可能性を秘めていますが、その代償として、不十分な品質基準が確立されていないため、効果的に迅速かつ効率的に作業を進めることができません。生産に入る前に、バリューストリームの中で欠陥を特定するためのチームの努力を修正することは、変更欠陥率の割合を低下させるための基礎となります。
負荷
負荷とは、ある時点においてバリューストリーム内でアクティブになっている作業項目(アクティブまたは待機中)の数である。負荷は、プロセスフローの生産性に関連するバリューストリームの利用能力を測定する。
まとめ
ソフトウェア・デリバリ・パイプラインでこれらのメトリクスを追跡するのは大変なことのように思えるかもしれませんが、バラバラのツールから手動でデータを収集して測定するのは苦痛です。しかし、バリューストリーム管理では、測定が簡単にできてしまうため、これらのメトリクスは無視できないほど重要です。当社のバリューストリーム管理ツールである HCL Accelerate は、既存の DevOps ツールチェーン内のすべてのものを自動的に接続し、ビジュアル・レポートにデータを収集し、測定スペクトル全体を最大限に活用して、非常に調整されたソフトウェア・パフォーマンス体験を提供します。
HCL Accelerate の無料 Community Edition でお試しください。