① 사용자 요구조건 조사

사용자 요구조건 조사

조사 단계는 시스템의 모습과 임무를 파악하는 단계이다. 이 단계에서 고객은 시스템의 목표 기술문(vision statement) 작성을 담당한다. 목표 기술문은 20~30 단어 정도로 구성되며 전체적인 시스템 메타포의 개발을 이끌 수 있어야 한다. 고개과 개발자는 이 단계에서 함께 일하면서 기술적 옵션, 요구 사항 분석을 조사하며 유저 스토리의 목록을 완성한다.

목표 기술문은 시스템의 목적을 기술하는 추상적인 문장이다. '이 시스템의 목적은 인터넷을 통해 서적을 판매하는 것이다' 와 같은 것이 그 예이다.

시스템 메타포는 팀에서 시스템을 개념화하는 방식이며 보통 비즈니스 분야의 말들로 쓰여진다. "고객이 들어와서 열람, 검색하고 책을 살 수 있는 가상의 서점" 같은 것이 그 예이다.

유저 스토리는 사용자의 요구 사항을 이해하는 하나의 도구이다. 유저 스토리는 사용 실례 같은 것과 비슷하며, 고객에 의해서 비전문적인 용어로 쓰여진다. 보통의 유저 스토리는 3~4 문장 정도의 길이이다.

유저 스토리 작성하기

프로젝트 시작 단계에서 고객은 중요하고 유저 추상적인 유저 스토리를 작성하고 개발자는 해당되는 개발에 필요한 시간을 추정해 본다. 물론 고객과 개발자 서로가 이 상태에서늬 예측은 상당히 추상적인 것이며 앞으로 개발이 진행되면서 이터레이션 단계에서 상세화될 것이라는 생각을 갖고 있다. 어떤 경우에는 개발자들이 좀 더 자세한 예측을 위해서 스파이킹(spiking - 프로토타이핑이나 기술적 연구)을 하는 경우도 있다. 기술 전문가나 컨설턴트가 추상적 수준에서의 타당성 검토나 관련 연구를 도울 수도 있다. 스파이킹은 단순하지만 개발에 필요한 노력과 방법론을 이해하는 데 커다란 도움이 된다.

스파이킹은 프로토타입을 만들면서 조사하는 것이다. 스파이킹은 일반적인 기술 연구에 시간을 들인다기보다는 특정 목적을 갖고 이루어진다.

스파이킹이 끝나면 개발팀이 그에 대한 지식을 얻게 되는 것이고 스파이킹에 사용된 코드는 버려진다. 스파이킹은 수시간에 이루어질 수도 있지만 보통의 경우에는 수일이 걸리게 된다. 작업이 진전되면서 어려운 문제에 대한 스파이킹을 포기하는 경우도 생기는데 이것은 일반적인 상황은 아니다.

스파이킹 기간에 작성된 코드는 보통 재사용할 만큼 품질이 좋지 못해서 버려지는 것이 일반적이다. 스파이킹을 할 때 개발자는 연구의 일환으로 코드를 작성하는 것이지 특정 디자인에 입각해서 짜는 것이 아니기 때문이다.

추정과 발견(Estimating and Discovering)

조사의 단계는 대부분 발견에 관한 것이다. 고객은 그들이 원하는 것은 발견해가고 개발자는 그들의 문제에 대한 접근 방식을 발견해 가면서 또 스파이킹을 통해서 추정을 해나간다. 스파이킹을 하는 데 필요한 시간을 추정하고 실제 드는 시간과 비교하는 것만으로 간단하게 처리된다. 이렇게 해서 조사 단계에서는 개발팀이 좀더 정밀한 추정 기술을 습득하게 하는 장점도 갖게 된다. 이런 기술은 이후 이터레이션 계획이 시작해지면 아주 중요해진다.