흔적

소프트웨어 품질을 보장하기 위한 방법중 코드 리뷰가 가장 효과적이다.

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

코드 리뷰 스펙트럼

코드 리뷰는 얼마나 프로세스를 따르냐에 따라서 방법이 나누어져 있다.

가장 정형화된 기법부터 살펴보면

Code Inspection 

일정한 패턴을 가지고 분석을 하며 4가지 역할을 가지고 구성이 된다.

1. 중재자 : 실제적인 매니저, 프로세스 정의와 산출물 정리, 테스트 환경을 확보하고 인원을 섭외한다. 인스펙션이 언제 끝날것인지 정의하는 역할
2. 리더 : 어떤 흐름으로 인스펙션을 진행할지 방향 제시
3. 디자이너와 코디 : 코드를 검증하고 잠재적인 결함 발견, 수정방안 제시
4. 테스터 : 테스트를 수행하고 결함을 찾아내는 역할

그리고 6단계에 걸쳐 코드 리뷰를 진행하게 된다.

1. 계획 : 기간, 종료 조건등 계획을 수립한다.
2. 오버뷰 : 시스템에 대한 교육이 진행되고 팀원간의 역할이 할당된다.
3. 준비 : 역할별로 필요한 문서 습득, 테스팅도구 구축
4. 인스펙션 : 각자의 역할에 따라 인스펙션을 수행한다.
5. 재작업 : 보고된 결함을 수정
6. 후처리 : 잘 수정되었는지 확인

Team Review

1. 발표자 : 코드를 만든 사람으로 코드에 대해 설명하고 팀원은 결함이나 개선안을 찾는다.
2. 중재자 : 리뷰의 주제를 선정하고 리뷰를 진행한다.

Walkthrough

워크스루는 단체로 하는 코드리뷰 기법중 가장 비 정형적인 기법으로 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 의견이나 아이디어를 공유한다.

Over the Shoulder Review

주로 2~3명이 진행하는 코드 리뷰로 코드 작성자가 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 결함을 발견하는 형식의 코드 리뷰이다.

Passaround

Git에 커밋 하기 전에 코드 내용을 리뷰하는 방법으로, 일일이 배포해서 리뷰를 받아야 하므로 자동화된 리뷰 도구를 사용하는것이 좋다.

코드리뷰를 사용해야 하는 시기?

1. 코드 인스펙션 : 릴리즈
2. 팀 리뷰 : 각 개발 유닛에서 사용, 팀 단위에서 활용하기 좋다.
3. 워크 스루 : 비정기적으로 개최
4. 피어리뷰 : 신입 개발자 교육, 지식공유
5. 패스 어라운드 : 팀 자체가 코드리뷰의 필요성을 느낄때

효과적인 코드 리뷰를 막는 요인들

리뷰의 주요 목적이 결함의 발견과 개선임을 인지하고 아이디어나 결함에 대한 의견을 자유롭게 표출 할 수 있도록 해야하며 발표자의 감정을 상하지 않게 말 하는 것이 중요하다.

이 글은 코드프레소 DevOps Roasting 코스를 수강하면서 작성한 글입니다.

시스템개발 및 운영에서 팀의 구조는 매우 중요하다.

프로젝트 유닛

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

1. 프로젝트 매니저 : 요구사항을 각 스크럼 팀에 분배하고 관리하며 다른 팀 간의 조율, 프로젝트 관리에 관련한 작업을 수행한다.
2. 프로덕트 매니저 : 고객으로부터 시스템에 대한 요구사항을 수집하고 분석하여 시스템에 대한 요구사항을 정의하고 우선순위를 결정한다.
3. 아키텍트 : 전체 시스템에 대한 구조를 설계한다.
4. 스크럼 팀 : 하나의 스크럼 팀은 마스터를 포함하여 4~7명 정도로 구성된다.
5. 스크럼 마스터 : 프로젝트 매니저로부터 받은 요구사항을 개발자에게 나눠주고 관리하는 역할을 한다.
6. 개발자 : 마스터로 부터 받은 태스크를 구현한다.
7. 테스트 : 해당 스크럼 팀에서 개발한 코드나 기능에 대해서 테스트를 진행한다.

관리 조직

1. 프로그램 매니저 : 필수적으로 필요하며, 여러 개의 프로젝트를 동시에 관리하며 커뮤니케이션과 서비스에대한 운영, 고객지원, 판매 등 전반적인것을 관리
2. 수석 프로덕트 매니저 : 팀 규모가 클 경우 존재한다.
3. 엔터프라이즈 아키텍트 : 팀 규모가 클 경우 분업의 용도로 사용하는데 전체 시스템에 대한 전체적인 구조와 비느니스와 개발 간의 기술적인 소통 채널이 된다.

공통팀

1. 빌드 엔지니어 : 전체적인 빌드 배포를 담당하는 엔지니어로 빌드 환경과 테스트 자동화 환경을 구축한다.
2. 개발 환경 관리 엔지니어 : 개발환경에 필요한 전반적인 부분을 관리한다.
3. 성능 엔지니어 : 전체 시스템에 대한 통합테스트와 시스템 테스트 집중관리한다.
4. 프로젝트 관리 오피스 : 각 프로젝트 진행 상황을 모니터링하고 일정을 관리한다.

운영팀

1. 인프라 엔지니어 : 하드웨어 장비에 대한 설치, 설정과 운영 담당
2. 솔루션 엔지니어 : 미들웨어 운영
3. DBA : 데이터베이스 운영자

계속해서 모니터링을 해야하므로 24/7 운영을 한다.

• Hand Over : 근무 시간이 끝난 후에 다음팀에게 인수인계 하는것

서비스 운영

관리자 : 서비스에 대한 관리를 한다.

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

이 글은 코드프레소 DevOps Roasting 코스를 수강하면서 작성한 글입니다.

* 스크럼(Scrum)은 프로젝트관리를 위한 상호,점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나이다.

소프트웨어 개발은 애자일 개발 방법론을 기반으로 진행되어 진다. 이 방법론의 특징은 협업을 중요시하며 태스크를 관리하는 기법을 중심으로 진행된다. 따라서 이런 태스크를 관리하는것이 매우 중요한데 이를 도와주는 대표적인 태스크 관리 시스템으로 JIRA가 있다.

JIRA : 스크럼 방법론을 기반으로 태스크 관리 도구이며 프로젝트를 관리할 수 있게 하는 도구다.

주요기능 정리 

JIRA를 사용하기 전에 먼저 엑셀을 통해서 구현하고자 하는 서비스의 주요 기능을 정의 하여 팀원들과 공유하여 리뷰하면서 수정하며 정리한다.

이때, 위와 같이 두 단계로 나눠서 Feature(기능)을 기술하는데 기능 1에선 일반적으로 생각할 수 있는 기능을 기술하고 기능 2에서는 상세 기능을 정의하는데 이런 기능 리스트를 정의할 때 4가지중요한 점이 있다.

1. “As a {user}, I want to do {something}나는 {사용자}로서 {무엇을}하고 싶다.” 형태의 스토리 기술 방법을 사용하여 서술한다.
2. 스토리 : 전체적으로 기능이 스토리 형태로 흐름을 가져가야 순서대로 기능을 기술할 수 있고 이해하기 편하며, 조금 더 빠짐없이 리뷰가 가능하다.
3. 테스트 가능 : 각 기능은 테스팅이 가능한 수준으로 디테일하게 서술되어야한다.
4. 디자인 가능 : 디자이너가 기능에 있는 스토리에 따라서 UX를 만들 수 있는 정도로 충분히 기술되어야 한다.

• UX 는 User eXperience로 쉽게 말해 사용자 경험을 의미합니다. 어떤 서비스나 기능을 제공할 때 사용자의 경험을 분석하여 보다 편하고 효율적인 방향으로 진행 될수 있도록하는 과정과 결과이다.

JIRA Agile Board(애자일 보드)

엑셀로 작성해둔 기능들을 JIRA에 기능들을 등록하기 전에 Agile Board를 알아야 한다.

스크럼 애자일 방법론을 보면 ‘스크럼 보드’라는 것이 소개되어 있는데 해야 할 일(To Do), 진행중인 일(In Progress), 완료된 일(Complete)로 진행 단계에 맞추어 일을 나누는 것이다. 이러한 스크럼 보드를 웹 형태로 만들어 놓은 것이 JIRA의 애자일 보드이다. 이렇게 단계별로 나누어서 일을 관리하게 되면 각자 해야할 일들을 작성 해 두어 자세한 기능관리가 가능하다.

애자일 보드는 팀원과의 협력을 도와주는 서비스 이므로 팀원들을 초대한다.

이름에는 본인이 진행하고자 하는 프로젝트의 이름을 적는다.

이렇게 하면 빈 애자일 보드를 생성할 수 있다.

이슈의 종류

JIRA에 입력되는 해야 할 일 기능들을 ‘이슈’라고 정의 하는데 이슈에는 몇가지의 타입이 존재한다.

1. Epic : LV1 기능으로 주요 기능들을 중심으로 정의한다.
2. Story : 사용자가 직접 사용하는 기능이다.
3. Story Point : 개발에 걸리는 시간이나 난이도를 지정한다.
4. Chore : 사용자가 이용하는 기능이 아닌 개발자만 개발해야하는 내용을 작성한다.
5. Task : 해야하는 일 이지만 개발과는 다른 업무 ( 회의, 기획, 문서작성 등 )
6. Bug : 테스트 엔지니어에 의해서 테스팅 되고 버그로 리포팅된 타입이다.
7. Sub Task : 스토리나 초어를 개발하는 과정에서 세부적인 업무의 할당이다. 이러한 세부 업무의 할당은 개별 개발자에게 할당되며 0.5에서 2일 정도에 끝날 수 있는 테스크가 할당이 되어야 한다.

에픽 등록

홈 화면에서 ‘c’를 누르면 이슈 만들기 창이 뜨는데 이슈 유형을 에픽으로 수정하여 이름과 설명 요약을 작성하면 된다.

그러면 이와 같이 에픽이 만들어진것을 확인할 수 있다.

이슈 등록과 매핑

Priority : 해당 이슈가 얼마나 중요한지를 나타내는 척도로

1. Blocker : 해결되지 않으면 프로젝트가 진행될 수 없는 경우
2. Critical : 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우
3. Major : 꼭 개발해야 하는 경우
4. Minor : 개발은 해야 하나 없어도 상관 없는 경우
5. Trivial : 있으나 없으나 크게 상관 없는 경우

릴리즈 버전 정의와 맵핑

릴리즈 : 작동 가능한 서비스 가능한 상태로 만드는 것, 운영 서버로 올리는 것

요즘 애자일 에서는 ‘쇼트 릴리즈’ 방식을 사용하여 짧은 주기로 릴리즈 한다. 보통 이상적인 경우 스프린트 하나가 끝나고 난 후 릴리즈를 하게 된다.

어떠한 기능을 언제 릴리즈 할 것인가를 정의 하는 것을 ‘릴리즈 계획’이라고 하는데 JIRA는 이 기능을 지원하고 있다.

스프린트 계획

스토리 포인트 부여하고 스프린트를 생성하고 기간을 설정한다.

스프린트 시작,진행

작업의 상태 설정

• 코멘트를 이용한 진행 상태 추가
• 해당 이슈를 해결하는데 필요한 내용이나 무슨 일을 했는지에 대한 로그를 남기는 것으로 커뮤니케이션 용도로 사용한다. (알람-이메일)

Version Control System 연동을 이용한 이슈별 코드 변경 추적 : JIRA는 Git 에 커밋 할 때 해당 이슈에 #을 넣어서 커밋하게 되면 해당 이슈에 관련된 소스코드 변경 부분을 링크로해서 반영 부분을 보여준다.

JIRA의 확장

JIRA는 개인별 혹은 프로젝트별로 대시보드를 구성해서 현황을 쉽게 확인 할 수 있다.

1. 사용자별 이슈 할당 현황 : 팀원별로 할당된 이슈의 수를 모니터링 하여 적절하게 이슈를 분산해서 배치할 수 있다.
2. Block, Critical, Major 이슈 개수 : 중요도가 높은 이슈들은 항상 모니터링하는 것이 좋다.
3. 신규생성 대 해결되는 이슈 그래프 : 스프린트 끝으로 갈수록 이슈가 생성되는 그래프를 해결되는 이슈 그래프가 쫒아가야한다.
4. 나에게 할당된 이슈
5. 내가 모니터링하고 있는 이슈
6. 다른 프로젝트의 진척 상황 : 프로젝트 매니저의 경우 여러개의 프로젝트의 진척사항을 모니터링 하는것이 좋다.

모바일 클라이언트 : 모바일을 통한 JIRA의 사용 (코멘트, 위치 서비스)