@독서 | @함께 자라기, 애자일로 가는 길

#함께 자라기, 애자일로 가는길    

---

#내가 좀 더 나은 사람이 되고, 좀 더 나은 개발자가 되는 것 그리고 그 것을 팀원들과 공유 하기 위한 방법론에 관한 책.

---

저자 : 김창준 출판사 : 인사이트

나의 생각

---

이 책을 읽으면서 저자의 깊고 넓은 견해에 대해 정말 많이 놀라웠다. 심리학부터 마케팅, 개발등 모든 분야별로 지식의 깊이가 남다르다는 생각을 하게 되었다. 그리고 좋은 말들이 워낙 많았기에 사실 이 책은 1년 마다 한 번씩 다시 보면 좋겠다는 생각을 했다. 

그리고 책을 다 읽기 전에 나와 같이 일하는 파트 분들에게 선물로 나누어 주었다.  정말 많은 공감을 했고, 남는 것이 많은 책이라 선물을 하고 싶었다. 특히나 시니어 개발자분들에게 선물로 주고 싶었다. 

그런 말이 나오는데, 비전문가일수록 자신이 최초에 설계한 것에 집착하려는 경향이 있다고 한다. 특히나 오히려 비전문가인 내가 보통 초기 설계에 집착하려는 모습을 작년에 깨닫게 되었다. 초기에 생각한 부분이 아닐수도 있고, 잘 되지 않을 수도 있는데도 불구하고 나는 그것에 목숨을 거는 경햠이 있었다. 그렇게 함으로써 더욱 복잡해지는데도 불구하고 그것이 정답이라 생각하곤 했다. 

어느 날, 멘토님에게서 그런 이야기를 들었다. 일 하면서 네가 원하는 대로 새로 생각한대로 다시 처음부터 작성하는게 더 빨리 끝날 수도 있다고 말이다. 

망치로 맞은 듯한 기분이었다. 나는 처음부터 방향이 여러 개인 길을 하나다! 오직 하나라고 여겨 그렇게만 진행을 하려고 한 것이 큰 잘못이자 실수였다. 이 책을 읽으면서 공감하는 부분이 왜이렇게나 많은지 모르겠다. 

나는 햇수로 4년차가 되었는데, 만으로 이제 만3년차가 되어 가면서 스트레스를 받곤 했다. 실력보다 연차가 더 빨리 쌓이는 것 같다. 

나의 실력은 어떻게 쌓아야 할까? 업무와 학습을 구분하려 했고, 항상 다른 별개로 치부 했다. 

그리고 내가 공부 하고자 하는 것은 시간이 없었고, 업무에서 필요한 기술을 익히는 시간을 만드느라 급급했다. 결국 내가 생각한 것들을 하지 못해 자기계발을 잘 못한다고 판단하곤 했다. 

그렇지만, 이 책을 읽으면서 내가 앞으로 어떻게 성장하고, 자라기 위해 의도적인 수련은 어떻게 해야 하는지 어렴풋이나마 갈피를 잡게 되었다. 

아무래도 이 책은 자라나는 새싹들에게 방향성을 제시 하는 책이라 생각했다. 그렇지만, 그 새싹이 이 험한 IT세계에서 경험치 많은 새싹일수도 있겠다.라는 생각이 들었다.

이 책을 읽는 우리들은 모두 함께 자라기를 꿈 꾸는 사람들이라는 생각이 들었다.

나도 자라고, 나의 옆에 있는 팀원도 자라기. 

내가 중요하다고 했던 이 책에 나온 부분들을 실천하는 개발자가 되겠다고 다짐하게 되었다.

좋은 글귀

---

내가 요즘에 얼마나 공부하고 수련하느냐로 내 직무 성과가 결정 된다는 이야기가 됩니다. 

1만 시간의 법칙에서 1만 시간은 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련을 한 시간을 일컫습니다. 그런 수련을 의도적 수련이라도 합니다. 그냥 경험이 아니고 매우 특수한 형태의 수련 방법입니다. 

피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것

자신이 이미 갖고 있는 것들을 잘 활용하라. 

• 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라.
•  이미 습득한 지식, 기술, 경험등을 서로 연결 지어서 시너지 효과가 나게 하고, 하나의 영역에서 다른 영역으로 왔다 갔다 하는 것을 자주 해서 다른 영역 간을 넘나 들기가 수월해지도록 하라.
• 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌하라.
• 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라.

외부 물질을 체화하라.

• 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 주기적인 외부 자극을 받으면 좋다. 대신 그 것을 재빨리 자기화해야 한다.
• 외부 물질 유입 이후 생긴 내부의 갈등을 해결하려는 데에 노력을 기울여야 한다. 무시하고 덮어두지 말라. 내가 가진 것들의 상생적 관계를 끌어내도록 하라.

자신을 개선하는 프로세스에 대해 생각해보라 

• 나의 작업 1을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라.
• 나를 개선하는 과정을 어떻게 하면 개선할 수 이쓸지 고민하라.

피드백을 자주 받아라

• 사이클 타임을 줄여라. 새로운 정보를 얻었다면, 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 혹은 1주 후에 작게라도 실험해 보는 것이 좋다.
• 순환율을 높여라.
• 일찍, 그리고 자주 실패하라. 실패에서 학습하라.

자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.

• 워드 커닝햄의 경우 자기의 수족을 마음대로 놀릴 수 없는 불편한 언어에서 프로그래밍을 하는 경우 점차적으로 자신을 도와주는 환경을 만들어 나간다. 
• 완벽한 도구와 환경을 갖추는 데에 집착해선 안 된다.

자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것입니다.

꾸준한 반복으로 달인이 되려면 적어도 실력을 개선하려는 동기가 있어야 하고, 구체적인 피드백을 적절한 시기에 받아야 한다.

일하는 방식, 개발하는 방식을 바꾸면 타당성과 피드백을 어느 정도 높일 수 있다.

타당성을 높이려면 변수를 제한하고 실험하면서 규칙성과 인과관계를 찾으려는 노력을 하면 된다. 피드백을 높이려면 동료나 상사, 고객에게서, 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하면 된다. 

실력을 높이기 위해서는 ‘의도적 수련(Deliberate Practice)’이 중요합니다. 

의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 합니다. 바로 이 때 최고 수준의 집중력을 보이고, 그 덕분에 퍼포먼스나 학습 능력이 최대치가 될 수 있다고 한다.

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 겁니다. 

지루함을 느끼는 경우: a1 실력 낮추기

• 지루함을 느끼고 있다면, 컴파일을 30초마다 한 번씩 한다면, 5분에 한 번씩으로 주기를 늘려 보는 것이죠. 

지루함을 느끼는 경우: a2 난이도 높이기

• 하루만에 개발하라고 주어진 업무를 한 시간내로 개발 해보기
• 평소 코드를 검토 할 때 버그를 시간당 하나 찾았다면, 두 개 찾기 
• 익숙한 작업을 새로운 언어로 진행해보기
• 안해도 되는 업무를 자신의 의지로 추가해보기 

상대의 전문성을 빠른 시간 내에 간파하는 기법 중에 남들보다 일을 좀 더 효율적/효과적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구 방법을 묻는 방법이 있다.

불안함을 느끼는 경우: a2 실력 높이기 

• 짝 프로그래밍
• 코드리뷰 받기
• 디버거, 자동 통합 도구
• 코드 분석툴

불안함을 느끼는 경우: b1 난이도 낮추기 

• 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 만드는 것을 첫 번째 목표로 삼기
• 같은 내용의 프로그램을 다른 언어로 만들어 보기

튜토리얼을 읽을 떄 다음 작성할 프로그램을 염두에 둔다는 점, 읽다가도 이 정도면 그 프로그램을 작성 할 수 있겠다는 생각이 들면, 그 자리에서 읽기를 멈추고 코딩을 시작합니다. 완성하게 되면 다시 돌아와서 읽기를 시작하고, 다시 다음 프로그램을 목표로 하는 것처럼 읽는 것을 적극적 읽기라고 한다. 

공부할 때, 표준 라이브러리 소스코드를 읽는다. 

공부 중에 다른 사람의 코드에 내가 필요한 기능을 추가 한다. 

그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각한다. 

전문가가 되면, 자신이 하는 일이 반복적으로 몸에 익고 자동화 되어서 결국 암묵적이 되어 버립니다. 

어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다.

신뢰가 꺠어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다. 

뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때, 사회적인 측면이 포함된다. 

뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했다. 

조엘테스트 

1. 소스컨트롤을 사용하는가?
2. 한 번에 빌드를 만들어 낼 수 있는가?
3. 일일 빌드를 만드는가?
4. 버그 데이터베이스를 가지고 있는가?
5. 새로운 코드를 작성하기 전에 버그를 고치는가?
6. 최신 업데이트 된 스케쥴이 있는가?
7. 스펙이 있는가?
8. 프로그래머가 조용한 작업 환경에서 일하는가?
9. 돈이 되는 한 최고의 툴을 사용하는가?
10. 테스터가 있는가?
11. 채용 면접 때, 후보가 코드르 짜게 해보는가?
12. 복도 사용성 테스트를 하는가? 

소프트웨어 개발을 잘 관리하려면 세 가지 근복적 능력이 필요하다. 

1. 복잡한 상황을 이해 하는 능력
2. 관찰하는 능력
3. 행동하는 능력

복수 공유는 신뢰도가 높아지고 성과도 더 좋아지게 한다.

상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요? 

전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 바텀업을 섞어 씁니다. 뛰어난 전문가일수록 더욱 그러합니다. 비전문가일수록 자신이 만든 애초에 세운 계획에 집착 했습니다. 오히려 전문가일수록 자신의 계획을 수정한 횟수가 많았습니다. 

비전문가는 아주 소수의 부분만 바꾸지만, 전문가는 전체적으로 손을 대고 바꿨다. 

고수는 상호 참조 전략을 쓰는 반면, 하수는 그렇지 않았다. 고수는 프로그램을 연구하면서 프로그램에서 이해한 것을 도메인 어휘로 번역한다. 그리고 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다. 이를 상호 참조 전략이라고 합니다.

뛰어난 팀이라면 거의 한 팀도 빠지지 않고, 공통적으로 갖고 있는 특징이 몇 가지 있는데, ‘삼투압적 의사소통’이 여기에 속한다. 

삼투압적 의사소통은 배어드는 소통 방식으로, 은연중에 서로 간에 정보가 스며드는 걸 말한다. 

일을 하면서 혹시 이거 이거 안되는데 아는 사람 있어요? 라고 물으면 다른 사람이 그것은 이래 이래서 그래요? 라고 하면서 서로 새롭고 가치 있는 정보를 서로 교환하게 된다. 

한 번에 처리 되는 일의 양을 줄여야 하고, 지속적인 흐름을 만들고 짧은 시간 내에 탑, 바텀 업을 오갈 수 있게 한다. 

심리적 안정감이란? 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때, 처벌 받거나 놀림받지 않을 거라는 믿음을 말한다. 

학습 속도가 빠른 팀은 새로운 기술을 조직적 차원의 도전으로 이해하고 받아들인다. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각한다. 

속도가 빠른 팀은 심리적으로 보호가 되고 있었다. 뭔가 새로운 것을 제안하고 시도 하는 데에 열려 있었고, 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다. 팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했습니다. 설사 그 새로운 방식이 효과가 없는 걸로 결론이 나더라도 말입니다. 

학습과 업무를 굳이 분리하지 말고 동체로 만들어라. 새로운 일의 방식을 실험해봅시다. 일단 30분만 업무 개션을 시도해 보는 겁니다. 

• 작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다. - 워드 커닝햄

학습 공동체를 구축해라.

주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아라.

---

남의 책을 읽는 데 시간을 보내라. 남이 고생한 것에 의해 쉽게 자기를 개선할 수 있다 - 소크라테스 -