태스크와 요구사항

요구 사항 저장

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

온라인으로 문서를 저장해서 공유하면 일관된 하나의 문서로 관리된다.

• 공유 파일 저장소 / 마이크로소프트의 셰어포인트 / 위키 등등

그 중 위키 페이지 사용시의 장점이다.

• 요구사항이 변경 될때마다 최신 문서를 볼수 있다.
• 업데이트 내용에 대한 히스토리를 저장해 놓기 때문에 문서 변경 내용도 함깨 관리할 수 있다.

요구 사항 변경 협의

요구 사항이 변경될 경우 근거 자료인 회의록(Meeting Minutes)을 남겨야 한다. 회의록에서 나온 액션 아이템(Action Item)을 요구 사항에 수정하고 태스크로 만들어서 반영한다. 이때 위키 페이지를 사용하여 요구사항과 작성된 태스크에 링크를 걸어 추적성을 제공한다.

요구 사항의 상세화

요구 사항은 실제 구현을 위해 상세화를 해야한다. 비즈니스 입장(SRS : 요구사항 정의서)에서 기술 요구 사항(TRS : 기술요구사항 정의서)으로 변경하는 과정에서 상세화 된다.

위키로 예를 들면 요구 사항을 Requirement로 정의하고, 상세화한 요구사항을 Sub-requirement로 정의한다. 상하 계층 연결 관계를 같도록 하여 추적성을 제공한다.

요구 사항 정의 방법에 대한 변화

기존의 소프트웨서 개발 방법론중 폭포수 모델의 경우 각 단계가 끝나고 다음 단계를 진행 하기 때문에 요구사항 분석단계에서 완벽한 요구사항이 필요하다. 하지만 고객은 새로운 시스템에 대하여 완벽한 요구사항을 정의할 수 없다.

애자일 프로세스는 요구 사항이 완벽하지 않다는 것을 알고 있고, 이를 전재로 해서 변경 가능한 요구 사항을 기반을 개발하는 프로세스 이다.

때문에 관리 관점과 요구 사항을 수집하는 관점에 변화가 필요하다.

“고객이 요구사항을 주는 것”에서 “요구 사항은 고객이 정하는 것이 아닌, 스스로 정하는 것”으로 변화해야 한다.

완벽하지 않는 요구 사항에 대한 행동

• 고객에게 요구사항을 커뮤니케이션을 통해 물어본다.
• 고객의 요구 사항이 확실하지 않다면, 유사 레퍼런스를 통해 요구 사항을 정의하여 고객과 협의한다.
• 요수 사항을 역으로 제안할 때는 프로토타입을 제작하여 커뮤니케이션을 하면 정확한 의사소통이 가능하다.
• 요구 사항을 가정할 때는 고객의 비즈니스 가치를 우선으로 한다.

요구 사항의 정의 기법

• who & why : 누가? 왜? 이 행위를 원하는 것인가?
• what : 이 행위의 결과를 통해 얻을 수 있는 비즈니스 가치는 무엇인가?
• how : 비즈니스 가치를 얻으려고 하는 행위가 무엇인가?

태스크들의 관계

요구 사항, 서브 요구 사항, 태스크들의 관계 이미지 이다.

출처 : 소프트웨어 개발과 테스트 그림 2–2

1. 요구 사항을 정의
2. 스프린트 일정을 잡고 요구사항을 각 스프린트에 분리해서 배치
3. 요구 사항들을 상세화하여 태스크를 나눔
4. 각 태스크에 개발자들을 배치
5. 개발자들은 일정을 배치

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

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

 

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

태스크

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

태스크 관리 도구