[북리뷰] 소프트웨어 개발과 테스트

 

 

소프트웨어 개발과 테스트

조대협지음, 프리렉, 2015

 

소프트웨어 개발 방법에 관해 그동안 읽었던 책들을 나열해 보자면, <애자일 프랙티스>, <애자일 회고>, <스크럼>, <사용자 스토리> 등이 되겠다. 이 책도 애자일 방법론을 소개하는데, 그런 방법들에 더해 테스트 툴, 성능관리 툴 등과 접목하여 효과적으로 성공적 프로젝트를 운용하도록 안내하는 책이다. 번역서가 아닌 조대엽님의 쉬운 글과 경험에 의해 도출된 노하우가 배어있다. 한 가지 아쉬운 점은 자바 개발환경에서 이루어져야 한다는 것인데, 공교롭게도 이번 프로젝트는 닷넷이다. 하여 이런 것들이 있구나 하는 선에서 실습없이 만족해야 했다.

 

스크럼 마스터와 제품오너는 성격과 전문성이 각기 다르다. 스크럼 마스터는 일정과 태스크 기반으로 팀을 운용하고 스크럼 방법론을 적용하는데 최적화되어 있는 관리적인 역할이라고 한다면, 제품 오너는 제품 도메인에 대한 전문적인 지식을 가지고, 제품의 기능을 정의하고, 비즈니스 쪽과 조율을 하면서 요구 사항의 구체화와 우선순위 조정을 하는 기획 및 의사소통 역할이 강하다. 그 때문에 가능하다면 스크럼 마스터와 제품 오너는 역할을 분리해서 각기 다른 사람으로 운영하는 것이 좋다.(29)

 

현재 맡고 있는 프로젝트에서 컨설턴트가 하는 역할과 유사한 것 같다. PM과 컨설턴트가 각자의 영역에서 선방하는 것이 보기 좋다. 보통 규모가 작은 프로젝트라면 언감생심.

 

 

 

단순히 스프린트에서 무엇 무엇을 했고, 잘됐다 안됐다가 아니라, 실제 구현 코드, 산출 문서, 테스트 결과 등의 구체적인 정보를 가지고 리뷰를 수행해야 한다. (45)

 

매일 아침마다 개발 현황을 나누는 회의를 진행중이다. 이것은 스크럼 개발방법론과 일치한다. 그런데 여기서는 좀더 구체적인 리뷰 수행을 요구하는데, 현실에선 녹녹치 않다. 

 

스프린트가 종료되고 모든 작업이 끝나면, 팀에서 운영 중인 방법론 자체에 대한 리뷰가 필요하다. 팀에서 운영 중인 태스크 관리 시스템(Task Management Process)은 처음에 세트업되면 많은 시행착오를 겪게 된다. 수행 시간 예측이나 스프린트 주기 설정, 태스크 관리 프로세스 등 많은 과제가 있는데, 스프린트의 경험을 기반으로 회고를 수행함으로써 프로세스를 발전시킬 수 있는 방향을 찾을 수 있다. (47)

 

보통 1,2 차 테스트 후에 집에 그냥 가기 마련이고, 바로 다음 차수 테스트를 준비하기 마련인데, 이런 시간을 갖는 것은 중요할 것이라고 본다.

 

가장 기본적인 원칙은 "기본 기능을 먼저 개발하되, 개발 난도가 높은 것을 우선으로 한다."이다. 기본 기능은 대부분 전체적인 구조의 뼈대가 되는 아키텍처와 연관되어 있는 경우가 많고 난도가 높은 부분의 경우, 구현의 실패 가능성이 많기 때문에 이러한 부분을 먼저 개발해서 시행착오를 초기에 겪고 나중에 문제를 해결할 시간을 벌기 위해서이다. (49)

 

현재 진행하고 있는 프로젝트의 폐착이라면 바로 이 순서를 지키지 못한 부분이랄 것이다. 쉬운 것 먼저 하고, 기한 맞춘다고 기본 외형만 갖추다가 정착 디테일에서 실패..

 

'고객은 자신의 요구 사항을 정확히 정의하지는 못하지만, 반대로 제시된 기능에 대해서 좋다, 나쁘다는 이야기 할 수 있으며, 고객의 요구 사항은 프로젝트 진행 과정 중에서 학습을 통하여 끊임없이 변화한다.' (56)

 

아래의 그래프가 보여주는 이상적인 스프린트 작업 잔여 그래프인데, 하향으로 치달아야 할 그래프가 꼭 오르는 것을 보면, 고객의 학습 결과가 반영된 결과일께다.

 

 

요구사항 정의기법은 스크럼 사용자 스토리나 다른 기법에서도 여러 방법으로 표현하고 있지만, 요약해보면 적절한 요구 사항 정의는 다음과 같다.
- 누가? 왜? 이 행위를 원하는가? - Who & Why
- 이 행위의 결과로 얻을 수 있는 비즈니스 가치는 무엇인가? - What
- 이 비즈니스 가치를 얻으려고 하는 행위가 무엇인가가 명확하게 정의되어야 한다. - How
(57)

 

이런 스크럼 방법론을 통해 각 개발자들의 성과를 한 눈에 볼 수 있도록 하는 툴들이 제공되고 있다고 하는데, 아래의 캡쳐를 보면 개발 상황이 한눈에 확인 되는 모양이 꽤 그럴싸하다.

 

전통적 개발 모델인 폭포수 방법론과 대별되는 각 테스트를 연결지어 보니, V 자가 된다. 인상적인 그림이라 한 컷 잡았다. 한 쪽은 Verification 이고, 다른 한 쪽은 Valiation 이라는 것도 잘 짜놓은 구성이다.

 

 

프로젝트 초기에 개발자들과 오리엔테이션을 가질 기회가 있다. 전체 개발 방향을 정하고, 테스트를 어찌 어찌 한다는 등의 논의를 하게 되는데, 여기서 활용할 수 있는 좋은 도표같아 정리하였다.

 

 

 

초과근무가 절대 프로젝트 품질에 도움이 되지 않는다. 피치 못할 일정 때문에 야근은 분명히 있을수는 있으나 그런 집중 근무 기간이 2주가 넘게 되면 생산성에 심각한 문제가 온다. (112)

 

 

 

이부분은 100%로 공감간다. 해 보니, 번아웃되고 능률도 기하급수로 떨어지는 것을 경험한다.

코드의 복잡도가 높을수록 결함의 발생 확률도 올라간다. 코드의복잡도를 측정하는 방법중 하나가 순환 복잡도(Cyclematic Complexity) 측정이라는 방법이 있다. 순환 복잡도는 (분기 조건의 수 +1)로 계산된다. 즉 if, while, switch, or 연산 등 분기문이 많으면 코드의 복잡도가 높아진다는 이론인데, 분기문이 많으면 실수를 할 확률도 높아진다. 그래서 테스트의 대상을 선정할 때 이 순환 복잡도가 높은 코드를 우선순위를 높게 높게 하면 상대적으로 잘 찾아낼 수 있다. (169)

 

코드 난도를 계산할 때 분기문으로 확인하는 것은 좋은 팁이다. 그만큼 많은 테스트가 필요하기 때문이겠다.

 

이렇게 이론적으로 섭렵한 프로젝트 운영 노하우들이 실제에선 얼마나 도움을 받을 수 있을지는 아직까지 미지수다. 현재 진행하는 프로젝트에 모인 인원만 200 여명이다. 우리 팀은 그중 하나의 프로그램을 맡아 10명정도 개발하고 있다. 물론 나의 위치는 DBA, TA 다. 이번 만큼은 PM 아니다. 앞으로도 계속 그렇게 가길 소망하고 있다. 한 발 물러서서 프로젝트를 객관적으로 들여다보는 좋은 계기가 됐고, 이론과 실제를 비교해 볼 수 있는 시간이었다.