[책] 실용주의 프로그래머 8장 프로젝트 전에

실용주의 프로그래머

The Pragmatic Programmer

 

8장. 프로젝트 전에

Before the Project (p.349)

 

항목 45 - 흔한 함정이나 곤란한 상황에 빠지지 않는 법을 익혀라.

항목 46 - 일반 통념과 제약 조건 관리(constraint management)

항목 47 - 우리가 생각하는 함께 일하기는 코딩하는 동안 문제를 함께 푸는 것이다.

항목 48 - 애자일 선언(Agile Manifesto)은 "공정(process)과 도구보다 개인과 상호 작용"으로 시작한다.

 

여러분 그리고 여러분의 팀은 프로젝트를 시작할 때 요구 사항을 파악해야 한다.

 

Topic 45. 요구 사항의 구렁텅이 (p.350)

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성되는 것이다.
- 앙투안 드 생텍쥐페이(Antoine de St. Exupery), <바람과 모래의 별들>

많은 책과 튜토리얼에 따르면 '요구 사항 수집'은 프로젝트 초기에 이뤄진다.

 

Tip 75. 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.

 

* 요구 사항 미신

소프트웨어 산업 초창기 컴퓨터가 컴퓨터를 다루는 사람보다 훨씬 비싸던 시절이 있었다.

비용을 절약하기 위해서 기계가 해야 할 일을 정확하게 기술하려고 애썼다.

돈이 많이 들었기에 사람들은 자신이 원하는 것을 정확히 알 때만 자동화를 시도하게 되었다.

초기의 컴퓨터는 기능이 충분치 않아서 해결 가능한 문제의 폭도 제한적이었다.

그래서 문제 이해 후 작업을 시작하는 것이 실제로 가능했다.

 

진짜 세상은 엉망이고 갈등이 넘쳐나며 알 수 없는 점도 많아서,

무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다.

그래서 프로그래머들이 등장했다.

Tip 76. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.
소프트웨어 개발은 사용자와 프로그래머의 공동 창작 작업이다.

 

* 상담 치료로서의 프로그래밍

우리의 경험상 최초의 요청 사항은 궁극적인 요구 사항이 아니다.

의뢰인은 인식하지 못할 수도 있지만, 의뢰인의 요청 사항은 사실 함께 탐험을 떠나자는 초대장이다.

 

의뢰인이 미처 고려해 보지 않은 문제도 있을 것이다.

여기가 바로 일이 재미있어지는 부분이다.

좋은 개발자라면 협상 능력을 키울 수 있는 상황이기도 하다.

 

의뢰인과의 소통을 통해서 판단을 내리며 해결책을 만드는 데 참여한다.

여러분이나 의뢰인이 혼자서 만들어 내는 것보다 아마 더 좋을 것이다.

 

* 요구 사항은 과정이다

 

Tip 77. 요구 사항은 피드백을 반복하며 알게 된다.
요구 사항을 이해하려면 탐험과 피드백을 거쳐야 한다.
결정한 요구 사항의 여파를 바탕으로 처음의 발상을 다듬는다.

 

의뢰인이 제시한 요구 사항에 대한 피대븍을 주고 의뢰인은 피드백을 바탕으로 자기 생각을 더 가다듬는다.

 

우리는 모형(mockup)이나 프로토타입을 만들어서 의뢰인이 직접 다루어 볼 수 있도록 한다.

공들여 만들지 않아도 생각을 전달할 수만 있으면 된다.

 

실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다.

과정의 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다.

혹시 정말로 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다.

 

* 의뢰인의 입장에서 보라

시스템이 실제로 어떻게 사용될지 통찰을 얻을 수 있을 뿐 아니라,

옆에서 지켜보는 것으로 의뢰인과 신뢰를 구축하고 의사소통의 기반을 다지는 데

얼마나 도움이 되는지 놀라게 될 것이다.

 

Tip 78. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
시스템이 정말로 어떻게 사용될지 통찰을 얻을 수 있는 가장 좋은 방법이다.

 

* 요구 사항 대 정책

 

Tip 79. 정책은 메타데이터다.
정책을 시스템 코드 안에 고정하지 말라. 대신 시스템이 사용하는 메타데이터로 표현하라.

 

* 요구 사항 대 현실

도구가 성공하려면 사용하는 사람의 손에 적응할 수 있어야 한다.

이 점도 염두에 두어야 성공적으로 요구 사항을 수집할 수 있다.

 

* 요구 사항 문서화

우리는 최고의 요구 사항 문서, 아니 아마 유일한 요구 사항 문서는 작동하는 코드라고 믿는다.

문서는 구현 과장에서 안내 역할을 하는 이정표일 뿐이다.

 

요구 사항 문서는 의뢰인을 위한 것이 아니다

의뢰인이 프로그래머를 고용하는 이유는,

의뢰인은 고차원적이고 모호한 측면이 있는 문제를 풀고 싶어 하는 반면,

프로그래머는 세부 사항과 미묘한 차이 하나하나에 관심을 두기 때문이다.

요구 사항 문서는 개발자를 위해서 쓰는 것이다.

 

요구 사항 문서는 계획을 위한 것이다

작은 인덱스 카드에 애플리케이션의 작은 일부가 그 기능을 쓰는 사용자 관점에서 어떻게 작동해야 하는지를 적자.

요구 사항을 화이트보드에 붙일 수도 있고, 상태나 우선순위를 표현하기 위해 이리저리 옮길 수도 있다.

요구 사항 설명을 짧게 제한하면 개발자들이 명확하지 않은 점을 물어보도록 유도할 수 있다.

코드를 작성하기 전이나 작성하는 도중에 일어나는 의뢰인과 개발자 간의 피드백 과정이 더 활발해질 수 있다.

 

* 지나치게 자세한 명세

요구 사항 문서를 만들 때 생기는 또 다른 심각한 문제는 지나치게 자세히 서술하는 것이다.

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

사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다.

 

요구 사항은 아키텍처가 아니다.

요구 사항은 설계가 아니며 사용자 인터페이스도 아니다.

요구 사항은 필요를 표현하는 것이다.

 

* 딱 하나만 더......

반복 주기를 거치며 의뢰인과 정기적으로 피드백을 주고 받자.

피드백은 서로 주고받는 것이다.

 

* 용어 사전 관리하기

'프로젝트 용어 사전(glossary)'을 만들고 관리하라.

용어 사전에 여러 사람이 접근하기 쉬워야 한다.

온라인 문서가 적합하다.

 

Tip 80. 프로젝트 용어 사전을 사용하라.
프로젝트에서 쓰이는 용어와 어휘들을 모두 한곳에 모으고 관리하라.

 

 

Topic 46. 불가능한 퍼즐 풀기 (p.362)

절대적 제약 조건은 그것이 아무리 불쾌하거나 어리석어 보여도 꼭 따라야 한다.

 

* 자유도

어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어

여러분에게 주어진 자유도(degree of freedom)를 파악하는 것이다.

 

문제는 틀을 찾는 것, 곧 진짜 제약을 찾는 일이다.

 

Tip 81. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
불가능한 문제와 마주쳤다면 진짜 제약 조건을 찾아라.
스스로 물어보라.
‘정말로 반드시 이렇게 해야 하나? 꼭 해야 하는 일이긴 한가?’

 

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

제약을 범주별로 나누고 우선순위를 매겨라.

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

 

* 자신만의 방법에서 빠져나오라

문제가 생각보다 훨씬 어려울 때 잠깐 다른 일을 해보자.

산책을 하거나 아예 내일로 미루거나..

 

여러분이 일부러 딴짓을 하고 있을 때 갑자기 여러분의 머릿속에 답이 떠오르는 일이

얼마나 자주 일어나는지 놀라게 될것이다.

 

간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다.
- 사이콜로지 투데이(Psychology Today)

 

그저 문제에 대해 이야기하는 것으로 주의를 돌리기만 해도 깨달음을 얻을 때가 있다.

 

* 행운은 준비된 사람에게 찾아온다

문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다.

여러분의 뇌에 경험을 주입하는 가장 좋은 방법은

이상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 주는 것이다.

언제나 "겁먹지 마시오.(DON'T PANIC.)"

 

 

Topic 47. 함께 일하기 (p.367)

사용자와 밀접하게 함께 일해라.

사용자는 여러분 팀의 일원이다.

 

한 사람이 코드를 입력하는 동안 한 명 혹은 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것.

이 방식은 함께 일하는 아주 강력한 방법이다.

끝없는 회의나 제안서보다, 그리고 유용성보다 무게를 더 중시하는 법률 문서스러운 문서 뭉치보다 훨씬 낫다.

 

그저 질문하고, 토론하고 메모를 하는 것이 아니라,

실제로 코딩을 하는 와중에 질문을 하고 토론을 하는것이다. (중요하다!)

 

* 짝 프로그래밍(pair programming)

직접 코드를 작성하는 사람 외의 사람의 존재로 인해 생기는 사회적인 압력은

변수 이름을 foo로 짓는 것 같은 나쁜 습관이나 약점으로부터 우리를 지켜준다.

 

다른 사람이 지켜보고 있으면 민망할 수도 있는 꼼수를 덜 쓰게 되고,

결과적으로 소프트웨어의 품질이 좋아진다.

 

* 몹 프로그래밍(mob programming)

셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판이다.

'실시간 코딩을 곁들인 밀접한 협업'이라고 생각해도 될 것이다.

 

* 무엇을 해야 할까?

현재 늘 혼자서 프로그래밍을 하고 있다면 짝 프로그래밍을 시도해 봐도 좋을 것이다.

새로운 아이디어를 모아야 하거나 골치 아픈 문제를 분석해야 한다면 몹 프로그래밍 시간을 가져 봐도 좋을 것이다.

이렇게 함께 일하는 동안 기술적인 면 외에 인간적인 측면도 신경 써야 한다.

 

가장 먼저 고려할 만한 몇 가지 팁.

- 코드를 짜는 거지 자아(ego)를 쌓는 게 아니다. 우리 모두는 각자 뛰어난 부분이나 장단점이 있다.

- 소규모로 시작하라.

- 코드만 비판하고 사람을 비판하지 말라.

- 다른 것은 틀린 것이 아니다. 이해하려고 노력하라.

- 자주 회고를 하라. 개선할 점을 찾아라.

 

여러분과 여러분의 팀이 늘 한 가지 방법으로만 일했다면,

다른 방식을 실험해 보는 것이 좋다.

예) 몹 프로그래밍을 할 때는 키보드로 입력하는 사람을 5~10분마다 바꿔 주어야 한다.

 

교과서와 사례 보고서를 모두 찾아보고 연구를 좀 하라.

곧장 코드로 뛰어들기보다는 간단한 연습 문제로 시작하라.

 

Tip 82. 코드에 혼자 들어가지 말라.
프로그래밍은 어렵고 힘들 수 있다. 친구와 함께 가라.

 

 

Topic 48. 애자일의 핵심 (p.372)

애자일은 여러분이 일하는 방식이지 여러분이 아니다.

 

Tip 82. 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.
애자일은 형용사다. 즉, 무언가를 하는 방식이다.

 

애자일 선선에서 언급한 가치를 기억하라.

우리는 소픝트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치를 찾아냈다.
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
왼쪽에 있는 것도 가치가 있지만 오른쪽에 있는 것에 더 높은 가치를 둔다.

 

애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이다.

 

* 애자일 프로세스라는 것은 있을 수 없다

애자일,

즉 기민함이란 것은 변화에 대응하는 것,

일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이다.

 

소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다.

온통 피드백을 수집하고 그에 대응하라.

 

* 그래서 우리는 무엇을 해야 할까?

애자일 선언은 피드백을 모으고 그에 맞게 행동함으로써 불확실성을 헤쳐 나가라고 제안한다.

 

애자일하게 일하는 방법.

1. 여러분이 어디에 있는지 알아내라.

2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.

3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

위 과정을 끝날 때까지 반복하라.

 

지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.

 

* 이 과정이 설계를 주도한다

좋은 설계는 나쁜 설계보다 바꾸기 쉬운 결과물을 만든다.

애자일에 대한 이 논의는 왜 바꾸기 쉬워야 하는지를 알려준다.

 

우리 피드백 고리를 효율적으로 만들려면 가능한 한 고치는 일이 쉬워야 한다.

 

애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다.

좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다.

바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다.

 

이것이 애자일이다.