7장. 프로젝트 전에
소제목
- 요구사항의 구렁텅이
- 불가능한 퍼즐 풀기
- 준비가 되어야만
- 명세의 함정
- 동그라미와 화살표
프로젝트를 시작 하기 전에 정리해야 할 사항들에 대해 다룬다. 프로젝트 전에 무엇을 해야할까?? 일단 요구사항을 정리해야 한다. 그리고 어떻게 프로젝트를 진행할 것인지에 대한 계획을 세워야한다. 만약 이 두 가지의 작업이 선행되지 않는다면, 프로젝트가 시작하기도 전에 망할 것 같다는 의심이 들고, 이는 실제 결과로 이어질 가능성이 매우 크다.
36. 요구사항의 구렁텅이
요구사항을 수집하기 보다는 채굴할 줄 알아야 한다. 사용자가 말한 요구사항의 핵심이 무엇인지를 파악하고, 이를 구체화하자. 그렇게 하기 위해서는 사용자와 함께 일하면서 지속적인 요구사항 채굴 과정이 필요하다.
아래 두 개의 요구사항 중 어느 것이 더 좋은 요구사항인지 맞춰보자.
- 특정 페이지는 인사과에서만 접근할 수 있도록 구현해주세요.
- 특정 페이지는 권한이 있는 사용자만 접근할 수 있도록 구현해주세요.
뭔가 첫 번째 요구사항이 더 구체적으로 말하는 것 같아 보이고, 그래서 더 좋은 요구사항으로 볼 수도 있다. 하지만 사내 정책이 따라 인사과가 아닌 다른 부서에서도 해당 페이지에 접근할 수 있도록 변경될 가능성이 있기 때문에 아래의 요구사항이 더 좋은 요구사항이다.
만약 첫 번째 요구사항을 가지고 구현을 했다면, 인사과에 대한 내용만 작성할 가능성이 있지만, 두 번째 요구사항으로 구현을 했다면 접근 권한을 체크하는 기능을 만들게 될 것이다.
37. 불가능한 퍼즐 풀기
푸는것이 불가능하다는 문제에 접근했을 때, 아래의 방법으로 접근해보자.
- 틀을 벗어나는 것이 아닌 틀을 찾자.
- 시행착오들을 기록하고, 왜 이런 방법으로 문제가 풀리지 않았는지 설명하라.
- 왜 이것이 문제인지 생각해보자.
- 문제가 어려운 이유를 설명하라.
- 더 쉬운 방법이 있는지 생각해보자.
38. 준비가 되어야만
빠르게 시작하는 것이 독이 될 수도 있다. 만약 코딩을 하는 중에 마음속에서 '이게 아닌데?' 라는 목소리가 들려오면, 잠깐 멈추고 문제가 될 수 있는 부분을 체크하자.
준비를 하는 좋은 방법 중 하나는 프로토타입을 만드는 것이다. 프로토타입을 제작하면서 설계하면서 생각하지 못했던 문제들을 마주칠 수 있고, 어떻게 진행하는 것이 좋을지에 대한 인사이트도 얻을 수 있다.
39. 명세의 함정
너무 상세한 명세보다 조금은 추상적으로 작성된 명세가 더 좋다. 상세한 명세는 가독성을 떨어뜨릴 수 있다.
40. 동그라미와 화살표
프로젝트에 여러가지 방법이 사용된다. 폭포수 기법, 스크럼, TDD 등과 같은 프로젝트 수행 기법을 사용하는 것은 좋다. 하지만 이를 맹신하는 것은 문제를 유발할 가능성이 있다. 언제나 형식적인 방법에 대해 비판적으로 생각하고, 더 좋은 방법은 없는가에 대해 고민하는 개발자가 실용주의 프로그래머다.
