[짧은 책 리뷰]함께 자라기 애자일로 가는 길

zzarbttoo·2021년 12월 8일
0

짧은책리뷰

목록 보기
1/1

개발바닥을 시청하던 중 김영한님이 이 책에 대해 추천하는 것을 보았다
그래서 바로 도서관에 가서 데려왔다

맨 뒷장이 인상깊다



이 책에서 함께는 협력을, 자라기는 학습을 말한다고 한다
책에서 개인적으로 필요한 부분을 정리해보았다 🙌

1. 자라기

경력이 모든 것을 말해주지는 않는다

연차가 얼마 안됐을 때 경력은 도움이 되지만 그렇지 않으면 크게 상관 관계가 없다
1만시간의 법칙은 경험을 말하는게 아니라 의도적 수련을 말하는 것이다
(칫솔질을 1만시간 넘게 한다고 전문가가 되지 않는다구~)
성장하기 위해서는 피드백을 짧은 주기로 얻는 것, 실수를 교정할 기회가 있는 것이 중요

좋은 사람을 뽑아도 성장할 수 있는 시스템 안에 있어야한다

조직에는 세가지 개선이 있다

A 서비스 결과물 개선
B 프로세스 개선
C 프로세스 개선안의 개선안

뒤로갈수록 복리의 효과로 성장하게 된다(부트스트랩핑)

집단의 지성을 높히는 것은 B, C를 해결하는 것이며 전반적인 효율을 가져온다
(잠자는 시간을 줄이는 것은 더하기적 사고이고 집단의 지성을 높히는 것은 곱하기적 사고)

자기개발은 복리의 효과를 가져온다

자기계발은 복리이다
지금 당장 안하면 지금 안좋은 것이 아니라 내년, 내후년에 추락을 경험할 것이다
반대로 자기계발이 축적되면 엄청난 차이를 만들어낸다

잘하기보다는 자라기에 초점을 맞춘다

학습프레임(성정하는 것에 초점, 다양한 방식으로 문제를 풀이)에 초점을 맞추는 것이 실행프레임(잘하기)에 초점을 맞추는 것 보다 더 큰 성장의 여지를 준다

같은 신입이더라도 어떠한 프레임에 초점을 맞추느냐에 따라 결과는 다르게 나올 수 있다
(적극성의 차이인거 같기도?)

전문성을 기르기 위한 조건

  1. 개선하려는 동기가 필요하고
  2. 구체적인 피드백을 적절한 시기에 받아야한다

전문성을 형성하기 위해서는 업무에 타당성(인과관계, 예측가능성)과 피드백이 필요하다

뛰어난 선수는 자기가 못하는 것을 연습하지만 뛰어나지 않은 선수는 자기가 잘하는 것을 연습한다

★ 제자리 걸음에서 벗어나기(몰입을 하기 위한 변화)

a1 : 지루함을 느끼는 경우 실력을 낮춘다

  • 평상시에 사용하는 보조도구(키보드), 디버깅 도구 사용 X, 컴파일 주기 낮추기 등

a2 : 지루함을 느끼는 경우 난이도를 높힌다 (제약 추가)

  • 100rps -> 1000rps 감당 시스템 만들기, 시간당 찾는 버그 늘리기, 익숙한 작업은 다른 언어로 짜보기, 업무 개선하기(안해도 되는 일 만들어서 해보기)

b2 : 불안함을 느낄 때 실력을 높여 몰입 영역으로 간다

  • 사회적 접근(페어프로그래밍, 고수에게 물어보기) , 도구적 접근(툴 사용), 내관적 접근(비슷한 일을 했던 경험 살려보기) 등으로 문제를 해결

b1 : 불안함을 느낄 때 난이도를 낮추어 몰입 영역으로 간다

  • 개발해야 하는 가장 핵심적인 부분에 대해서만 개발을 한 후 기능을 추가해나간다
  • ex ) 알고리즘 수업을 할 때 스크립트 언어인 파이썬으로 먼저 개발을 한 후 C로 바꾸어 개발을 해 알고리즘 로직과 로우레벨에 대한 이해를 동시에 함

이러한 방식으로 난이도를 조정할 수 있으며 난이도는 버그 유무, 새로운 업무 추가, 전략 잘 못 짬 등에 따라 요동치기 때문에 항상 나의 감정상태를 보고 조절을 할 수 있어야 한다

팀장은 팀원의 상태를 항상 살피며 팀원이 몰입의 단계로 갈 수 있도록 해야한다

새로운 언어를 배우는 쉬운 방법

빠르게 언어를 학습하는 방법은 적극적으로 학습하는 것이다

  • 튜토리얼을 만들때에도 무엇을 만들지 생각을 하며 소스코드를 읽는다
  • 표준 라이브러리 소스코드를 읽는다(언어간 기능의 차이는 없어도 유지보수 용이성의 차이 발생)
  • 다른 사람의 코드에 내가 필요한 기능을 추가한다(오픈소스 등)

실수 문화

  1. 실수 예방 : 실수 자체를 예방하는 문화
  2. 실수 관리 : 실수 후 실수를 통해 학습할 수 있고 대비할 수 있도록 하는 문화

실수 관리 문화가 있을수록 실수를 통해 학습하는 경우가 많기 때문에 회사의 수익성이 높다
따라서 실수를 격려하는 문화가 필요하다

뛰어난 선생?

학생을 가르칠때 선생은 자신이 인지하지 못한 자동화된 부분에 대해 빼고 가르치기 때문에
지식의 30% 정도밖에 전달하지 못하게 된다
많이 아는 선생이 잘 가르치는 것은 아니라는것이다

때문에 가르칠 때는 문제 해결시 어떠한 과정을 거치는가에 대해 알려주는 것이 중요하다

나홀로 전문가에 대한 미신(신뢰 또한 사회적 자산)

  • 결국 좋은 기술이라도 사람들이 싫어하면 도입하지 못한다
  • 평판도 자산이다
  • 새로운 기술을 도입할 때에도 기술적 요인보다 사회적 요인이 더 병목이 될 수도 있다
  • 뛰어난 개발자일수록 인터렉션에 신경쓰고 협력에 대해 강조한다
  • 사회적 기술은 주위 사람들과 주고받는 상호작용을 기록하고 복기하고 다르게 행동하는 것을 시뮬레이션 하는 과정에서 훈련된더

2. 함께

이게 협업..?(이게 맞아..?)

업무를 세밀하게 나누고 이를 끼워 맞추는 것이 협업은 아니다
(내가 이제까지 한 것은 협업이 아니라 분업이었나보다)

  • 페어프로그래밍을 통해 코드의 추상성을 높이고 서로 다른 관점으로 코드를 짤 수 있다

공유가 신뢰를 만든다?

  • 공유를 하는 것이 신뢰감을 높힌다고 생각하지만 오히려 하나만 공유했을 때는 불안감 때문에 신뢰감이 떨어졌다
  • 복수개의 결과물을 공유했을 때는 작업물 == 나 라는 생각이 없기 때문에 불안감이 덜해졌고 성과도 좋았다
  • 신뢰를 떨어트리는 공유와 신뢰를 높히는 공유가 있기 때문에 잘 선택해서 해야한다

조용한 환경이 도움이 되는가

  • 팀이 만드는 소음은 더이상 소음이 아니며, 면대면 의사소통은 협력에 중요하기 때문에 조용한 환경만을 선호해서는 안된다(뜨끔)

정말 객관적인 것은 존재하는가

  • 객관적인 것만으로는 사람을 설득할 수 없다
  • 객관적인 것도 사실 주관적인 것이다
  • 결국 설득하려는 사람에게 기존에 신뢰를 쌓아야하고, 사람마다 다른 설득 전략을 취하는 수 밖에 없다
  • 설득을 하기 위해서는 그 사람을 이해하는 것에서 출발해야한다

올바르게 질문을 받아주는 방식

  1. 잘못된 방식
  • 팀 전체에 문제가 발생했을 때 이렇게 질문을 받은 사람의 책임이 크다
  • 면박을 줄 경우 또 질문을 할 가능성이 낮아지고 혼자 문제를 떠안고 해결하지 못 할 가능성이 높다
  1. 이해하는 대화
  • 왜 업무를 이렇게 처리했는가에 대해 이해를 하며 질문을 받아주는 방식
  1. 행동을 유도하는 대화
  • 2번 + 동기부여 + 목표 수립까지 하는 대화

능력이 없을수록 1번처럼 한다는데(머리의 생각을 구체적으로 정리하는 것이 어렵고 귀찮아서)
나도 그랬던 적이 많을 것 같다
일단 2번처럼이라도 할 수 있도록 노력해야지

전문가는 무조건 탑다운?

  • 난해한 문제를 풀 때 문제를 한번에 파악하기 어렵기 때문에 전문가는 탑다운만 고수하기 보다는 탑다운과 바텀업을 모두 섞어서 사용하게 된다
  • 완벽한 계획은 없고 오히려 탑다운만 고수할 경우 업무를 잘못할 수 있다

팀은 전문가로 이루어져야만 한다?

  • 팀내 전문가가 많아도 협업이 안되면 오히려 성과가 낮은 것을 볼 수 있었다

개인이 잘 하는 것 보다는 팀단위로 성장하는 것이 중요

  • 성공한 리더 하나가 있는 것 보다 팀단위로 학습을 진행하는 것이 더 효율적이었다
  • 성공하는 회사는 심리적 안정감이 있어야한다(실패해도 면박을 받지 않을것이라는 믿음)
  • 팀단위를 바꿀 힘이 아직 없다면 내 학습환경부터 바꾸어나가면 된다
  • 작교 유용한 프로그램을 매일 짜는 것이 중요하다

3. 애자일

애자일 업무 방식

  • 개인이 프로젝트를 병렬로 맡는 것 보다 여러 명이 한 문제를 푸는 것이 더 효율적일 수 있다
  • 애자일은 일을 공유하고 업무의 경계가 뚜렷하지 않다
  • 애자일은 지식을 공유하는 방식으로 이루어진다

그래서 애자일이 무엇인가

  • 애자일은 고객 참여가 중요하다
  • 이건 아마 서비스 가능한지를 염두에 두고 코드를 짜는 것과 같다고 생각하면 될 듯 하다

결국은 애자일이라는 방법론보다는 누군가가 참여를 하는가가 중요한 문제이다
그리고 좋은 팀장, 팀원들의 역할이 중요하다고 생각했다


살면서 팀플도 많이 했고, 팀장 역할도 많이 했지만 이걸 읽으면서 생각해보니 좋은 팀장/팀원은 아니었던 것 같다
특히 질문을 받아주는 방식에 대해서는 정말 내가 많이 잘못을 했던거구나 하고 반성을 하게 됐다
(+ 애초에 실력이 별로 없어서 그랬던거 같기도 하다)

다행히 아직 살 날이 많은 것 같고, 업무를 할 날도 많아 보이니 이런 서적들을 참고해서
남은 날들이라도 좋은 팀장/팀원이 되도록 노력해야겠다는 생각을 했다

profile
나는야 누워있는 개발머신

0개의 댓글