실용주의 프로그래머 8장 - 프로젝트 전에

나의 키워드

• 요구 사항의 구렁텅이
• 불가능한 퍼즐 풀기
• 함께 일하기
• 애자일의 핵심

---

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

요구 사항의 구렁텅이

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성되는 것이다. - 앙투안 드 생텍쥐페리

• 많은 책과 튜토리얼에 따르면 ‘요구 사항 수집’은 프로젝트의 초기에 이뤄진다. 수집이라는 말은 왠지 베토벤의 전원 교향곡이 배경 음악으로 부드럽게 울려 퍼지는 가운데 행복한 분석가들이 주변에 널려 있는 지식 덩어리를 주워 담는 장면을 연상케 한다 (p.350)
• 요구 사항이 이미 널려 있다는, 고로 그것들을 쉽게 찾아서 바구니에 주워 담고 행복하게 가던 길을 계속 갈 수 있다는 느낌을 풍긴다. 사실을 그렇지 않다. 요구 사항이 땅 위에 놓여 있는 경우는 드물다 (p.350)

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

• 초기의 컴퓨터는 기능이 충분치 않아서 컴퓨터로 해결할 수 있는 문제의 폭도 제한적이었다. 그래서 전체를 먼저 다 이해한 후에 작업을 시작하는 것이 실제로 가능했다. 무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다. (p.351)

프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.

• 신입 개발자들이 자주 범하는 실수는 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다. 우리의 경험상 최초의 요청 사항은 궁극적인 요구 사항이 아니다. (p.352)
• 새로운 요구사항을 받았다. “5만 원 이상인 모든 주문은 배송비가 무료입니다.” 잠시 멈춰서 이런 요구 사항을 받았다고 상상해 보라. 어떤 생각이 먼저 떠오르는가? (p.352)
  • 어떤 종류의 배송이 무료인가? 당일 배송, 아니면 일반 배송?
  • 국제 배송은 어떤가?
  • 5만 원에 현재 고객이 선택한 배송 방법의 배송비도 포함인가?
  • 5만 원에 세금도 포함인가?
  • 5만 원이 모두 종이책이어야 하나, 아니면 전자책을 포함해도 되나?
  • 나중에 5만 원 기준이 또 바뀔까?
• 이것이 우리가 하는 일이다. 간단히 보이는 무언가를 받으면 특이한 경우에 대해 캐물어서 사람들을 화나게 하는 것 말이다. 의뢰인이 이미 생각해 본 문제일 수도 있다. 그렇다면 이미 어떤 식으로 구현해야 한다는 계획이 있을 것이므로 질문으로 정보를 끄집어내기만 하면 된다.
• 여러분의 역할은 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다 (p.353)

요구 사항은 피드백을 반복하며 알게 된다.

• 여러분의 임무는 의뢰인에게 그들이 제시한 요구 사항의 여파를 깨우쳐 주는 것이다. 여러분은 피드백을 주고 의뢰인은 피드백을 바탕으로 자기 생각을 더 가다듬는다.
• 실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다. 그래서 우리는 짧은 주기로 반복하는 것을 선호한다. 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. 혹시 우리가 정말로 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다. (p.355)

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

• 우리는 최고의 요구 사항 문서, 아니 아마 유일한 요구 사항 문서는 작동하는 코드라고 믿는다. 그저 문서는 목표가 아니고, 의뢰인에게 승인해 달라고 들이밀 수 있는 것도 아니라는 뜻일 뿐이다. 문서는 구현 과정에서 안내 역할을 하는 이정표일 뿐이다. (p.357)
• 우리가 논의했듯이 의뢰인은 자신이 원하는 것을 처음에는 잘 모른다. 따라서 의뢰인이 말한 것을 확장하여 법률 문서에 준하는 수준으로 만든 문서는 그저 사상누각에 불과하다. (p.358)
• 의뢰인은 200 페이지에 달하는 문서를 읽지 않는다. (p.358)
• 의뢰인에게 두꺼운 기술 문서를 들이미는 것은 평범한 개발자에게 고대 그리스어로 된 “일리아스”를 한 권 주면서 이걸로 비디오 게임을 만들라고 하는 것이나 마찬가지다. (p.359)
• 많은 프로젝트가 범위(scope)의 증가 때문에 실패한다고 알려져 있다. 해답은 다시 한번 피드백이다. 반복 주기를 거치며 의뢰인과 정기적으로 피드백을 주고받는다면, “딱 한 기능만 더”란 요청이 미치는 영향을 의뢰인이 직접 체험할 것이다. 화이트보드에 또 다른 스토리 카드를 올리겠지만, 그 카드를 구현할 시간을 확보하기 위해 다음 반복 주기로 미룰 카드 선택을 도와주게 될 것이다. 피드백은 서로 주고받는 것이다. (p.360)
• ‘프로젝트 용어 사전’을 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 한다.

불가능한 퍼즐 풀기

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

• 해법은 다른 곳에 있다. 불가능한 퍼즐을 푸는 방법은 상상 속이 아닌 실제 제약 조건을 알아내고, 그 속에서 해법을 찾는 것이다. (p.363)
• 사람들은 정답일 가능성이 있는 해결 방안도 너무 쉽게 포기하곤 한다. (p.363)
• “유레카”의 순간을 경험하려면 여러분 뇌의 무의식 영역에 원료를 많이 주입해야 한다. 문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다. (p.366)

함께 일하기

• 코드를 짜는 거지 자아를 쌓는 게 아니다. 누가 가장 똑똑한지 겨루는 것이 아니다. 우리 모두는 각자 뛰어난 부분이나 장단점이 있다. (p.371)
• 소규모로 시작하라. 네다섯 명과 몹을 만들어 보거나, 짝 프로그래밍을 짧게 몇 번 해 보는 것으로 시작하라. (p.371)
• 코드만 비판하고 사람을 비판하지 말라. “넌 틀렸어”. 보다는 “이 부분을 한 번 볼까요?”가 훨씬 듣기 좋다. (p.371)
• 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다. (p.371)
• 자주 회고를 하라. 그래서 다음번에 시도하거나 개선할 점을 찾아라. (p.371)

애자일의 핵심

그 단어를 계속 쓰는군. 그 단어의 뜻이 네가 생각하는 그 뜻이 아닌 것 같은데.

• ‘애자일’은 명사가 아니다. ‘기민하다’는 뜻의 형용사다. 즉 무언가를 하는 방식이다. (p.372)
• 애자일 선언에서 언급한 가치를 기억하라 (p.373)
  • 공정과 도구보다 개인과 상호작용
  • 포괄적인 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응하기

왼쪽에 있는 것도 가치가 있지만 우리는 오른쪽에 있는 것에 더 높은 가치를 둔다.

• 사실 누군가가 “이걸 하세요. 그러면 애자일인 겁니다.”라고 한다면 이건 틀린 말이다. 정의상 그렇다. (p.373)
• 물리적인 세계에서든 소프트웨어 개발에서든 애자일, 즉 기민 함이라는 것은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이기 때문이다. (p.374)
• 가젤은 일직선으로 뛰어가지 않는다. 체조 선수는 매 순간 수없이 동작을 수정하며 환경의 변화나 사소한 발 위치의 실수에 반응한다. 개발팀이나 개발자 개인도 마찬가지다. 소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다. 온통 피드백을 수집하고 그에 대응하라는 것뿐이다. (p.374)

도전해 볼 것

• 프로젝트 용어 정리 문서 만들기, 이번 TF 팀 프로젝트에 대한 회고

궁금한 점

• 개발할 때 팀 내부의 서로의 장단점을 알고 있나요?