1. 요구사항의 구렁텅이
요구사항이 분명한 경우는 많지 않다. 또한 비즈니스 정책이 포함된 요구사항이라면 바뀌기도 쉽다.
따라서 요구사항은 최대한 일반적 진술로 만들고, 정책은 하나의 구현예로, 애플리케이션의 메타데이터로 만들어야 한다.
이렇게 해야 정책이 바뀌어도 메타데이터만 업데이트하면 된다.
그런데 요구사항, 정책, 구현의 구분은 쉽지 않다. 특히 사용자 인터페이스와 관련해서는 더더욱.
사용자가 작업을 어떻게 하느냐는 것보다 왜 하는지를 알아내는 것이 실질적 비즈니스 문제를 해결할 수 있는 길이다.
이를 알아내기 위해서는 직접 사용자가 되어서 또는 사용자와 함께 일함으로써 정보를 얻을 수 있다.
요구사항을 알아냈다면 이를 문서화해야 할 것이다.
문서화를 위해 요구사항을 갈무리하는 방법으로 유스 케이스의 개념을 사용할 수 있다.
유스 케이스는 목적지향성을 강조함으로써 템플릿을 만들어 필요한 사항을 모두 넣어 계층적으로 구조화할 수 있다.
다만 요구사항 문서는 너무 자세할 필요는 없다.
오히려 좋은 요구사항 문서는 추상적이어서 비즈니스에 필요한 사항을 정확히, 간단하게 반영할 수 있는 문서이다.
추상적이어야 요구사항이 오래가고 보편적인 서비스를 제공할 수 있게 된다.
요구사항에 대해 토론을 시작하면 각 분야의 전문가들이 자신에게 의미가 있는 용어들을 사용하게 된다.
같은 의미라도 다른 단어를 사용하고, 이것이 시스템에도 적용되지 않게 하기 위해서는 프로젝트 용어사전을 만들어야 한다.
프로젝트에 참여하는 모든 사람들이 같은 용어사전을 가지고 사용할 수 있도록 해야 한다.
2. 불가능한 퍼즐 풀기
프로젝트를 하다 보면 정말 풀리기는 할까 싶은 문제들이 존재한다.
이럴 때 필요한 것은 생각의 틀을 벗어나는 것이 아니고 틀(제약)이 무엇인지를 찾아야 한다.
가능한 모든 해결 방법을 나열해보고, 왜 안되는지 하나하나 '증명'해 보아야 한다.
가장 구속이 심한 제약을 파악하고 나머지 제약들을 끼워 맞춰야 한다.
생각했던 것보다 어려운 문제를 발견했을 때는 더 쉬운 방법이 있지는 않은지, 문제가 어려운 원인이 무엇인지, 진짜 문제를 풀려고 하고 있는지에 대한 답을 찾다보면 깨달음을 얻을 때가 있다.
필요한 것은 진짜 제약과 오도하는 제약의 차이를 구별하기 위한 지혜이다.
3. 준비가 되어야만
경력을 쌓게 되면 그만큼 경험에서 오는 지혜도 쌓이게 된다.
작업을 시작하기 전 의심스럽거나 꺼림칙하다면 그 느낌을 따르는 것이 좋다.
만약 새로운 프로젝트를 시작하게 된다면, 실질적인 작업을 시작하는 것 자체가 부담스러울 수 있다.
이럴 때는 프로토타이핑을 통해 불안감을 해소하거나 진짜 개발을 시작해도 될지를 정할 수 있다.
4. 명세의 함정
명세는 요구사항을 정리하고 모호함을 제거하며 개발자와 사용자가 모두 보게 되는 문서이다.
그렇기 때문에 무거운 책임이 따르고, 이로 인해 설계자들이 명세서에 지나치게 세부적인 사항까지 명시하도록 만든다.
하지만 이는 오히려 프로젝트의 발목을 잡을 수 있는데, 그 이유는
1. 현실적으로 모든 세부사항을 다 잡아낼 수는 없다. 다 잡아냈다고 생각해도 결국은 새로운 세부사항이 또 생긴다.
2. 자연 언어의 한계로 인해 글로 설명하는 것보다 실제로 하는 것이 쉬울 때가 많다.
3. 세부사항이 지나치면 개발자가 더 효율적인 방법을 찾아냈어도 적용할 수 없다.
그러므로 실용주의 프로그래머라면 요구사항의 수집, 설계, 구현은 각각이 고립된 것이 아니라 하나의 과정 속에서 심리스(seamless)하게 진행된다는 점을 잊지 말아야 한다.
5. 동그라미와 화살표
오늘날에도 소프트웨어 분야에서는 수많은 방법론(기법)이 등장해 개발자를 골치아프게 한다.
이런 방법론들은 분명 쓸모는 있을 수 있으나, 이 또한 하나의 도구이므로 맹신해서는 안된다.
실용주의 프로그래머는 여러 방법론을 비판적으로 바라보고, 각각의 방법론에서 좋은 것만 뽑아 자신의 작업 실천 방법 속에 녹여 넣는다.
