なぜメンテナンス作業を開発作業から分離するのですか？

StackOverflow https://stackoverflow.com/questions/1416387

  •  06-07-2019
  •  | 
  •  

質問

私は、ソフトウェアに命を吹き込む同じチームによってメンテナンスが行われている会社で働いています。

非常に頻繁に、別のメンテナンスチームまたはメンテナンスプログラマーがいる組織について耳にします。私が疑問に思うのは、この背後にある理由は何ですか？

「古いコード」をより少ない人間に捨てる以外に、何かありますか？

独自の「ジャンク」を維持することから学んだ教訓はるかに高い価値がありますか？欠陥を最初に引き起こした人が行った場合、欠陥の修正ははるかに効果的ではありませんか？

個別のメンテナンスチームを持つことが有益であるという本当の理由を逃していますか？

役に立ちましたか？

解決

これを最もよく説明するために思い浮かぶ概念は、「スラッシング」です。これは基本的に、メンテナンス作業と開発作業の両方に関連する切り替え費用です。これがおそらく、責任を分離する最大の理由です。他には、ジュニアまたはエントリーレベルのプログラマーが足を濡らし、経験豊富な開発者がより価値の高いアイテムを生産できるようにする機会が含まれます。

同時に、アプリを作成した開発者には、それをサポートしなければならないという価値があると思います。第1に、彼らはコード内の問題をすぐに見つけて、そこから学ぶことができます。第二に、彼らはそれをサポートしなければならないので、コードの保守性と品質について考えるでしょう。

実際のスラッシングの例：

1500時間の開発プロジェクトが割り当てられ、最後の3つのアプリケーションのシステムメンテナンスとサポートも担当しています。この新しいプロジェクトでは、これらの3つのアプリをサポートするために、週に平均7回中断されます。他の3つのアプリで作業を開始するたびに、20分かけて問題を解決します。問題を修正した後、20分を費やして、新しいアプリで最後に触れたコードを思い出します。これは、中断ごとに40分、または週に280分という合計コストです。つまり、これらのアプリをサポートするために切り替えただけで、1週間で2.67時間の生産性が失われました。

他のヒント

私は1年以上にわたってアジャイルチームに取り組んでいます。ライブ製品の場合、それは実際には問題ではないと思います（つまり、最新バージョンのみを使用しているクライアントを意味します）。しかし、製品のいくつかのバージョンが市場に出回っており、それぞれのバージョンをサポートする必要があるとしましょう。

たとえば、BentleyのMicrostationを使用します。 3D（建築、プラント設計、鉄道、道路、橋など）の設計アプリケーション。ここで、v8、v9、v10が市場に出ているとします。それらには異なる機能があり、ファイル形式はバージョンごとに大幅に変更されています。しかし、プロジェクトは非常に大きい（またはクライアントが非常に重要である）ため、v8のクライアントとv9のクライアントをサポートすると同時にv10を開発する必要があります。そのため、会社には以前のバージョンに割り当てられた保守チーム（または時間）が必要です。また、製品がカスタマイズと上記のシナリオをサポートしている場合、通常、これらのチームはカスタマイズチームと呼ばれます。

問題はより実用的です：

  • 古いコードは、もはや会社やチームにいない人々によって書かれています;
  • 古いコードは外部の開発者によって作成されました;

多くの企業では、元のコーダーがもはや存在しないために、元のコーダーによってもはやメンテナンスされていないコードベースを持つことは本当に一般的です。コードベースが十分に大きい場合は、誰かがそれを最新に保つ必要があるため、メンテナーと呼ばれます。

このケースを回避できる場合、あなたにとっては良いが、それは常に一時的なものであることを確認してください。

私はその慣行に同意するとは言いませんが、多くの組織ではコンサルタントが短時間でソフトウェアを書くためにオンボードされ、プロジェクトは社内のプログラマーに渡されて「維持」されます。理論的根拠は、トレーニングなしでより熟練した人を連れてきて、「知識の伝達」を含めることができるということです。ソフトウェアの一部をそのまま保持することに取り組む人々に。

要するに、多くの場合、政治的/非現実的な理由で行われます。

メンテナンスチームと機能開発チームを分割する背後にある動機は、物事を円滑に実行し続けることだと思います。個別のメンテナンスチームがあれば、残りの開発者が解放され、問題のプロジェクト/製品を前進させることができます。

最初の仕事は、元の開発者が新しいプロジェクトに移ったソフトウェアモジュールの保守でした。

推測しています：

  • 新しい開発をより予測可能かつスケジュールしやすくします。開発者は、メンテナンスに関するいくつかの未解決の問題を修正するためにそれを呼び出さないためです

  • 新しい開発者（例：私）を訓練する機会

さらに、私が管理していたコードは「ジャンク」ではありませんでした。 -それは、ベルなどの顧客に展開されていた初期のパケット交換ネットワークである電話会社のソフトウェアでした。ドキュメント...

... OPのサブタイトルはのようです＆quot;元の開発者になってもらい、彼の鼻をこすりましょう：それが彼を学ぶだろう！＆quot;

コードが既に十分に記述されている場合、その引数（元の開発者に教える）は適用できません。

「メンテナンス」を行っていたと言うと、は新しい機能の開発に似ていますが、非常にマイナーな機能です...たとえば、プロトコルの仕様を少し変わった方法で解釈した新しい顧客のデバイスとの相互運用などです。

[問題を分析および診断し、修正をコーディングします。 QA担当者は、対応する新しいテストケースを自動テストスイートに追加します。]

私が見ることができる利点の1つは、コードを修正するのに十分なコードを理解する責任がある組織内に少なくとも1人の他の人がいることです。また、この人は異なるアジェンダを念頭に置いており、設計/開発レビューに参加する必要がある場合は、メンテナンスの観点からコードをレビューできます（彼/彼女はそうすべきです）。

また、「メンテナンス」展開、構成、バックアップなどのさまざまなアクティビティを参照する場合がありますが、これらのアクティビティは別のチームで確実に処理する必要があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top