Study Note

태스크 본문

아키텍처/소프트웨어 개발과 테스트

태스크

moreLearn 2020. 2. 18. 11:27

태스크란 상세 요구 사항을 구현하기 위해 디자인, 문서 작성, 코딩, 테스트 과정에서 발견된 버그들을 처리하는 행위를 태스크라고 한다.

  • 태스크는 1~2일 단위로 처리할 수 있도록 분리한다.
  • 요구사항 ~ 태스크까지 계층 구조를 갖는 연결성을 부여한다.
  • 개발 프로세스에 맞는 태스크 종류를 정의한다.

태스크의 종류

  • 작업 아이템 (Working Item)
    디자인, 구현, 디버깅 작업등에 해당한다.
  • 문서화 (Documentation)
    산출물/매뉴얼을 작성하는 문서화 작업이다.
  • 테스트 (Test)
    태스크를 테스트한다. 코딩에서 테스트 작업, 문서화에선 리뷰를 통한 테스트 이다.
  • 버그 (Bug)
    테스트 과정에서 생긴 버그에 해당하며, 추적성을 부여하기 위해 서브 요구 사항과 연결한다.

 

우선순위 결정

보통 1달 주기의 스프린트에서 처리해야할 작업인 태스크에 우선순위를 결정해야 한다. 기본 원칙은 다음과 같다.

“[기본 기능]을 먼저 개발하지만, 개발 [난도]가 높은 것을 우선으로 한다.”

  • 기본 기능
    대부분 구조와 뼈대가 되는 아키택처와 연관되어 있다. 때문에 우선 순위가 높다.
  • 난도
    난도가 높은 경우 실패 가능성이 많기 때문에 먼저 개발하여 시행착오를 초기에 겪고 문제 해결의 시간을 벌기 위해 우선 순윈가 높다.

개발의 경우에는 고려할 2가지 요소는 긴급도 (Severity), 우선순위 (Priority) or 난도 (Difficulty)인다.

“[긴급도]가 높을 것을 우선으로 하며, 그 중 개발 [난도/우선순위] 가 높은 것을 우선으로 한다.”

 

선행 개발

난도가 높은 태스크의 경우 기간 내에 개발하기 어려울 수 있다. 이때 [선행개발/탐색 개발] 방법을 사용하여 개발 전에 공부하고 테스트를 해본다.

프로젝트 시작전 기술 탐색 개발을 하는 방법

내부 개발팀이나 자체적으로 솔류션을 개발하는 경우

  • 프로젝트 시작 전에 개발인원이 확보 되어 있으면 프로젝트 시작 전에 탐색 개발을 하는것이 유리하다.
  • 개발 인원들이 기술을 습득하고 내재화할 수 있는 기간을 확보할 수 있다.

내부 개발인원을 확보하지 못한 경우

  • PoC (Proof of Conect : 콘셉트 검증)
    업체로부터 제안받은 기술이나 솔루션을 아키텍처와 요구사항에 맞는 작동 여부를 사전 검증하는 방법이다. 선행 개발과 유사한 효과를 발생한다.
  • BMT (Beanchmark Test : 벤치마크 테스트)
    기술이 검증된 상태에서 여러 제안된 솔루션을 비교 검토하는 과정이다. 최적화된 선행 개발 효과를 낼 수 있다.
조직적으로 별도의 선행 개발팀을 운영하는 방법
  • 선행 개발팀은 1~2 스프린트에 앞서서 기술을 검토하고 프로토타이핑 후에 샘플 코드를 개발팀에 전달한다.
  • 개발 요구 사항 변화에 바로 대응하는 선행 개발을 할 수 있다.
  • 팀 내에 속해 있기 때문에 기술이전과 지속적인 기술 지원이 가능하다.

엑셀을 이용한 태스크 관리

프로젝트의 이슈 추적 시스템의 도입이 어렵거나, 별도 프로세스 정립, 학습 곡선이 필요한 경우 엑셀 기반 태스크 관리가 효율적일 수 있다. 각 태스크는 1 ~ 3일 정도로 지정해야 관리가 제대로 된다.

엑셀에서의 각 항목들이다.

  1. 태스크 # : 태스크의 번호이다.
  2. 카테고리 : 태스크의 종류로 디자인, 분석과 같은 단계일수도 있고, 로그처리, 에러 핸들링같은 패키지일 수 있다.
  3. 서브 태스크 : 태스크들을 나눠서 정의한 부분이다. 독립된 기능으로 나누는 것이 좋다.
  4. 태스크 상세 : 태스크의 상세 내용이다.
  5. 담당자 : 작업 지정된 사람이다.
  6. 우선순위 : 중요도를 지정한다.
  7. 종료일 : 작업 예상 종요일을 지정한다.
  8. 상태 : [신규/할당됨/진행 중/연기됨/종료]를 설정한다.

프로세스

스크럼 방법론에서 기본적으로 태스크 리스트를 정하고 이터레이션 기간을 정한다. 태스크 리스트는 프로젝트 매니저가, 세세한 태스크는 구성원이 직접 작성한다.

태스크 시간 예측

  • 각 팀원의 가동률을 80%로 잡는다. 항상 100% 근처이기 때문에 낭비되지 않는다.
  • 모듈 개발시 설계:구현:테스트의 기간이 1:1:1의 비율을 갖는다.

프로젝트 매니저

  • 구성원의 스케줄로 이터레이션 기간에 맞출수 있는지 체크
  • 태스크가 일정 내에 끝나지 못할경우 우선순위에 따라 다음 이터레이션으로 넘기거나 개발자를 더 할당

매일 10~20분 정도 모이는 스크럼 미팅에서 팀원 스캐줄과 문제 사항을 채크하고 도움을 주고 받을 사항을 예기하며 매일 태스크 리스트를 업데이트하고 스캐줄에서 발생 가능한 리스크를 관리한다.

 

이 글은 저: 조대협님의 "대용량 아키텍처와 성능 튜닝"을 읽고 공부한 내용입니다.

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

 

2020/02/18 - [아키텍처/소프트웨어 개발과 테스트] - 태스크와 요구사항

 

태스크와 요구사항

요구 사항 저장 요구 사항이 지족성으로 변경된다. 변경된 요구 사항을 일관된 하나의 문서로 관리한다. 만약 그렇지 않고 워드, 파워포인트 같은 문서로 저장하면 요구 사항이 변경될때 마다 문서를 수정하고 재..

more-learn.tistory.com

2020/02/18 - [아키텍처/소프트웨어 개발과 테스트] - 태스크 관리 도구

 

태스크 관리 도구

도구를 사용하는 이유 멀리 떨어져 있어도 쉽게 공유가 가능하다. 검색 등을 이용하여 지난 이슈애 대한 내용 추적이 좋다. 업무 프로세스에 맞춰 플로 등을 커스터 마이징 할 수 있다. 다음과 같이 태스크 관리에..

more-learn.tistory.com

 

'아키텍처 > 소프트웨어 개발과 테스트' 카테고리의 다른 글

Technical Debt  (0) 2020.02.18
태스크 관리 도구  (0) 2020.02.18
태스크와 요구사항  (0) 2020.02.18