[조대협의 소프트웨어 개발]애자일 개발 방법론

하나의 소프트웨어를 개발하기 위해서는 요구사항을 분석해서 디자인하고, 이 디자인을 나눠서 개발자들이 각자 개발을 진행. 개발된 컴포넌트는 테스트되고 마지막에는 서로 합쳐져서 하나의 유기적인 시스템을 이룬다.

이러한 개발 과정을 ‘개발 프로세스’라고 한다. 개발 프로세스에 조직 구조와 도구 셋을 포함하여 개발 방법론이라고 정의한다.

 

실용주의 방법론

• 변화를 수용한다 

 요구 사항 등이 변화 할것을 인정하고 진행하고, 요구 사항 변화를 수용하여 개발 범위를 조정하면서 프로젝트를 진행한다.

• 개발 과정을 짧은 조각으로 나누어서 반복적으로 개발

반복적 개발방법론이라고한다. 소프트웨어 이터레이션이라는 조각으로 나눈 다음에 각 이터레이션 별로 분석-설계-구현- 테스트를 반복 이터레이션이 끝날 때마다 소프트웨어를 릴리즈 한다. 다음 이터레이션부터 제품을 지속적으로 업그레이드하면서 덧붙여 나가는 것으로, 이터레이션을 반복적으로 수행하기 때문에 전 단계의 이터레이션이 끝나면 요구사항을 수정 반영하고 전 단계의 이터레이션에서 배운 내용을 기반으로 프로세스를 끊임없이 성숙시켜 나간다

소프트웨어에 결함이 있음을 전제로 한다.

소프트웨어 개발 과정이 완벽하지 않음을 전제로 하고 개발 과정 중에서 버그가 발생할 수 있음을 가정하고 개발한다.

• 문서 작업을 최소화한다.

형식화된 문서보다는 커뮤니케이션이 원활한 형태의 문서 도구를 사용하고 가능하면 산출물 형태의 문서 작업은 생략한다.

• 협업과 커뮤니케이션에 많은 비중을 할애한다.

애자일 방법론 중의 하나인 XP(Extreme Progamming) 방법론을 보면 고객을 프로젝트 공간에 같이 있도록 한다.

• 자동화 도구를 사용한다.

빌드나 테스트를 통합된 환경에서 자동화한다. 

 

합리적인 방법론은 맞고 개발자에 친숙한 방법론이지만 학문이다. 실용주의 방법론이라고 해서 무조건 쉬운 게 아니며 제대로 익히고 사용하기 위해서는 공부와 노력이 필요하다. 단 제대로 사용할 경우 큰 효과를 기대할 수 있다.

애자일 개발 방법론

 

  실용주의 방법론에서 소프트웨어 개발 프로세스는 애자일을 바탕으로 구성된다. 이 방법론의 특징은 구성원 간의 협업을 중요시하는 사상이다. 애자일 방법론에는 XP, AUP, 스크럼, Lean, 칸반 등 여러 가지 구체적인 방법론이 있다.

 

프로세스 디자인 방향

빅 엄브렐라 방법론 : 조직에서 사용하는 전통적인 개발 프로세스를 사용하여 전체 프로세스를 사용하여 전체 프로세스에 대한 관리성을 확보하고, 단계별 개발은 스크럼 방법론을 적용

 

2. 빅 엄브렐라 방법론의 팀 구조

• 프로젝트 매니저(PM)

전체 프로젝트를 관리하는 역할을 한다. 큰 프로젝트의 경우 PMO나 여러 개발 단위의 프로젝트 매니저를 정의한다. 주로 전통적인 개발 프로세스를 기준으로 프로젝트 관리한다.

• 프로젝트 리더 (PL)

실제 개발팀을 가지고 구현을 리드하는 사람 작은 조직이나 프로젝트에서는 PM이 PL도 하는 경우가 있다.

• 애자일 코치

애자일 방법론 중의 스크럼 방법론의 스크럼 마스터와 같은 역할

 

스크럼 마스터란? 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자는 스프린트 목표와 백로그 등의 결정에 있어 중심이 되는 상위 관리자로, 제품 책임자가 독단적으로 목표를 결정하지 않고, 고객과 관리자 및 팀원들이 모여서 목표를 정한다.

 

실제로 애자일 프로세스를 적용할 때까지는 성숙단계까지 지속적인 관찰과 코칭이 필요하다.

 

스크럼 

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

스크럼(Scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

 

특성

• 솔루션에 포함할 기능/개선점에 대한 우선순위를 부여한다.

• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.

• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.

• 날마다 15분 정도 회의를 가져라.

• 항상 팀 단위로 생각하라.

• 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

전통적인 스크럼 개발 방법론

 

조대협의 소프웨어 개발과 테스트 그림 1-5 스크럼 방법론 개념

 

스크럼은 기본적으로 반복과 점진적 개발 방법에 기초한다.

스크럼 몇 개의 이터레이션으로 구성되는데 이 이터레이션을 스프린트라 부른다.

각 스프린트는 1~4주 정도의 기간을 갖는다. 이 스프린트는 일종의 타임 박스의 개념을 가지며 한번 정해진 스프린트 기간은 변경될 수 없다는 것을 전제로 한다.

 

스크럼에는 고객의 요건으로부터 작성된 제품 백로그가 존재한다.

구현 단계에 스크럼을 적용할 경우에 요구사항 정의서(SRS)이나 기술 요구사항 정의서(TRS)에 정의된 기능이나 구현 요구사항이 제품 백로그의 항목으로 적절하다.

 

스크럼 방법론에서 역할

• 제품 오너

제품 오너는 요구사항을 정의하고 제품 백로그를 업데이트하는 역할

제품 백로그 내의 항목에 대한 우선순위를 조정하는 역할을 한다.

• 스크럼 팀

제품 백로그의 내용에 따라 스프린트를 수행하는 역할

• 스크럼 마스터

프로젝트에 대한 일정과 태스크 조율하는 역할과 스크럼 방법론을 팀에 전파하고 적용하는 책임을 갖는다.

에픽과 사용자 스토리

사용자 스토리는 ‘as a user, ~~‘라는 표현이다. 이러한 사용자 스토리를 큰 단위로 묶어 놓은 것을 에픽이라고 한다. 예를 들면 ‘사진 업로드’, ‘사진 리스트’ 와 같은 큰 기능 단위에 익숙한다. 그래서 사용자 스토리들을 묶어서 에픽 형태로 표현할 수 있다. 에픽은 20~30개 정도가 관리하기 적절하다.

사용자 스토리는 이를 구현하기 위해서 몇 개의 하위 태스크로 나누어진다. 예를 들면 ‘사진 업로드’라고 했을 때  ‘사진 업로드 모듈 개발’, ‘사진을 디스크에 저장하는 모듈 개발’, ‘사진 메타 정보를 데이터베이스를 저장하는 모듈 개발’ 이 될 수 있다.

엔터프라이즈 개발 

엔터프라이즈 소프트웨어 개발에 있어서 적용이 어렵다. 그래서 기존 스크럼 방법론과의 차이를 둔다. 그 차이는 조금 더 관리 지향적인 관점에서 접근하여 프로젝 프로젝트에 대한 진행 상황에 대한 가시성을 확보하는데 목적을 둔다.

 

제품 백로그

실제로 구현되어야 하는 기능 목록을 나열한다. 목록은 요구사항 정의서나 기술 요구사항 정의서로부터 도출된다.

제품 백로그 항목

• 번호(NO)

기능에 대한  ID

• 항목 제목(Item)

구현 요건(기능/비기능)

• 설명(Description)

요건에 대한 간략한 설명

• 예측 소요시간(Estimated Resource)

얼마나 많은 리소스가 소요되는가에 대한 예측치 기록. 스프린트가 종료될 때마다 새롭게 업데이트한다. 스크럼 방법론에서는 스토리 포인트라는 개념을 사용해서 표현한다.

• 요건 설명 링크

백로그의 아이템 이름과 설명만 가지고 정확한 요건을 알 수 없다. 그래서 해당 아이템에 대한 구체적 요건을 알기 위해서 별도의 문서에 기술하여 참고

• 우선순위(Priority)

항목에 대한 우선순위를 지정. 우선순위에 따라서 스프린트를 스케줄링하기 때문에 제품 백로그에서 매우 중요

• 상태(Status)

해당 아이템의 진행 상황을 의미

• 항목에 대한 비즈니스 가치

항목에 대한 비즈니스적인 가치에 대해서 점수를 매기는 방법

 

릴리즈 계획

 

릴리즈 시기마다 작동 가능한 기능들을 릴리즈한다 릴리즈 된 시점에서 QA(Quality Assurance : 품질보증) 팀에서 릴리즈 된 버전 넘겨서 테스트를 수행하고 구현된 기능에 대한 품질을 검증받는다. 이러한 방식은 모든 개발이 끝나고 통합하고 테스트하는 것보다 조기에 버그를 발견할 수 있고 그 버그 해결하는 비용을 줄일 수 있다.

 

스프린트 계획

 

스크럼 방법론에서는 다음과 같은 절차로 스프린트를 계획한다.

• 팀원의 가용시간

• 제품 백로그의 항목을 구체적인 태스크로 분할

• 각 태스크에 대해서 수행 시간을 단축

하지만 세부 태스크로 나누는 과정을 개발팀에 함께 수행하는 경우가 많기 때문에 실제 엔터프라이즈 프로젝트에서는 다음과 같은 방법을 권장한다.

• 제품 백로그의 항목을 구체적인 태스크로 분할

• 각 태스크를 프로젝트 리더인 스크럼 마스터가 적절한 사람에게 배분

• 배분된 사람이 태스크의 수행 시간을 예측하도록 함

 

태스크는 어떤 사람이 무슨 일을 한다는 구체적인 정의가 필요하다. 예시를 들자면 ‘로깅 기능의 설계’를 보면 적절하다고 생각할 수 있지만 로깅 기능 설계 문서 작성인지 로깅 설계 리뷰 회의 인지 종결 조건이 명확하지 않다. 종결 조건을 정의하게 되면 태스크를 관리하기 용이하다.

 

1:1:1 법칙

 

제품 백로그 항목은 분석/설계, 구현, 테스트 3가지로 분류할 수 있다. 일반적으로  분석/설계, 구현, 테스트에 대한 리소스 할당 비율은 1:1:1이 된다.

 

20% 버퍼의 법칙

 

각 태스크에 수행 시간과 담당자를 지정해야 한다. 수행 시간과 담당자는 팀원들과 의사소통으로 정해진다. 그리고 실제 태스크에 대한 시간보다 20% 정도 여유를 두는 게 좋다. 

 

스프린트 관리

 

스프린트 계획이 끝나면 계획에 따라서 프로젝트를 수행하면서 스프린트를 관리해야 한다.

 

일일 스크럼은 오전 업무 공유시간이다. 스크럼에서 가장 유용하고 중요한 기법의 하나이다. 팀원들이 모여서 어제 한일과 오늘 자신이 해야 할 일을 짧게 발표하되 30분을 넘지 않도록 한다. 이 과정에서 팀원은 다른 팀원의 태스크 진행 상황을 공유할 수 있고 만약 일의 진행에서 문제가 되는 부분이 있으면 도움을 받을 수 있다.

 

프로젝트 매니저는 일일 스크럼에서 공유된 일정을 바탕으로 스프린트 백로그의 상세 태스크를 업데이트를 한다. 중요한 점은 각 태스크의 종료 시까지 남은 시간을 반드시 기록한다. 이 데이터는 처음 계획 대비 현재 상황이 어떻게 되고 있는지 판단할 수 있는 지표가 된다.

 

번다운 차트는 백로그를 업데이트하면서 남은 작업 일수를 계산이 가능하다. 이를 그래프로 표현한 것을 번다운 차트라고 한다. 스토리 포인트를 이용해서 번다운 차트를 작성한다.

출처 제타위키

 

 

태스크 상태는 각 태스크에 대해서 상태를 관리한다. 태스크 상태는 태스크의 상태 흐름에 따라 정의되는데 이를 태스크 워크플로라고 한다. 태스크 워크플로는 최대한 단순해야 하며, 관리 지향적이기보다는 실무 중심적이어야 한다.

또한 워크플로가 적용되는 업무의 특성별로 잘 정의되어야 한다.

조대협의 소프웨어 개발과 테스트 그림 1-12 태스크 상태 전이 흐름

태스크 상태 전이 흐름에 따른 설명

 

스프린트 종료는 정해진 기간에 스프린트가 종료되면 스프린트를 정리한다.

스프린트 종료 조건은 팀에 따라 정할 수 있는데 3가지 조건을 많이 사용한다.

• 정해진 시간

• 태스크 종료

• 예산 종료 시까지

어떤 조건을 사용하든 상관은 없으나 명시적인 종료 조건을 정의해야 한다.

 

스프린트 리뷰는 스프린트가 종료된 후에 스프린트에서 구현된 기능을 리뷰 하는 단계이다. 실제 구현 코드, 산출 문서, 테스트 결과 등의 구체적으로 리뷰를 한다. 여기서 고객을 참여시켜서 자산에 대해서 간략한 데모를 고객에게 수행한다. 

 

스프린트가 구현이 된 경우 제대로 되는지 안되는지 확인하기 위해서는 테스트 밖에 없다. 테스팅 구현은 4가지를 권장한다.

• 단위 테스트 : 개발자가 개발 컴포넌트 단위로 테스트 수행

• 회귀 테스트 : 테스트했던 내용을 다음 테스트에도 포함시켜 새로운 코드 추가나 변경이 기존 기능에 영향을 주지 않는지 검증

• 테스트 자동화 : 테스트를 자동화하여 회귀 테스트를 지원하고 테스팅의 효율성을 극대화

• 점진적 통합 : 일일 빌드 등을 통해서 빅뱅 방식의 일시적인 코드 통합이 아닌 점진적 통합 전략을 사용

 

리뷰가 끝났으면 리뷰 과정에서 나온 추가 요건이나 변경 상황을 반영하여 제품 백로그를 업데이트를 해야 한다. 또한 스프린트가 종료되고 모든 작업이 끝나면 팀에서 운영 중인 방법론 자체에 대한 리뷰가 필요하다. 이러한 리뷰는 프로세스를 발전시킬 수 있다.

 

---

이 글은조대협의 소프웨어 개발과 테스트 책을 참고하여 작성되었습니다.

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