커뮤니케이션
잘못된 커뮤니케이션은 프로젝트를 실패로 인도하는 최대의 위험요소이다
이러한 문제점을 해결하기 위해서 비즈니스 분석가들의 요구사항 정의를 개발자들이 명확하게 이해하고 있어야 한다. 또한 요구사항을 정의할 때 분석가들과 개발자들간의 요구사항의 기술적 위험성을 발견하기 위한 엄격한 논쟁이 필요하다. 이를 위하여 무엇보다도 명확한 가치체인이 형성되어 있어야 하며 모든 참여자들은 가치체인을 정확하게 알고 있어야 한다. 또한 많은 사람들이 쉽게 이해할 수 있도록 반드시 기술적이지 않는 방식으로 기술되어야 한다.
가치있는 요구사항
비즈니스 또는 상품에 직접적인 가치를 더할 수 있어야 한다. PULL 이론이 말하고 있는 것과 같이 고객이 원하지 않는 요구사항은 분석되거나 개발되는 낭비가 발생되어서는 안 된다는 것이다. 이러한 접근법은 과도한 요구사항 정의를 억제하는 동시에 빠르게 변화하는 고객의 요구사항에 유연하게 대처할 수 있게 한다.
결과적으로
- 고객에 의하여 사용되지 않는 기능,
- 정말로 필요하지 않는 기능,
- 실재 비즈니스에 가치를 더하지 않는 기능
요구사항 기반의 소프트웨어 평준화
반복적 점증적 개발방법을 적용하는 경우 기민하게 변화하는 고객의 요구사항을
수용할 수 있도록 요구사항의 내용에 따라 약 6주 ~ 8주
간격의 반복 개발 주기를 준수한다. 기본적으로는 6주를 기준으로
하며 요구사항의 난이도에 따라 최대 8주 동안 개발을 진행한다.
단일 Iteration 에서
개발 가능한 User Case 시나리오들을 선택할 때는 각 시나리오들의 가치에 따라 구분하여 선택하여
높은 가치의 요구사항들이 먼저 개발될 수 있도록 한다.
이력관리
위에서 요구사항은 반드시 상품에 직접적인 가치를 더할 수 있는 것이어야 한다고 정의하였다. 이력추적관리란 요구사항에서부터 시작하여 최종 제품이 만들어지는 전체활동을 추적이 가능하도록 지속적으로 이력을
관리한다는 것을 의미한다. 다르게 이야기하면 가치의 흐름을 관리하자는 것과 동일한 의미이다.
요구사항 이력관리는 왜 필요할까? 요구사항 이력관리 다음의 두 가지
목적이 있다.
- 품질보증: 고객이 (또는 비즈니스 설계자가) 요청한 모든 기능을 보유하고 있는 제품임을 증명함으로써 올바른 제품을 만들었음을 보장할 수 있다.
- 변경 영향도 분석: 영향을 받는 모든 요구사항, 디자인, 그리고 구현 소스를 확인하여 요구사항 변경에 따른 영향 분석을 도와준다.
또한 추가적으로
- 구현된 요구사항 비율
- 전체 성공적으로 구현된 요구사항 비율
참고자료
댓글 없음:
댓글 쓰기