우리는 새로운 프로젝트를 진행하고 있으며 현재 개발자는 팀 A와 팀 B의 두 팀으로 나뉘어져 있습니다.이 프로젝트에는 개발 스택 전체에서 개발이 필요한 두 부분이 있습니다. 아래에 표시된 스택의 매우 단순화 된 샘플 :
프로젝트의 각 부분은 전체 스택에 걸쳐 개발이 필요하므로 팀 B 내에서 작업을 분류하고 다른 부분 간의 상호 작용을 설계하고 해결하는 방법 인 풀 스택 개발자 접근 방식이 일반적입니다.
그러나 최근에 팀 A가 스택의 특정 부분을 담당하고 싶다는 것을 알게되었으며, 데이터 추상화 계층 (및 데이터 계층에 내용을 넣는)이 처리하는 두 팀 간의 구분을 제안하고 있습니다. 팀 B의 발전이없는 그들 자신.
나에게 이것은 매우 부자연 스럽습니다. 각 팀은이를 달성하기 위해 서로 다른 목표와 시간 척도를 갖지만 팀 B는 기능을 구현하기 위해 팀 A에 의존합니다. 제안 된 솔루션은 공통 인터페이스가 사전 정의되어 있다는 것입니다 (아마도 프로젝트에 2 년의 시간 척도가있어 다수 일 수 있음). 그런 다음 팀 A는 자체 목표가 있음에도 불구하고 이러한 인터페이스에 필요한 비트를 조기에 개발하는 한편 팀 B는 즉각적인 단기 요청을 모두 처리하여 진행할 수 있도록합니다.
이 접근 방식에 대해 다음과 같은 우려가 있습니다.
- 인터페이스는 변경 될 수 있으며 팀 A는 변화하는 요구 사항을 수용 할 수있는 대역폭이나 시간이 없을 수 있습니다.
- 팀 A의 코드 버그는 팀 B의 진행을 방해 할 수 있으며 팀 A의 우선 순위 대기열이 다르기 때문에 이러한 문제를 해결하는 데 우선 순위가 아닐 수 있습니다.
- 팀 전체에 지식 부족-팀 B는 어떤 일이 벌어지고 있는지를 완전히 이해하지 못하고 이로 인해 잘못된 디자인 결정을 내릴 수 있습니다.
업계의 많은 회사들이 하위 팀을 가지고 있으며이를 처리 할 수 있어야한다고 제안되었습니다. 내 이해에서 일반적으로 팀은 내가 처음에 기대했던 방식으로 (Full Stack) 나뉘거나 다음과 같이 기술 스택을 나눕니다.
그래서 저는 나머지 산업이 무엇을하고 있는지 알고 싶습니다. 대부분의 분할은 수직 / 수평입니까? 대각선 분할이 의미가 있습니까? 대각선 분할이 발생하면 내 우려가 유효 해 보이며 팀 B가 염려해야 할 것이 있습니까? 팀 B의 성공 또는 실패에 대한 책임은 아마있을 것입니다.