メンテナンスに費やされた時間の業界平均

最近、マネージャーがバグの修正に非常に多くの時間を費やしていると発表しました。彼は私たちが常に完璧なコードを書くべきだと思っていると思います（もちろん、まだ不可能な締め切りに間に合います！）そして、新しいコードを書くのにバグ修正に費やす時間の業界平均は何だろうと思いました。

だから、新しいコード開発に対するバグ修正に時間を費やした指標はありますか？または、業界全体のバグ修正時間の実証分析はありますか？50％がバグの修正に費やしすぎていますか？20％または33％はどうですか？

個人的な経験からの逸話的な証拠を受け入れることはうれしいです。それは、ここでパフォーマンスを比較できる統計の一部を形成するからです。

最近、マネージャーがバグの修正に非常に多くの時間を費やしていると発表しました。

上記は非常に無知です。そのような場合の推奨読書：Robert L. Glassによるソフトウェアエンジニアリングの事実と誤,、特に「事実43.メンテナンスは解決策であり、問​​題ではない」。

ウィキペディアの記事では、ソフトウェアのメンテナンスに費やされた80％の努力に言及しています。

私のマネージャーは、ディルバートのPHBを天才のように見せます:)

上で与えられたHmはまた、あなたが行うすべてのリクエストが実際にバグであるかどうかを分析するためにいくらか努力します。

私の経験では、機能拡張や新機能のリクエストがバグとして提出されることはあまりにも頻繁でした。優れたマネージャーはプログラマーにそのことを知ってもらいます-悪いマネージャーは、バグを修正するのに時間がかかりすぎると不平を言い続けます。

最初に尋ねる質問は、「バグ修正」が実際にコーディングのバグなどを修正しているかどうかです。実際のコードバグの修正は、適切なコードベースがある限り、ほとんどの場合比較的小さいはずです。貧弱なコードベースで作業している場合、大規模なバグ修正は避けられません。

ただし、プログラムを実稼働に移行する過程で、文書化されていない要件、予期しないユーザーアクティビティ、データの異常、ハードウェアの非互換性、インストールの問題、厳密にはコードのバグではないその他の問題が見つかります。多くの場合、管理者とユーザーはこれらの生産サポート/メンテナンスの問題をバグと見なします。これは通常、コードの変更が必要だからです。

また、マイナーな拡張要求と呼ばれるべきものをバグとしてグループ化するマネージャーに会いました。多くの場合、これらはバグ追跡または問題報告システムに入力され、これにより「バグ」の統計が実際よりも高くなる可能性があります。

コードの量、コードの長さなどに依存します。

ソフトウェアのバグの修正に費やす時間は、リリースの最初の6〜12か月までフロントロードする必要がありますが、時間が無限に近づくにつれて、メンテナンスに費やす時間と初期開発に費やす時間は100％を超えます。作業。

厳密な統計情報はありませんが（Code Completeにはありますが、どのページ/セクションを正確に伝えることはできません）、私の経験では、開発の約40％（場合によっては60％も）がメンテナンスに費やされています。リリースするコードが多いほど、メンテナンス時間が長くなることは明らかです。バグは常に機能するとは限らず、プログラムの欠陥であるのと同じくらい不確実性の結果です。

優れたチケットトラッカー（AtlasianのJiraなど）を使用し、さまざまなカテゴリ、ユーザーストーリー、緊急度レベルを正しく入力し、チームメンバーの同意を得て、実際にこれらのメトリック（およびその他）を計算した場合驚くほど簡単です。

前のプロジェクトでは、Jiraを使用してバグ/タスク/ todoリストを管理しましたが、最終的に、遅延と問題の最大の原因は非効率的な管理手法であることが判明しました。

奇妙なことに、その情報が出てきたとき、私たちは突然Jiraを使用しなくなり、新しい製品を導入してそれを置き換えると突然言いました。

それまでの間、Jiraを通過するデータのリクエストはすべて管理チームに送信する必要があり、直接アクセスは削除されました。

気づかなかったのは、統計計算の一環として、開発チームがJiraからWebフックにデータを突っ込んでおり、このWebフックを使用して、内部サーバーのエンドポイントにデータを渡し、コードを作成したことですこれらのレポートは自動的に。

Webフックの監視を開始したところ、Jiraが使用されなくなったと言われたにもかかわらず、かなり長い時間（正確には6か月以上）ずっと生き続けており、経営陣による大規模な乱用は間違った使い方でただ横暴に。

もちろん、Jiraほど複雑なものである必要はありません。

低利回りソリューションが必要な場合は、google-docsスプレッドシートとGDocs通知APIを使用して、タスク/チケット/バグ/機能リクエストなどを追跡できます。

GDocs自体がWebフックやあらゆる種類のものを発行できるようになりました。

それをGitやGithub、あるいはコードがリポジトリにコミットされたときにトリガーするいくつかのフックと組み合わせると、驚くほどの量のデータを記録できるかなり効率的な自家醸造システムが手に入ります。

ただし、一般に、製品の自然寿命​​の100％のうち、greenfield devとメンテナンスの分割は通常20/80であり、ALM（アプリケーションライフタイム管理）サイクルのコストのほとんどはメンテナンスとサポートコストに費やされます。

バグのないコードを書くことは単純に不可能なので、バグの修正に時間をかけすぎるようなことはありません。

優れたテストと継続的な統合ポリシーは欠陥を減らしますが、完全に根絶することは決してありません。

そうでないと信じる人（IMHO）は、正確な判断を下すのに十分な知識を持っていないか、ソフトウェアを書くことが実際にどれほど難しいかについて盲目です（より一般的な場合）。

あなたのマネージャーがそれに賛成していて、そのうちのいくつかがそうであるなら、あなたは彼があなたが何をしてどのようにそれをするかを正確に見ることができるように彼が1日あなたを隠すことを提案したいかもしれません。

Iv'eは、この種の仕事が積極的に奨励されているいくつかの企業で働いていました。上位レベルのスタッフが下位レベルのスタッフを隠しており、その逆も、関係者にとって本当に素晴らしい学習体験になります。