1

私の会社がはるかに小さかった昔、開発作業をチームに分割することは非常に簡単でした。

  • 「アプリケーション」チームはアプリケーション固有のロジックを開発しましたが、多くの場合、特定の業界の問題に関する深い洞察が必要です)
  • 「ジェネリック」チームは、すべてのアプリケーションに共通/ジェネリックな部分を開発しました (ユーザー インターフェイス関連のもの、データベース アクセス、低レベルの Windows のものなど)。

何年にもわたって、チーム間の境界があいまいになりました。

  • 「アプリケーション」チームは、アプリケーション固有の機能を「汎用」部分で作成することが多いため、「汎用」チームにその部分を作成するよう依頼する代わりに、開発をスピードアップするために自分で作成します。次に、「ジェネリック」チームに寄付します
  • 「一般的な」チームの焦点は、より「保守志向」であるようです。すべての「非常に一般的な」コードは既に作成されているため、新しい開発は必要ありませんが、アプリケーション チームから寄贈されたすべての機能を継続的にサポートする必要があります。

これはすべて、チームを分割することはもはや良い考えではないことを示しているようです。おそらく、「汎用」チームは、「ソフトウェア品質」チーム (高品質のソフトウェアを作成するためのルールを定義および保護する) または「ソフトウェア展開」チーム (ソフトウェアの展開、インストール方法を定義する) に進化する必要があります。 .

異なるアプリケーションがある場合、異なるチームにどのように作業を分割しますか?

  • 誰もがジェネリック コードを書き、それを中央の「ジェネリック」チームに寄贈できますか?
  • 誰もがジェネリック コードを書くことができますが、誰もこのジェネリック コードを「管理」していません (誰もが所有者です)。
  • 汎用コードは「汎用」チームによってのみ作成され、アプリケーションは「汎用」チームが汎用部分を提供するまで待機する必要があります (ライブラリ経由、DLL 経由)。
  • 異なるアプリケーション間でコードが重複することはありません
  • 他の方法？

ミックスを使用すること (誰もがコードのどこにでも記述できるようにすること) の利点は次のとおりであることに注意してください。

  • コードはより柔軟な方法で記述されます
  • デバッガーで「汎用」コードに簡単にステップ インできるため、コードのデバッグが容易になります。

しかし、大きな (そしておそらく唯一の) 欠点は、この汎用コードを管理する明確なチームが存在しなくなった場合、この汎用コードが誰の責任にもならない可能性があることです。

あなたのビジョンは何ですか？

4

2 に答える 2

2

さまざまな「アプリケーション」チームがある場合、常に複製された機能になります。同じタイプのヘルパークラスで、同じ問題が何度も解決され、多くの場合、わずかに異なる方法で解決されます。

問題は、誰も「一般的な」チームや「フレームワーク」チームに参加したくないということです。そのチームは、コードベースから利用できる機能を宣伝することと、「アプリケーション」の人々が実際に使用することを確認することの両方で非常に困難な仕事をしています。それ。

あなたは何人かのリードエンジニア/開発者を指名する必要があります。これらの人々の役割は、「アプリケーション」チームと「ジェネリック」チームの両方の間でコードの開発を監督することです。また、「汎用」チームが再利用できる機能を把握し、それが実際に使用されていることを確認する責任もあります（単に再発明されただけではありません）。最初に、この分野で1人（または数人）の人に知識と責任を持たせることで、チーム会議を開いて「皆さん、ここに新しいAPIのセットがあります、それらを使い始めてください」と言うよりも早く知識を広めることができます。これらのリード開発者の役割の1つは、コードレビューを管理することであり、そのコードレビューの一部は、適切な「一般的な」コードが使用されていることを確認することです。

もちろん、ジェネリックチームは、自分が持っているものを文書化するために適切な作業を行う必要があります。アプリケーション開発者がジェネリックコードの中から必要なものを見つけられない場合は、先に進んで自分で記述し、現在のサイクルを永続させます。

于 2010-04-05T10:26:10.370 に答える
1

私の以前の雇用主の 1 人は、開発作業を分割するために次のようなアイデアを持っていました。

  • 通常、平均して 3 ～ 6 か月の長期プロジェクトに取り組むプロジェクト チーム。

  • バグ修正やその他のメンテナンス作業項目に加えて、最大 2 週間かかる可能性のある短期的な機能に取り組む継続的なエンジニアリング チーム。ここで重要なのは、このグループのターンアラウンドはプロジェクト チームとは大きく異なると考えられるため、このグループは短いサイクルで作業する準備をしておく必要があるということです。

私はこれがどれほどうまくいくかを見るのに十分な時間そこにいませんでしたが、私の心には良い考えです. 重要なポイントは、他の方法では完了できない小さな仕事がたくさんあるということですが、会社全体にとって非常に役立つ可能性があるため、これは大きな仕事に加えてそれらの小さな仕事を成し遂げる方法です。この 2 つの間にあるものはすべてレビューされ、CE チームのために小さなビットに分割されるか、共通の領域に十分な類似のビットがある場合はプロジェクトにラップされます。バグ修正を行い、プロジェクト チームが行うようにまとめます。

于 2010-04-05T15:50:57.830 に答える