変更ごとのバージョン管理とバグ追跡のオーバーヘッドが多すぎますか？
私はCVSクレイジーでBugzillaナッツのような場所で働いています。
各リリースには非常に多くのブランチがあるため、それらを数えることはできません。誰もが常に自動マージしています。
このジョブにはfluidityはありません。すべてがlock-stepと感じています。簡単なことでも25ステップかかります。それは工場の生産ラインにいるようなものではなく、毎日自分で工場を立ち上げるようなものです。
状況例：
単一のバグを修正するには、まず、クリーンで新しい仮想マシンを入手します。次に、Bugzillaレポートに記載されている別のブランチに基づいて、その単一のバグ修正用のブランチを作成します。ブランチをマシンにインストールし、セットアップします。バグを修正しました。私はそれをチェックインし、他の人がテストするためにマシンとマシンを残します。次に、バグ管理ソフトウェアにアクセスして、すべての手順を含めて、私が行ったことを説明し、テストケースを作成する必要があります。最終的には誰かがリリースとマージします。
どんなに小さなバグでも、私はこれらすべてのことをしなければなりません。時々人々は複数のバグの作業を組み合わせますが、私が言ったように、これはほとんど不可能ですので、これはほとんど不可能です。
他の仕事では、私は入ってバグを修正します。私がSCMを使用したことはほとんど覚えていませんが、これまでに使用したすべてのジョブはSCMを使用しました。それは、他のすべてのジョブでは、どういうわけかそれを邪魔にしないためです。
プロセスが邪魔になり、それ自体が終了するポイントはありますか？それはエンジニアリングですか？
プロセスが邪魔になり、それ自体が終わりになるポイントはありますか？
残念ながら、重いプロセスが一般的です。一部の人々-特に管理-プロセスが製品を生産することを宗教的に想像します。そのため、彼らはプロセスをやりすぎて、実際に実際に製品を作成する一握りの勤勉で賢い人であることを忘れます。上級管理職にとって、彼らのビジネスが数人のオタクの手にあると考えることすら恐ろしいので、現実から目を閉じて、代わりに彼らに制御の幻想を与える彼らの親しい「プロセス」を考えてください。
これが、少数の優れたエンジニアを抱えるアジャイルな新興企業が、確立された大企業を打ち負かすことができる理由です。かつて小規模な新興企業が競合他社を打ち負かしたり、完全に新しい市場を作成したりした例：
- アップル（アップルIは1エンジニアによって作成されました。当時、会社には3人の男性がいました）。
- Google（元々2プログラマーによって作成されました）。
- Facebook（1-当初は人の努力）。
- Microsoft（2-1975年の男性企業）。
これらは外れ値であり、極端な例外であり、深刻なことを行うには、大規模で確立された企業であることが容易に言えるでしょう。しかし、リストは続きます。そして。恥ずかしいほど長いです。今日のほとんどすべての主要な企業はガレージショップとしてスタートしましたが、それは異常なことをしました。変なもの。 彼らはそれを間違っていました。彼らはプロセスに従ってそれをしていたと思いますか？
企業は通常、私がコントロール柔軟性のジレンマと呼んでいるものに苦しんでいます。ルール、構造、官僚的なオーバーヘッドが少ないほど、物事を達成するのがより簡単で速くなります（それはまたより楽しいです）。ただし、「悪い」ことを「良い」ことと同じくらい簡単に行うことができます。つまり、重大ではない間違いをほとんどしない熟練した従業員がいる場合にのみ、問題はありません。
一方、低から半熟練の従業員が多い場合や、間違いを犯すコストが高すぎる場合（北半球でのスペースシャトルの破片のリスクなど）、企業はますます「ルール」を積み重ねる傾向があります。 "および"プロセス "を試して最小化します。
唯一の問題は、これらのプロセスの累積的なオーバーヘッドにより、才能のある従業員が会社を辞めるような結果を達成することが困難になることです。その結果、平均的なスキルがさらに低下し、さらに多くのプロセスと官僚が必要になります。つまり、急進的な事態が発生するか、会社が立ち直るまで、死のスパイラルは続きます。
この側面でノーリターンのポイントを過ぎてしまったように見える会社にいる場合は、自分の仕事を「気にしない」ように解決するか（ほとんどの人がこれまで行ってきたことが行われています）、地獄から抜け出すことができます。あなたの魂をそのままにして:)
会社があまり進んでおらず、あなたが完全な決意と意志力によってコースを逆転させることを試みることができる手段を持っている場合。ただし、成功を保証することなく多大な労力と個人的なエネルギーを消費する可能性があるので、価値があることを十分に確認してください。時々、自分の損失を減らして、自分の経験をより豊かに数える方が良い場合があります。
このような開発スタイルの正当な理由は1つだけです。開発されたソフトウェアは完全にミッションクリティカルであり、いかなる状況下でもバグを含んではいけません。旅客機のジェットエンジン燃料噴射ファームウェア、または心臓ペースメーカーファームウェア、または核ミサイル発射システムを考えてみてください。
他のすべての状況では、コストのオーバーヘッドはビジネスを殺します。次に進む時間です。
この質問には実際には2つの質問が含まれており、個別に対処する必要があります。
一部のチームに厳密な開発プロセスがあるのはなぜですか？
簡単な答えは、そうしないと間違いが起きるからです。コストのかかる間違い。これは開発にも当てはまり、残りのIT分野（システム管理者、DBAなど）にも当てはまります。
多くの開発者とITワーカーが理解するのは非常に困難です。なぜなら、私たちのほとんどは、「極端」の1つでしか働いたことがないためです。小さなマイクロISVやフリーランスの仕事でさえ、人々がひどく台無しにしないか、台無しのコストが低いのです。
しかし、これらのフェーズの間に会社を見たことがあれば、ITスタッフが優秀で才能のある会社であっても、プロセスがない、または中途半端なプロセスの危険性を理解できます。ご覧のとおり、スタッフ間のコミュニケーションは 組み合わせ爆発 問題に苦しんでいます。 1つのチームで約6〜10人の開発者のレベルに到達すると、主要または重大な欠陥の主な原因は、才能やノウハウの不足ではなく、コミュニケーションの不足です。
アリスは月曜日の朝に周りに尋ねて、だれもその部分に取り組んでいないので、体幹で再建手術をすることは大丈夫だと決定します。ボブは休暇から元気いっぱいに戻って1時間後に到着し、まったく同じ領域に新しい主要機能を実装することにしました。とにかく誰もそのコードに触れないので、なぜブランチに悩むのでしょうか。それで、アリスはその「技術的負債」を完済し、ボブは6か月間バックバーナーにされていた彼のキラー機能を実装します。チームは遅れを取り、悪夢のような紛争の地獄を乗り越え、次の数週間はバグやリグレッションとして生き続ける必要があります。
アリスとボブの両方がコーディング作業で素晴らしい仕事をしましたが、どちらも悪い決断で始まりました（「起こり得る最悪のことは何ですか？」）。チームリーダーまたはプロジェクトマネージャーがそれらを事後分析し、チェックリストを作成してこれが再発しないようにします。
- 衝突の影響を最小限に抑えるため、チェックインは毎日行う必要があります。
- 1日を大幅に超える変更は、ブランチで行う必要があります。
- すべての重要なタスク（リファクタリングなどの非機能的な作業を含む）は、適切に追跡し、バグトラッカーに割り当てる必要があります。
多くの人にとって、この「プロセス」は常識のように思えます。古い帽子です。しかし、小さなチームの多くがこれを行わないことをご存知ですか？ 2人のチームは、ソース管理にさえ気を使わないかもしれません。誰も気にしない？正直言って必要はありません。問題が発生するのはチームが成長したときだけですが、プロセスは成長しません。
もちろん、プロセスの最適化はパフォーマンスの最適化に似ています。それは逆指数曲線に従います。上記のチェックリストは欠陥の80％を排除する可能性がありますが、それを実装した後、他の何かが残りの欠陥の80％を占めていることがわかります。架空の、しかしおなじみの例では、ビルド環境が異なるためにビルドエラーが発生する可能性があります。これは、標準のハードウェアがなく、開発者が2週間ごとに更新されるオープンソースライブラリを使用しているためです。
したがって、3つの選択肢があります。（a）ハードウェアを標準化し、サードパーティライブラリの使用を厳しく制限するため、コストがかかり、生産性が大幅に低下する可能性があります。または、（b）ビルドサーバーをセットアップし、sysadminグループとフルタイムの開発者がそれを保守するか、または（c）開発者が標準の仮想マシンを配布して、それを基に構築するように開発者に指示することにより、これを自分で行うことができます。明らかに（b）は最良の長期的な解決策ですが、（c）は信頼性と利便性の短期バランスが優れています。
サイクルが繰り返されます。あなたが見るすべての「方針」は、一般に、実際の問題を解決するために制定されています。 Joel Spolskyが2000年までずっと書いているように （完全に異なるトピックについては気にしますが、それでも関連性があります）：
レストランに行って「犬は許可されていません」という標識が表示されている場合、その標識はあくまでも悪質だと思われるかもしれません。
それがallで起こっていた場合は、「No Snakes」の記号も表示されます。結局のところ、蛇は誰も好きではありません。そして、彼らが座ったときに椅子を壊すので、「象なし」の標識。
記号がある本当の理由は歴史的です。これは、人々が自分の犬をレストランに連れて行こうとしたことがあったことを示す歴史的マーカーです。
ほとんどの（すべてを言うわけではありませんが）ソフトウェアチームでも同じです：などのポリシー「すべてのバグ修正に対してテストケースを追加する必要があります」ほぼ常にチームは歴史的に回帰に関する問題を抱えていました。回帰は、ほとんどの場合、能力不足というよりはコミュニケーションの故障が原因である問題の1つです。ポリシーを理解している限り、正当なショートカットを使用できる場合があります（たとえば、6つの小さなバグを修正する必要がありましたが、それらはすべて同じ機能に含まれていたため、実際には9つのバグすべてに対して1つのテストケースを作成できます）。
それがプロセスが存在する理由を説明していますが、それだけではありません。残りの半分は：
プロセスが従うのが難しいのはなぜですか？
これは実際には答えるのが最も簡単な質問です。これは、チーム（またはその管理）が繰り返し可能な結果と欠陥の最小化に焦点を当てているためです（上記のように）しかし、そのプロセスのoptimizationとautomationに十分な注意を払っていません。
たとえば、元の質問では、いくつかの問題が見られます。
リビジョン管理システム（CVS）は、今日の標準ではレガシーです。 newプロジェクトの場合、それはSubversion（SVN）によってほとんど完全に置き換えられました。Subversion（SVN）自体は、Mercurial（Hg）などの分散システムによって急速に衰退しています。 Hgに切り替えると、分岐とマージfarが簡単になり、上記の私の架空の例でさえ、毎日のコミット要件ははるかに簡単になります。リポジトリはローカルなので、コードをコンパイルする必要さえありません。 -実際、怠惰な開発者は、必要に応じてこの手順を自動化し、ログオフスクリプトを設定して、ローカルリポジトリへの変更を自動的にコミットすることもできます。
仮想マシンプロセスの自動化に費やされた時間はありません。ソース/ライブラリを取得、構成、および仮想マシンにダウンロードするプロセス全体を100％自動化できます。ローカルマシンのバグ修正に取り組んでいる間に中央サーバーで実行する無人プロセスである可能性があります（VMのみを使用してクリーンビルドを保証します）。
一方、一定の規模では、開発者ごとのVMのソリューションはばかげてきて、継続的インテグレーションサーバーが必要です。これにより、個々の開発者がビルドについて心配する必要がほとんどなくなります。ビルドサーバーは常にクリーンであるため、クリーンな仮想マシンの設定について心配する必要はありません。
質問の文言（「すべてのステップのテストケース」）は、いくつかの手動テストが行われていることを意味します。繰り返しになりますが、これは比較的低い作業負荷の小さなチームでは機能するかもしれませんが、大規模ではまったく意味がありません。回帰テストは自動化することができ、自動化する必要があります。 「ステップ」はなく、ユニットまたは統合テストスイートに追加されたクラスまたはメソッドのみです。
言うまでもなく、Bugzillaから新しい（より良い）バグ追跡システムに移行すれば、エクスペリエンスのその部分の苦痛ははるかに少なくなります。
これらの問題を解決していないからといって、企業は必ずしも安いや愚かなとは限りません。彼らが知っているのは、現在のプロセスが機能することであり、場合によってはリスクを嫌い、それについての変更に消極的です。しかし、実際には、メリットを確信する必要があるだけです。
開発者がすべての非コーディングタスクに時間を追跡するのに1週間費やした場合、簡単にそれを追加して、（たとえば）Mercurialへのアップグレードに資本がなく、100人時間の投資をすると、経営陣に示すことができます。マージの競合を解決するために週あたり最大10人時を排除すると、10週間の見返りが得られ、ほぼ確実に同意します。ビルドサーバー（CI）またはより優れたバグ追跡についても同様です。
要約すると：誰も経営陣に今日行うことが十分に重要であると確信していないため、チームはまだこれらのことを行っていません。したがって、イニシアチブを取り、それを費用便益の方程式に変えます。最小限のリスクで簡略化/自動化できるタスクに費やされた時間を調べ、新しいツールまたは手法の損益分岐点と最終的な見返りを計算します。それらがstill聞かない場合、あなたはすでにあなたの残りのオプションが何であるかを知っています。
開発者が1週間かけてすべての非コーディングタスクに時間を費やした場合、簡単に合計して管理を表示し、それを費用便益の方程式などに変えることができます。
上記の部分はさらに拡張する価値があります。
動いていることが確認できました。プログラマーは、私が取り組んだプロジェクトの1つで数回、それが望ましい変更につながるたびに使用しました。
私の全体的な印象は、正しく行われた場合、このトリックはoverrule管理の無知と慣性をかなり大量に消費する可能性があるということでした。
私たち（開発者）がこの種の手段に頼らなければならなかった会社 [〜＃〜] diy [〜＃〜] のアプローチは、ITに関しては非常に未熟でした。より熟練したソフトウェアベンダーでは、そのようなことが主にマネージャー自身によって行われているのを見ました。そして原則として、彼らは私たちのプログラマよりも生産性が高かった。はるかに生産的です。
規制の厳しい業界で作業している場合、その厄介なプロセスにはいくつかの理由がある可能性があります。ある日監査を受けることができ、誰がそのバグを修正したか、どのようにレビューしたか、誰がテストしたかを説明するためにすべての記録を表示する必要があります。それなど.
だからそれは必要な悪かもしれない。
一方、そのプロセスに正当な理由がない場合は、おそらく経営陣からの信頼の欠如以外に、上司に相談して、会社の時間（つまりお金）を節約する方法を彼に伝えてください。
それが正しく説明されていれば、より速くより良いプロセスを拒否する正しい心の誰もいない。
しかし、変更を正当化するためにあなたの議論を守る準備ができています。
問題の半分は、古くなったツールをプロセスで使用していることです。あなたが説明することは、バグごとにブランチを作成するという面倒な作業なしに、最新のDVCSで非常に簡単に行うことができます。
別の問題は、あなたが楽しんでいる仕事のラインに明らかにいないことです。あなたは開発をしたい一方で、メンテナンスで働いています。仕事を変える以外にできることはほとんどありません。
ソフトウェアエンジニアリングの分野は本質的に "プロセスのすべて"なので、そのように "なっている"かどうか疑問に思うのは、要点を逃しているようなものです。
ほとんどのプログラマーは、プロセスの絶対的な最小値に煩わされることになりますが、組織が直面している問題を解決しない場合でも、アジャイルな方法論を提唱する人がいる限り、それは完全に可能 for 「顧客が要求する」など、健全なビジネス上の理由のために「重い」プロセスを使用することを決定する会社。これは、顧客がフォーチュン500企業、大学、または政府機関の場合に一般的です。これらの顧客への販売の報酬は、追加のプロセスのオーバーヘッドを正当化するほど十分に大きい場合があります。
あなたの会社は1つのデータポイントであり、より重いプロセスに向かう、またはそれから遠ざかる業界全体の傾向に経験を一般化することは不可能です。本当の問題は、あなたの会社、あなたの製品、あなたの顧客、そしてあなた自身、プログラマーとして個人的にどのバランスが最も効果的かということです。その会社で働きたくない場合は、変化を促すか、別の仕事を取得してください。
他の質問から 今日あなたから見てきたように、あなたはあなたの仕事にかなり不満そうです。あなたは長い間そこにいませんでした、あなたはあなたがあなたが過ちを犯したと思っていることを上司に伝えることができます、そしてそれはあなたが予想よりも早く離れる時です。
仕事に長けていれば、新しい仕事を見つけるのにそれほど苦労することはありません。正直なところ、このプロセスが存在する正当な理由がないのであれば、私も移動を検討するでしょう。まったくCVSを使用することは本当に私にとって大きな決断ですが、私はインタビューでソース管理の質問を常にします。明らかに、私はあなたの状況を知ることができません、そして、あなたが他の義務があるならば、仕事を辞めることは不可能かもしれません。
私はソフトウェアエンジニアリングが非常に悪いプログラマーであふれている方法について噴出するつもりでしたが、あなたが説明する状況はひどいです。
私の個人的な経験では、あなたが説明するこの「プロセス」の一部は、プログラマーに課しているシステムの非効率性を完全に認識していない管理とシステム管理を伴います。例としては、オペレーティングシステムの選択の制限、使用するソフトウェアの制限、インターネットアクセス、個人用デスクトップの管理特権などがあります。これらすべては必須優れた開発に不可欠です。
さらに、企業のさまざまな支店で採用されている「マジックソリューション」間の互換性要件。例には、一元化されたソース管理を課す本社、オフサイトのOutlookサーバー、およびすべての問題に適していない可能性があるコーディングのガイドラインまたは言語が含まれます。
エンタープライズジャガーノートのホイールを動かし続けるのはそれほど楽しいことではありませんが、一部の企業ではイノベーション、創造性、および輝きの小さな泡が存在していることがわかりました。
あなたはおそらくプロセス指向会社で働いています。代わりにresult oriented会社を見つけようとしますが、それはあなたがどのようにそれを行うかではなく、何をするかが重要です。
私の会社にも「プロセス」があります（しかし、それは非常に簡単です）。しかし、それが邪魔になると、ルールを破ってステップをスキップします。結果を得るためにショートカットを使って何も壊さない限り、誰も私に何も言わないでしょう。
トム・デマルコ：
...私の 初期メトリックブック ...最も引用されている行は最初の文です： "測定できないものを制御することはできません。"この行には本当の真実が含まれていますが、使用することにますます不快になっています。引用（および実際には本のタイトル）に暗黙的に示されているのは、制御はソフトウェアプロジェクトの重要な側面であり、おそらく最も重要な側面です。しかし、そうではありません。
...制御に集中するほど、比較的小さな価値のあるものを提供しようとするプロジェクトに取り組む可能性が高くなります。
私の考えでは、ソフトウェアプロジェクトを制御する方法よりもはるかに重要な問題は、このような限界的な価値をもたらす多くのプロジェクトをなぜ地球上で行っているのかということです...
プロセスが邪魔になり、それ自体が終わりになるポイントはありますか？それはエンジニアリングですか？
文字通り、ほとんどのengineeringは、特定の問題に対応するために、確立された部分を一定の順序でまとめています。これは、MEに1日中何をしているのかを尋ねると最も明白です。エンジニアリングとアーキテクチャまたは（あらゆる分野の）初期段階の製品開発を混同している。私はあなたの質問について二つの見解を持っています。
- あなたは、バグ修正作業に割り当てられており、アーキテクチャや設計作業に割り当てられていないようです。
- あなたの同僚は、彼らをより効率的にするために限られた回避策（バグ修正VMを組み合わせる）を考え出しているようですが、あなたは彼らの賢明な例に従っていないようです。
それは単に、多数の人を必要とする建設的な努力のなかで、何人かの人々が設計を行い、より大きなグループが実装を「得る」という事実です。申し訳ありませんが、あなたはその2番目のグループに属しています。
他のコメンテーターが指摘しているように、CVSは高度に分岐した開発モデルの仕事に最適なツールではありませんが、マージの責任はないことも指摘しています...心配しないでください。
あなたの不満のほとんどは、本質的に「開発前、開発中、または開発後にテストしたくない！」ポイントごとにステップを分解してみましょう。
- 単一のバグを修正するには、まず、クリーンで新しい仮想マシンを入手します。テスト環境
- 次に、Bugzillaレポートに記載されている別のブランチに基づいて、その単一のバグ修正用のブランチを作成します。-バグが見つかった環境を複製します。 ..これは無理ですか。
- マシンにブランチをインストールし、セットアップします。バグを修正しました。私はそれをチェックインします-基本的な開発プロセス
- ...他の人がテストできるようにマシンとマシンを残します。-マージチームは、マージが行われた場合に修正を検証できるようにしたいと考えています。南。
- それから私はバグ管理ソフトウェアに入り、私がしたことを説明しなければなりません-あなたがこれをしない店にいるなら...なぜバグを追跡するのですか？
- そしてすべてのステップでテストケースを書きます。-私は間違っている可能性がありますが、それはすべての「クールな子供たち」が進んでいる方向のようですとにかく
- 最終的に他の誰かがリリースとマージします。-そして、上記の手順のいくつかは、仕事を簡単にするためのものです
あなたの前の誰かが明らかにバグのトリアージを行って、見つかったバグが別のリリースで再修正されたり、以降のリリースで壊れたりしないようにします（それがテストケースの目的です）。
このプロセスについて少しでも異常または熱狂的でさえある唯一のことは、VM事です。あなたがどのドメインで作業していたかを知っていれば、合理的であると考えられる公正なチャンスがあります。
面白い。テスターはいますか？彼らはその一部をしているはずです。私は1人であり、私が働く場所には適切な解決策があります。
あなたが説明しているように、機能的な欠陥の場合、私たちのプロセスは次のようになります：
- VMで欠陥をテストします（顧客から報告された、または私の探索的テスト中に、またはw/e）
- バグが見つかった/再現した。
- バグを作成します。バグは次のとおりです。
- インストールからバグが発生するまでの完全な再現。
- VMのスナップショットへのリンク（開発者がそれを必要とする場合...私がとにかくスナップショットを作成します）。
- システム情報、私が行う必要がある特別な設定。
- そのバグは開発者に割り当てられます。彼らが修正に取り組んでいる間、I：
- テストケースを作成する
- 手動テストを自動テストに書き込む（または変換する）
それから私は解決策を待ち、開発者が必要な方法で開発者を助けます。それが解決されて戻ってきたとき、私は：
- 自動テストケースと手動バージョン（場合によって）を実行して、修正を確認します。
- バグを閉じます。
TL; DR：テスターがいない場合は、テスターが必要です。あなたがいくつか持っている場合、彼らは「自分の役割を果たしている」わけではありません。
「それから、その単一のバグ修正のためにブランチを作成します」
単一のバグ修正のためにブランチを作成する必要はありません。まず、bugzillaでバグを作成します。リリースブランチをチェックしてください。修正してください。コミットメッセージに書き込まれたテキストキーワードに応じて、バグ番号を含むコミットメッセージでコミットを実行します。これにより、バグが更新され、「修正済み、テストが必要」または「修正済み、テスト済み、マージが必要」とマークされます。バグデータベースは、行われたすべての変更とそれらが行われた理由の完全な追跡メカニズムです。バグデータベースからレポートを実行して、この情報を抽出できます。
ほとんどのプロセスは自動化できると思うので、仮想マシンとブランチの作成（コードのコンパイル、デバッガーのセットアップなど）はすべて完了しましたあなたがバグに取り掛かる前にあなたのために。
何をしたか、どのようにテストすべきかを説明することは、すべてのバグ修正にとって価値があります。 テキストを書くだけで問題をキャッチできることがわかりました。リスクなどについて考えさせるためです。
そのため、プロセスは少し「やりすぎ」かもしれませんが、実際の問題は、プロセスをサポートするカスタムの自動化ツールが不足していることです
おやおや、あなたの思考プロセスは正しいです。あなたが説明したことはまったくひどいものであり、ソフトウェアでどのように間違ったことが起こり得るかについての真のデモンストレーションです。ここに朗報ですが、アジャイルを真の精神で実践している企業は非常にたくさんあります。私が働いている会社はそのようなものです。最近はたくさんありますが、それは本当に良いニュースです。
職場で本当に物事が正しくないと感じたとき、できることは2つあります。ポジティブな変化に影響を与えるか、その場所を離れてより良い場所に加わることができます。
CVSや構成管理システムに問題はありません。残念ながら、その使用方法は、その目的を実際に知らなくても、組織全体で！@＃$にこのような痛みをもたらします。
アジャイルの本当の意味をすばやく理解するには、Venkata Subramaniam著の「Practices of a Agile developer」という本をよく読んでください。簡単に理解できる言語でうまく書かれています。
幸運を願っています！