📍책 정보
- 제목: 함께 자라기(애자일로 가는 길)
- 작가: 김창준
- 출간연도: 2018
📍직원을 뽑을 때 무엇이 그 사람의 실력을 가장 잘 예측할까?
상관성의 정도
- 0.5 초과: 강한 상관성
- 0.2 ~ 0.5: 중간
- 0.2 이하: 약한 상관성
존 헌터의 미 연방 정부 채용 및 성과 데이터 분석 결과를 살펴보면..
예상보다 직원의 성과와 상관성이 낮았던 선발 요소
- 학력: 0.1
- 경력: 0.18 -> 0년차 vs 2년차 비교 시에는 유효하나 이외에는 무의미
-> 즉, 경력과 업무 수행 능력에 깊은 상관성이 없는 것으로 나타남
- 관심사(취미활동): 0.1
- 나이: -0.01
직원 성과와 상관성 높았던 선발 요소
- 작업 샘플 테스트(실제로 채용 후 해야할 작업의 일부를 해보는 테스트): 0.54
- 지능 테스트: 0.51
- 구조화된 인터뷰: 0.51
- 성격 테스트: 0.41 ~ 0.31
- 레퍼런스 체크: 0.26
📍학습에서 중요한 것
1. 피드백을 짧은 주기로 얻는 것
일반적인 프로젝트에서는 설계 단계에서 했던 결정의 피드백을 몇 달 후(테스트 단계) 에 받게 됨
-> 그 때 쯤 되면 자신의 결정이 기억에 가물함
-> 즉, 피드백 주기가 길어지면 학습이 잘 안됨
애자일 프로젝트에서는 피드백을 10분, 1시간, 하루, 일주일 등 짧은 시간 후에 받음
2. 실수를 교정할 기회가 있는 것
- 내가 잘 했나 못 했나 알지 못하면 행동을 조정할 수 없다
3. 의도적 수련
- 자신의 실력을 향상시키기 위한 의도적 훈련
- 단순한 경험이나 반복이 아님
📍프로그래머 vs 소프트웨어 개발자
프로그래머와 소프트웨어 개발자의 명칭 차이가 중요하지는 않지만.. 미국 노동부에서는 아래의 기준으로 나눴다
- 프로그래머: 스펙대로 코드를 만드는 사람
- 소프트웨어 개발자: 사용자의 요구사항을 분석하고, 그에 대한 솔루션을 설계하는 것까지 포함
현재 자신의 업무 상황 속에서 창의적으로, 사회적으로 일하지 않는 기간이 계속된다면, 결국 자신의 커리어에 막대한 손해가 될 수 있다
- 사회적 업무: 다른 사람의 생각과 마음에 관심을 갖고, 그들을 설득하고, 협상하는 등의 일
-> 혼자서 딱 정해진 일만 할 수 있는 환경은 축복이 아니라 저주가 될 수 있다
📍달인이 되는 법
1. 실력을 개선하려는 동기
2. 구체적인 피드백을 적절한 시기에 받아야 한다
📍전문성을 기르는 법
수십년 동안 일하면서 전문가가 안 되는 비결
- 타당성과 피드백이 부족한 환경에서 일하는 것
- 예) 공항 수화물 검사 직원은 자신이 얼마나 실수를 했는지 모름. 얼마나 많은 칼이나 마약류를 놓쳤는지 알 수 없기 때문에
📍타당성을 기르는 법
- 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려 노력하기
📍실력을 기르는 법
미하이 칙센미하이의 몰입 이론
- 과제 난이도와 현재 실력이 엇비슷해야 몰입하며 집중력과 퍼포먼스를 최대로 발휘하게 된다
- 또한 학습과 행복감도 제일 높다
업무중에 불안감이나 지루함을 느끼고 있다면, 성장에 도움이 되는 환경이 아니므로 다른 방법 강구 필요
몰입 이론에 기반한 실력 높이는 전략 4가지
지루함 낮추기1 (실력 낮추기)
- 평소 쓰던 IDE 자동 완성 기능을 일부러 쓰지 않거나, 마우스 대신 키보드로만 개발하기
- 좀 더 집중해야 하고, 머릿속으로 좀 더 많은 연산을 해야 함
지루함 낮추기2 (난이도 높이기)
- 더 빨리 해내기 (하루가 주어진 작업을 1시간 내로 끝내는 방법 찾기)
- 새로운 방법으로 해결해보기
- 더 효율적으로 앱이 동작하게 만들기
- 굳이 할 필요 없는 작업도 해보기 (테스트 코드 붙이기, 리팩토링 등)
- 더 빠르고 효율적으로 처리하기 위한 나만의 방법이나 도구 만들기
불안함 낮추기1 (실력 높이기)
- 잘하는 사람에게 도움 청하기
- 스터디
- 과거의 경험 살펴보기
불안함 낮추기2 (난이도 낮추기)
- 간단하면서 핵심적인 목표만 달성하기
- 연구 예시) 쉬운 작업을 하고나서 어려운 작업을 한 피실험자들의 에러 발생률이 더 낮았음
- 몰입과 자기효능감이 늘어 자신감을 얻고 더 큰 문제에 도전하기 쉬워짐
이러한 방법들을 섞어서 즉각적으로 방법을 바꿔가며 진행해야 함
- 메타인지: 자기가 현재 어떤 상태인지 계속 알아차리는 것
📍프로그래밍 언어 빨리 배우는 방법
1. 튜토리얼을 읽을 때, 무엇을 만들지 생각하고 읽는다
- 읽다가 이제 프로그램을 만들 수 있겠다 생각이 들면, 공부를 중단하고 바로 코딩 시작
예) 단어 카운터 프로그램 만들어보며 반복문, 함수 개념 사용
2. 공부할 때 표준 라이브러리 소스코드 읽는다
- 언어의 창시자(또는 메인테이너 그룹)가 만들었기 언어의 철학과 코드 사용 패턴을 가장 정확하게 익힐 수 있음
📍실수 예방 대신 실수 관리
- 전문가들도 실수를 한다. 따라서 실수를 예방하는 것보다 빠르게 발견해서 해결하는 것이 더욱 중요하다.
- 실수 예방 문화: 실수 일으킨 사람을 비난
- 실수 관리 문화: 실수로부터 학습하려고 하고 문제 해결에 초점
- 실수 관리 문화를 갖춘 회사의 수익성이 더 높다
실수가 없으면 학습할 수 없다
📍협력을 통한 추상화
심리학자 대니얼 슈와르츠가 톱니바퀴 문제를 주고, 개인, 두 사람이 각각 문제를 풀게 했다
- 문제) N개의 톱니바퀴가 있을 때, 가장 왼쪽의 톱니바퀴를 시계/반시계로 돌릴 때 가장 오른쪽의 톱니바퀴는 어느 방향으로 돌까?
(톱니바퀴 수가 짝/홀수 에 따라 추상화된 규칙성을 찾는 문제)
- 개인의 경우 14%만 추상화된 규칙을 찾아냄
- 두 사람의 경우 58%가 추상화된 규칙을 찾아냄
=> 같이 작업하는 경우 추상화 경향성 높음
=> 둘이서 협력하면서 작업하면 서로 시각이 달라서, 두 사람을 연결해줄 다리(추상화 요소)가 필요하기 때문
=> 혼자 작업할 때는 추상화의 필요가 덜함
비즈니스 로직의 경우, 가독성이 중요하지만, 때때로 가독성을 희생하며 중복을 제거하면서(추상화) 인사이트를 얻을 수 있음
📍복수 공유(share multiple)의 장점
팀원간 신뢰성을 높일 수 있음
예) 디자이너 A, B 가 각자 디자인 작업물을 공유할 때
- 단수 공유 등에 비해 상대방의 부담을 덜어줄 수 있음 (거절, 지적할 필요 없이 하나 선택해주면 됨)
- 작업자 입장에서도 자신의 작업물에 대해 부정적 피드백을 들을 걱정이 없어서 불필요한 방어심리가 줄어듬
=> 복수 공유 결과, 신뢰성, 전문가, 고객 평가가 더 높았음 (신뢰성 뿐만 아니라 성과도 좋음)
📍감정을 배제할 수 없다
합리적 평가를 위해 알고리즘이나 규칙을 도입했다고 하자, 그래도 결국 평가자의 맘에 들지 않으면 알고리즘이 잘못됐다고 판정됨
남을 설득하려면 객관성에 대한 환상을 버려야 함
- 설득하고 싶은 상대를 자주 만나 신뢰를 쌓고
- 그 사람이 무엇을 중요하게 여기는지 이해해야 함
=> 설득은 자료가 아닌, 내가 설득하려는 사람에게서 출발해야 한다
예) 애자일 도입을 꺼려하는 팀원들을 설득할 때, 팀원들이 나를 좋아하나? 신뢰하나? 먼저 생각해야 함
📍공감하며 도와주기
후배 개발자의 질문을 받았을 때, 상대방이 어떤 멘탈 모델을 갖고 있는지 파악하면서 공감해주면서 들어줘야 한다
- 어떤 시도를 했냐
- 어떻게 검색했냐
- 어디서 자료를 찾았냐
📍전문가 vs 비전문가
시작
- 전문가는 상황 파악 먼저 (초보자는 뭘 할지부터 정하려고 함)
바텀업 vs 탑다운
전문가들은 바텀업과 탑다운을 섞어가며 일함 -> w 모양을 그리며
- 바텀업과 탑다운이 전환되는 순간 아하 모먼트(A-ha Moment) 발생
비전문가는 초기 계획에 집착하고 아주 소수의 부분만 바꾸며 일함
반면, 전문가는 계획을 빈번하게 수정
📍고성과 개발자들의 특징
1. 상호 참조 전략을 활용
상호참조 전략
- 프로그램을 이해할 때, 프로그램에서 이해한 것을 도메인 어휘로 바꿔서 검증
2. 추상과 구체의 차원을 자주 오감
하수는 두 세계를 빈번히 연결하려는 노력 안함 -> 한 쪽에만 집중
📍효과적인 팀 구조
애자일 관점에서
1) 한 사람이 다기능을 갖추고 (소기능 집중보다)
2) 협력이 쉽게 되도록 하는 것이 좋음
업무를 주고 받는데서(인수인계 등) 오버헤드가 크기 때문
- 오버헤드가 적어야 하고 덜 일어나게 해야한다
=> 이렇게 하려면 한번에 처리하는 일의 크기가 작아져야 함
전문가들만 모아서 팀 만든다고 잘하는 게 아니고 오히려 성과가 떨어질 수 있음
정보 공유 및 협력을 잘하기 위한 명시적 도움이 필요
소셜 스킬을 갖춘 제네럴리스트가 있으면 도움이 된다
팀원들의 심리적 안전감이 성과에 지대한 영향
- 실수를 예방보다 관리하려고 해야 함
- 실수했다고 혼나는게 아니라 빠르게 해결하는 것에 초점
📍학습과 일은 하나다
학습은 실행에서 이루어진다 지금 당장하지 않으면 계획만 세우다 끝낼 확률이 50%
- 일단 30분만 해보기!
- 워드 커닝햄의 명언
작지만 유용한 프로그램들을 매일 작성할 것
📍프로젝트 확률론
일의 소요 시간 추정 및 일정 안에 완료될지 판단할 때
- 사람들이 통상적으로 추정하는 소요시간의 2~3배는 해야 80% 정도의 확률로 마칠 수 있다
- 일의 소요 시간을 추정할 때, 대부분의 사람들이 낙관적으로 추정
📍애자일(agile) 방법론
프로젝트에 존재하는 불확실성 때문에, 미리 분석, 설계 등을 하는 의미가 없어짐
- 따라서 짧은 피드백 주기에 따라 개발 진행
실패가 OR 조건이 아닌 AND 조건으로 발생하게 관리해야 함
- OR 조건은 발생이 쉽고, 한 가지 요소가 전체에 영향을 끼칠 수 있음 (하나만 만족해도 전체 조건이 참)
- AND 조건은 모든 조건이 만족되어야 하므로 발생이 어려움
예) 애자일에서의 코드 리뷰
애자일의 핵심: 고객에게 매일 가치를 전하라
1) 고객에게
- 우리의 진짜 고객은 누구인가?
2) 매일
- 어떻게 점진적으로 가치를 전할 것인가?
- 어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?
3) 가치를
- 무엇이 가치인가?
- 지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?
- 지금 가장 높은(중요한) 가치는 무엇인가?
- 비슷한 수준의 가치를 더 값싸게 전달하는 방법은?
4) 전하라
- 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?
- 고객이 정말 가치를 얻고 있는가?
애자일 실천법중에서 프로젝트 성공과 상관성이 높은 것들
- 고객 참여: 0.77 (애자일 성숙도가 낮은 조직에서 상관성이 0.94로 매우 높아짐)
=> 고객이란 프로젝트 성패를 좌우하는 사람
=> 고객을 설득해야 함(참여를 위해)
=> 고객에게 빠른 피드백 획득 등
- 리팩터링: 0.42
- 코딩 후 자동화 테스트 붙이기: 0.38
- 코드 공유: 0.37
=> 개발자 설득 (이 코드가 보다 좋은 코드임을 설득)
- 짧은 반복 개발 주기: (애자일 성숙도가 높은 조직에서 상관성이 0.49)
무섭고 두렵더라도 중요한 일이면 꼭 해야 함 (안할 경우의 리스크가 너무 큼)