소프트웨어 개발과 테스트 - 애자일 개발 방법론과 태스크 관리

 

소프트웨어 개발과 테스트 국내도서 저자 : 조대협 출판 : 프리렉 2015.01.15 상세보기

◎ 폭포수 모델 : 소프트웨어 개발생명주기(SDLC : Software Development Life Cycle)에 기반하고 있는 소프트웨어 개발 기법으로, 워터폴 모델·폭포수 모형·선형순차 모형·단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다. 

◎ 제품 오너 : 제품 오너는 요구사항을 정의하고, 제품 백로그를 업데이트 하는 역할을 맡고 있다. 가장 중요한 역할은 제품 백로그 내의 항목에 대한 우선순위를 조정하는 역할을 수행한다. 

◎ 릴리즈 계획 : 해야 할 일의 목록인 제품 백로그가 정의 되었으면, 언제 어떤 일을 해야 할 지를 정의해야 한다. 일반적으로 말하는 스케줄링인데, 릴리즈 계획에서는 프로젝트의 큰 마일스톤을 정하는 작업을 한다. 

◎ 대시보드 : 대시보드는 프로젝트 진행 현황에 대한 요약 표이다. 태스크 관리 도구의 초기화면으로, 진행 상황, 위험요소, 팀원들의 개별 워크플로들을 모니터링 할 수 있다. 

◎ 리포팅 : 리포팅 기능은 개발자별 이슈 현안, 번 다운 차트, 전체 개발팀의 중요 아이템 등 여러 가지 조건에 따라서 질의한 결과를 엑셀이나 다른 형태의 리포트로 출력할 수 있게 해주는 기능이다.

◎ 소프트웨어 개발은 사람이 하는 일이다. 하나의 소프트웨어를 개발하기 위해서는 요구 사항을 분석해서 디자인하고, 이 디자인을 나눠서 개발자들이 각자 개발을 진행한다. 개발된 컴포넌트는 테스트되고 마지막에는 서로 합쳐져서 하나의 유기적인 시스템을 이룬다. 이러한 개발 과정을 '개발 프로세스'라고 하고 여기에 조직 구조와 도구 셋을 포함하여 개발 방법론이라고 정의한다. 

◎ 실용주의 방법론에서 소프트웨어 개발 프로세스는 애자일을 바탕으로 구성되는데, 애자일 방법론은 요즘 들어 가장 인기 있고 가벼운 방법론 중의 하나다. 이 방법론의 특징은 구성원간의 협업을 중요시하는 사상을 가지고 있다. 

◎ 제품 오너는 요구 사항을 정의하고, 제품 백로그를 업데이트 하는 역할을 맡고 있다. 가장 중요한 역할은 제품 백로그 내의 항목에 대한 우선순위를 조정하는 역할을 수행한다. 제품 오너는 직접 스프린트에 참여하며, 비즈니스 쪽 등과 지속적으로 의사소통을 하면서, 계속해서 불명확한 요구 사항을 구체화하고 기능의 우선순위를 조정해서 팀에게 명확한 제품의 방향성과 기능을 제시해준다. 

◎ 스크럼 마스터는 일종의 개발 PL 이라고 보면 된다. 해당 프로젝트에 대한 일정과 태스크를 조율하는 역할을 수행한다. 일정을 정의하고 관리하는 것보다는 정해진 일정에 따라서 개발을 수행 리드하는 역할에 가깝다. 스크럼 마스터는 프로젝트를 관리하는 역할 이외에도 스크럼 방법론을 팀에 전파하고 적용하는 책임을 갖는다. 이를 코칭이라고 하는데, 코칭은 교육과 성격이 다르다. 교육이 교육장에서 일주일 정도 강의를 듣는 것이라면, 코칭은 일종의 실무 교육과 같은 의미를 갖는다. 

◎ 전통적인 스크럼 방법론에서는 기능에 대한 항목은 제품 오너가 하지만 이를 세부 태스크로 나누는 과정을 개발팀이 함께 수행하는 경우가 많다. 엔터프라이즈 개발을 위한 스크럼 방법론은 프로젝트 관리 차원을 강조한 방법론이기 때문에, 개발팀 내의 자유로운 접근보다는 관리 측면에서 리드가 백로그 항목의 정의와 태스크 관리를 하도록 한다. 

◎ 태스크를 정의하는 데 가이드를 제시하면, 제품 백로그 항목은 분석/설계, 구현, 테스트 이 3가지로 크게 분리될 수 있다. 어떤 구현 테스트를 하기 위해서 요건에 대한 분석 및 설계가 필요하다. 비록 미리 다 설계가 되어있는 부분이라도, 실제 구현에 있어서는 국지적인 설계 변경이 필요하거나, 프로토타이핑들이 필요하기 때문에 분석/설계에 대한 시간은 소요된다. 

◎ 일일 스크럼은 일일 오전 업무 공유 시간이다. 스크럼에서 가장 유용하고 중요한 기법의 하나다. 스크럼 팀은 매일 오전에 같은 자리에 모여서 어제 자신이 한일과 오늘 자신이 해야 할 일을 짧게 발표한다. 전체 시간은 30분을 넘지 않도록 한다. 이와 함께 자신이 진행해야 하는 태스크를 종료하는 데 필요한 시간을 같이 이야기 한다. 

◎ 스프린트가 종료된 후에는 스프린트에서 구현된 산출물을 리뷰하는 단계가 필요하다. 요건에 따라 적절하게 구현이 되었는지 품질은 만족해야 했는지 등의 검증이 필요하다. 단순히 스프린트에서 무엇 무엇을 했고, 잘했다 안됐다가 아니라, 실제 구현 코드, 산출 문서, 테스트 결과 등의 구체적인 자산을 가지고 리뷰를 수행해야 한다. 

이 과정에서는 고객을 참여시켜서 자산에 대해서 간략한 데모를 고객에게 수행한다. 이 데모는 고객 보고를 위해서 별도의 PPT나 데모를 준비하는 것이 아닌 비정규적인 리뷰이다. 정규적인 리뷰는 릴리즈 시기별로 진행하도록 하고, 스프린트 리뷰 준비를 위해서 별도의 시간이나 리소스를 낭비하지 않도록 한다. 

◎ 스크럼 방법론을 적용할 때 중요한 점 중의 하나가 각 스프린트에 처리할 작업의 우선순위를 결정하는 것이다. 다른 시스템 개발에 대한 종속성이 있을 때는 당연히 선행 개발해야 하는 것이 맞겠지만, 이 우선순위 결정은 개발된 시스템의 전체적인 품질에 큰 영향을 미치게 된다. 

◎ 태스크는 몇 가지 종류를 가질 수 있으며, 팀의 프로젝트 관리 방안에 따라서 재정의되어야 한다. 몇 가지 예를 들어보면 다음과 같다.

- 작업 아이템 : 작업 아이템은 일반적인 작업으로 디자인 및 구현, 디버깅 작업 등이 여기에 해당한다. 

- 문서화 : 문서화 작업으로 산출물이나 매뉴얼을 작성하는 태스크이다. 

- 테스트 : 해당 태스크에 대한 테스트이다.

- 버그 : 테스트 과정에서 버그가 발생하였을 경우, 추적성을 부여하기 위해서 버그를 서브 요구사항과 연결한다.