[TIL] 8장 프로젝트 전에 , 9장 실용주의 프로젝트

8장 프로젝트 전에 | 9장 실용주의 프로젝트

 

노마드 북클럽은 끝난지 좀 되었고, 나는 결국 완주해내지는 못했다.
그래도 책을 마무리를 지어야 하기 때문에 올려보는 실용주의 프로그래머 마지막 TIL. 좀 더 정리해야하는 TIL들이 남아있기는 한데 마무리도 지어야 새로운 책을 읽어나갈 수 있어서 일단 마무리를 해본다.

오늘의 TIL 3줄 요약

• 프로그래머의 역할은 더 나은 결과를 낼 수 있도록 노력하는 문제해결사이다.
• 팀을 더 가치있게 만들 수 있는 프로그래머가 되어야 한다.
• 내 코드와 나의 결과물에 자부심을 가져야 한다.

1. 책에서 기억하고 싶은 내용

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

[ 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. ]
진짜 세상은 엉망이고 갈등이 넘쳐나며 알 수 없는 점도 많다. 무엇을 다루든 정확한 명세란 것은 거의 불가능하다고 볼 수 있다.
그래서 우리 프로그래머들이 등장한다. 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다. 

우리의 역할은 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다. 이 탐험은 지적이고 창의적인 과정이다. 여러분은 순간적으로 판단을 내리며 해결책을 만드는 데 참여한다. 

프로젝트 진행 도중 때때로 정말 어려운 퍼즐을 붙잡고 씨름할 일이 생길 것이다. 도무지 이해가 안 되는 엔지니어링 문제일 수도 있고, 혹은 생각했던 것보다 훨씬 작성하기 어려운 코드일 수도 있다. 어쩌면 불가능해 보일지도 모르겠다.

하지만 보이는 것만큼 실제로도 정말 그렇게 어려울까?
어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 여러분에게 주어진 자유도를 파악하는 것이다. 퍼즐의 해답은 그 자유도(degree of freedom) 안에서 발견된다. [ 생각의 틀을 벗어나지 말고, 틀을 찾아라. ]

어떤 때는 문제가 생각보다 훨씬 어려워 보이기도 한다. 아마 접근 방법을 잘못 선택했다는 느낌이 들 것이다. 더 쉽게 문제를 푸는 방법이 있지 않을까? 바로 이 '불가능'한 문제 때문에 일정이 늦어지고 있거나, 심지어 시스템을 작동하게 만드는 일 자체를 포기하고 있을지도 모르겠다.

잠시 딴짓을 하기 딱 좋은 시간이다. 잠깐 다른 일을 하라.
딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다.

나는 17,000쪽에 달하는 문서를 읽고 싶어 하는 인간을 만나본 적이 없다. 만약 만났더라면 유전자 풀에서 제거하기 위해 죽여버렸을 것이다. - 조지프 코스텔로

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

[ 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다. ]

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

물리적인 세계에서든 소프트웨어 개발에서든 애자일, 즉 기민함이란 것은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이기 때문이다. 
개발팀이나 개발자 개인도 마찬가지다. 소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다. 

애자일 하게 일하는 방법
1. 여러분이 어디에 있는지 알아내라.
2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
위 과정을 끝날 때까지 반복하라. 위 과정을 여러분이 하는 모든 일의 모든 층위에서 재귀적으로 적용하라.

프로그래머는 고양이 같은 면이 있다.
호기심 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다.

깨진 창문을 없애라. 품질은 팀의 문제다.
아무리 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면, 자질구레하게 계속되는 문제를 고치는데 필요한 열정을 유지하긴 어려울 것이다. 개발자가 이런 수정 작업을 하느라 시간을 쏟는 것을 팀이 적극적으로 방해하고 나선다면 문제는 더욱 커진다.

여러분의 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다. "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것이다. 할 일을 백로그로 관리하든 업무 목록이나 업무 흐름 도구를 사용하든 간에 기능 개발로만 몽땅 채우지는 말라. 
- 구형 시스템 유지보수
- 프로세스 회고와 개선
- 새로운 기술 탐험
- 학습 및 기술 갈고닦기
[ 실현하려면 계획하라. ]

당신이 사람들을 황홀하게 만들 때, 당신의 목표는 그들로부터 돈을 벌거나, 당신이 원하는 일을 시키는 것이 아닙니다. 사람들을 커다란 기쁨으로 충만하게 하는 것입니다. - 가이 가와사키

개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. 그래서 우리가 여기 있는 것이다. 

[ 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라. ]
여러분의 고객을 기쁘게 하고 싶다면 고객이 문제를 풀 때 적극적으로 도와줄 수 있는 관계를 구축하라. 여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. 우리는 문제를 해결한다.

실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다. 설계 혹은 코드를 맡는다면 자신이 보기에 자랑스러운 작품을 만들어 낼 것이다. [ 자신의 작품에 서명하라. ]