개발 팀 간의 기술 계약은 어떻게 유지합니까?

Question

예를 들어 팀 A와 팀 B는 비슷한 기능을 구현해야하는 다른 응용 프로그램에서 작업하고 있습니다. 문제의 기능은 데이터베이스에 의존하며 데이터베이스는 팀 B의 제어하에 있습니다. 두 응용 프로그램의 사용자 인터페이스는 서로 다른 기술을 기반으로하지만 기능은 대략 동일합니다. 두 팀은 각각 요구 사항과 설계 문서를 가지고 있습니다. 기능은 두 팀의 피드백을 기반으로 변경 될 수 있지만 두 팀은 요구 사항 및 설계 문서를 업데이트해야합니다.

팀은 지리적으로 분산되어 있으며 팀 자체의 구성원도 지리적으로 분산되어 있습니다. 두 팀은 동일한 클라이언트 엔티티로 작업하지만 다른 사람과 작업합니다. 각 팀에는 자체 비즈니스 분석가 (요구 사항 전문가)가 있습니다. 오해를 피할 수 있도록 전자 메일보다 공식적인 팀 간의 기술적 의사 소통을 위해 노력하고 있습니다.

팀 B가 데이터베이스 및/또는 기능을 변경하면 다른 팀에 알리는 방법은 무엇입니까? 인터페이스 계약과 같은 정식 텍스트 기반 문서를 사용합니까? 템플릿을 공유 할 수 있습니까? 아니면 다른 메커니즘을 사용합니까?

Answer 1

당신은 시도하고 위키에 게시해야한다 제안 djna와 솔루션의 데이터베이스 부분에 대한 단일 설계 문서를 가지고 있어야

(당신에게 매우 비슷한 소리) 내 자신의 경험에서 몇 가지 데이터와의 상호 작용을위한 공개 계약을 통해 올바른 방향으로 나아가는 좋은 단계입니다. 사람들이 올바른 일을 할 때 수렴하도록 돕는 일종의 '공유 된 비전'을 모든 사람들에게 줄 것입니다. 계약은 데이터 액세스가 표준화 된 방식으로 수행되도록 보장해야합니다.

그러나 경험상 코드가 항상 스펙을 정확히 따르는 것은 아니므로 두 시스템 중 하나를 데이터베이스에 통합하는 책임이있는 팀 중 하나의 소유자를 지정할 수도 있습니다.

그런 다음 테스트를 통해 야간 빌드 프로세스를 연속적으로 구현하고이 빌드에는 데이터베이스가 포함되어야합니다. 이 과정에서 이전에 문제가있는 부분에 플래그를 지정하면됩니다.

내가 맡은 프로젝트에서 가끔 의견 차이가 나고 고장이 생겨 결국 두 팀이 합쳐졌습니다. 이것은 우리 모두를위한 최고의 해결책이었습니다 !!

희망 조금 조금 도와주세요

Answer 2

두 팀이 변경 사항을 인식 할 수 있도록 팀 사이트 (한 팀 또는 두 팀 모두) 또는 Wiki가있는 경우는 어떻습니까?

Answer 3

정기적 인 독립 회의. 전화 회의를 통해. 스탠드 업 == 간단하고 집중적이며 정보 중심. 회의 외부의 개별 토론에 토론을 위임하고 다음 번에 다시보고하십시오.

합의에 도달 할 수없는 곳을 중재하고 전반적인 솔루션 무결성을 보장하기 위해 전반적인 권한이 있어야합니다.

나는 현재 현실을 게시하기위한 위키 또는 기타 협력 사이트에 동의합니다.