3장(2,3) 소프트웨어 팀의 구조, 코드 리뷰

3장 JIRA를 이용한 스크럼과 개발 조직, 코드 리뷰 기법

2. 소프트웨어 팀의 구조

일반적인 소프트웨어 개발팀의 구조는 소프트웨어를 직접 개발하는 프로젝트 유닛, 전체 프로젝트들을 관리하는 관리조직과 각 개발팀에 공통으로 테스트 등의 지원을 해주는 공통팀과 마지막으로 개발된 시스템을 운영하는 운영팀으로 나눌 수 있다.

2.1 프로젝트 유닛

프로젝트 유닛(Project Unit)은 하나의 시스템을 개발하는 최소 단위이다.

  • 프로젝트 매니저(Project Manager) : 여러 개의 스크럼 팀을 운영하면서 단일 시스템 구현을 관리한다.

  • 프로덕트 매니저(Product Manager) : 고객으로부터 시스템에 대한 요구 사항을 수집하고 시장을 분석하여 시스템에 대한 요구 사항을 정의하고, 우선순위를 정하는 역할을 한다.

  • 아키텍트(Architect) : 전체 시스템에 대한 구조를 설계한다.

  • 스크럼 팀(Scrum Team) : 하나의 프로젝트 유닛은 내부의 서브 시스템이나 컴포넌트 단위에 따라 몇 개의 스크럼 팀으로 나누어진다.

  • 스크럼 마스터(Scrum Master) : 스크럼 마스터는 프로젝트 매니저로부터 받은 요구 사항을 개발원들에게 나눠주고, 관리하는 역할을 한다.

  • 개발자(Developer) : 스크럼 마스터로부터 받은 태스크를 구현한다.

  • 테스트(QA) : 시스템의 특성이나 팀의 구조에 따라서, 해당 스크럼 팀에서 개발된 코드나 기능에 대한 테스트를 수행한다.

2.2 관리 조직

프로그램 매니저(Program Manager)

여러 개의 프로젝트를 동시에 관리하며 개별 프로젝트의 구현보다는 비즈니스 조직과의 커뮤니케이션과 개발 후 서비스에 대한 운영, 고객지원, 판매, UX 등에 대한 전반적인 면을 모두 관리한다.

수석 프로덕트 매니저(Chief Product Manager, 팀 규모가 클 경우)

전체 프로덕트 요구 사항에 걸쳐서 전반적인 부분을 관리하는 사람을 치프 프로덕트 매니저라고 한다.

엔터프라이즈 아키텍트(Enterprise Architect, 팀 규모가 클 경우)

엔터프라이즈 아키텍트는 전체 시스템에 대한 개념적인 구조와 비즈니스 간에 연결 역할을 하면서 비즈니스와 개발 간의 기술적인 소통 채널이 된다.

2.3 공통팀

공통팀(Shared Unit)은 개발 기간에 한 팀에 집중되지 않고 중간마다 필요할 때만 사용되므로 자원의 효율성을 위해 전체 팀에 걸쳐 공통된 조직으로 운영하는 것이 좋다.

  • 빌드 엔지니어 : 전체적인 빌드 배포를 담당하는 엔지니어이다. CI와 CD 도구를 이용하여 빌드 환경과 테스트 자동화 환경을 구축한다.

  • 개발 환경 관리 엔지니어 : 개발환경에 필요한 전반적인 부분을 관리한다.

  • 성능 엔지니어 : 시스템 테스트를 위한 부하테스트 작성 및 장애 테스트의 수행, 그리고 병목 구간 발견 및 튜닝에 대한 모든 작업을 수행한다.

  • 프로젝트 관리 오피스(PMO) : 프로젝트 조직이 거대할 경우, 전체 프로젝트를 중앙에서 통제한다.

2.4 운영팀

시스템 운영(Technical Operation)

테크 옵스(Tech Ops)라고 이야기 하는 분야로, 구현된 하드웨어나 소프트웨어를 포함한 시스템에 대한 운영을 담당한다. 테크 옵스는 시스템의 설치, 설정, 세트업 및 배포와 같이 설치에 대한 프로세스뿐만 아니라 시스템에 대한 모니터링 및 장애 처리까지의 시스템에 대한 기술적인 운영에 대한 전반적인 부분을 담당한다.

  • 인프라 엔지니어 : 네트워크 장비, 서버 등 하드웨어 장비에 대한 설치, 설정과 운영을 담당한다.

  • 솔루션 엔지니어 : 메시지 큐, MQ, 애플리케이션 서버와 같은 미들웨어를 운영한다.

  • DBA : 데이터베이스 운영자

서비스 운영(Service Operation)

서비스 운영은 구축된 서비스에 대한 운영을 담당한다. 시스템에 대한 기술적인 면을 배제한 부분을 포함한다.

  • 관리자(Admin) : 서비스에 대한 관리를 한다.

  • 고객지원(Support) : 기술지원이나 고객 불만 접수와 같은 고객 지원 서비스를 담당한다.

3. 코드 리뷰

코드 리뷰란 코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드에 숨어 있는 잠재적인 결함을 찾아내고 이를 개선하는 일련의 과정을 정의한다.

3.1 코드 리뷰 스펙트럼

정형성에 따라 대표적인 리뷰 방법을 나열해보면 다음과 같다.

손쉬운 방법 ← 피어리뷰 ← 패스 어라운드 ← 팀 리뷰 → 워크스루 → 코드 인스펙션

3.2 코드 인스펙션

전문화된 코드 리뷰팀이 시스템이 어느 정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다. 인스펙션 팀은 크게 4가지 역할을 가지고 구성된다.

중재자(Moderator)

중재자는 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀 간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다. 인스펙션이 언제 끝날 것인지 종료 조건을 정의한다.

리더(Leader)

리더는 전체 시스템을이해하여 인스펙션 팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 제시한다.

디자이너와 코더(Designer/Coder)

디자이너가 지시한 방향에 따라서 코드를 검증하고 잠재적인 결함을 발견 및 권장 수정 방안을 만들어낸다.

테스터(Tester)

테스터는 인스펙션이 진행 중인 모듈에 대해서 테스트를 수행하고 결함을 찾아내는 역할을 수행한다.

인스펙션은 다음 6단계로 진행된다.

계획 : 기간,대상,종료 조건,팀 구성 → 오버뷰(Overview) : 시스템 교육, 팀원 역할 정의 → 준비 : 도구, 환경 구축. 문서 이해와 인터뷰 → 인스펙션재작업 : 결함 수정 → 후처리(Follow-up) : 결함 수정 확인

3.3 팀 리뷰

리뷰 시간에 발표자(Author,코드를 만든 사람)가 코드에 대해 설명하고 팀원은 결함이나 개선안을 찾는다. 중재자는 리뷰의 주제를 선정하여 리뷰를 진행하고 리뷰에서 나온 의견을 정리하여 액션 아이템으로 기록한다. 액션 아이템들은 프로젝트 매니저가 실제 프로젝트 태스크로 관리해야 한다.

3.4 워크 스루

워크 스루(Workthrough)는 단체로 하는 코드 리뷰 기법 중에서 가장 비정형적인 방법이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료로부터 의견이나 아이디어를 듣는 시간을 갖는다.

3.5 피어 리뷰 또는 오버 더 숄더 리뷰

피어 리뷰오버 더 숄더 리뷰는 2~3명이 진행하는 코드 리뷰 형태다. 코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 결함을 발견하는 방법이다.

3.6 패스어라운드

패스어라운드(Passaround) 리뷰는 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다.

Last updated

Was this helpful?