読み取り時間:13分
ソフトウェア開発に対するアジャイルアプローチは、長い間一般的な慣行であった。 HP online surveyによると、ITプロフェッショナルの16％が純粋なアジャイルを選択し、51％がitにリーンし、24％がアジャイルハイブリッドアプローチを採用しています。 今日では、ウォーターフォール開発はアジャイルの差別化要因として最も頻繁に言及されています。 アジャイルプロジェクト管理方法論に関するホワイトペーパーの主な違いについて広く議論しました。
アジャイル管理の適応性と柔軟性と変化への迅速な対応にもかかわらず、ワークフローは集中管理されたままです。 アジャイルKpi（主要業績評価指標）は、戦略的な計画、評価、および運用プロセスの改善のためのガイダンスを提供します。
従来の価値管理システムは、カテゴリースケジュールとコストの枠組みの中でタスクの完了に焦点を当てる傾向があります。 しかし、アジャイルでは、顧客とチームメンバーはすぐに結果を見て、スケジュール要件に対応する製品を提供するための時間枠と労力を調整します。 そのような知識はどのツールと技術を必要としますか？ アジャイル開発指標のパフォーマンス評価の概要は次のとおりです。
アジャイルソフトウェア開発Kpi
この記事では、すべての可能なアジャイル開発メトリックとKpiを探求するつもりはありません。 その上で、あなたのプロジェクトに最もよく一致させるあなた自身の物を発明することができる。 ただし、複数のソフトウェア開発の側面で使用される最も一般的なKpiについて説明します:
- ベロシティ
- スプリントバーンダウン
- リリースバーンダウン
- サイクルタイム
- 累積フロー
- フロー効率
- 自動テストによるコードカバレッジ
- 手動テストに対するテスト自動化
- mccabe cyclomatic complexity(mcc)
- コードチャーン
これらは、最初に探索しなければならない重要なものです
進行中の作業を測定
速度
速度は、スプリントで完了した作業量（ これは予測や比較ツールではありませんが、velocityは次のスプリントでどれだけの作業を行うことができるかについてのアイデアをチームに提供します。
Velocity indexはチームごとに一意であり、コミットメントがどれほど現実的であるかを評価するように設定する必要があります。 たとえば、プロジェクトバックログに200のストーリーポイントがあり、平均してチームがスプリントごとに10のストーリーポイントを完了した場合、チームはプロジェ
スピードを追跡する時間が長いほど、義務とコストの対応の精度が高くなります
アジャイル方法論を採用したばかりのチームや新製品に着手したチームでは、最初のいくつかのスプリントの速度推定値は不安定になるでしょう。 しかし、チームが経験を積むにつれて、速度はピークに達し、予測可能な流れとパフォーマンスの期待の高原に到達します。 一貫性のあるフローの減少は、開発の問題を示し、変更の必要性を明らかにするでしょう。
ベロシティメトリックを使用するためのヒント
3-5スプリント後の戦闘の不一致。 長時間経過しても速度が一貫していない場合は、明確な推定を妨げる外部要因と内部要因の両方を評価することを検討してください。
チームとタスクの変更後の速度追跡を変更します。 チームメンバーがプロジェクトを離れるか、複数のメンバー/タスクが追加された場合は、velocityを再計算するか、計算を完全に再起動します。
初期の予測には三つのスプリントで十分です。 将来のパフォーマンスを予測するには、前の3つのスプリントの平均を使用します。
スプリントバーンダウンチャート
スプリントバーンダウンチャートは、スプリントの終了前に行われる残りの作業量を示します。 このツールは、完了したアイテムを一覧表示するのではなく、目標に向かって進行状況を表示するため、特に価値があります。 また、チームがスプリントの開始時に行った計画ミスを明らかにするのにも非常に便利です。
下のチャート上の黒い線は、チームが時間通りにスプリントを完了するためにストーリーポイントを燃やす必要がある速度を示す予測（理想的な傾向）線を表 青い線は、スプリント全体の作業の合計量とその進捗状況を示します。 あなたは、五日と六日の間に、一つのチームが予測された進捗状況を達成するために管理していないことがわかります。 しかし、7日目に問題が解決され、作業は軌道に乗っていました。 このような継続的な更新は、チームが毎日のスタンドアップ会議中に新たな問題に対処することができます。
作業パフォーマンス自体に加えて、バーンダウンチャートは計画上の問題を明らかにすることができます
スプリントバーンダウンにアプローチするためのヒント
ストーリーポイントはスコープ内にもあるべきです。 ワークフローが一貫していない場合、一部のタスクが不均一なチャンクに分割されている可能性があります。 理想的な傾向と現実の間の偏差の範囲は、この問題をはっきりと強調しています。
計画外のタスクのためのアカウント。 バーンダウンチャートは、非表示のタスクと追跡されていないタスクの範囲を理解するのに役立ちます。 作業量が減少するのではなく増加している場合、プロジェクトには、対処すべき多くの未評価または計画外のタスクがあります。
バーンダウンチャートを使用してチームの信頼度を評価する。 現在の料金を考慮して、スプリントを時間通りに完了することについてどのように自信を持っているかをチームに尋ねます。 この指標を長く適用するほど、スプリントの推定値はより正確になります。
バーンダウンチャートによるリリースの推定
リリースバーンダウンチャートは、リリース前に完了する必要がある作業量を示します。 このグラフは進行状況の概要を示しており、オンタイム配信を保証するために変更を実装することができます。
従来のバージョンのグラフはsprint burndownグラフに似ていますが、y軸がスプリントで、x軸が残りの作業(日、時間、またはストーリーポイント)の尺度であるプロジェ しかし、より多くの作業がプロジェクトに追加されたり、推定作業が期待を満たしていない場合はどうなりますか？
下の図では、チームは4つのスプリントでプロジェクトを完了する予定で、当初は45のストーリーポイントを持っていました。 1回目と2回目のスプリントでは計画通りに進行しましたが、3回目のスプリントでは推定作業量が増加し、y軸に負の値で反映されました。 3回目のスプリントでは、5つの新しいストーリーポイントが登場しました。 しかし、最終的には5試合の出場にとどまった。 したがって、進行状況とリリース時間を調整する必要がありました。
リリースバーンダウンチャートは、要件の変化が多い状況に非常に効果的であり、チームが各スプリント中に軌道に乗ることがで
リリース時のリアルタイム予測。 プロジェクトが製品を反復的に開発するたびに変更が発生したら、これらの変更がリリース日にどのように影響するかを確認する必要があります。 リリースバーンダウンチャートは、作業範囲の更新に応じてリアルタイムでリリース日を予測することができます。
チームが製品リリースを時間通りに完了できるかどうかを見積もることも、追加されたタスクを考慮して期限がさらに進むことを予測することもで
作業を完了するために必要なスプリントの数を評価することも、リリースバーンダウンチャートで考慮すべき重要な要素です。
プロセスの健全性を評価し、ボトルネックを見つける
サイクルタイム
サイクルタイム指標は、作業を再開して再度完了する必要があるたび サイクル時間を計算することは全面的な性能についての情報を提供し、未来の仕事の完了を推定することを可能にする。 より短いサイクル時間はよりよい性能を示す間、一貫した周期の内で渡すチームは最も評価される。
下のグラフを使用すると、タスクを完了するのにかかる平均時間を特定し、交差してはならない中央値または管理限界線を描き、どのタスクが終了す
標準偏差は、タスクを完了するための通常の日数と推奨されていない日数の間に線を描画します
特定の期間のすべてのサイクルをスタックし、それを他のデータと比較することから洞察を引き出すこともできます。 さらに調査を行うことで、仕事の質について結論を出すことができます。
ここでは、月から月までの完了したタスクの数がバグの数と同じように増加していることがわかります
サイクルタイムの使い方
類似点を探します。 良い習慣は、エンジニアリングや管理のいずれかで、繰り返しの問題を明らかに、完了するために予測不可能なサイクル時間を取る同様の項目を見つ
過去の同様のタスクに基づいて新しいタスクを完了する時間を予測することで、データ駆動型の意思決定を行うことができます。
このグラフでは、同じ作業ペースをどのように維持し、作業の速度を低下させる内部問題があるかどうかを定義する方法を説明しています。
累積フローチャート(CFC)
累積フローメトリックは、プロジェクトの各段階でのさまざまなタイプのタスクの数を示すチャート領域で記述され、x軸は日付を示し、y軸はストーリーポイントの数を示します。 その主な目標は、さまざまな段階でタスクがどのように分散されるかを簡単に視覚化することです。 チャート上の線は、”完了”タスクを持つバンドが継続的に成長する必要がありますが、多かれ少なかれ滞在する必要があります。
チャートは、バンドの突然のボトルネックや上昇などの多くの重要な情報を開示しています
CFCは、チームの作業を簡単に視覚化するた このチャートは、かんばんの三段階のワークフローにも対応しています。 ここでは、to-do、in progress、completedの3つの主要なタスクカテゴリもマップします。
さらに、このチャートは、仕掛品(仕掛品)の制限を超えた時期を特定するのに役立ちます。 アジャイル開発において最も価値のあるツールの一つであるWIP制限は、プロジェクトのステータスごとに最大作業量を設定することで、仕上げ作業の文化
CFCによって指摘されている問題は何ですか？
- バックログの成長は、現時点で取り組むには優先度が低すぎるか、廃止された未解決のタスクを示します
- 一貫性のないフローと突然のボトルネックは、後の段階でどの領域を平滑化すべきかを示します
- 各バンドの幅は、平均サイクルタイムを示します
- “進行中”領域の大幅な拡大は、チームがこれを行うことができないことを意味する可能性があります。プロジェクト全体を時間通りに終了する
フロー効率
フロー効率は、開発によってほとんど見落とされているかんばん開発において非常に有用なメトリ チーム。 フロー効率は累積フローを補完しますが、実際の作業と待機期間の間の分布についての洞察を提供します。 開発者が待たずに一度に一つのことに取り組んでいるのはまれなケースです。 現実は通常より複雑です。 そして、”進行中の作業”は、常にステータスと一致しない名前です。
たとえば、コードには多くの依存関係があり、別の機能が終了する前、優先順位が変更される前、または利害関係者の承認を待っている前に、いくつかの機 あなたが仕事に対して待つどのくらいの時間を測定することは、実際の仕事に関連するプロセスを合理化するよりもさらに有用であり得ます。
最も低い効率の表示器を見ることによって、流れの効率
流れの効率
計算式を使用する方法を主要なネック理解できます。 これらの指標を組み込んだプロジェクト管理ソフトウェアを適用しない限り、作業/(作業+待機)*100%という単純な式でフロー効率を計算できます。 それからそれをデジタル式に視覚化したりまた更にあなたのオフィスのwhiteboardのグラフを引くことができる。
他のすべての指標と同様に、すべてのプロジェクトの通常の数値を請求することは不可能です。 これは基本的に、ストーリーポイントや別の作業項目が85パーセントの処理時間に対して15パーセントの処理時間を待機することを意味します。 LeanKanban School of Managementの管理専門家であるDavid J.Andersonは、ほとんどのチームの目標は40％以上であることを示唆しています。
流れの効率を固定する前に仕事の細部を分解して下さい。 グラフは、あなたの効率が最も低かった時間の正確な期間を表示することができます。 そして、このデータは、本当の原因とその治療法が簡単に明らかにされていないので、非常に慎重に分析する必要があります。 集中的な行動を開始する前に、原因を徹底的に調査してください。
ブロッカー解析により流量効率を向上させました。 前のポイントを実現するための良い手段は、ブロッカークラスタリング解析でフロー効率を向上させることです。 いくつかの作業がブロックされている場合、それは彼らが彼らに反応することができますので、チームの注意にこれらのブロッカーを持って来るために、色のステッカーや視覚信号の別の形態に値します。
一部の作業がブロックされた日数をマークし、解像度に優先順位を付けることができます
通常、ブロッカーは相互に多くの依存関係を持っているため、クラスタに蓄積されます。 内部ブロッカーと外部ブロッカーのような高レベルの類似性から始めて、設計、不足しているコンテンツ、またはその他の不足している機能をさらに指定してクラスタライズすると、より良いブロッカー分析を行うことができます。 ブロッカー解析は、流量効率の谷を調査する簡単な方法です。
コード品質の測定
コードカバレッジ
コードカバレッジは、自動テストの実行中に実行されるコードまたはブロックの行数を定義します。 コードカバレッジは、テスト駆動開発(TDD)の実践と継続的な配信のための重要な指標です。 伝統的に、メトリックは単純なアプローチによって解釈されます：コードカバレッジが高いほど、より良いです。 これを測定するには、カバーオールのような利用可能なツールのいずれかが必要になります。 テストを実行すると、ツールはどのコード行が少なくとも一度は呼び出されているかを検出します。 呼び出された行の割合は、コードカバレッジです。
カバーオールは、各ファイル測定に対するコードカバレッジを分解し、カバーされていない行とカバーされていない行を強調表示します
コードカバレッジの使用方法
カバーされていない行に焦点を当て、カバーされている行を過大評価しないでください。 コード行が1回またはそれ以上呼び出された場合、それがサポートする機能が完全にうまく機能し、ユーザーが満足しているとは限りません。 テストタスクを終了するには、コード行を呼び出すだけでは十分ではありません。 一方、覆われていない線の割合は、何がまったく覆われていないかを示し、テストに値する可能性があります。
カバーコードに優先順位を付け、100パーセントを目指すことはありません。 これは直感に反するように見えますが、100パーセントのカバレッジは、コードを適切にテストしたことを意味するものではありません。 プロジェクトには、重要なコードと残りのコードベースがあります。 テストの自動化は通常、高価なイニシアチブであるため、機能と対応するコードのチャンクに優先順位を付ける必要があります。
手動テストに対するテスト自動化
この測定は、手動テストに対する自動テストで既にカバーされている機能内のコード行数を定義します。 これは前の指標に直接従いますが、特定のユースケースがあります。 テストの自動化手動テストに対する割合は、回帰をカバーするために自動化が非常に必要な場合にのみ使用されます。 回帰テストは、機能の更新後に何かが壊れたかどうかを確認するために行われます。 また、製品が一定の改善を受けている場合は、回帰テストを自動化する必要があります。 そうでない場合は、手動のQAスペシャリストは、更新のコミットごとに同じテストシナリオを繰り返し繰り返す必要があります。
コードカバレッジに使用されているのと同じ計測器を使用して、このメトリック
を描画することができます。 通常、テスト駆動型の開発フレームワーク内で作業しない限り、自動テストによってすべてを一度にカバーするのに十分な時間と人的資源がありません。 したがって、ユーザーエクスペリエンスに影響を与えることが確実な機能に優先順位を付けることをお勧めします。
McCabe Cyclomatic Complexity(MCC)of code
コードの複雑さの測定は、コードのテストおよびメンテナンス中の問題のリスクを評価するために使用されます。 コードの複雑さが高ければ高いほど、許容可能な数のバグがあり、高い保守性を維持することがより困難になります。 コードの複雑さを測定するための最も一般的なアプローチは、McCabe Cyclomatic Complexity Metric(MCC)です。 MCCの複雑さの結果を描画するための式の1つは次のとおりです:
MCC=edges–nodes+return文
画像上のMCCは3
に等しいこのメトリックでは、開発者は主観的にそれを見てコードの複雑さを推定していません。 エンジニアのスキルセットが異なるため、評価が異なるため、コードのリファクタリングやバグの修正は長期的にはより困難になります。 市場には、コード階層の深さやコード行数など、他のコード複雑度指標と組み合わせることができる多くのMCC測定ツールがあります。
MCCの使用の詳細と落とし穴
コードの複雑さに対する人間と機械の認識のバランスをとる。 MCCを使用する主な理由の一つは、仲間の開発者のためにコードを読みやすくすることです。 コードの可読性により、従来のコードに対処しなければならない新しい開発者の長期的なオンボーディングのリスクが軽減されます。 また、リファクタリングも簡素化されます。 ここでの問題は、MCCモデルがいくつかの複雑で読みやすい方法を容認できないと考えることができることです。 単純な論理を持つ多くのメソッドは、単一の複雑なメソッドよりも人間にとって理解するのがさらに難しくなる可能性があります。
MCCを制限的な指標にしないでください。 一部の組織では、MCCテストに合格しないコードコミットの終了を練習しています。 これは潜在的にコードの単純さを高める可能性がありますが、クラス、メソッド、および関数のレベルで複雑なコードを持つのは自然です。 それらを完全にブロックすることは必ずしも有益ではありません。 一般的なコードの複雑さKPIを開発者に設定することをお勧めします。
コードレビューのためにMCCを適用します。 MCCテストのもう一つの貴重なプラクティスは、コードレビュー中にそれを適用して、欠陥のリスクが最も高い特定のコードチャンクをレビューする作業の範
コードチャーン
コードチャーンは、全体的なプロセスとリリース前の時間の両方の点で、コードベースに起こる傾向と変動を非常に便利に視覚化します。 Churnは、追加、削除、または変更されたコード行数を測定します。 グラフには3つの測定値がすべて表示されることがあります。
Microsoftのこの例には3つのパラメーターがすべて含まれていますが、選択的に使用できます
コードチャーンの追跡はやや原始的なメトリクスに見えますが、さまざまな開発段階でコードの安定性を評価することができます。 初期のスプリントでは安定性が最も低く、リリース直前には安定性が最も高くなることを期待する必要があります。 コードが非常に不安定で、リリース日が近づいている場合は、アラームを鳴らしてください。
コードチャーンユースケース
規則性を探します。 コードの変更の定期的なスパイクは、タスク生成アプローチが十分に集中しておらず、定期的に多くの大規模なタスクを生成することを明らかにする
不規則だが高いスパイクは調査が必要である。 コードの変更に不規則だが強力なスパイクがある場合は、コード内でこのような地震のピークを引き起こしたタスクを調査し、特に新しいコード行の数が変
トレンドに注意してください。 製品の安定性は、リリース前に非常に重要になります。 前述したように、解約率は、チームがリリースに近づくほど減少傾向にあるはずです。 増加傾向は、新しいコードが十分なテストを受けない可能性が高いため、リリース後に製品が不安定になる可能性があることを意味します。
コントロールではなく進歩を目指す
他のパフォーマンス指標と同様に、アジャイルメトリクスには、あなたの成功を密封する明確な答えや実用的な しかし、彼らが提供する知識を使用して、議論を開始し、評価を行い、問題のある問題に対処するための独自の計画を提供する必要があります。
指標は、チームのパフォーマンスと仕事に対する全体的な満足度に関する数値的な洞察を提供しますが、それらに固執しないでください。 アジャイルメトリクスが標準化されていないことを考えると、異なるチームの成功を比較する意味はありません。 むしろあなたのチームのフィードバックを包含し、規則的な議論を始め、共通の目的およびサポートの大気を養うことを確かめなさい。