제 8장 프로젝트 전에

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

TIL (Today I Learn)

• Assignment 13
• 2022-04-03

---

오늘 읽은 범위

• 8장 프로젝트 전에
  • Topic 45 요구 사항의 구렁텅이
  • Topic 46 불가능한 퍼즐 풀기
  • Topic 47 함께 일하기
  • Topic 48 애자일의 핵심

 

---

3줄 요약

• 요구 사항은 피드백을 반복하며 알게 된다. 
• 사용자는 여러분 팀의 일원이다. 
• 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.

 

---

 

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

 

책에서 기억하고 싶은 내용을 써보세요

Topic 45 요구 사항의 구렁텅이

• 요구 사항이 땅 위에 놓여 있는 경우는 드물다. 보통은 가정과 오해, 정치의 지층 속 깊숙이 묻혀 있다.
  • 심지어 아예 존재하지 않을 때도 있다
• 그것이 우리가 하는 일이다. 간단해 보이는 무언가를 받으면 특이한 경우에 대해 캐물어서 사람들을 화나게 하는 것 말이다.  여러분의 역할은 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다
• 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다.
  
  • 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. (cuz 짧은 주기 선호)
  • 요구 사항은 피드백을 반복하며 알게 된다.
• 사용자처럼 생각하기 위해 사용자와 함께 일하라.
• 요구 사항은 아키텍처가 아니다. 요구 사항은 설계가 아니며 사용자 인터페이스도 아니다. 요구 사항은 필요를 표현하는 것이다.
• '프로젝트 용어 사전glossary’을 만들고 관리하라.

 

 

Topic 46 불가능한 퍼즐 풀기

• 어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유도를 파악하는 것이다. 
• 생각의 틀을 벗어나지 말고, 틀을 찾아라.
  • 제약(틀)을 범주별로 나누고 우선순위를 매겨라.
• 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다.
• 뇌에 경험을 주입하는 가장 좋은 방법은 일상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 주는 것이다.

 

 

 

Topic 47 함께 일하기

• 사용자는 여러분 팀의 일원이다. 
• ‘짝 프로그래밍pair programming’
  • 한 사람이 코드를 입력하는 동안 한 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 것
  • 입력을 담당한 개발자는 문법이나 코딩 스타일 같은 낮은 수준의 세부 사항에 집중해야만 한다. 반면에 다른 개발자는 문제를 더 높은 수준에서 넓은 범위를 보며 고민할 수 있다.
  • 사람의 존재로 인해 생기는 사회적인 압력은 나쁜 습관이나 약점으로부터 우리를 지켜준다.
• ‘몹 프로그래밍mob programming’
  • 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판 = 실시간 코딩을 곁들인 밀접한 협업
  • 키보드로 입력하는 사람은 5~10분마다 바꿔 주어야 한다.
• 이것이 우리가 말하는 “함께 일하기”다.
  • 그저 질문하고, 토론하고 메모를 하는 것이 아니라, 실제로 코딩을 하는 와중에 질문을 하고 토론을 하는 것이다.
  • 코드에 혼자 들어가지 말라.

 

 

" 애자일, 즉 기민함이란 것은
변화에 대응하는 것, 
일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것
이 전부이다. "

 

Topic 48 애자일의 핵심

• 애자일은 여러분이 일하는 방식이지 여러분이 아니다
  • 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.
  • 애자일은 ‘기민하다’는 뜻의 형용사다. 즉, 무언가를 하는 방식이다. 여러분은 애자일한 개발자가 될 수 있다. 

 

[ 애자일의 4가지 가치 ]

공정과 도구보다 개인과 상호작용
포괄적인 문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기

이 가치들은 무엇을 하라고 알려 주지는 않는다. 대신 여러분이 할 일을 결정할 때 무엇을 추구해야 할지를 알려 준다.

 

• 개발할 때 따라야 할 단 한 가지 계획이란 없다.
  • 온통 피드백을 수집하고 그에 대응하라는 것뿐이다.
• 각 팀은 팀의 프로세스가 얼마나 잘 운영되는지 검토할 때 피드백 고리를 활용해야 한다.
  • ex) 변수 이름짓기 같은 낮은 층위에 적용하면 결합도를 낮추는 코드가 나온다
  • ex) 요구 사항에 대한 작업 시작 후 바로 불필요한 작업임을 깨닫게 되는 것처럼 가장 높은 층위에도 적용된다.
• 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다.
  • 바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다.
  • 이것이 애자일이다

 

[ 애자일하게 일하는 법 ]

1. 여러분이 어디에 있는지 알아내라.
2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

 

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 내가 꽤나 많이 되내이고 잘 써먹는 말이 있다. 인간(人間)이란, '사람과 사람사이' 라는 뜻으로 결국 사람은 사회적 동물이라 다른 사람이 없으면 살아갈 수 없는 존재라는 것이다. 개발도 마찬가지이다. 여러 사람과 협의하고 의견을 나누며 피드백을 받을 때 좋은 소프트웨어가 탄생한다. 오픈 소스가 왜 대세가 되었겠는가?
  • 그렇지만 나도 혼자 혹은 둘이서만 개발하게 되는 경우가 많았다. 코드 리뷰는 꼼꼼히 하려고 하지만 더 많은 사람이 생겼을 때에 대한 대책은 딱히 없는 것 같다.
  • 그때는 다시 이책과 더불어 애자일을 더 받아들여야만 하겠지. (살고 싶으면...)
• '나는 17,000쪽에 달하는 문서를 읽고 싶어 하는 인간을 만나본 적이 없다. 만약 만났더라면 유전자 풀에서 제거하기 위해 죽여 버렸을 것이다.'. 오늘은 여기서 피식했다. 문서는 최대 효율 최소 양이 제일 좋은 것 같다.
• 간혹 화상 회의를 하다보면 짝이나 몹 프로그래밍을 잠깐씩 하게되는 경우가 있다. 물론 전체 코드 작성이 아닌 설계 방향성 정도를 보여주는 선에서 마무리 되긴 했지만 이런 방식을 굉장히 적극적으로 권장하는구나. 한국에서는 좀 찾아보기 힘든 문화이고 솔직히 나도 좀 부담스럽기는 한거 같다. 
• 애자일애자일 말이 정말 많다. 하지만 결국은 ETC다.

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

• 특별히 없다. 다만 저자가 말하는 협업 과정을 실제 모범 사례로 한 번쯤 경험해보고 싶다. 정말 애자일한 팀들은 어떻게 일할까.