そして、ここスクラムではほとんど答えがありません。 ほとんどすべてのプロセスで使用できる純粋なビジネスメトリック（ ROI 、 獲得ビジネス価値 、 テスト済み機能の実行など）に加えて、スクラムはVelocityメトリックも提供します。 ただし、Velocityをメトリックとして使用する価値はないとすでに書かれています。 これは、予期しない不快な結果につながる可能性があります。
一目で良い指標がないことがわかります。 記事の最後で、スクラムのいくつかの暗黙的なメトリックに言及しますが、ここでは問題の原因について説明します。 主な理由は時間です。 ビジネスは時間によってほとんどすべてを測定します（お金でさえ時間です）。 そしてスクラムでは、この時間は固定されており（「鉄の三角形」をすぐに覚えています）、開発は反復によって実行されます。 しかし、反復の中で、タスク、ユーザーストーリー、テスト、製品の収集、インストールなど、多くの興味深いことが起こります。 そして、これらの情報はすべて、反復の背景で失われます。 いわゆる「ノイズスムージング」が行われます。 あるアクティビティでドラッグした場合、別のアクティビティに追いつくことができます。 結局、反復は完全にチームに属し、チームは、すべてが最後に準備ができていれば、反復内で何かを「発明」できます。 このアプローチは計画には非常に適していますが、メトリックスにはうんざりします。
第一に、反復の終了時にメトリックを取得することは非常にまれです。 そして、これはせいぜい週に一度です。 基本的には、2週間ごとにすべて同じです。 第二に、私たちはすでに「スムージング」に言及しており、独自の調整も行います。 全体のイテレーション、状況は非常に悪かったが、最終的には誰もが非人道的な努力と出来事をした-すべては準備ができており、メトリックは整然としている。 いいですか？ いや！ 有用な情報を失い、間違いから学ぶことはありません。
かんばんでは物事がまったく異なります。 ここでは、 各タスクに注意が払われます 。 開発チームを通過するタスクフロー全体からメトリックが削除されます。 メトリックの短いリストは次のとおりです。
- サイクル時間 -タスクの開発が開始されてから最終的な配信フェーズを完了するまでの間にタスクが開発中であった時間。
- WIP-作業中の同時タスクの数。 タスクの作業のさまざまな段階に分かれています。
- リードタイム -タスクが表示されてから最終的に配信されるまでの時間。 実装キューにサイクルタイムとレイテンシを含めます。
- 無駄な時間 -タスクが直接作業ではなく、さまざまなキューで費やす時間。
- 有効性とは、異なるキューでの期待値ではなく、タスクの操作に直接費やされる時間の割合です。
- スループット -時間単位（日、週、月）ごとにチームが実行できるタスクの数。
この単純なメトリックのリストにより、開発プロセスを完全に理解および制御し、絶えず分析および改善できます。 理想的には、これらのメトリックは、タスクのカテゴリ（サイズ、種類、緊急度）のコンテキストで考慮され、何が起こっているかについての理解をさらに向上させ、チーム作業結果のより正確な予測を可能にします。
私は、スクラムで暗黙的なメトリックに言及することを約束しました。 これらのメトリックは、バーンダウンチャートを使用して収集できます。 毎日の進捗とスケジュールのスムーズさを考慮して、チームワークのパターンを決定するために分析できます。 分析を強化できます。 これを行うには、タスクを分類し、各カテゴリのバーンダウンチャートを作成する必要があります。 一部のチームは反復内でタスクメトリックを追跡しますが、私の意見では、これはスクラムの原則に多少反します。反復内では、チームは任意の順序でタスクに取り組むことができます。
まとめると。 かんばんでは、メトリックはスクラムよりもはるかに強力ですが、これにより、かんばんが実装しやすいアプローチになりません。 それどころか、かんばんには、継続的な改善を伴うチームからのより多くの責任、管理、および分析が必要です。 しかし、ビジネスの観点から見ると、かんばんははるかに透明で制御されています。
どのような指標を使用していますか？ スクラムでどの指標がうまく機能しましたか？