2장 태스크 관리

1. 태스크 정의와 우선순위 결정

1.1 우선순위 결정

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

우선순위를 정할 때는 두 가지 요소를 고민해야 하는데 긴급도(Severity)와 난도(Difficulty)이다.

• 긴급도는 우선으로 구현해야 하는 기능들이다. 난도가 높지 않더라도 필수적으로 필요한 기능들이다.

• 난도는 개발의 난도를 뜻한다.

개발의 우선순위는 긴급도가 높은 것을 우선으로 하되, 그 중 난도가 높은 것을 우선하여 수행한다.

1.2 선행개발

선행개발이란 해당 기능에 대해 적용 가능한 기술들을 찾고 검토해서, 시험 코드를 만들어보고 테스트를 거쳐서 개발에 대한 확신을 한 후에 개발을 착수하는 방법이다.

선행 개발의 방법

• PoC (Proof of Concept: 콘셉트 검증) : 업체로부터 제안받은 기술이나 솔루션이 제대로 요구 사항에 맞게 작동하는지, 어떤 아키텍쳐를 사용할지 사전 검증하는 방법

• BMT (Benchmark Test: 벤치마크 테스트) : 기술이 검증된 상태에서 여러 제안된 솔루션을 비교 검토하는 과정

• 선행개발팀 운영 : 1~2 스프린트에 앞서 기술을 검토하고 프로토타이핑 후에 개발팀의 기술이전과 기술지원

2. 엑셀을 이용한 태스크 관리 방법

스크럼 방법론을 적용하기 위해 JIRA와 같은 이슈 추적 시스템을 이용할 수 있지만 프로젝트에 따라서 도입이 어렵거나, 별도의 프로세스 정립이나 학습 곡선이 필요한 경우가 있기 때문에, 떄에 따라서 엑셀 기반의 태스크 관리가 효율 적일 수 있다.

엑셀 항목에 다음과 같은 항목을 정한다.

[ 태스크#, 카테고리, 서브 태스크, 태스크 상세, 담당자, 우선순위, 종료일, 상태 ]

2.1 프로세스

1. 해야 할 태스크 리스트를 정하고 이터레이션 기간을 정한다. (설계:구현:테스트의 비율이 1:1:1이 되도록 한다.)

2. PM은 스케줄을 가지고 이터레이션 기간에 맞출 수 있는 지 체크하고 일정과 리소스를 관리한다.

3. 매일 태스크 리스트를 업데이트하여 스케줄 상에 발생할 수 있는 리스크를 관리한다.

3. 태스크의 상하구조

3.1 요구 사항 저장

변경된 요구 사항을 항상 일관되게 관리하기 위해 문서를 온라인에 저장해놓고 공유하는 방법이 있다. 이때 노션과 같은 문서 협업 툴이나 위키를 사용한다.

3.2 요구 사항 변경 협의

고객과의 협의를 통해 요구 사항이 변경될 경우, 변경에 대한 근거 자료는 회의록(Meeting Minutes)이다. 회의록을 정리하고, 회의록에서 나온 액션 아이템을 다시 요구 사항이나 태스크로 만들어서 반영해야 한다.

회의록은 요구 사항을 저장하는 wiki와 함께 사용하면 효과적이고, 회의록이 영향을 주는 태스크나 요구 사항에 대해서 링크를 걸어 추적성을 제공할 수 있다.

3.3 요구 사항의 상세화

분석 단계에서 추출된 요구 사항은 실제 구현을 위해 상세화되어야 한다. 요구사항 정의서(SRS)와 기술요구사항 정의서(TRS) 같은 기술 요구 사항으로 변경되는 과정에서 상세화될 수 있다.

위키에 정의된 요구 사항을 Requirement라고 정의한다면, 상세화된 요구 사항을 Sub-Requirement(하위 요구 사항)라고 정의한다. 이 둘 간에 상하 계층 연결 관계를 갖도록 하여 추적성을 제공해야 한다.

3.4 태스크의 종류

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

• 작업 아이템(Working Item) : 일반적인 작업으로, 디자인 및 구현, 디버깅 작업등이 해당한다.

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

• 테스트

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

순서를 보면 먼저 요구 사항을 정의한 후에 스프린트 일정을 잡은 후 요구 사항을 각 스프린트에 분리해서 배치한다. 스프린트에 들어가기 전 요구 사항들을 상세화해서 태스크로 나누고 각 태스크를 개발자에게 배치한다. 각 개발자는 일정을 배치한다. 태스크는 1~2일 단위로 처리할 수 있는 분량으로 나누는 것이 좋다.

4. 태스크 관리 도구

4.1 왜 도구를 사용하는가?

도구를 사용하면 위치적으로 멀리 떨어진 사람도 쉽게 공유 가능하고 검색 등을 이용해 지난 이슈에 대한 내용 추적이 용이 하며 업무 프로세스에 맞춰서 플로 등을 커스터마이징할 수도 있다.

4.2 도구 선택 시 고려사항

1. 워크플로 사용자 정의(Workflow Customization) [필수]

워크플로는 각 개발 조직의 업무 프로세스에 의해서 다시 정의되기 때문에 반드시 워크플로를 커스터마이징 할 수 있어야 한다.

2. 계층(Hierachy) [필수]

등록되는 태스크의 종류를 정하고, 이 종류별 상하 또는 평행상의 관계 설정이 가능해야 한다. 계층이 필요한 이유는 추적성을 보장하기 위함이다.

3. 대시보드 [권장]

대시보드는 프로젝트 진행 현황에 대한 요약 표이다. 태스크 관리 도구의 초기화면으로, 스프린트별 진행 현황, 위험 태스크 관리, 번 다운 차트, 스프린트 별 결험 발생 수, 개발자별 태스크 처리량 등을 모니터링할 수 있다.

4. 외부 시스템 연동 [권장]

태스크 관리 시스템은 대부분 외부 다른 개발 환경과 연동하면 시너지 효과를 줄 수 있는데, 주로 연동 대상이 되는 시스템들은 다음과 같다.

• 인증 체계 연동 : 인증 시스템과 연동하면 별도 계정 관리를 하지 않아도 된다.

• 형상 관리 시스템 연동 : 태스크의 내용이 어떻게 구체적으로 반영되었는지를 추적할 수 있다.

• 위키 등 외부 시스템 연동 : 태스크 관리 시스템에만 저장할 수 없는 공통된 문서들을 링크를 통해 태스크와 연결하여 모든 자료를 취합할 수 있다.

5. 리포팅 [권장]

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

4.3 이슈 트랙킹 도구

태스크 기반의 소프트웨어 개발 프로세스 관리를 해주는 도구가 있는데, 이런 도구들을 태스크 관리 시스템(Task Management System) 또는 이슈 트랙킹 시스템(Issue Tracking System)이라고 한다. 클라우드 서비스에는 trello나 JIRA On Demand 서비스가 있고 설치형 오픈소스에는 다음과 같은 것들이 있다.

• Trac : 이슈 관리 + 형상 관리 + Wiki (단일 프로젝트)

• RedMine : 이슈 관리 + 문서 관리 + 형상 관리 + 다수 프로젝트

• JIRA : 이슈 트랙킹 + 다른 시스템과 연동(형상 관리, 위키, 코드 리뷰, 빌드 자동화 등)