프로젝트를 시작하기도 전에 기본원칙을 정하지 않는다면 망할 수도 있다.

📔요구사항의 구렁텅이

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라,
더이상 빼낼 것이 없을 때 얻게 되는 것이다.
			-생텍쥐페리-

요구사항을 수집하지 말고 채굴하라.

요구사항은 대게 프로젝트의 초기에 이뤄진다.

요구사항이 지면에 놓여져 있는 경우는 드물다.

요구사항은 최대한 일반적 진술로 만들고 나머지 정책에 대한 정보는 개발자에게 구현에서 지원해야할 것들의 한 예로 넘겨주어야 한다.

사용자의 요구사항 내면 깊이 들어갈 수 있는 기법은 사용자가 되어보는 것이다.

사용자처럼 생각하기 위해 사용자와 함께 일하라.

요구사항을 만들 때 생기는 큰위험은 지나치게 자세한 명세를 하는 것이다.

좋은 요구사항 문서는 추상적이다.

요구사항에 관한 한 비즈니스에 필요한 사항을 정확히 반영하는 가장 간단한 진술문이 최고다.

그렇다고 해서 모호하게 하라는 말은 아니다.

구체적인 것보다 추상적인 것이 더 오래간다.

프로젝트 용어사전을 사용하라.

사용자와 개발자가 동일한 것을 다른 이름으로 가리키는 프로젝트가 성공하기는 매우 힘들며, 같은 이름으로 다른 것을 지칭하는 상황에서는 더더욱 어렵다.

📔불가능한 퍼즐 풀기

프리기아의 왕 고르디우스는 아무도 풀 수 없는 매듭을 묶었다.
고르디우스의 매듭을 푸는 자가 아시아의 왕이 될 것이라는 이야기가 전해졌다.
알렉산더 대왕은 검으로 그 매듭을 잘라내 버렸다.
요구사항에 대한 조금 다른 해석, 그것이 다였다.
그는 결국 아시아의 대부분을 다스리게 되었다.

모든 선입견을 의심해보고 그것이 명백한 진짜 제약인지 가늠해봐야 한다.

이것은 틀을 벗어나고 벗어나지 않고의 문제가 아니다

문제는 틀을 찾는 것, 정말로 제약인 것들을 찾는 일이다.

생각의 틀을 벗어나지 말고 틀을 찾아라.

풀리지 않는 문제와 마주쳤다면, 생각해 볼 수 있는 모든 가능한 해결 경로를 눈 앞에 나열해보라.

아무리 쓸모없고 바보같이 보이는 경로라도 절대 버리지 말라.

이제 목록을 점검하면서 왜 그 경로를 따라 갈 수 없는지 설명해보라.

정말 확신하는가? 증명할 수 있는가?

제일 구속이 심한 제약들부터 파악해 내고 나머지 제약들을 그 안에서 맞춰 보아야 한다.

고르디우스의 매듭처럼, 요구사항을 새롭게 해석하니 문제 전체가 사라져버리는 경우도 많다.

우리에게 필요한 것은 진짜 제약과 우리를 오해하게 하는 제약 그리고 그 차이를 구별하기 위한 지혜이다.

📔준비가 되어야만

가끔은 망설이는 자가 재난을 모면한다.
			-제임스 써버-

일을 뛰어나게 수행하는 사람들의 공통점 : 그들은 언제 시작해야하고 언제 기다려야 하는지 안다

마음 속에서 '기다려'라고 들려오는 목소리에 귀를 기울여야 한다.

준비가 되었을 때 시작하라.

좋은 판단이냐 늑장부림이냐

모든 사람들은 백지상태를 두려워한다 그래서 일을 시작하는 최초행위를 미루기를 좋아한다.

그렇다면 좋은 때를 기다리는 것인지 늑장부림인 것인지 판단하는 것은 프로토타이핑을 시작하는 것이다. 보통은 2가지 중 한가지 반응이 일어난다.

1. 지루한 느낌을 받는 경우

   이것은 늑장부림이었기 때문에 진짜 개발을 시작해야한다.

2. 몇몇 전제가 틀렸다는 것을 깨닫는 경우

   어떻게 해야할지가 보인다면 진짜 개발을 시작해야한다.

📔명세의 함정

프로그램 명세화란?

요떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이며 명세화는 주요한 모호함을 제거하는 등의 방법으로 세계를 설명하고 명확하게 만드는 의사소통의 한 행위이고 현재와 미래의 개발자, 사용자와의 대화이고 약속이다.

어떤 일들은 설명하기보다 실제로 하는 것이 쉽다.

ex) 신발끈을 리본모양으로 묶는 것을 글로 설명하는 것

"이렇게 하면 더 효율적인데"라는 생각이 드는데 명세에서 규정한 설계때문에 제약을 받고 있다면 이런 기회를 포착하는 것 자체가 불가능할 것이다.

그러니 너무 명세에 고립되어 진행하지 말라!

구현과 테스트에서 나온 반응이 명세화 과정으로 다시 돌아가는 것을 깨닫게 될 것이다.

명세서가 상세해지다보면 결국 그 이득이 감소하거나 심지어 줄어드는 지점에 이르게 된다는 점을 염두에 두어야 한다.

📔동그라미와 화살표

형식적 방법의 노예가 되지 마라.

형식적 방법의 단점

• 최종사용자는 다이어그램을 이해못하기 때문에 설계자가 해석해줘야한다 그러면 다이어그램의 이점이 사라진다 가능하다면 언제나 사용자에게 프로토타입을 보여주고 그것을 직접 다뤄보게 하는 편이 좋다.
• 각 집단의 의사소통의 부족과 노력의 낭비로 이어져서 설계자들과 코딩하는 사람들 사이에는 '우리 VS 저들' 식의 사고방식이 생기는 경향이 있다.

사람들이 펼치면 몇백 평이 넘을 클래스 다이어그램 종이 뭉치와 유스케스 150개를 들고 회의에 들어오더라도 그 모든 것 역시 여전히 틀릴 가능성이 있는 요구사항과 설계에 대한 그들의 해석일 뿐이다.

비싼 도구가 더 좋은 설계를 낳지는 않는다.

프로젝트의 철학이 "클래스 다이어그램이 바로 애플리케이션이다, 나머지는 기계적인 코딩일 뿐이다."인 프로젝트를 보게 된다면 여러분은 아직도 가야할 길이 먼데 배는 물에 잠겨 들어가는 느낌이 무엇인지 알게 될 것이다.

형식적 방법은 물론 필요하고 도구일 뿐이다!