팀 토폴로지
4가지 기본 팀 유형
팀 토폴로지에서는 4가지 팀 유형을 소개한다. 1
- 스트림 정렬Stream-aligned
- 주요 비즈니스의 변화 흐름에 정렬돼있고 교차기능 기량을 갖춘 구성원들로 조합돼 다른 팀을 기다리지 않고도 중요한 증분을 전달할 수 있는 팀.
- 플랫폼Platform
- 스트림 정렬팀의 소프트웨어 전달을 지원하는 기반 플랫폼에 관한 업무를 수행하는 팀. 플랫폼은 복잡한 기술을 단순화해 그 기술을 사용해야 하는 팀이 가진 인지 부하를 감소시킨다.
- 활성화Enabling
- 다른 팀들이 전환 혹은 학습 과정에서 소프트웨어를 도입하고 수정하는 것을 지원하는 팀.
- 난해한 하위시스템Complicated subsystem
- 일반적인 스트림 정렬팀 혹은 플랫폼 팀이 다루기 너무 어려운 하위시스템을 전문 영역으로 하는 팀. 꼭 필요한 경우에만 선택해 한시적으로 운영한다.
3가지 상호 작용 모드
각 팀들은 다음과 같은 상호 작용 모드를 가질 수 있다.
- 협력Collaboration 모드
- 두 팀은 공동의 목표(특별히 새로운 기술이나 접근 방식의 발견과 같은)를 두고 밀접하게 협업한다. 오버헤드가 발생하지만 빠른 학습 속도에서 얻는 가치가 크다.
- 엑스 애즈 어 서비스X-as-a-Service 모드
- 한 팀은 다른 팀이 제공한 무언가(API, 도구 혹은 소프트웨어 제품 전체 등)를 소비한다. 협력은 최소화된다.
- 촉진Facilitation 모드
- 한 팀(일반적으로 활성화 팀)은 다른 팀이 새로운 접근 방식을 학습하거나 적용하는 것을 촉진한다.
위의 3가지 핵심 범주 이외의 상호 작용은 불필요하다. 다시 말해, 다른 상호 작용을 선택했다면 팀의 책임 경계를 잘못 결정하고 팀의 목적을 잘못 이해한 것이다. 1
저 세 가지를 단순하게 표현할 수 있을 것 같다.
- 협력
- 다른 팀과 같이 일한다. 밀접하게 협력한다.
- 문제가 빨리 해결된다.
- 어느 정도 공동으로 책임을 지게 된다.
- 소프트웨어 경계가 흐릿해진다.
- 엑스 애즈 어 서비스
- 다른 팀과 같이 일한다. 최소한으로 협력한다.
- API를 만든다. 이렇게 만든 API는 다른 팀이 사용할 수 있다.
- 책임 구분이 명확하다.
- 만들어진 서비스를 쓰는 팀들은 문제를 빨리 해결하게 된다.
- 촉진
- 다른 팀을 도와준다.
- 새로운 접근 방식을 도입하게 하거나 알려준다.
- 도움을 받는 팀이 마음을 열어야 한다.
메모
[[/Conway-s-law]]를 토대로 조직 설계 프레임워크를 제공하는 책이다.
이 책에서는 팀에 대해 단호한 입장을 취한다.
- 팀은 5 ~ 9 명으로 이루어져야 한다.2
- 이 인원을 넘어서면 팀 내 신뢰가 잘 안 쌓이고, 결정도 부적절하게 내리게 된다.
- 그 결과로 팀이 생산하는 소프트웨어의 변동성도 커지게 된다.
- 업무 전달/담당의 가장 작은 단위는 팀이어야 한다.2
- 개인에게 업무를 할당하면 안된다.
- 팀을 안정된 상태로 유지해서 업무가 팀으로 흐르도록 해야 한다.3
- 소프트웨어의 모든 부분은 한 팀이 소유해야 한다.4
- "어떠한 컴포넌트, 라이브러리, 코드도 공동으로 소유해서는 안된다."
- 팀의 인지 부하에 맞춰 소프트웨어 경계를 선택한다.5
- 한 팀이 난해한 도메인을 2개 이상 책임지면 안된다.6
- 한 개만 맡도록 한다.
소프트웨어 규모가 급격히 커지면서 팀을 압도하는 일이 발생하지 않도록 하려면, 한 하위시스템(혹은 컴포넌트) 규모를 한 팀이 관리할 수 있는 수준으로 제한해야 한다. 특히, 한 팀이 견딜 수 있는 최대 인지부하를 절대로 초과하지 않도록 해야 한다. 팀 전체가 복잡성과 정신적 오버헤드를 감당할 수 있어야 한다. 이런 팀 규모 아키텍처는 가장 먼저 사람에 집중한다. 이는 소프트웨어 아키텍처에 있어, 기술에 집중하는 모놀리식 혹은 마이크로서비스 아키텍처보다 훨씬 지속 가능하며 인간적인 접근 방법이다. 7
참고문헌
- 팀 토폴로지 / 매튜 스켈톤, 마누엘 페이스 저/김연수 역 / 에이콘출판사 / 2020년 12월 30일 / 원서 : Team Topologies: Organizing Business and Technology Teams for Fast Flow