함께 자라기-애자일로 가는 길

애자일로 가는 길

'함께'는 협력을 말하고, '자라기'는 학습을 말합니다. 무엇이건 실제 바깥세상(야생)에 임팩트를 남기려면 혼자 힘으로만 되는 게 없습니다. 함께 해야 합니다. 주변 사람들과 함께. 매일 부대끼는 동료들과 함께.

스스로 변하고 싶지만 계속 실패하는 사람, 조직을 개선하기 위한 시도를 하다가 오히려 데어본 사람, 불확실한 상황에서 합리적인 판단을 해야 하는 사람, 한 분야에서 전문성을 키워야 하는 사람에게 전문성을 키울 수 있는 제대로 된 방법을 알려줍니다. 어떤 분야에서 일하든 어느 위치에 있든 상관 없습니다.

이 책에서는 일하는 방법의 핵심과 통찰을 다룹니다. 개인의 힘으로는 극복할 수 없는 한계를 깨뜨리려면 모두가 같이 발전해야 합니다. 나 그리고 더 나아가 남을 변화시키는 삶에 대해 얘기합니다.

[목 차]

1 자라기
당신은 몇 년 차?
자기계발은 복리로 돌아온다
학습 프레임과 실행 프레임
가장 학습하기 힘든 직업이 살아남는다
달인이 되는 비결
수십 년 동안 전문가가 안 되는 비결
당신이 제자리걸음인 이유
의도적 수련의 일상적 예시
프로그래밍 언어 배우기의 달인
실수는 예방하는 것이 아니라 관리하는 것이다
뛰어난 선생에 대한 미신
나홀로 전문가에 대한 미신

2 함께
소프트웨어 관리자의 개선 우선순위
협력을 통한 추상화
신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
객관성의 주관성
이것도 모르세요?
하향식 접근의 함정
전문가팀이 실패하는 이유
구글이 밝힌 탁월한 팀의 비밀
쾌속 학습팀
프로젝트 확률론

3 애자일
애자일의 씨앗
애자일 도입 성공 요인 분석
당신의 조직에 새 방법론이 먹히지 않는 이유
애자일을 애자일스럽게 도입하기

[본 문]

골프 퍼팅 연습을 하는데, 공이 어디로 가는지 전혀 보지 않고 1,000개의 공을 친다고 생각해 보죠. 이건 도대체 뭘 연습하고 있는 걸까요? 뭔가 연습이 되긴 하겠죠. 하지만 정확하게 퍼팅하는 부분은 연습이 되질 않을 겁니다. 내가 잘했나 못 했나 알지 못하면 행동을 조정할 수가 없죠. 그래서 학습에서는 피드백이 중요합니다.
(/ pp.28~29)

가용시간을 늘리고, 쓸데없이 낭비되는 시간을 줄이고, 잠자는 시간을 줄이는 것이 더하기적 사고라면, 집단의 지능을 높이는 것은 곱하기적 사고입니다. 집단의 지능을 높이면 모든 지적 활동의 효율이 좋아지기 때문에 전반적인 개선(B 작업)이 일어나고, 특히나 개선 작업을 더 잘하게(C 작업) 되겠지요. 지금보다 속도가 더 날 수 있다는 겁니다.
(/ p.38)

우리의 일자리가 인공지능으로 대체되지 않으려면, 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 하는 상황이 된 것입니다.
(/ p.47)

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 겁니다. 더 무서운 건 점차 이런 환경에 익숙해지고 행동이 습관화된다는 점이죠. 그때는 자기 인식도 잘 되지 않습니다.
(/ p.64)

전문가도 1시간에 평균 3~5개의 실수를 저지른다고 합니다. 그런데, 왜 우리 세상은 그렇게 엉망이 아닐까요? 그것은 전문가들이 실수를 조기에 발견하고 빠른 조치를 취할 수 있기 때문입니다. 이렇게 "실수는 어떻게든 할 수밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 된다"는 겁니다. 이 태도를 실수 관리라고 합니다.
(/ p.91)

결국 결정하는 것은 사람입니다. 그 사람 마음에 드냐 안 드냐, 이겁니다. 안 들면 어떤 이유를 들어서든 반대하게 됩니다. 도대체'누구'의 객관이냐 이거죠. 가만히 보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저질러 왔습니다.
(/ p.139)

두 개의 팀을 상상해 봅시다. 한 팀은 서로 잘 물어보지 않고, 물어봐도 "이것도 모르세요?"의 수준으로 대답해 줍니다. 반대로 다른 팀은 서로 코칭을 해주면서 함께 동기와 의지를 북돋워주고 같이 고민해줍니다. 어느 팀의 사람들이 성장할까요?
(/ p.152)

"일정 안에 가능한가요?" 모두 가능하다고 합니다. 7명이 각기 90% 확률의 확신을 갖고 있다고 답했다고 칩시다. ...[중략]... 이 경우 확률을 계산하려면 0.9를 일곱 번 곱해야 합니다. 그러면 0.48이 나옵니다. 즉, 모든 개발자가 90%의 확률로 안심을 하고 있지만 전체 프로젝트 입장에서는 마감일에 맞출 확률이 동전 던지기에서 앞면이 나올 확률보다 안 나오는 것입니다.
(/ pp.181~184)