最も一般的なアジャイルメトリックスを使用した経験
アジャイルメトリックスを使用してチームの生産性を測定することは、アジャイルの哲学の重要な部分です。 チームマネージャーとすべてのメンバーは、自分の仕事の結果を見て、ワークフローを改善し、効率を高めるために、このデータを使用する必要があります。
エンドユーザーとクライアントは、製品の結果を評価することに焦点を当てたアジャイルプロジェクトメトリックの使用からも利益を得ることが メトリクスを使用すると、スクラムマスター、開発者、設計者、テスターはアプリケーションのパフォーマンスを測定し、現在および以前のタスクが製品をより良
この記事では、重要なアジャイルメトリクスを確認し、このアジャイルメトリクスダッシュボードを実際のプロジェクトに適用した経験を共有します。 チームを成功裏に導き、結果を出すためには、どの指標を適用するかだけでなく、どのように行うかを知る必要があります。 
一般的なアジャイルメトリクスの種類
アジャイルメトリクスの分類は石で設定されていません。 それでも、長年にわたり、さまざまなアジャイルフレームワークで三つの主要な種類のアジャイルメトリクスが上昇してきました。
- かんばん指標—これらの指標は、投資時間（サイクルタイム）と配信結果（スループット）、およびその比率を測定することに基づいています。
- スクラムメトリック—ワークフローの計画と理解に焦点を当て、特定の期間にどのくらいの作業が実行されたかを示すメトリック。
- リーンメトリック—機能のテスト、可能性のあるエラーのチェック、負の影響の予見による技術的評価による生産効率と製品品質の継続的な測定。
ソフトウェア開発プロセスと結果の主な側面を評価するために、三つのタイプのすべてのメトリクスを使用します: 製品品質、チームの生産性および健康。
アジャイル品質指標
チームの速度と効率の測定を開始する前に、一般的に正しい方向に動いているかどうかを知る必要があります。 タスク自体が間違った方法で形成されている場合、すべての開発タスクを迅速に配信するために使用するのは何ですか？ 各ソフトウェア開発チームとマネージャーの優先事項は、すべての活動が製品の改善に関連していることを確認することです。
エスケープされた欠陥
各アジャイルプロジェクトにはスプリントまたは作業サイクルがあり、その終わりに特定のタスクが配信されます。 作業が完了した後、チームのマネージャーは、ターンit結果の品質を評価する必要があります。 すべての変更、編集、および修正されていないバグは、開発者が修正することができたが、修正しなかった問題をエスケープされた欠陥です。
エスケープされた欠陥に関するレポートを作成し、具体的な統計を収集した後、結果をチームと議論する必要があります。 各チームメンバーは、チームが一般的にミスエラーの種類を知っていることを確認してくださ 個々の提案がある場合は、チームメンバーと一対一で議論してください。
失敗した展開
製品が展開されたがリリースされていない場合、またはユーザーの誘致に失敗した場合、これは失敗した展開として記録されます。 場合によっては、展開の失敗が利害関係者の決定に発生したり、ビジネスモデルが信頼できないことが判明したりすることがあります。 問題の原因が何であれ、失敗したすべての展開とその失敗の理由を記録する必要があります。
新しい展開をリリースする前に、チームは常に以前に失敗した展開のリストを見て、これが同じプロセスを実行できないかどうかを調べることができます。 以前のバージョンの失敗の理由を分析することで、将来の問題を回避することができます。
Release Net Promoter Score(NPS)
Net Promoter Scoreは、ユーザーの反応を定量的(数値、統計、平均評価)と定性的なフィードバック(レビュー、直接フィードバック、メッセージ、電子メール、通話)で評価するメトリクスです。 チームがフィードバックを収集して分析した後、各チームメンバーは、ユーザーが製品を推奨する可能性があるかどうかを評価するスコアを提案します（通常、スコアは1から10までの制限で設定されます）。
アジャイルプロジェクトマネジメントメトリクス
以前の失敗と成功の完全な履歴が得られたら、現在のすべての不完全なプロジェ 製品の”何をすべきか”という開発の方向性を確立した後、”チームの効率を評価する必要があります。 アジャイルプロジェクトメトリクスを使用すると、チームメンバーが期待に応えているかどうか、タスクを理解しているかどうか、期限を管理しているかどうか、すべてのプロセスが調整および同期されているかどうかを知ることができます。
リードタイム
リードタイムは、スプリントの終了時にプロダクトバックログエントリが到着するのにかかった時間をチームが確認できるメトリッ これは、任意の開発段階での製品の追跡、タスクごとのタスク、またはアイデアからリリースまでの全体的な時間の費用を評価するために使用できます。 これは、開発者が将来の作業を計画し、価格を見積もる際に使用できる長期的な指標です。
各プロジェクトのリードタイムを必ず記録してください。 プロジェクト全体をカバーするより大きな画像の統計と、スプリント指標を整理した両方を保持することをお勧めします。
サイクルタイム
リードタイムが長期的なチームパフォーマンス指標の中にある場合、サイクルタイムは個々のタスクに焦点を当てます。 このメトリックでは、1つのタスクごとに1つのサイクルが実行される1サイクルの期間を評価し、プロジェクトごとのサイクル数を計算し、製品がすでにベータテストまたはリリースされている場合にエンドユーザーの達成結果を測定します。
サイクルタイムを使用すると、チームはあるタスクに時間がかかりすぎるか、チームメンバーが自分の目的を達成していないかをすぐに確認できます。 この短期的な指標は、プロジェクト管理をはるかに容易にし、問題が発生したときに迅速に特定するのに役立ちます。
スプリントバーンダウン
この指標は短期および長期の両方に適用されます。 そのためには、スプリントの合計数を推定し、可能性のある時間の費用を予測する必要があります。 また、長期的に使用することができます-管理者は、以前のプロジェクトのレポートを分析し、予想される時間枠に失敗した段階を特定し、遅延の原因を分析
最も重要なのは、sprint burndownでチームのワークフローのダイナミクスを追跡できることです。 一部のメンバーは、他の人がプロジェクトの終わりに向かって燃え尽きる一方で、最初の段階で仕事を遅くする傾向があります。 スプリントのバーンダウンを使用すると、チームリーダーはこれらの傾向を検出し、その原因を特定し、作業の配分と時間管理をメンバーに支援できます。
ソフトウェア開発におけるアジャイルの長所と短所についての詳細を学ぶ！
Epic&Release burndown
この指標はSprint Burndownに似ていますが、唯一の重要な違いは、リリース前とリリース後のチームの生産性に焦点を当てていることです。 管理者は、新しい要件を追加し、エンドユーザーのフィードバックに基づいたタスクを組み込むことができます。 これは、プロジェクトのリリース後に与えられたタスクも組み込まれているため、sprint burndownの改良版です。
Velocity
このメトリックは、特定の期間における完了したストーリーポイントの数を評価します。 あなたの歴史に基づいて、あなたは将来のストーリーポイントのための時間の費用を予見することができます。 特定のスプリントでチームの速度が低下すると、チームメンバー間の誤解や、以前に予想されていたよりも困難なタスクが指摘される可能性があります。
ソフトウェア開発におけるアジャイルの長所と短所についての詳細を学ぶ！
追加のアジャイルメトリクス
アジャイルメトリクスは、チームがプロジェクトをよりよく知り、製品開発の多くの重要な側面を追跡するのに役立ちます。 また、上級幹部向けのアジャイルメトリクスもあり、開発とチームの幸福の全体像を見ることができます。 私たちの経験によると、これらの追加の指標は、あなたの仕事のあらゆる側面を測定するのに役立ちます。 しかし、私たちは最終製品について最も多くを伝え、完全に完全な結果を提供するのに役立つ重要な特性を定義しました。
累積フロー
メトリックの名前は、すべてのプロジェクトフローを累積し、単一の図で評価するという目的を明確に示しています。 このようなグラフを持つことで、より詳細なアジャイルレポートを分析する時間がないプロジェクトの利害関係者に送信することができます。
この図では、通常、次のプロセスについて説明しています:
- backlog内のタスク:backlogチームメンバーのタスクの数は、指定された時間枠内にあります。
- 承認された作業:
- バッファータスク:承認を待っているすべての作業がバッファゾーンに定義されています。
- 進行中:現在のワークロードを評価する必要があります。
コードチャーン
この指標は、リリース前のコードベースの変更の傾向を示しています。 チャーン図には、一度に追加、削除、または変更されたコードの量が表示されます。 初期のスプリントでは、コードがまだ不安定であるため、グラフ上に多くのスパイクや落下がありますが、プロジェクトが進行するにつれて、コードチャーン
リリースの前に、チャーンは衰退を得るべきです—リリースの前にコードを追加または編集することは、十分なテストを受けないことを意味します。 全体的に、アジャイルチャートに不規則性があるときはいつでも、その理由を調査してください。
管理図
管理図は、チームがサイクルタイムの持続時間に関する情報を見ることができるグラフです。 理想的な結果は、チャート上の線が時間とともに着実に下がっていくことを意味します—それはチームの速度の増加を意味します—単一のサイクルごとに もう一つの重要な側面は一貫性である—サイクル時間は関係なく、タスクの種類の滞在する必要があります—それはあなたが正しい作業分布を持って
健康指標
ソフトウェア開発チームは、メンバー間のコミュニケーションを円滑に保ち、誰もが満足しているかどうかを確認するなど、長期的な優先順位に焦点を当てる必要があります。 アジャイルは柔軟な方法論であり、管理者が何に注意を払うべきかを知るとすぐに、さまざまなメンバーの利益に適応できることを意味します。 すべてのチームメンバーがワークフローに満足しているかどうかを確認する方法は次のとおりです。
幸福
あなたのチームで信頼され、非公式の関係を持っている場合、それは各メンバーとの開いたダイアログから開始する方が簡単です。 全員に、1から5までの会社での経験を評価するように依頼してください。 あなたは質問を支援することができます—彼らの仕事の最高と最悪の側面は何ですか、何を改善することができ、何が幸福を増やすことができますか？ チームが友好的なコミュニケーション習慣を持っていない場合は、匿名の調査を使用すると、より客観的な結果につながることができます。
チームの士気
チームの士気と幸福は同じものではありません。 チームの士気は、生産性、自尊心、自分のプロの資質の評価に結びついているのに対し、幸福は快適さと関係があります。 繰り返しますが、従業員に1から5までの士気を評価し、次の質問をするように依頼することができます;
- 会社で働くことはあなたのスキルを向上させるのに役立ちましたか？
- 現在のワークロードであなたの可能性を最大限に探求していますか？
- あなたの仕事を楽しんでいますか？
- あなたの仕事の明確な結果を見ていますか？
- あなたは新しいプロジェクトに熱心ですか？
ここでの目標は、チームの開発の流れが正しい方向に進んでいることを理解することです。 時には、ソフトウェア開発チームのマネージャーは、メンバーの利益を無視して、収益性の高いが退屈なタスクを取 この調査は、従業員が自分の仕事に興奮し、挑戦しているかどうかを確認するのに役立ちます。
チームメンバーの離職率
チームマネージャーが頻繁にチームメンバーを交換する場合、作業環境が不健康である可能性が高いことを意味します。 時間をかけて売上高の一定の割合は健康である—実際には、それが停滞を意味するように、あなたは、年間の人々の任意の追加を持っているしたくありませ しかし、あなたは活動の突然のスパイクに注意する必要があります—いくつかの人々がチームを去った月、または多くの人々が参加しました。 突然多くの新規参加者が追加された場合は、プロジェクト関連の作業に直接行く前に、オンボーディングプロセスに注意を払う必要があります。
エンドユーザーの利益を測定する
アジャイルチームは、製品が最終的なユーザーとビジネスオーナーのニーズにどれだけ適合するかを知 これは、最終的なユーザーのためのコードの品質とその使いやすさだけでなく、可能なメンテナンスの合併症を決定する包括的なコード分析で行われます。
静的コード分析
これは、ソフトウェアが非アクティブな場合のコード分析の単純なタイプです。 オープンソースツールでコードを自動的に監視するだけで、セキュリティ上の問題を特定し、技術的な負債やバグを検出し、問題のあるコードフラグメントをガベージコレクタに送信することができます。
動的コード分析
動的コード分析は、エンドユーザーが受け取った経験を評価するためにソフトウェアを実行する必要があります。 私たちは、開発者とテスターが常にユーザーの立場に立ち、最も一般的なシナリオを探求することを奨励しています。 たとえば、彼らは同僚や家族をソリューションに紹介し、フィードバックを要求することができます—それは契約で禁止されていない限り。 最も重要なことは、動的コード分析を完全に担当するQA専門家のチームがあります。
最高のアジャイルメトリクスを適用する方法
利用可能なアジャイルメトリクスのすべての種類の中から、チームやプロジェ それはより緊急の仕事からあなたをそらすべきではありませんが、これらの重要な特性を追跡することは、習慣でなければなりません。 ここでは、アジャイルメトリクスをワークフローにシームレスに組み込んだ方法を示します。
パフォーマンス、予算、品質に焦点を当てる
すべての指標を選択した後、作業の品質、負荷、時間の費用、予算を明確に把握できるようにする必要があり まず、アジャイルのパフォーマンス評価のためのサイクルタイムと速度、コード品質評価のためのコード分析、すべての開発プロセスとそのコストを追跡するための累積フローなど、アクティブなプロジェクトに関連する短期的なメトリクスを設定しました。
最初のスプリントでは、次のことを確実に行います:
- プロジェクトに含まれるスプリントとサイクルの数を定義します。
- クライアントのニーズを考慮して、プロジェクト全体の時間費用を見積もります。
- 最終製品の複雑さのレベルを理解するための競争力のあるソリューションの評価。
- プロジェクトの最もエキサイティングで、挑戦的で、困難な側面に対するチームメンバーの期待に関するフィードバックを収集します。
このようにして、プロジェクトを完了するためにどれだけの時間を費やし、同様のソリューションに基づいて品質基準を設定し、チームがタスクに取り組む意欲を持っているかどうかを知ることができます（生産性に大きな影響を与えます）。
最初のスプリントの後の指標
ここでは、クライアントとすべてのチームメンバーからのフィードバックを得ることに焦点を当てます。 最初のスプリントの後、ワークフローに関わるすべての関係者がプロセスを理解し、快適に感じることを知りたいと考えています。 また、コードの品質を評価することにも重点を置いており、次のスプリントのそれぞれの一部としてコード分析と技術負債評価を計画しています。 コードの最初の行が書かれるとすぐに、その品質を維持することが私たちの優先事項です。
Velocityは
の後に来ますVelocityは私たちのプロジェクトで最も重要な指標の1つですが、重要な指標ではありません。 私たちは、初期段階での速度数に私たちの判断を基づかないようにしています。 チームは計画をスキップしたり、クライアントにいくつかの重要な質問をするのを忘れたりする可能性があります。 私達は顧客およびチーム-メンバーが彼らのペースを見つけることを可能にするプロダクトの最初の段階を急がない。
チームの速度を上げることは、実行時点での優先事項の1つになります。 すべての機能とデザインがレイアウトされるとすぐに、時間の費用を最小限に抑え、すべてのタスクをできるだけ早く完了するよう努めています。
個々の指標
使用される各指標は、チーム全体と個々のメンバーに対して同様に利用可能である必要があります。 開発者、テスター、デザイナーは、チーム全体だけでなく、自分の仕事のペースと結果を見ることができるはずです。 それを実現するために、JiraやHubstaffなどの生産性ツールと時間追跡ツールを使用しています。 すべての一般的なレポートは、個々のものと同期されている—メンバーは、彼らの時間が作る全体的な生産時間の割合を見ることがで
よくある質問
アジャイルのKPIとは何ですか？
アジャイルにおける主要業績評価指標は、ビジネス目標を達成する上でチームの効率性を示す測定可能な値です。 高レベルのKpiは、最終製品、コンバージョン率、フィードバック品質に魅了されたユーザーの数など、多くの要因に依存する長期的な結果に焦点を当てています。 低レベルのKpiは、プロジェクトに費やされた時間（通常は時間単位で計算）、プロジェクトの予算（タスクごとの投資）など、多くの関連要因の影響を受けな
アジャイルは、継続的な改善に基づく開発方法論です—ソフトウェア開発は、データを分析し、それに適応します。 チームは、パフォーマンスと作業品質に関するアジャイルKpiを分析し、次のスプリントですぐに変更を実装します。
スプリントメトリックとは何ですか？
スプリントメトリクスは、ソフトウェア開発チームの成果物を評価し、各スプリントの終わりまでに最終顧客にどれだけの価値が提供されたかを この値は、新しい機能、設計の改善、またはバグの削除で測定できます。
スプリント指標の次の目標は、ビジネス面でチームの有効性を測定することです—ソリューションが市場にどのくらい迅速に配信されたか、クライア 最後に、メトリクスは、開発者のプロジェクトに対する満足度と、チームが一般的に取っている方向性を示す必要があります。
アジャイルプロジェクトにとってメトリクスが重要なのはなぜですか？
アジャイル方法論の全体のポイントは、開発者が各スプリントの後にプロセスで常に修正を行うことができるということです。 具体的なデータ、統計、グラフを持つことで、開発者は次のスプリントにどのような変更を加えるかを理解し、最終製品の品質を評価することができます。
アジャイルにおけるスプリントとは何ですか？
スプリントとは、チームが特定の数のタスクを完了するように設定された開始日と終了日を持つ明確に定義された期間です。 スプリントはスクラム、アジャイル、DevOpsの基礎であり、チームはワークロードを管理しやすい小さなチャンクに分割し、各スプリントの結果を追跡します。 これらの各期間は、事前に計画、リスク評価、責任割り当て、およびスプリント後の分析を伴うミニプロジェクトのように扱われます。
各プロジェクトは一連のスプリントで構成されています。 各スプリントは評価されるため、早期に問題を発見し、次のスプリントでそれらを削除するのは簡単です。
ソフトウェア開発のためのメトリックは何ですか？
ソフトウェア開発指標は、ソフトウェア開発プロジェクトの品質、パフォーマンス、およびチームの健康を測定できる定量的な値です。 これらは、プロジェクトが進むにつれて開発プロセスを改善するのに役立ち、組織と計画を改善するためのチームの将来の作業に使用できます。
ソフトウェア開発指標には主に六つのタイプがあります:
- 正式なコードメトリクス—これらは、コード行数（LOC）、命令パスの長さなどを決定することによって実行された作業量を計算する客観的な定性的な値です。
- 開発者の効率性指標—チームは、割り当てコード、アクティブな日数、およびタスクに費やされた時間を計算できます。
- アジャイルプロセスメトリック—プロジェクトがスプリントに分割されると、チームはプロジェクトの小さな部分の効率を測定することができます–リードタイム(複数のスプリントを含む可能性のある特定の開発段階に費やされた時間)、サイクルタイム(通常は1つのスプリントが1サイクルに該当する)、およびベロシティ(特定の時間枠で行われたタスクの数)。
- 運用指標—これらの指標は、ソフトウェアの実行特性をチェックし、会社のスタッフがサードパーティの助けを借りずにツールを維持するのにどれだけ効 Mean Time Between Failures and Mean Time to Recover(MTTR)ソフトウェアが自然な状況でどのように実行されるか、および負荷を処理する社内チームがどのように装備されているかを確認し
- テストメトリクス—これらのメトリクスは、コードカバレッジ—テストされたコードの量、バグの数、および技術負債の割合を評価します。
- 顧客満足度—チームは、ネットプロモータースコア、顧客満足度スコア、および顧客努力スコアを測定することにより、製品に対するエンドユーザーの反応に関す これらの指標は、ユーザーが製品を推奨するかどうか、および結果に満足しているかどうかをそれぞれ評価します。
アジャイルメトリクスはソフトウェアネットワークの一部であり、私たちのガイドからわかるように、他のカテゴリで構成することができます。
SDLCメトリクスとは何ですか？
SDLCは、ソフトウェア開発ライフサイクルであり、典型的な技術がその概念、実行、および最終化の間に受ける一連の段階です。 平均的なSDLCは、次の段階で構成されています:
- 既存のシステムを評価し、その機能、利点、問題を定義する;
- 新しいプロジェクトの機能、デザイン、ターゲットオーディエンスなどの要件を定義する。;
- システムの設計と一般的なユーザーパスの概要;
- ソフトウェアの開発、つまりコードの記述、ハードウェアの準備、機能の作成を意味します;
- ソフトウェアの性能、機能、セキュリティ、インターフェイスなどのテスト;
- 技術が長期的に実行される自然環境でソフトウェアを展開する;
- コードを更新し、特定のフラグメントを置き換えたり編集したり、バグを削除したりすることにより、システムを維持する。
SLDCの各ステージは、以下の特性によって測定することができます。
- 要件：チームはプロジェクトのすべての要件を収集し、時間とお金の面でそれぞれの実装を評価する必要があります;
- ソフトウェア品質:すべてのアジャイル品質指標は、SDLCの開発段階で使用できます;
- テストケース:チームは、実行されたテストアクティビティの数、速度、およタスクごとに獲得すると、すべてのチームメンバーが生産的かどうかを評価できます。
このガイドに記載されているすべての指標は、ソフトウェア開発ライフサイクルのさまざまな段階で使用できます。 このプロジェクトは、問題が積み重なる可能性があり、製品の重大な欠陥を見逃すことが容易であるため、リリースに近い監視の必要性が最も高いです。
アジャイルメトリックのスループットとは何ですか？
スプリントごとに完了したストーリーの数を計算するメトリックです。 スクラムでは、同様のメトリックはスプリント速度と呼ばれます。
結論
アジャイルメトリクスは、ソフトウェア開発プロジェクト全体を通して情報に基づいた意思決定を行うための強固な基盤を設定します。 開発者は、これらの洞察を使用して、次のスプリントで効率を高め、製品の品質を常に向上させることができます。 しかし、ソフトウェア開発プロジェクトでは、開発指標が絶対的な優先順位になるべきではないことに注意する価値があります。 開発者は、まず第一に、プロジェクトのニーズと視聴者の好みに依存する必要があります。
Jelvixでは、指標をプロジェクトに適用するためにパーソナライズされたアプローチを使用しています。 まず、プロジェクトのMVPについてクライアントと議論し、ターゲットオーディエンスを調査し、競争力のあるソリューションを分析し、プロジェクトに最 私たちは、すべての単一のKPIを適用するように努力していません—代わりに、私たちは、プロジェクトが最もニーズを反映したものを選択します。