개발 스택 슬라이싱-대각선으로?


11

우리는 새로운 프로젝트를 진행하고 있으며 현재 개발자는 팀 A와 팀 B의 두 팀으로 나뉘어져 있습니다.이 프로젝트에는 개발 스택 전체에서 개발이 필요한 두 부분이 있습니다. 아래에 표시된 스택의 매우 단순화 된 샘플 :

여기에 이미지 설명을 입력하십시오

프로젝트의 각 부분은 전체 스택에 걸쳐 개발이 필요하므로 팀 B 내에서 작업을 분류하고 다른 부분 간의 상호 작용을 설계하고 해결하는 방법 인 풀 스택 개발자 접근 방식이 일반적입니다.

여기에 이미지 설명을 입력하십시오

그러나 최근에 팀 A가 스택의 특정 부분을 담당하고 싶다는 것을 알게되었으며, 데이터 추상화 계층 (및 데이터 계층에 내용을 넣는)이 처리하는 두 팀 간의 구분을 제안하고 있습니다. 팀 B의 발전이없는 그들 자신.

여기에 이미지 설명을 입력하십시오

나에게 이것은 매우 부자연 스럽습니다. 각 팀은이를 달성하기 위해 서로 다른 목표와 시간 척도를 갖지만 팀 B는 기능을 구현하기 위해 팀 A에 의존합니다. 제안 된 솔루션은 공통 인터페이스가 사전 정의되어 있다는 것입니다 (아마도 프로젝트에 2 년의 시간 척도가있어 다수 일 수 있음). 그런 다음 팀 A는 자체 목표가 있음에도 불구하고 이러한 인터페이스에 필요한 비트를 조기에 개발하는 한편 팀 B는 즉각적인 단기 요청을 모두 처리하여 진행할 수 있도록합니다.

이 접근 방식에 대해 다음과 같은 우려가 있습니다.

  • 인터페이스는 변경 될 수 있으며 팀 A는 변화하는 요구 사항을 수용 할 수있는 대역폭이나 시간이 없을 수 있습니다.
  • 팀 A의 코드 버그는 팀 B의 진행을 방해 할 수 있으며 팀 A의 우선 순위 대기열이 다르기 때문에 이러한 문제를 해결하는 데 우선 순위가 아닐 수 있습니다.
  • 팀 전체에 지식 부족-팀 B는 어떤 일이 벌어지고 있는지를 완전히 이해하지 못하고 이로 인해 잘못된 디자인 결정을 내릴 수 있습니다.

업계의 많은 회사들이 하위 팀을 가지고 있으며이를 처리 할 수 ​​있어야한다고 제안되었습니다. 내 이해에서 일반적으로 팀은 내가 처음에 기대했던 방식으로 (Full Stack) 나뉘거나 다음과 같이 기술 스택을 나눕니다.

여기에 이미지 설명을 입력하십시오

그래서 저는 나머지 산업이 무엇을하고 있는지 알고 싶습니다. 대부분의 분할은 수직 / 수평입니까? 대각선 분할이 의미가 있습니까? 대각선 분할이 발생하면 내 우려가 유효 해 보이며 팀 B가 염려해야 할 것이 있습니까? 팀 B의 성공 또는 실패에 대한 책임은 아마있을 것입니다.


10
"업계의 나머지 부분"은 아마도 여러분이 생각할 수있는 모든 분할 조합을 수행하고있을 것입니다. 그러나 솔직히, 당신은 팀 A가 책임지고 싶어 하는지 말하지 않았습니다 . 그리고 그것은 당신의 팀이 얼마나 큰지, 그리고 동등한 자격을 갖는지에 차이를 만듭니다.
Doc Brown

세 번째 그림에서 팀 A와 팀 B의 작업이 별도의 API로 분리되어 있습니까? 그 구분선에 의해 부과되는 분명하고 논리적 인 경계가 있습니까? 노동 분업은 새로운 것이 아니다. 예를 들어 Stack Exchange에는 자체 디자이너가 있습니다.
Robert Harvey

@DocBrown 나는 팀 A와의 이전 프로젝트 실패 후 'A 요리사가 국물을 망친다'고 느끼기 때문에 팀 A가 책임지고 싶어한다고 생각하지만 실제로는 확실하지 않습니다. 팀은 각각 약 5 명의 개발자이며 합리적으로 능숙합니다.
Ian

1
수직 분할에 대해 확신을 갖지 못하면 팀 A가 자신의 요청보다 우선 순위가 높은 팀 B의 요청을 처리하도록 커밋 할 수 있습니다. 이것은 혈액을 막거나 나쁜 혈액을 막을 수 있으며, 지불해야 할 대가입니다.
Hans-Peter Störr

1
@hstoerr : 흥미롭게도 이것은 스크럼 얼라이언스가 제안 하는 것입니다 소비 컴포넌트 팀 (다른 컴포넌트 팀의 결과물을 사용하거나 "소비"하는 컴포넌트 팀)은 생산자 팀의 제품 소유자 역할을합니다. scrumalliance.org/community/articles/2012/september/…
Ian

답변:


12

귀하의 우려는 매우 유효합니다. 특히 팀 A에 대한 첫 두 가지 요점은 팀 B에 영향을주는 기능을 추가하거나 버그를 수정할 시간이없는 것입니다. 나는 이것이 내 업무에서 꽤 여러 번 발생하는 것을 보았습니다.

다음과 같은 경우에 좋습니다.

  • 팀 A는 데이터베이스의 새로운 기능이 필요한 프로젝트를 수행하는 것으로 알려져 있으며, 팀 B의 목표는 본질적으로 "프론트 엔드"기능 만 수행하는 것입니다. 예를 들어, 팀 B가 회사의 새로운 iPhone 앱을 작성하는 경우 데스크톱 버전의 모든 기능을 이식 / 재 구현해야하므로 한동안 새 데이터베이스 필드를 추가하지 않을 수 있습니다.

  • "풀 스택"은 단일 개발자 (또는 개발자 팀)가 전체를 효과적으로 "소유"할 수 없을 정도로 복잡해졌습니다. "소유"란 기능을 추가하고 버그를 수정하는 것이 아니라 시간이 지남에 따라 더 많은 기술적 부채를 피할 수있을 정도로 시스템 전체를 이해하고 관리한다는 의미입니다. 이 경우, 팀 A가 DAL / 데이터베이스 구현 (아마도 일부 내부 진단 도구)에 매우 간단하거나 피할 수없이 밀접하게 연결된 UI / 웹 API를 소유 한 경우 "대각선"분할은 합리적인 이동입니다. 복잡한 사용자를위한 프론트 엔드

  • 경영진은 팀 A의 병목 현상이 발생할 위험을 이해하고 있으며 이러한 위험이 실제 문제로 변할 경우 기꺼이 역대화할 의향이 있습니다.

업계에서 어느 정도 공통적인지 말할 수는 없지만 적어도 내가 일하는 곳에서는 모든 응용 프로그램 개발자가 "풀 스택"이어야합니다. 우리가 보유하고있는 것은 사내 데이터베이스, 웹 서비스 프레임 워크 및 UI 프레임 워크 (내 회사가 거대하다고 언급 했습니까?)를 개발 / 유지 관리하는 "인프라"팀으로, 수백 개의 모든 애플리케이션이 전체 스택을 가질 수 있습니다. 회사 전체는 여전히 모든 서비스에 일관된 성능과 UI를 제공 할 수 있습니다.

최근에 우리 회사는 새로운 UI 프레임 워크를 만들어 왔기 때문에 새로운 앱 중 일부가 버그와 새로운 프레임 워크의 기능 상실로 인해 상당히 차단 된시기가있었습니다. 우리 중 일부는 프레임 워크를 소유 한 팀에 풀 요청을 제출할 수있는 권한을 부여 받았기 때문에 더 이상 그렇지 않습니다 ( "비대화"가 아니라 아이디어를 얻습니다).


2
두 번째로, 이것은 합리적인 규모의 비즈니스 응용 프로그램에 해당됩니다. API가 잘 정의 된 라이브러리는 너무 크지 않은 경우 논리적 경계로 보입니다.
Robert Harvey
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.