修正されたバグを本番環境にどれくらい早く取り込むことができますか？

Question

私は2つの非常に異なるアプリケーションを使用しています。

アプリ＃1はFTPに直接アクセスできるWebアプリなので、バグの修正は非常に簡単です。 Cat Aのバグは通常、翌日以内に修正されます。ここでは問題ありません。

アプリ＃2は石油ビジネスドキュメント管理アプリです。エンドユーザーテストとシステムテストという2つの受け入れテストフェーズを経る必要があります。このフェーズ後に発見されたバグは、次のバージョン（通常2〜3か月）まで保持されます。すべての新しいリリースパッケージには莫大な費用がかかります。エンドユーザーに、次のバージョンまでバグのいくつかに対応しなければならないことを説明するのは非常に困難です。

すぐに修正できない重大なバグにどのように関係しますか？

Answer 1

あなたの記述された状況における私の個人的な意見では、非常に深い構造上の問題であり、プロジェクトが始まる前に対処すべきでした。すべてのプログラマーは、必要に応じて変更を直接プッシュする少なくとも1人の人物を知っている必要があり、その手順は明確でなければなりません。正直なところ、データ損失の可能性があるセキュリティまたはデータベースの問題はどうですか？もちろん、それを直せないのであれば、スタッフに直接連絡して、「これをしないでください」と伝えてください。しかし、正直なところ、この問題をできるだけ早く世に出すことが最善の方法です。私は、ボタンが2回押された後にプログラムが動作を終了するだけのターミナルアプリケーションでも同様のケースがありました。修正は些細なことでしたが、誰も修正することを許可されず、このことを実行するためにすべての人が文字通り何時間も費やしました。重要な変更のショートカットを要求してください！

Answer 2

バグをすばやく修正するほど、修正する必要があるバグが多くなります。

Answer 3

管理でバグを修正できる速度は、バグが修正されるまで持続するコスト管理に直接関係します。

私は1人のチームです。私とバグの間に何も立っていません：）

Answer 4

実際には、組織の規模、システムの規模、システムの重要性、およびバグの影響例：

One Man ShopまたはLow Impact System （最も速い-上記のアプリ＃1）

バグを修正する時間= バグを見つける時間 + コードを修正する時間 + 本番環境にデプロイする時間

大規模な組織または重要なシステム（最長-上記のApp＃2）

バグを修正する時間= バグを見つける時間 + ドキュメント＆amp;バグに優先順位を付ける + 費用を見積もる + 修正作業を承認する + 修正を設計する + ドキュメントの修正 + コード修正までの時間 + ドキュメントのテスト計画の時間+ テストの修正の時間+ リグレッションの時間テスト + パフォーマンス/負荷テストまでの時間 + スケジュール＆amp;展開を承認 + 修正を展開する時間

編集：いくつマイクロソフトの従業員は電球を変更するのに必要ですか？はこのトピックに関する興味深い読み物です。

1 ： http://blogs.msdn.com/ericlippert/archive/2003/10/ 28 / 53298.aspx

Answer 5

答えは、生産環境へのアクセス量と、命にかかわるお金の量との関係です。

Answer 6

回避策。

以前は、バグにより機能が停止しているとユーザーが判断し、バグが修正されるまで待機し、そのセクションのダウンタイム中に情報を入力しているとユーザーに伝えた経験があります。古いExcelバージョンのアプリケーション（ExcelからのOracle APEXの移行）を実行し、Excelアプリケーションからデータを再び動的に挿入するための所要時間を尋ねました。そのための所要時間は、元のバグのダウンタイムよりも長くなりました。