0

たとえば、チーム A とチーム B は、同様の機能を実装する必要がある異なるアプリケーションに取り組んでいます。問題の機能はデータベースに依存しており、データベースはチーム B の管理下にあります。2 つのアプリケーションのユーザー インターフェイスは異なるテクノロジに基づいていますが、機能はほぼ同じであると想定されています。どちらのチームにも独自の要件と設計ドキュメントがあります。いずれかのチームからのフィードバックに基づいて機能を変更できますが、その後、両方のチームが要件と設計ドキュメントを更新する必要があります。

チームは地理的に分散しており、各チームのメンバーも地理的に分散しています。両方のチームは、同じクライアント エンティティを扱いますが、担当者は異なります。各チームには独自のビジネス アナリスト (要件スペシャリスト) がいます。誤解を避けるために、チーム間のテクニカル コミュニケーションを電子メールよりも正式なものにしようとしています。

チーム B がデータベースや機能の機能を変更した場合、他のチームがそれについて適切に通知されるようにするにはどうすればよいですか? インターフェイス コントラクトなどの正式なテキスト ベースのドキュメントを使用していますか? それらのテンプレートを共有できますか? それとも、他のメカニズムを使用していますか？

4

3 に答える 3

1

私自身の経験からのいくつかのこと（あなたの経験と非常に似ているように聞こえます）

djna が提案するように、データとのやり取りに関する定義済みの公開契約を使用して、wiki または同様のものに投稿する必要があるソリューションのデータベース部分の単一の設計ドキュメントを作成する必要があります。これは正しい方向への良い一歩です。誰もが一種の「共有ビジョン」を得ることができ、正しいことを行うために収束するのに役立ちます。契約では、データ アクセスが標準化された方法で行われるようにする必要があります。

ただし、経験上、コードは常に仕様に正確に従っているとは限らないため、両方のシステムをデータベースに統合する責任を負うチームの 1 つから 1 人の所有者を割り当てることもできます。

次に、テストを使用して夜間の継続的なビルド プロセスを実装します。このビルドにはデータベースが含まれている必要があります。これにより、プロセスの早い段階で問題が発生する可能性があります。

私が取り組んだプロジェクトから、時折意見の相違や崩壊が生じる可能性がありますが、最終的には両方のチームを統合しました. これは私たちにとって最高の解決策でした!!

これが少し役立つことを願っています

于 2009-11-20T17:20:43.507 に答える
1

両方のチームが変更を認識できるように、チーム サイト (両方を 1 つのチームとして) または Wiki を用意するのはどうでしょうか。

于 2009-11-20T16:53:42.687 に答える
0

恒例のスタンドアップミーティング。電話会議を介して。スタンドアップ == 簡潔で、高度に焦点を絞った、情報中心。会議外での個別のディスカッションにディスカッションを委任し、次の会議で報告します。

ただし、合意に達することができない場合に仲介し、全体的なソリューションの完全性を確保するために、全体的な権限が必要です。

現在の現実を公開するための Wiki またはその他の共同サイトに同意します。

于 2009-11-20T17:00:12.723 に答える