독서 - 함께자라기, 애자일

함께자라기를 읽고

“학습 속도가 빠른 팀” 에 대한 내용이 이전 회사의 프론트엔드 팀에 해당하는 것 같아 뿌듯했다. 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조하고, 학습이 실행과 동시에 이루어 지고, 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고 같이 학습해야 한다고 생각하고, 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했던 것이 해당했다.

그리고 “나홀로 전문가에 대한 미신” 을 읽고 반성을 많이 했는데,

TDD 도입이 실패하는 경우, 사람들이 TDD의 기술적 내용을 잘 몰라서보다도 TDD를 도입하는 데에 필요한 사회적 자본과 사회적 기술이 없어서가 훨씬 더 많았습니다

“아니다. 절대 부정할 수 없는 자료를 들이밀어야 한다” 라고 말하는 분들이 있지만, 마음에 안 들면 어떤 ‘객관적’자료를 갖다 줘도 설득할 수 없습니다. 특히나 그 자료에 “당신의 생각이 틀렸다”라는 암시가 강하게 있다면(그리고 그렇게 해서 그들의 코를 납작하게 해 주고 싶다면) 더 더욱 설득이 어렵습니다.

이 내용을 보고 이전 회사에서 백엔드 개발자들과 Rest API 에 대한 이야기를 하기 전에 그 분들과 유대관계를 만들었으면 어땠을까 하는 생각도 들었고, 내 의사소통 방식이 오만했을수도 있겠구나 하는 반성도 했다.

내 고객은 내 동료라는 것을 다시 마음속에 새겨야겠다.


1부 자라기

당신은 몇 년 차?

  • 경력 연차라는 것으로부터 이 사람이 초급인지 아닌지 정도의 정보만 기대할 수 있으며
  • 초급이 아닌 사람들에 대해서는 경력 연차가 오히려 혼동을 불러일으키는 잘못된 정보로 적용할 수 있고
  • 고로 경력 연차로 채용 여부나 임금 수준을 결정하는 것은 판단 편의적이고 관료주의적이며 결과적으로 조직에 손해를 줄 수 있는 방식
  • 구인 프로세스 대안
    • 구조화된 인터뷰(행동 중심적 인터뷰)
    • 작업 샘플 테스트
    • 짧은 기간동안 일을 해보게 하는 것
    • 함께 일할 사람들이 인터뷰에 참여 하는 것
  • 내가 요즘에 얼마나 공부하고 수련하느냐로 내 직무 성과가 결정된다

자기계발은 복리로 돌아온다

직장인이 투자하는 하루 평균 자기계발 시간으로는 12시간 정도가 54.1%로 1위, 1시간 미만 33.8%, 23시간 9.4%, 3시간 이상 2.8%

자기가 습득한 지식이나 능력은 복리로 이자가 붙습니다

가용시간을 늘리고, 쓸데없이 낭비되는 시간을 줄이고, 잠자는 시간을 줄이는 것이 더하기적 사고라면, 집단의 지능을 높이는 것은 곱하기적 사고입니다. 집단의 지능을 높이면 모든 지적 활동의 효율이 좋아지기 때문에 전반적인 개선이 일어나고, 특히나 개선 작업을 더 잘하게 됩니다.

  1. 더하기보다 곱하기를 할 수 있을 것인가
  2. 어떻게 곱하는 비율을 높일 수 있는가, 혹은 이자적용 주기를 짧게 할 수 있는가

| 자신이 이미 갖고 있는 것들을 잘 활용하라 | - 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다. 자신이 올해 몇 권을 읽었다고 자랑하지 말고, 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라

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

| --- | --- | | 외부 물질을 체화하라 | - 외부 자극을 받으면 재빨리 자기화 해야 한다.

  • 외부 물질 유입 이후 생긴 내부의 갈등을 해결하는 데에 노력을 기울여야 한다. |

| 자신을 개선하는 프로세스에 대해 생각해 보라 | - 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라

  • 나를 개선하는 과정을 어떻게 하면 개선할 수 있을지 고민하라 |

| 피드백을 자주 받아라 | - 사이클 타임을 줄여라 1달, 혹은 1주 후에 작게라도 실험해 보는 것이 좋다

  • 일찍, 그리고 자주 실패하라. 실패에서 학습하라 |

| 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라 | - 마음대로 할 수 없는 불편한 환경에서 점차적으로 자신을 도와주는 확녕을 만들어라

  • 완벽한 도구와 환경을 갖추는 데에 집착해선 안 된다. |

학습 프레임과 실행 프레임

실행프레임은 사람들이 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀입니다.

학습프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀을 말합니다.

실행프레임은 여러분의 목표가 학습을 통한 성장이라면 불리한 선택입니다.

가장 학습하기 힘든 직업이 살아남는다

학습하기 힘든 환경과 주제

  • 목표(Goal)가 모호하고 주관적일 수 있으며 동적이다.
  • 매 순간 선택할 수 있는 행동/선택의 종류(Move)가 불확실하다.
  • 매 순간 내가 목표에 얼마나 근접했는지를 알기 어렵다(내가 한 선택의 피드백을 빨리 얻기 어렵다)
  • 주로 열린 시스템(즉, 예상 못 한 외부 요소가 갑자기 들어오는 경우가 흔한) 속에서 일한다.
  • 과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.

컴퓨터로 대체되기 힘든 일

  • 독창성 : 독창적인 방법 생각해내기
  • 사회적 민감성 : 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
  • 협상 : 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
  • 설득 : 다른 사람들이 마음이나 행동을 바꾸게 설득하기
  • 타인을 돕고 돌보기 : 개인적 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것

어떤 직업을 컴퓨터화할 수 있는 확률이 높을수록 해당 임금이 낮았다는 뜻입니다.

해당 직업에서 독창성, 사회적 민감성, 협상, 설득, 타인을 돕고 돌보기 같은 것들이 요구되는 수준이 높을수로고 그 직업은 컴퓨터화하기 힘듭니다.

컴퓨터 프로그래머 다른 사람이 준 스펙대로 개발하는 것
소프트웨어 개발자 뭘 만들지를 고민하고 설계하는 부분이 포함, 그 과정에서 타인과 상호작용하는 업무가 많음

달인이 되는 비결

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

수십 년 동안 전문가가 안 되는 비결

타당성과 피드백 높이기

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

당신이 제자리걸음인 이유

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

더 뛰어난 스케이터가 엉당방아를 더 자주 찧을 수 있다는 것입니다.

  • 제자리걸음에서 벗어나기

자기가 지금 어떤 상태인지 살피는 알아차림이 꼭 필요합니다. 메타인지 전략이라고도 하는데, 교육학과 심리학 연구에서 공부를 잘하는 사람들의 중요한 특징 중 하나로 꼽습니다.

의도적 수련의 일상적 예시

  • 난이도 조절을 적극적으로 점진적으로
  • 적용 범위, 대상을 작게 시작해서 더 넓게, 다양하게 확장
  • 처음엔 자신에게 적용

프로그래밍 언어 배우기의 달인

역엔지니어링 : 설계도 없이 완성품으로부터 설계를 추론하는 것

  1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다
    • 튜토리얼을 읽다가도 이 정도면 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작합니다.
    • 첫 번째 목표로 주로 삼는 프로그램은 단어 개수 세기 프로그램입니다.
    • 이 문제를 염두에 두고 글을 읽으면 "이 언어에서 루프는 어떻게 짜야 하지?", "글자 하나를 읽으려면 어떻게 하지?", "출력은 어떻게 하지?" 같은 질문들을 갖고 적극적으로 읽게 되겠죠. 또, 여러 언어에서 같은 프로그램을 작성하면서 언어 사이의 차이를 쉽게 느낄 수 있을 겁니다.
  2. 공부할 때 표준 라이브러리 소스코드를 읽는다.
    • 튜토리얼을 읽어 나가면서 틈틈이 해당 언어의 표준 라이브러리를 찾아 읽습니다.
    • 어떤 스타일을 따르고 어떤 숙어를 사용했는가 입니다. 이것이 프로그램 기능의 차이를 가져오지 않을지는 몰라도, 프로그램 작성 비용과 유지보수 비용을 좌우하게 됩니다.
  3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
    • 그 당시에 자신이 만들 수 있는 작고 간단한 추가 기능을 생각해 낼 수 있다.
  4. 전문성을 효과적으로 뽑아내는 전문가 되기
    • 전문가가 구체적인 사건에 대해 말하도록 유도하기

실수는 예방하는 것이 아니라 관리하는 것이다

  • 실수는 어떻게든 할 수밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 된다.
  • 회사 문화가 실수 예방 보다 실수 관리 에 가까울수록 그 기업의 혁신 정도가 높고 회사의 수익성이 더 높았습니다.
  • 실수가 없으면 학습하지 못합니다.
  • 교육 중에 실수를 더 유도해야 오히려 학습 전이가 더 잘 일어납니다.

뛰어난 선생에 대한 미신

  • 내가 이 문제를 해결할 때 어떤 과정을 거치는가”를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석하는 것이죠. 그리고 학생들이 이걸 배우면서 어떤 생각을 하는가를 직접 관찰하고 질문을 던지고 분석할 수 있을 겁니다.

나홀로 전문가에 대한 미신

  • 어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다
  • 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때 사회적인 측면이 포함됩니다. 기술적인 조언만 하는 게 아니라는 뜻입니다.
  • 뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했습니다.
  • TDD 도입이 실패하는 경우, 사람들이 TDD의 기술적 내용을 잘 몰라서보다도 TDD를 도입하는 데에 필요한 사회적 자본과 사회적 기술이 없어서가 훨씬 더 많았습니다.
  • 사회적 기술은 도움받기, 피드백 주고받기, 영향력 미치기, 가르치고 배우기, 위임하기 등이 있습니다.

2부 함께

소프트웨어 관리자의 개선 우선순위

  • 제럴드 와인버그는 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했습니다.
    1. 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
    2. 관찰하는 능력으로, 무엇이 벌어지고 있는지를 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
    3. 행동하는 능력으로, 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.
  • Quality software Management - 책
    1. 시스템적 사고
    2. 일차적 측정
    3. 일치적 행동
    4. 변화를 기대하기
  • 소프트웨어 개발 비용
    • 관리, 시스템, 사람, 도구 순서로 프로젝트의 성공에 영향을 끼친다.
    • 하지만, 관리자들이 선호하는 순서는 정확히 역순이다.
    • 도구 - 소프트웨어 개발에 사용되는 도구, 컴퓨터, 모니터, 버그 트래커, 디버거, IDE
    • 사람 - 사람들의 능력과 경험
    • 시스템 - 제품 자체의 복잡도, 요구되는 신뢰성, DB크기, 타깃 등의 변화 가능성, 스케줄 제약
    • 관리 - 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기를 고취하는 것, 작업 조건/환경을 개선하는 것, 자원의 준비, 리스크를 확인하고 적절한 조치를 취하는 것, 요구사항과 설계 스펙이 비준되게 돕는 것

협력을 통한 추상화

  • 둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다.

신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가

  • 신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 등의 연구가 많이 있습니다.
  • 복수 공유의 경우 같은 시간 말을 해도 대화가 좀 더 상호적이었던 것이죠.
  • 복수 공유는(같은 시간을 투자했을 때) 신뢰도 높아지고 성과도 더 좋았다는 말입니다.

객관의 주관성

  • 품질을 이야기 할 때에는 ‘누구’를 놓고 하는 말이냐는 걸 생각해 봐야 한다 이겁니다. 이 누구를 빼놓게 되면 고생은 고생대로 해놓고 품질이 형편없다는 소리를 들을 수 있습니다. 당사자가 별로 중요하게, 가치 있게 여기지도 않는 거에만 신경을 썼을 수 있거든요.
  • 인간에 대한 이해가 필수적입니다.
  • “아니다. 절대 부정할 수 없는 자료를 들이밀어야 한다” 라고 말하는 분들이 있지만 / 마음에 안 들면 어떤 ‘ 객관적’자료를 갖다 줘도 설득할 수 없습니다. 특히나 그 자료에 “당신의 생각이 틀렸다”라는 암시가 강하게 있다면(그리고 그렇게 해서 그들의 코를 납작하게 해 주고 싶다면) 더 더욱 설득이 어렵습니다.
  • 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사 결정을 제대로 할 수 없다는 것을 알 수 있습니다.
  • 남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 합니다. 그래야 현실적으로 설득이 가능합니다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 합니다. 출발은 결국 내가 설득하려는 사람에게서 하는 것입니다. 자료에서 출발하는 것이 아닙니다.
  • 상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?

이것도 모르세요?

  • 공감하고 이해하려는 대화
    • 공감하면서 들어주려 했고,
    • 상대가 어떤 멘탈모델을 갖고 있는지 파악하려 함
    • 이 상황에서 왜 그런 접근을 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있습니다.
  • 훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해하려고 합니다.

하향식 접근의 함정

  • 뛰어난 팀이라면 거의 한 팀도 빠지지 않고 공통적으로 갖고 있는 특징이 몇 가지 있었는데, ‘삼투압적 의사소통’이 거기에 속합니다.
  • 그리고 한번에 처리되는 일의 양을 줄여야 합니다.
  • 흔히 말하는 개발의 5단계도 비슷합니다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고민하지 말고, 어떻게 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다 할 수 있을까를 고민해야 할 것입니다.

전문가팀이 실패하는 이유

  • 협력 개입이 된 경우, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했습니다.
  1. 전문가들 모아서 팀 만든다고 잘하는 것 아니고
  2. 오히려 성과가 떨어질 수 있고
  3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
  4. 소셜 스킬 등이 뛰어난 제너럴 리스트가 있으면 도움이 된다

구글이 밝힌 탁월한 팀의 비밀

  1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등) 보다 팀원들이 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.
  2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 심리적 안전감이었다.
  3. 팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
  • 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음

쾌속 학습팀

  • 교육 배경인아 수술 경험 등은 학습 곡선의 기울기에 영향을 주지 못했습니다.
  • 독재자가 아니라 파트너가 될 수 있는 능력입니다.
  • 학습이 빠른 팀은 팀원을 뽑을 때부터 달랐습니다
    • 선발 자체가 매우 협동적으로 이루어지고
    • 단순한 업무 수행능력 뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지,
    • 새롭고 애매모호한 상황을 즐길 수 있는지,
    • 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지
  • 학습 속도가 느린 팀
    • 새로운 기술을 비꼬고 조소하기도 했습니다. 냉소주의는 전염성이 강합니다.
    • 학습을 개인의 과제로 치부했습니다.
    • 단기간의 퍼포먼스를 중요시했습니다.
    • 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했습니다.
  • 학습 속도가 빠른 팀
    • 자신이 팀원이 됐다는 사실 자체를 자랑스럽게 생각하고 있었습니다.
    • 심리적으로 보호가 되고 있었습니다.
    • 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았습니다.
    • 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했습니다.
    • 학습이 실행과 동시에 이루어졌습니다.
    • 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고 같이 학습해야 한다고 생각했습니다.
    • 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.
  • 현실에서 실천하기
    • 자신의 학습 환경을 만드세요
    • 학습과 일을 굳이 분리하지 마시고 동체로 만드세요
    • “작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다”

프로젝트 확률론

  • 소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요시간에 적어도 2~3배를 해야 80%정도의 확률로 마칠 수 있는 시간이 나온다고 합니다.
  • 애자일은 좋은 일해 대해서는 ‘그리고’ 확률을 ‘또는’확률로 바꾸고, 나쁜 일에 대해서는 ‘또는 확률을 ‘그리고’ 확률로 바꾸는 경향이 있습니다.

3부 애자일

  • 애자일이 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있습니다.
  • 학습과 협력은 불확실성이 큰 상황에서 좋은 대응 전략이 됩니다.

애자일의 씨앗

  • 고객에게 매일 가치를 전하라
    • 고객에게
      • 우리의 진짜 고객은 누구인가?
    • 매일
      • 어떻게 점진적으로 가치를 전할 것인가?
      • 어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?
    • 가치를
      • 무엇이 가치인가?
      • 지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?
      • 지금 가장 높은 가치는 무엇인가?
      • 비슷한 수준의 가치를 더 값싸게 전달하는 방법은?
    • 전하라
      • 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?

애자일 도입 성공 요인 분석

성공도 회귀분석

  • 고객참여 (0.77)
  • 리팩터링(0.42)
  • 코딩 후 자동화 테스트 붙이기(0.38)
  • 코드 공유(0.37)

성공도 회귀분석(성숙도 4 이하)

  • 고객참여(0.94)

성공도 회귀분석(성숙도 4 이상)

  • 짧은 반복 개발 주기 (0.49)
  • 고객참여 (0.36)
  • 코드 공유(0.33)

당신의 조직에 새 방법론이 먹히지 않는 이유

  • 새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제가 아닐까요?
  • 나는 어떤 팀장인가를 먼저 자문해봐야 하지 않을까 싶습니다

애자일을 애자일스럽게 도입하기

  • 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다.
  • 현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 ㅎ녀 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이 아닐까 합니다.