この質問には実際に2つの質問が含まれており、個別に対処する必要があります。
一部のチームには厳格な開発プロセスがあるのはなぜですか？
簡単な答えは、そうしないと間違いが起こるからです。費用のかかる間違い。これは開発にも当てはまり、残りのIT分野（sysadmin、DBAなど）にも当てはまります。
多くの開発者やITワーカーにとって、これは理解するのが非常に困難です。なぜなら、私たちのほとんどは「極限」の1つでしか働いたことがないからです。小型のマイクロISVやフリーランスの仕事でさえ、人々がひどくめちゃくちゃにならない場合や、めちゃくちゃのコストが低い場合です。
しかし、これらの段階の間にある会社を見たことがあれば（優秀で才能のあるITスタッフがいる会社でさえ）、プロセスを持たない、または半ばプロセスを行うことの危険性を理解できます。スタッフ間のコミュニケーションは、組み合わせ爆発の問題に悩まされています。単一のチームで約6〜10人の開発者のレベルに達すると、重大または重大な欠陥の主な原因は、才能やノウハウの不足ではなく、コミュニケーションの不足です。
アリスは月曜日の朝に尋ねて、誰もその部分に取り組んでいないので、トランクで再建手術をしても大丈夫だと判断します。ボブは1時間後、休暇から元気に戻って到着し、まったく同じエリアに新しい主要な機能を実装することを決定しました。そこでアリスはその「技術的負債」を返済し、ボブは6か月間バックバーナーにあった彼のキラー機能を実装し、最終的に両方がコードをチェックインすると（もちろん金曜日の締め切り直前に！）、全体がチームは遅れをとり続け、数週間の間バグやリグレッションとして存続し続ける悪夢のような紛争を乗り越えなければなりません。
アリスとボブは両方ともコーディングタスクで素晴らしい仕事をしましたが、どちらも悪い決断から始まりました（「起こりうる最悪の事態は何ですか？」）。チームリーダーまたはプロジェクトマネージャーは、それらを事後分析し、これが再び発生しないようにチェックリストを作成します。
- 衝突の影響を最小限に抑えるため、チェックインは毎日行う必要があります。
- ブランチでは1日以上かかる変更を行う必要があります。
- すべての重要なタスク（リファクタリングなどの機能以外の作業を含む）は、バグトラッカーで適切に追跡して割り当てる必要があります。
多くの人にとって、この「プロセス」は常識のように思えます。古い帽子です。しかし、多くの小規模なチームがこれを行わないことを知っていましたか？2人のチームは、ソース管理をまったく気にしません。誰も気にしない？正直なところ必要ありません。問題はチームが成長したときにのみ発生し始めますが、プロセスはそうではありません。
もちろん、プロセスの最適化はパフォーマンスの最適化に似ています。逆指数曲線に従います。上記のチェックリストは欠陥の80％を除去するかもしれませんが、それを実装した後、他の何かが欠陥の残りの 80％を占めることがわかります。架空の例ですが、ビルド環境が異なるためにビルドエラーが発生する可能性があります。これは、標準ハードウェアがなく、開発者が2週間ごとに更新されるオープンソースライブラリを使用しているためです。
したがって、次の3つの選択肢があります。（a）ハードウェアを標準化して、コストが高く生産性を大幅に低下させる可能性があるサードパーティライブラリの使用を厳しく制限するか、（b）ビルドサーバーをセットアップし、sysadminグループとフルタイムの開発者がそれを維持するか、（c）標準の仮想マシンを配布し、開発者にその上に構築するように指示することにより、開発者自身でこれを行うことができます。明らかに、（b）は最良の長期ソリューションですが、（c）信頼性と利便性の短期バランスが優れています。
サイクルは延々と続きます。表示されるすべての「ポリシー」は、通常、実際の問題を解決するために制定されています。ジョエル・スポルスキーが2000年にずっと書いたように（まったく別のトピックを念頭に置いていますが、それでも関連性があります）：
レストランに行くと、「No Dogs Allowed」というサインが表示されている場合、そのサインは純粋に説明的なものだと思うかもしれません。
それが進行中のすべてである場合、「ヘビなし」の標識もあります。結局のところ、誰もヘビが好きではありません。そして、彼らが座るときに椅子を割るので、「象なし」のサイン。
本当の兆候があることがその理由は歴史ある：それは、人々がレストランに彼らの犬を持参しようとする使用ことを示している歴史的なマーカーです。
ほとんど（すべてとは言いません）のソフトウェアチームでも同じです。「バグ修正ごとにテストケースを追加する必要があります」などのポリシーは、ほぼ常に、チームが過去に回帰の問題を抱えていることを示します。 回帰は、これらの問題の別の1つであり、ほとんどの場合、無能ではなくコミュニケーションの崩壊によるものです。ポリシーを理解している限り、正当なショートカットを使用できる場合があります（たとえば、6つの小さなバグを修正する必要がありましたが、それらはすべて同じ機能であったため、実際には9つすべてに対して1つのテストケースを書くことができます）。
これがプロセスが存在する理由を説明していますが、それがすべてではありません。残りの半分は：
プロセスを追跡するのが難しいのはなぜですか？
これは実際には答えるのがより簡単な質問です：チーム（またはその管理者）は繰り返し可能な結果に焦点を合わせ、欠陥を最小限に抑えます（上記のとおり）が、そのプロセスの最適化と自動化に十分な注意を払っていないためです。
たとえば、元の質問には、いくつかの問題があります。
リビジョン管理システム（CVS）は、今日の標準ではレガシーです。ための新しいプロジェクト、それはすぐにそのようなMercurialの水銀（Hg）のような分散システムによってケラレつつある自体のSubversion（SVN）によってほぼ完全に置き換えられました。Hgに切り替えると、分岐とマージがはるかに簡単になり、上記の仮想的な例でさえ、毎日のコミット要件が非常に簡単になります。リポジトリはローカルであるため、コードをコンパイルする必要さえありません。-実際、怠lazな開発者は、必要に応じてこのステップを自動化することもできます。ログオフスクリプトを設定して、変更をローカルリポジトリに自動的にコミットします。
仮想マシンプロセスの自動化に費やした時間はありません。ソース/ライブラリの取得、構成、および仮想マシンへのダウンロードのプロセス全体を100％自動化できます。ローカルマシンのバグ修正作業中にどこかで中央サーバーで実行する無人プロセスである可能性があります（クリーンビルドを保証するためにのみVMを使用します）。
一方、特定の規模では、開発者ごとのVMソリューションは愚かになり始め、継続的インテグレーションサーバーが必要になります。これは、個々の開発者がビルドをまったく心配する必要がないため、実際の生産性のメリットが得られる場所です。ビルドサーバーは常にクリーンであるため、クリーンな仮想マシンのセットアップについて心配する必要はありません。
質問の文言（「すべてのステップを含むテストケース」）は、いくつかの手動テストが行われていることを意味します。繰り返しますが、これは作業負荷が比較的小さい小規模なチームには有効かもしれませんが、大規模ではまったく意味がありません。回帰テストは自動化することができ、自動化する必要があります。「ステップ」はなく、クラス/メソッドがユニット/統合テストスイートに追加されます。
言うまでもなく、Bugzillaから新しい（より優れた）バグ追跡システムに移行すると、その部分の経験がはるかに簡単になります。
これらの問題を解決していないからといって、企業は必ずしも安くも愚かでもない。彼らが知っているのは、現在のプロセスが機能していることだけであり、場合によってはリスク回避的であり、それについて何も変更することに消極的です。しかし、本当に彼らはただ利益を確信する必要があります。
開発者がすべての非コーディングタスクの時間を追跡するのに1週間を費やした場合、簡単に足し合わせて、管理者に（たとえば）資本金がゼロで、100時間の投資でMercurialにアップグレードできることを示すことができますマージの競合を解決するために週に最大10人時間を削減すれば、それは10週間の見返りであり、ほぼ確実にそれに同意します。ビルドサーバー（CI）またはより優れたバグ追跡と同じアイデア。
要約すると、チームは、これらのことをまだ行っていません。なぜなら、今日行うのに十分重要であると経営者に確信していないからです。だからイニシアチブを取り、それを費用便益の方程式に変えてください。最小限のリスクで簡素化/自動化できるタスクに費やされる時間を調べ、新しいツールまたはテクニックの損益分岐点と最終的なペイオフを計算します。彼らがまだ聞いていない場合は、残りのオプションが何であるかを既に知っています。
開発者がすべての非コーディングタスクに時間を追跡するのに1週間を費やした場合、簡単にそれを追加し、管理を表示して...費用対効果の方程式などに変換できます...
上記の部分はさらに拡大する価値があります。
動作することを確認できます。プログラマーは、私が取り組んでいるプロジェクトの1つでそれを数回使用し、そのたびに必要な変更が行われました。
私の全体的な印象は、正しく行われた場合、このトリックはかなりの量の管理の無知と慣性を覆すことができるということでした。
私たち（開発者）がこの種のDIYアプローチに頼らざるを得なかった会社は、ITに関しては非常に未熟でした。よりベテランのソフトウェアベンダーでは、そのようなことは主にマネージャー自身によって行われています。そして、原則として、彼らは私たちのプログラマーよりも生産的でした。はるかに生産的。