실용주의 프로그래머 정리 7

프로젝트 전에

이번 장에서는 프로젝트를 시작하기 전에 준비해야 할 것들에 대해 다루고 있습니다.

36. 요구사항의 구렁텅이

대부분의 클라이언트는 원하는 요구사항을 정확히 표현하지 못합니다. 따라서 우리는 클라이언트의 요구사항으로부터 더 정확한 요구사항을 끄집어내야 합니다. 요구사항을 정확하게 뽑아내기 위해서는 사용자가 어떻게 사용하는지에 집중하기 보다는 왜 필요한지 파악하는 것이 더 중요합니다. 요구사항의 핵심적인 내용을 파악해야 추후 요구사항의 변경이 생겼을 때 좀 더 유연하게 대처할 수 있습니다.

요구사항을 깊이있게 파악하기 위해 가장 좋은 방법은 사용자가 직접 되는 것입니다. 실제로 사용자와 함께 출근해서 일해보고 도메인을 파악해보면 좀 더 핵심적인 요구사항을 파악할 수 있습니다.

요구사항의 핵심을 파악하고 나면 문서화를 해야하는데 이때는 사용자를 포함 시킨 유스 케이스를 작성해서 표현하는 것이 좋습니다. 그렇지만 너무 상세하게 작성하는 것은 좋지 않습니다. 좋은 요구사항 문서는 추상적이지만 명확하게 작성해야 합니다. 변경될 수 있는 정책은 추상화 속에 감추고 핵심적인 부분은 명확하게 표현하는 것이 좋습니다.

조금씩 요구사항이 추가되는 것을 막기 위해 요구사항에 대한 다양한 기록을 추가해보세요. 누가 이 기능을 요구했고 이 요구사항을 개발하는데 얼마나 걸렸는지 등 요구사항에 대한 기록을 추가하면 슬금슬금 요구사항이 추가되는 것을 막을 수 있습니다.

마지막으로 공통 용어 사전을 만들고 관리해야 합니다. 같은 의미를 표현하는 여러 용어가 있으면 커뮤니케이션이 복잡해지고 요구사항을 잘못 이해하는 경우도 생깁니다.

37. 불가능한 퍼즐 풀기

불가능해보이는 문제를 대할 때는 자유의 정도와 애매한 제약 조건을 정확하게 분석하면 문제를 푸는데 큰 도움이 됩니다. 제약 조건의 틀을 파악하는 것만으로도 해결 방안이 나오는 경우도 있습니다. 가장 중요한건 진짜 제약 조건과 헷갈리게 하는 제약 조건을 구별하는 것입니다.

그럼에도 문제가 계속 풀리지 않는다면 한 걸음 물러서서 다음 질문에 대해 답을 찾아봅시다.

• 더 쉬운 방법이 있을까?
• 이게 진짜 중요한 문제인가?
• 왜 이게 문제인가?
• 뭐 때문에 문제가 어려울까?
• 반드시 이렇게 해야할까?
• 반드시 해야하나?

이 질문들에 답을 찾다보면 갑자기 깨달음을 얻는 경우가 많습니다.

38. 준비가 되어야만

대부분 사람들이 일의 시작을 미룹니다. 이 때 일을 시작하기 애매해서 기다리는건지 단지 늑장부리는건지 구분할 필요가 있습니다. 이럴 때 좋은 방법은 프로토타이핑을 해보는 것입니다. 가장 어려울 것 같은 부분을 찾아서 프로토타이핑 해보고 만약 큰 문제가 없고 의미없게 느껴진다면 바로 개발을 시작하면 됩니다. 어쩌면 프로토타이핑 중에 전제 조건이 잘못됐다는 것을 파악할 수 도 있습니다. 이는 불필요한 업무 진행을 막아줄 수 있습니다.

39. 명세의 함정

프로그램 명세화는 요구사항 분석 이후에 개발할 시점까지 작성하는 과정인데 유지보수하기 위한 기록으로 사용할 수 있습니다. 하지만 너무 상세한 명세는 별로 도움이 되지 않습니다. 이해할 수 있게 작성하기는 쉽지 않고 너무 상세한 명세 때문에 개발을 할 때 더 좋은 방법이 있는데 놓칠 가능성도 있습니다. 요구사항 -> 명세 -> 개발을 구분하지 말고 심리스하게 다루도록 합시다. 개발을 하다가 다시 요구사항으로 돌아갈 수 있고 명세가 수정 될 수도 있습니다. 명세에 너무 의존하지 말고 개발하는 과정이라고 생각합시다.

40. 동그라미와 화살표

형식적인 방법론에 집착하지 말고 유연하게 사용하는 것이 좋습니다. 각 방법론들은 특정 상황에 적합한 경우가 많아서 우리가 진행하는 프로젝트에 딱 들어맞는 경우는 별로 없습니다. 따라서 방법론들을 비판적인 시각으로 잘 바라보고 필요한 부분들만 잘 뽑아서 사용하세요. 방법론의 노예가 되지말고 사용자가 돼야 합니다. 방법론은 정답이 아니고 특정 상황에 맞는 도구일 뿐입니다.