[박승훈] 8장: 프로젝트 전에

8장/박승훈.md

@@ -0,0 +1,255 @@
+## Topic 45 : 요구 사항의 구렁텅이  
+
+> "완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성되는 것이다." - 앙투안 드 생텍쥐페리
+
+<br />
+
+> 나의 생각
+
+멋진 말인 것 같습니다. 채울 때가 아니라 본질과 핵심을 남기고 깎아낼 때가 항상 더 어려웠던 것 같아요. 특히 자소서랄까...
+
+<br />
+
+### 자신이 뭘 원하는지 아는 사람은 아무도 없다.
+
+- 무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다.
+- 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다.
+- **프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.**
+- (잘해서 기획자를 돕자!)
+
+<br />
+
+### 상담 치료로서의 프로그래밍
+
+- 의뢰인은 현재 발생한 문제를 푸는 전술적인 사안을 가지고 온다.
+- 신입 개발자들이 자주 범하는 실수는 이런 요청 사항을 받았을 때 바로 해결책을 구현해 버리는 것이다.
+- 최초의 요청 사항은 궁극적인 요구 사항이 아니다.
+- 의뢰인의 요청 사항은 사실 함께 탐험을 떠나자는 초대장이다.
+- 여러분의 역할은 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다.
+
+<br />
+
+> 나의 생각
+
+기획자가 장황한 개발 요구사항을 들고 왔을 때, 조금 더 기획자가 바라는 서비스에 대해서 길을 밝혀주고 더 비판적으로 바라보며 의견을 내서 궁극적인 가치를 더 쉽고 합리적인 길로 갈 수 있도록 힘써야겠다고 생각했다.
+
+<br />
+
+### 요구 사항은 과정이다.
+
+- 요구사항은 피드백을 반복하며 알게 된다.
+- "말씀하신 게 이런 것입니까?" 부류의 피드백에 의존해야 한다.
+- 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다.
+- 짧은 주기로 반복하여 반복 주기가 끝날 때마다 의뢰인에게 피드백을 받는다.
+- 피드백 수집은 의뢰인과의 관계를 쌓아 나가는 시작점이기도 하다.
+
+<br />
+
+> 나의 생각
+
+개발 일을 하면서 내가 이해한 기획 요소들이 실제로 의뢰인(보통 기획자)이 요구하는 것과 실상이 달랐다는 사실을 종종 마주하곤 한다. 그래서 모호한 부분은 정확히 짚고 넘어가고, 완전히 일을 마치고 피드백을 받는 게 아니라, 중간중간 확인을 하고 넘어가는 것이 좋겠다고 생각했다.
+
+<br />
+
+### 요구사항 vs 정책
+
+> "정책은 메타데이터다."
+
+- 현재의 정책 정보는 시스템이 지원하는 것들 중 한 사례일 뿐이다.
+- 시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다.
+
+<br />
+
+> 나의 생각
+
+굉장히 일반적인 공통 컴포넌트를 제작하거나 디자인시스템을 개발할 때, 개발자가 이런 부분까지 조작하고 커스텀할 수 있도록 다각적인 확장성을 고려하며 만들게 되는 것 같다고 생각했다. 즉, 말 그래도 시스템적으로 개발하는 것이다. 특히 도메인이 덜 묻어있는 general한 컴포넌트일수록 더 그런 경향이 강했다. 이런 사례와 비슷하다고 생각했다.
+
+<br />
+
+### 요구사항 문서화
+
+> "유일한 요구사항 문서는 '작동하는 코드'이다."
+
+- 문서는 구현 과정에서 안내 역할을 하는 이정표일 뿐이다.
+- 의뢰인은 자신이 원하는 것을 처음에는 잘 모른다. 따라서 의뢰인이 말한 것을 확장하여 법률 문서에 준하는 수준으로 만든 문서는 그저 사상누각에 불과하다.
+- 요구사항 명세의 문제 : **"의뢰인은 절대 그걸 읽지 않는다."** 
+
+<br />
+
+### 지나치게 자세한 명세
+
+- 문서를 만들 때 생기는 또 다른 문제 : **지나치게 자세히 서술하는 것**
+- 좋은 요구 사항은 추상적이다. 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다.
+- 요구 사항은 필요를 표현하는 것이다.
+
+<br />
+
+> 나의 생각
+
+장황한 문서의 문제점인 "의뢰인은 절대 그걸 읽지 않는다"라는 부분에서 현업에서 기획자가 A4 몇 장에 달하는 기획 요구사항을 굉장히 상세하게 적어주는 점에서 감사한 점이 있으면서도 실제로 모두 읽지 못하는 상황에 대입이 되어 공감이 되기도 했다.   
+
+더 짧고 강력하고 효과적으로 전달할 수 있도록 문서 작성보다는 직관적인 소통에 더 힘쓸 필요가 있겠다고 느꼈다.
+
+<br />
+
+### 용어 사전 관리하기
+
+- 프로젝트 용어 사전을 만들고 관리하라.
+- **프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 한다.**
+- 프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용해야 한다.
+- 사용자와 개발자가 동일한 것을 다른 이름으로 부른다면 프로젝트는 성공하기 힘들다. 같은 이름으로 서로 다른 것을 지칭한다면 더더욱 힘들다.
+
+<br />
+
+> 나의 생각
+
+현재 지원서 리뉴얼 프로젝트를 진행하면서 UI/멘탈 모델의 구조를 기획/프론트/백엔드에서 각자 다른 이름으로 부르는 것을 보며 용어의 통합이 필요하다고 이전부터 느껴왔고 몇몇 목소리도 많았는데, 총대 메고 용어 사전을 만드는 게 필요할 수도 있겠다고 생각이 든다.
+
+<br />
+
+## Topic 46 : 불가능한 퍼즐 풀기
+
+> 불가능한 일을 해내는 것은 "요구사항에 대한 조금 다른 해석", 그게 다였다.
+
+- 그럴싸해 보이는 제약 조건이 사실은 전혀 제약 조건이 아닐 수도 있다.
+- 유효하지 않은 제약을 인식하고 그걸 무시해버려라.
+- 제약이나 조건들의 경계선을 파악하라.
+- 제약의 인식과 함께 주어진 자유도를 파악하라.
+
+<br />
+
+### 풀리지 않는 문제와 마주쳤다면?
+
+- 생각해볼 수 있는 모든 해결 경로 후보를 눈 앞에 나열해보라.
+- 아무리 쓸모없고 바보 같아 보이는 경로라도 절대 버리지 말라.
+- 그리고 목록을 하나씩 점검하면서 왜 그 경로를 따라갈 수 없는지 설명해보라.
+- 제약을 범주별로 나누고 우선순위를 매겨라.
+- 제일 구속이 심한 제약부터 파악해 내고, 나머지 제약을 그 안에서 맞춰보라.
+
+<br />
+
+### 묵은 제약을 검토하라
+
+- 일을 시작할 때의 제약들이 지금도 모두 적용되는가?
+- 제약 조건의 해석이 아직도 타당한가?
+- 시간이 지나면 제약은 변화한다.
+- 변화하는 상황 속에서 묵은 제약을 유지하지 않도록 주의하라.
+
+<br />
+
+### 자신만의 방법에서 빠져나오라
+
+> "딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다."
+
+여러분이 일부러 딴짓을 하고 있을 때 갑자기 여러분의 머릿속에 답이 떠오르는 일이 얼마나 자주 일어나는지 놀라게 될 것이다.
+
+<br />
+
+> 나의 생각
+
+회사에서 일단 해놓고 나왔지만 마음에 안 들었던 개발 내용이, 버스를 타려고 기다리고 있는데 번뜩이는 해결방법이 생각나서 바로 뚝딱 해결했던 경험이 글을 읽는 며칠 전에 있었다. 주의를 벗어나서 의식이 아닌 무의식이 문제를 해결해주는 사례는 많았고, 이를 잘 활용할 수 있어도 좋겠다는 생각이 들었다.
+
+<br />
+
+### 행운은 준비된 사람에게 찾아온다.
+
+- 뇌의 무의식 영역에 원료를 많이 주입해야 한다.
+- 문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다.
+
+<br />
+
+## Topic 47 : 함께 일하기
+
+> "만들고 싶은 코드 구조에 맞춰 팀을 조직하라. 예를 들면 팀이 여러 지역으로 나뉘어 있으면 더 모듈화, 분산화된 소프트웨어를 만드는 경향이 있다."
+
+<br />
+
+### 짝 프로그래밍(pair programming)
+
+- 개발을 실행하는 개발자(driver)는 낮은 수준의 세부 사항에 집중한다. (문법이나 코딩 스타일 등)
+- 지시를 내리는 개발자(navigator)는 더 높은 수준의 문제에 집중한다. (전체적인 설계, 구조 등)
+- 이 고민 리소스의 분리는 제한적인 인간의 뇌 용량을 극복하고 두 개의 뇌를 유기적으로 개발 진행에 활용할 수 있게 한다.
+
+<br />
+
+### 상대방의 존재로 인한 효과
+
+- 서로의 존재로 인해 생기는 사회적인 압력은 변수 이름을 foo로 짓는 것 같은 나쁜 습관이나 약점으로부터 우리를 지켜준다.
+- 다른 사람이 지켜보고 있기에 민망할 수 있는 꼼수를 덜 쓰고, 결과적으로 프로그램의 품질이 좋아지게 된다.
+
+<br />
+
+> 나의 생각
+
+페어프로그래밍의 의외의 효과인 것 같다. 사실 페어 프로그래밍을 하면서 정말 체감하는 효과였던 것 같은데, 이렇게 글로 표현된 것은 처음 보는 것 같다. 너무 적나라하기 때문이었을까.
+
+<br />
+
+### 몹 프로그래밍(mob programming)
+
+- 몹 프로그래밍은 '폭도(mob)'를 의미하는데, 이는 집단으로 무언가를 하는 것을 의미한다.
+- 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판이다.
+- 실시간 코딩을 곁들인 밀접한 협업
+- (처음 들어봐서 신기하네요.)
+
+<br />
+
+### 함께 일하는 방법
+
+- 코드만 비판하고 사람을 비판하지 말라.
+- 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다.
+- 자주 회고를 하라. 그래서 다음 번에 시도하거나 개선할 점을 찾아라.
+
+<br />
+
+> 나의 생각
+
+- 좋은 조언이라고 생각한다. 진정으로 함께 일하기 위한 노하우인 듯하다. 이번 토픽의 전체 내용을 생각해봤을 때 물론 여러 장점이 있는 것도 사실이지만, 당장 원맨 리소스를 온전하게 프로젝트를 녹이기 위해서 각자 뛰고 있는 상황에, 페어/몹 프로그래밍으로 취할 수 있는 이점이 드라마틱할 지, 그리고 현업의 상황이 이를 이해해줄지 의문이 들기도 했다. 적용한다면 어떻게 할 수 있을지 고민이 필요한 포인트인 것도 같다.
+
+<br />
+
+## Topic 48 : 애자일의 핵심
+
+> 누군가가 "이걸 하세요. 그러면 애자일인 겁니다."라고 한다면 이건 틀린 말이다. 정의상 그렇다.
+
+- 애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이다.
+- 애자일 프로세스라는 것은 있을 수 없다. 변화에 대응하는 것, 맞부딪히는 미지의 것에 대응하는 것이 전부이기 때문이다.
+- 피드백을 수집하고 그에 대응하라.
+- 무엇을 하라고 알려주지는 않는다. 대신 **할 일을 결정할 때 무엇을 추구해야 할지를 알려준다.**
+
+<br />
+
+### 개발의 더 나은 방법들
+
+|AS-IS|TO-BE|
+|--|--|
+| 공정과 도구 | 개인과 상호작용 |
+| 포괄적인 문서 | 작동하는 소프트웨어 |
+| 계약 협상 | 고객과의 협력 |
+| 계획을 따르기 | 변화에 대응하기 |
+
+<br />
+
+### 애자일하게 일하는 방법
+
+1. 여러분이 어디에 있는지 알아내라.
+2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
+3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
+
+**지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.**
+
+<br />
+
+### 이 과정이 설계를 주도한다.
+
+- 좋은 설계의 척도는 설계의 결과물을 얼마나 바꾸기 쉬운지로 판단한다.
+- 피드백 고리를 효율적으로 만들려면 가능한 한 고치는 일이 쉬워야 한다.
+- 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다.
+
+<br />
+
+> 나의 생각
+
+우리 팀도 팀장님이 200만원 사비를 내고 애자일 교육을 따로 받으셨다고, 팀원들을 다 모아서 애자일의 정의부터 이후 프로젝트의 진행 방향에 대한 가이드를 잡아주신 적이 있다. 그런데 아쉽게도 지향하고자 하는 방향과 달리 커다란 워터폴을 잘게 자른 모습으로 어쩔 수 없이 변해버렸다. 서비스의 최종 모습에 대한 기획적인 목표, 그리고 고객사에 공문을 내놓은 마감기한이 있고, 이를 쫓아가는 과정을 밟으며 이상과 현실은 많이 다름을 느끼는 현장 속에 있다.  
+
+애자일은 결국 피드백을 모으고 변화에 대응하는 것이라면, 이후에는 이렇게 애자일, 그리고 그 저면의 가치를 더 잘 이해하고 적용할 수 있도록 노력해야겠다고 생각했다. 회사 생활을 하면서 가능할지는 아직 모르겠다.