ソフトウェア開発チームを管理するのは並大抵のことではありません。プロジェクトが最終ラインに到達するまで、エンジニアリング プロジェクト マネージャーは息つくことができません。ソフトウェア エンジニアリング マネージャーがプロジェクトとチームのパフォーマンスを向上させる方法を模索するのはこのためです。そして、まさにそこに、Kpi のようなものが神の姿を借りて登場します。
KPI はチームのフィットネス トラッカーのようなものです。KPI は、物事がスムーズに機能している部分と、ネジを締める必要がある部分を確認するのに役立ちます。しかし、無数の KPI が存在する中で、実際にどの KPI を考慮すべきでしょうか?あなたをロックスター ソフトウェア チーム マネージャーのように見せてくれるトップ 15 と、やめたほうがいいかもしれないいくつかを詳しく見てみましょう。
KPI は画面上の単なる数値ではなく、より良い意思決定へのロードマップです。適切な指標を追跡することで、チームがどこで優れているか、どこに改善の余地があるかを特定できます。これは、プロジェクトのタイムライン、リソースのニーズ、潜在的な障害を予測するのに役立つ水晶玉を持っているようなものです。
あなたがレースに参加していると想像してください。ただし、車がトラックを走り回るのではなく、チームはスプリントでタスクを完了するために競い合っています。
問題は、スタートライン (「やるべきこと」) からゴールライン (「完了」) までどれくらい早く到達できるかということです。
そこで、サイクル タイムが登場します。これは、チームがどれだけ早く仕事を終わらせているかを示すストップウォッチです。
サイクルタイムはスピードがすべてですが、ただ速く走るだけではありません。
重要なのは効率性であり、どこで速度低下が発生しているかを知ることです。平均して、高パフォーマンスのチームのサイクル タイムはタスクあたり約 1.8 ～ 3.4 日です。
時間がかかっている場合は、内部を調べて遅延の原因を確認する時期が来ている可能性があります。プロセスのボトルネック、マルチタスクが多すぎる、または単なる古い技術的負債である可能性があります。
あなたのチームがモバイル アプリの新機能に取り組んでいるとします。タスクは月曜の朝にバックログから「進行中」に移行します。開発チームはコーディング、テスト、コミットのプッシュを開始し、水曜日の午後までにタスクが完了し、「完了」とマークされます。これは 3 日のサイクルタイムです。
さて、別のタスクで行き詰まりが発生したとします。コード レビューに永遠に時間がかかるか、依存関係によって物事が滞っている可能性があります。そのタスクが 7 日または 10 日も続く場合は、何かが正しくないことを示しています。
ここで魔法が起こります。サイクルタイムを追跡することで、パターンを見つけることができます。
もしかしたら、あなたのチームはいくつかのタスクでは非常に迅速に取り組んでいるかもしれませんが、他のタスクでは行き詰まっているかもしれません。この洞察があれば、詳細を掘り下げてプロセスを合理化する方法を見つけることができます。おそらく、コードレビュープロセスを微調整したり、タスクの優先順位を変更したりするのと同じくらい簡単なことかもしれません。
目標は？サイクル タイムを短縮し、チームがプロのようなタスクを継続的に達成できるようにするため。
そして、それが起こったとき、あなたはただ速く動いているだけではなく、賢く動いているのです。
コードに関して言えば、コードを大量に書くことが重要ではなく、書いたものが実際に機能することを確認することが重要です。そこでコード カバレッジが役立ちます。
コード カバレッジはコードの健康診断と考えてください。
コードベースのどの程度がテストされているかがわかるため、問題になる前に卑劣なバグを発見できていることがわかります。
ソフトウェア開発の世界では、コード カバレッジの適切なベンチマークは約 70 ～ 80% です。それを達成できているなら、かなりうまくやっていると言えます。
ただし、ここでの目標は完璧であることではないことに注意してください。100% のカバー率は、ビーチの砂粒をすべてキャッチしようとするようなものです。
代わりに、コードの重要な部分がカバーされていることを確認することに重点を置きます。
電子商取引サイト用の新しい機能を構築していると想像してください。ショッピング カートだとします。
カートに商品を追加し、合計を計算し、支払いを処理するコードを作成しました。さて、顧客が使い始める前に、これらすべてが機能することを確認したいと考えています。
各部分のテストを作成します。
カートにアイテムを追加 -- アイテムが正しく追加されたかどうかをテストします。
合計の計算 -- 誰かが複数の項目を追加したときに、計算が正しいことを確認します。
支払いの処理 -- 支払いゲートウェイをテストして、取引がスムーズに行われることを確認します。
テストがこれらすべてのシナリオをカバーし、エラーなしで実行される場合は、確実なコード カバレッジが得られます。しかし、支払いプロセスのテストを省略すると (複雑であるか余分に時間がかかるため)、コードの重要な部分がテストされないままになることになります。これは、夜間にドアの鍵を開けたままにするようなものです。
コード カバレッジを常に監視することで、コードの大部分が確実にテストされるようになり、本番環境にバグが侵入する可能性が減ります。重要なのは問題を早期に発見し、後で顧客からの苦情に発展しないようにすることです。
これを想像してみてください。開発チームは同じコード部分を何度も書き直し続けています。進歩に向けて全力疾走する代わりに、彼らはハムスターの回し車の上で立ち往生し、実際には前に進むことなくグルグル回り続けます。これはコードのやり直しが実行中であり、何かが間違っていることを示しています。
理想的には、チームは新しい機能の構築に多くの時間を費やし、すでに行われたことをやり直す時間を減らす必要があります。コードのやり直しが多すぎると、生産性が低下する可能性があります。
実際、研究によると、頻繁なやり直しにより開発者の時間の最大 40% が消費される可能性があり、その時間をイノベーションに費やしたほうがよいと考えられます。
変更失敗率 (CFR) を開発チームの「バグメーター」と考えてください。これは、コードの変更によって機能が損なわれる頻度を測定します。 CFR が高いということは、水漏れのあるボートを所有しているようなものです。スムーズに航海する (クールな新機能を構築する) 代わりに、常に水を汲み続ける (バグを修正する) ことになります。
理想的な世界では、コードベースに加えたすべての変更が完璧に機能します。しかし実際には、物事は壊れます。 Accelerate State of DevOps Report によると、CFR の業界平均は約 16 ～ 30% であり、10 件の変更のうち 1 ～ 3 件で問題が発生する可能性があることを意味します。 CFR がそれを徐々に上回っている場合は、本番環境に移行する前にコードにさらに多くの TLC が必要であることを示しています。
あなたのチームが新機能を公開すると、すぐにユーザーがクラッシュを報告し始めたとします。データを詳しく調査すると、最近の展開の 40% で問題が発生していることがわかりました。ああ！ CFR が高いということは、チームがバグの対処により多くの時間を費やし、イノベーションに費やす時間が減少することを意味します。
目標は？テストとコード レビューを改善して CFR を下げると、次の大きなものの構築により多くの時間を費やし、すでに出荷されたものの修正にかかる時間を短縮できます。
欠陥検出率 (DDR) は、バグ捕捉スコアカードのようなものです。コードが公開される前に捕らえたバグの数と、リリース後にすり抜けたバグの数を示します。 DDR が高いほど、テスト ゲームの品質が向上します。しかし、より多くのバグが忍び寄って運用環境に現れている場合は、テスト ツールを強化する時期が来ています。
良好な DDR は、テスト プロセスがしっかりしていて、通常はリリース前にバグの 85% 以上を捕捉することを目指していることを示します。 DDR が低い場合、多くの危険信号を見逃して、後でユーザーが苦情を言い始めて初めて気づくようなものです。
新しいアプリのアップデートをリリースすると想像してください。テスト中に 8 つのバグを発見しましたが、リリース後、ユーザーからさらに 5 つのバグが報告されました。つまり、DDR は 8/13、つまり約 62% になります。素晴らしいとは言えません。これは、テストでバグの 40% 近くが見逃されたことを意味します。これは、リリース前のチェックを強化する時期が来たことを明確に示しています。
DDR を強化するには、自動テストを改善したり、より徹底的なコード レビューを実施したり、大規模なリリースの前にさらに多くのユーザー受け入れテストを実行したりすることを検討してください。 DDR が優れているほど、ユーザーの満足度は高まり、リリース後の「うーん」という瞬間は少なくなります。
バグ率は、コード内に厄介なバグがどのくらいの頻度で現れるかを測定します。バグ率が高い場合は重大な危険信号となる可能性があり、コードが急いで外に出されているか、まだコツを学んでいる人によって書かれているかのどちらかであることを示しています。業界データによると、経験豊富なチームは通常、コード 1,000 行あたりのバグが 10 個未満であることを目標としています。
あなたのチームが新機能をリリースすると、数時間以内に 15 件のバグが報告されます。この種の現象が定期的に発生する場合は、コード レビューやテストにもっと注意が必要であること、または開発者がコード レビューやテストを正しく行うためにさらに時間がかかる可能性があることを示しています。
MTTR は、システムクラッシュ後にチームがいかに早く立ち直れるかにかかっています。
これは災害復旧用のストップウォッチであり、混乱からどれだけ早く立ち直ることができるかを示します。理想的には、低い MTTR が必要です。数時間ではなく数分を考えてください。
あなたのウェブサイトは午後 2 時にクラッシュし、チームは午後 2 時 15 分までにウェブサイトをオンラインに戻しました。これは 15 分の MTTR です。チームが復旧するまでに通常 1 時間かかる場合は、インシデント対応計画を修正する時期が来ている可能性があります。
ベロシティは、スプリント中にチームがどれだけの作業を完了したかを測定します。これは生産性の指標ですが、異なるチーム間で常に一致するわけではないことを忘れないでください。重要なのは、単に数値を比較することではなく、時間の経過とともに速度がどのように変化するかを追跡することです。
最後のスプリントで、チームは 50 ストーリー ポイントを完了しました。このスプリントでは、彼らは 55 点で終了しました。ベロシティが高いということは、チームの調子が上がっていることを意味している可能性があります。あるいは、チームがより簡単なタスクに取り組んでいることを意味している可能性があります。ここでは一貫性に注意してください。
累積フローは、ワークフロー内でタスクが蓄積されている場所を示します。
これをプロジェクトのトラフィック レポートと考えてください。タスクが 1 つのステージで長時間滞留している場合は、ボトルネックが発生しています。
他のタスクはスムーズに進んでいる一方で、「コードレビュー」では多くのタスクが滞っていることに気づきました。これは、物事を進めていくために、より多くのレビュー担当者またはより適切に定義された基準が必要であることを意味する可能性があります。
デプロイメントの頻度は、チームがコードを実稼働環境にプッシュする頻度を追跡します。デプロイメントの頻度が高いということは、一般的にチームが機敏で適応力があることを意味します。速度のために品質を犠牲にしないように注意してください。
あなたのチームは週に 2 回アップデートを展開しています。それらの更新が確実であればそれは良いことですが、各展開でバグが発生する場合は、元に戻して品質に重点を置く時期が来たかもしれません。
キュー時間は、タスクが「To Do」の山に詰まっている場合など、待機状態にある時間を測定します。キュー時間が長いと、タスクが多すぎるなど、チームメンバーが少なすぎるなど、プロセスの非効率性を示す可能性があります。
タスクが何日も QA の承認を待っている場合、それは QA チームが助けを必要としているか、タスクを進めるための基準を合理化する必要があることを示しています。
スコープ完了率は、チームが実行する予定だった作業が実際にどれだけ完了したかを示します。チームが定期的にタスクを未完了のまま放置している場合、それは彼らが噛みきれないほどのことを噛みしめていることを意味している可能性があります。
귀하의 팀은 이번 스프린트에서 20개의 작업을 완료할 계획이었지만 15개만 완료했습니다. 이와 같이 범위 완료율이 낮다는 것은 팀이 보다 현실적인 목표를 설정하거나 시간을 더 잘 관리해야 함을 의미할 수 있습니다.
추가된 범위는 스프린트가 시작된 후 새 작업이 얼마나 자주 추가되는지 추적합니다. 여기서 높은 비율은 계획이 잘못되었거나, 더 나쁘게는 범위가 확장된다는 신호일 수 있습니다. 즉, 일정이나 리소스를 조정하지 않고 프로젝트 목표가 계속 확장되는 경우입니다.
10개의 작업으로 스프린트를 시작했지만 결국에는 5개를 더 추가했습니다. 이는 범위가 50% 증가한 것이며, 이는 팀이 계획 중에 작업 범위를 충분히 철저하게 지정하지 않고 있음을 의미할 수 있습니다.
리드 타임은 작업이 생성된 시점부터 완료될 때까지의 총 시간을 측정합니다. 아이디어부터 실행까지의 전체 여정과 같습니다. 일반적으로 리드 타임이 짧을수록 팀의 효율성이 높아지는 반면 리드 타임이 길수록 프로세스의 지연이나 병목 현상이 발생할 수 있습니다.
기능 요청이 들어오고 컨셉부터 배포까지 2주가 걸립니다. 비슷한 작업에 일주일이 걸렸다면 이제는 무엇이 속도를 늦추는지 조사할 때입니다. 승인이 지연되거나 팀 간에 핸드오프가 너무 많이 발생했을 수도 있습니다.
또한 읽어 보세요: 변경 리드 타임: DORA 지표 및 소프트웨어 제공에 미치는 영향에 대한 심층 분석
이탈률은 코드가 작성된 직후에 코드가 다시 작성되거나 크게 변경되는 빈도를 추적합니다. 높은 이탈률은 초기 접근 방식이 올바르지 않았거나 요구 사항이 너무 많이 변화하고 있다는 신호일 수 있습니다.
팀에서 기능을 작성했는데 초기 구현이 요구 사항을 충족하지 못했기 때문에 일주일 이내에 기능의 절반을 다시 작성해야 합니다. 이런 일이 계속 발생한다면 계획에 더 많은 시간을 투자해야 하거나 처음부터 요구사항을 더 명확하게 해야 한다는 신호입니다.
어떤 KPI에 주목할 가치가 있는지 궁금하십니까? 팀의 성과와 진행 상황에 대한 전체 그림을 제공하는 항목에 집중하세요. 주의할 점:
코딩 효율성: '이봐, 내가 이걸 썼어!'에서 코드가 얼마나 빠르고 원활하게 흘러가나요? "와, 효과가 있다!"
협업 지표: 잘 연습된 밴드나 싱크로나이즈드 수영 팀처럼 팀이 얼마나 조화롭게 경기를 펼치고 있는지를 나타냅니다.
예측 가능성 측정항목: 프로젝트 결과를 얼마나 정확하게 예측하여 날씨 앱만큼 신뢰할 수 있지만 더 정확한 예측을 할 수 있는지.
신뢰성 측정항목: 코드가 얼마나 견고한지, 그리고 교활한 버그가 눈에 띄기 전에 테스트에서 얼마나 잘 잡아내는지.
이러한 KPI는 예상치 못한 일을 방지하고 프로젝트를 순조롭게 진행하는 데 도움이 됩니다. 성공 툴킷의 필수 요소라고 생각하세요. 보풀 없이 좋은 것만 있으면 됩니다!
결론은 다음과 같습니다. KPI는 단순한 숫자가 아니라 현명한 의사 결정을 위한 비밀 무기입니다. 전문가처럼 엔지니어링 생산성의 우여곡절을 탐색하는 데 도움이 됩니다. 그리고 미들웨어의 DORA 지표를 여기에 추가하면 무적의 팀이 됩니다. 미들웨어는 배포 빈도, 리드 타임, 변경 실패율, 평균 복구 시간과 같은 DORA 측정항목을 쉽게 추적하여 추측을 배제합니다.
KPI를 감시하고 항상 올바른 방향으로 나아갈 수 있도록 도와주는 개인 조수가 있는 것과 같습니다. 미들웨어를 사용하면 단순히 문제에 대응하는 것이 아니라 문제를 예측하고 소프트웨어 개발을 성공으로 이끌 수 있습니다. 오픈소스 저장소를 확인해 보세요!
미들웨어 본사
/
미들웨어
개발자의 잠재력을 발휘하는 오픈 소스 엔지니어링 관리
오픈소스 커뮤니티에 참여하세요
미들웨어는 엔지니어링 리더가 DORA 지표를 사용하여 팀의 효율성을 측정하고 분석할 수 있도록 설계된 오픈 소스 도구입니다. DORA 측정항목은 소프트웨어 제공 성과 및 운영 효율성에 대한 통찰력을 제공하는 4가지 주요 값 집합입니다.
다음과 같습니다.
목차
소프트웨어 개발 KPI(핵심 성과 지표)는 코드 품질, 배포 빈도, 리드 타임 등의 지표를 포함하여 개발 프로세스의 효율성과 효율성을 평가하는 데 사용되는 측정 가능한 값입니다. KPI는 특정 목표에 대한 진행 상황을 평가하고 전반적인 성과를 개선하는 데 도움이 됩니다.
DORA 지표를 포함한 KPI를 추적하려면 프로젝트 관리를 위한 Jira, 코드 통찰력을 위한 GitHub와 함께 포괄적인 성과 추적을 위한 미들웨어를 사용하세요.
以上が5 つの項目で追跡する必要がある上位のソフトウェア開発 KPIの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
