함께 자라기

다시보기

책 소개

함께 자리기

애자일로 가는 길

agile-coach-book.jpeg

김창준

애자일 마스터

기업/그룹 강의

http://agile.egloos.com/

조금 삐딱하게 보기

들어가며

솔플 vs 팀플

요즘, 임팩트를 남기려면 혼자서는 되는게 없다.

예전에는?

  • 예전엔 있었다
  • 많은 천재들

우리와 먼 이야기들…

요즘은 어떤가?

너무 커져버린 세계

  • 복잡한 이해 관계
  • 나비 효과

어쩌라고…

유다희

you-died.jpeg

실패할 기회가 주어지는가?

도전의 기회가 부족함

  • 우리나라는 특히 더?
  • 다 때가 있다

실패할 수 있는 시기가 정해져 있다?

노동자의 멍에 1

꼭 자라야 하는가? → 학습

  • 돈과 명예
  • 시간과 자유

기본 소득이 필요하다!

노동자의 멍에 2

혼자 할 수 없는가? → 협력

  • 무엇을 하고 싶은가에 따라 다르다
  • 혼자 이룰게 많이 없음 → 너무 커져버린 세계

이래선 안된다

우리에게 주어진 현실적인 목표는 무엇인가?

  • 범위를 좁혀 정의해 보자
  • 매일매일 자라기? → 너무 힘든거 아니냐…

자라기

야생 학습

  • 협력을 기반으로 비 순차적이며
  • 자료에 구애받지 않고 평가하기 어려고
  • 정답도 없고 목표가 분명하지 않은 학습.

제도권 학교의 학습과 다르다.

불확실성

불확실성이 높을수록 야생 학습이 중요시 된다.

  • 변하는 목표
  • 계획의 수정

과연 그런가?

연차

’경험’ 이라는 요소

평가는 단순하지 않고 경험도 무시할 수 없다.

상관성 1

  • 연차와 직무 성과의 상관성은 0.18 수준
  • 학력에 대해서는 0.10 수준.

0.20 이하는 크게 상관 없다고 평가할 수 있다.

상관성 2

  • 인턴쉽
  • 지능 테스트
  • 구조화된 인터뷰
  • 성격 점검
  • 레퍼런스 체크

연차와 실력은 무관할 수 있지만 경험과 실력도 무관할까?

Latte is horse

  • 경험과 문제 이해
  • 요구사항 파악

진짜 실력

실력이 뛰어난 사람은 문제를 이해하는 데 시간을 적게 쓴다.

누구를 채용해야 하는가?

협업과 성장

엔지니어링 → 효율 → 돈 → 인건비

그리고 잘 성장시키기도 중요하다.

100K lines of code

1만 시간의 법칙. → 10만 라인의 코드…

의도적 수련

  • 칫솔질 비유
  • 걷기 비유
  • 연주자의 공연 시간
  • 선수의 토너먼트 시간

Agile = Agility + Iteration

  • 의도적 수련
  • 피드백

의미있는 수련을 바탕으로

평가와 피드백을 빠른 주기로 얻는 것!

자기계발

하루 평균 1~2 시간

직장인 통계 자기계발 시간

이 시간은 복리로 동작한다.

→ 과연 이 시간을 낼 수 있을까?

복리의 매커니즘

진짜 복리로 동작하게 하려면 꾸준해야 한다.

작업의 구분

  • A: 원래 할 일,
  • B: 원래 할 일을 개선,
  • C: 원래 할 일을 개선하는 걸 개선하는 일!

복리 조직이 되자

진보와 성장

  • 뭔가를 뒤에 남겨두고 앞으로 가는 것,
  • 성장을 가리고 있다.

성장은 우리 안에 뭔가를 남겨두고 커진다.

부트스트랩

소프트웨어 자신에게도 자주 사용되는 용어;

  • 부팅
  • 특이점

완벽한 도구와 환경에 집착하지 말 것

학습과 실행

고난과 역경

  • 환경: 실행 프레임
  • 태도: 학습 프레임

학습 프레임이 갖추어진 주니어의 기대치가 높다.

학습하기 힘든 직업

일자리

  • 특이점
  • 전산화에 병목이 되는 구간

지각과 조작, 창의적 지능, 사회적 지능

코딩하기도 힘든데…

컴퓨터 프로그래머 vs 소프트웨어 개발자

협상과 설득 능력

협상과 설득이 왜 필요한가?

전문성

강한 동기(motivation), 구체적이고 적절한 타이밍의 피드백

직관

직관이 가치를 가지려면 타당해야 하고, 피드백을 받을 수 있어야 한다.

  • 인과관계와 규칙성
  • 예측 가능성

전문성이 필요한 곳

타당성과 피드백이 없는 환경에서는 전문성을 높일 수 없다.

오픈소스 컨트리뷰션

소프트웨어 개발은 중간 정도 가진다.

의도적 수련

양적인 부분, 그리고 질적인 부분을 고려해야 한다.

난이도와 몰입

  • 익숙한 도구를 멀리하기
  • 작업 시간을 단축하기
  • 익숙한 작업을 다른 언어로
  • 리팩토링
  • 자동화 테스트

Simple and Possible

  • Divide & Conquer

프로그래밍 학습

적극적 읽기

  • 뭘 만들지 생각하고 문서를 읽기
  • 할만한 단계가 되면 읽기를 멈추고 코딩

읽을거리

Pervasive 코드

토이 프로젝트를 넘어

  • 커뮤니티 참여
  • 피드백 경험

토이 프로젝트 구현을 넘어 기여하는 코드 작성

No hello

질문을 잘하자.

전문성을 얻어내기 위한 전문가 되기.

  • Cognitive interview

실수 관리

실수 발견

실수 예방이 아니라 실수를 조기에 발견하고 관리할 것.

→ 세상이 엉망이 아닌 이유;

심리적 안정감

심리적 안정감도 문화의 일부. 실수 훈련 같은 기법도 활용.

→ 실수 격리 노하우가 필요하다.

뛰어난 선생과 좋은 선생 그리고 전문가

가르치기

아무리 좋은 가르침에도…

  • 평균 70% 는 가르치지 않은 것 투성이
  • 자동화 된 요소들은 암묵적이 되어버림

메타 인지

가르치는 사람의 메타 인지 능력에 따라

학업성취도 영향에 큰 효과를 가져다 준다.

인터렉션

뛰어난 연구자는 같은 부탁을 해도

훨신 짧은 시간에 타인의 도움을 받아냄.

뛰어난 개발자일수록

타인과 인터렉션에 더 많은 시간을 사용함.

마이크로 인터렉션 in 뛰어난 프로그래머

프로그래밍 실력은 좋은데

의사소통 능력은 부족하다라는 평가는 변했다.

프로그래밍을 잘 한다의 정의에

뛰어난 의사소통 능력이 포함되어 있다.

마이크로 인터렉션 강화 훈련

주변 사람들과 매일 주고 받는

인사, 대화, 문답 등에 신경을 쓰도록;

함께

소프트웨어 관리 개선

일을 잘 나눌 수 있는 때는

프로젝트가 완료된 시점

조엘 테스트

조엘 온 소프트웨어의

조엘 테스트를 맹신하지 말라.

이것도 제대로 못하는게 현실인데?

좋은 도구

비싼 툴이 대부분 더 좋은게 사실

소프트웨어 품질 관리

  1. 복잡한 상황을 이해 → 계획을 수립 → 또는 변경
  2. 관찰하고 적응 그리고 이해
  3. 적절하게 행동

장인과 도구

지속 가능 개발

Sustainable Development

소프트웨어 개발 비용

  • 개발에 들어가는 모든 도구,
  • 사람들의 능력과 경험,
  • 시스템의 복잡도,
  • 인원을 배정하고 작업을 분배하고 조정하며 위임,
  • 모니터링과 동기부여,
  • 작업 환경 개선,
  • 빠른 리스크 파악 및 조치,
  • 요구사항과 스펙을 검증…

등에 들어가는 비용의 합.

조직의 규모에 따라

Case by case

우리 회사 개발팀(실)의 경우…

약은 약사에게 진료는 의사에게

하지만 관리자가 도구에 집작하는 것은

패착이 될 확률이 높아짐

도구는 도구를 다루는 사람이 잘 압니다…

협력의 추상화

소프트 스킬

  • 커뮤니케이션 능력
  • 협업 능력

뛰어난 프로그래머에 대한 정의

소프트 스킬에 대한 관심이 늘어나고 있다.

시그마 모델과 파이 모델

집단의 퍼포먼스 측정 모델

협업의 장점이 없어 보이는 경우가 종종 있다.

파이 모델의 효율

파이 모델이 효과를 내기 위해 필요한 조건들이 있다.

시각화 도구(중간 매개체)를 통해 커뮤니케이션해야 한다.

협업과 커뮤니케이션 비용

톱니바퀴 실험에서 협업 모델의 참여자들이

추상화 규칙을 찾아내는 속도가 빨랐다.

커뮤니케이션을 위해

추상화 단계가 필요했기 때문이다.

ETC - Easy to change

  • Indirectinal

디자인 패턴을 공부하며 배우는

대부분의 주제가 담고 있는 목표.

어떻게?

추상화를 높이는 쉬운 방법은 협업하기

신뢰와 공유

신뢰 자산이 높을수록 커뮤니케이션 비용이 낮아진다.

Trust me I am dog

trust-me.png

소통 신뢰

신뢰를 샇는데 필요한 건

  • 투명성
  • 공유
  • 상호 피드백

뒤통수 치는 분들이 너무 많아서…

공유의 한계

  • 하나를 공유할 때, 최선의 최소를 공유할 때는
  • 신뢰도 평가 점수가 좋지 않았다.
  • 대신, 모든 것을 공유할 때 신뢰도가 높아졌다.
  • 공유물과 자신을 동일시 하지 않게 해야 한다.

객관성의 주관성

설명하기

IT업계에서 사용되는 용어가

자연어가 아니기 때문에

설명을 잘 하는 것도 능력이 된다.

상대적 품질

품질은 상대적이다.

설득에는 객관성이 필요하다.

그동안의 신뢰는 어디가고…

객관성의 주관성

결국 결정하는 것은 사람이기 때문에

객관성은 주관적일 수 밖에 없다.

설득과 신뢰

즉, 감성과 이성을 분리하는 것은 불가능하다.

설득을 하려면 신뢰가 필요하다.

성향과 기질

MBTI?

코칭 기법

홍춘이가 잘못했다.

’이것도 모르세요?’

vs

’이런거 알려주는 사람 나 밖에 없어.’

공감하고 이해하기 위한 대화 방법

행동을 유도하는 대화 방법

피코치가 행동할 수 있도록 유도하는 방법

컨텍스트 전환

  • Concurrency
  • Threshing

탑다운과 바텀업

당연히 뛰어난 전문가는

탑다운과 바텀업을 섞어 문제를 해결한다.

엔지니어링

  • 비용의 문제

복잡하고 어려운 문제일수록 사고흐름은 예측할 수 없고

추상성이 높아졌다가 낮아졌다가를 반복한다.

’일정 산출해주세요.’

vs

’언제까지 돼요?’

인류보안계획

plan-failed.jpeg

힘든 과제이니 철저하게 계획하고

단계별로 접근하자 라는 명제는 수준 낮은 접근 방법이다.

실제로 전문가일수록 자신의 계획을 수정하는 경우가 많다.

스크럼

컨텍스트 유지 비용을 낮추는 방법

소수의 인원이 모든 역할을 하는 방법

컨텍스트 전환이 쉽도록 협업 상태를 개선하는 방법

둘 다 가능한 조직을 만드는 방법…

의사소통이 원활해야 한다.

사실은?

모두 전문가가 되면 되겠구나!

New Normal

물리적인 거리: 가까울수록 좋은데…

실패하는 전문가

협업하지 않는 전문가 집단은

비전문가 집단보다 못한 성과를 내는 경향이 있다.

소셜 스킬이 높은 제너럴리스트가 필요한 이유

탁월한 팀 유지

심리적 안정감이 중요

학습 속도

어려운 일일수록 새로운 학습이 필요하고

이전 경험과 지식은 학습 속도에 영향을 주지 않을수 있다.

리더와 학습 속도

대신 리더가 팀 학습 속도에 영향을 준다.

팀 리더는 팀원을 뽑을 때부터 협동적이었다.

선발 기준도 단순 업무 수행 능력이 아니었다.

Don’t be cynical. don’t be serious, also

냉소는 별로 도움이 안됨.

프로젝트 성공의 요소

PERT

통계상 추정시간의 2~3 배를 곱해야

80% 정도의 확률로 마무리 할 수 있었다.

업무 공유

공유되지 않는 업무는 제 시간에 완성되기 어렵다.

애자일 방법론

필요할 때 하자.

잘 모름;

뛰어난 하드 스킬

가이드

상황 판단 능력

상황/현상을 판단하는 능력이 필요한데…

코드 쓰기

  • 의도와 맥락 이해
  • 고민과 해결 제공

적절한 설명

코드가 아니더라도…

  • PR 본문
  • 커밋 로그

상황 이해

왜 이런 코드가 생산되었는지…

고민의 흔적

문제 해결을 위해 제시한 방법(주로 PR) 이외에

또 다른 방법이 있는지 고민할 수 있는 선택지를 제공한다.

의도 파악

  • 예전 코드가 왜 이렇게 작성되었는지 이해하고
  • 작업자의 의도를 이해하여 변경하며
  • 다음 작업은 어떤게 이어져야 하는지 알려준다.

프로젝트의 맥락을 잘 파악하기;

가이드라인 지키기

가이드라인을 잘 따르고

코드 품질을 신경쓰면서

기술부채가 어떤지 알고 있어야 한다.

코드 품질

시간에 양보하지 말자.

기술 부채 파악

분위기 파악

답답한 부분은 무엇이고

어떤 분위기로 협업이 이루어지는지

눈치채고 있어야 한다.

Be careful with legacy code :)

HBnHQIsk3faK81Fp.jpg

시야

단순히 이 기능에 대한/이 버그에 대한 해결이 아니라

종합적인 면으로 전체 솔루션의 맥락을 이해해야 한다.

작은 변경이라도 전체를 조망하고 있어야 한다.

변경에 대한 책임

메인테이너가 아니더라도

코드 변경에 대한 책임감을 느껴고 있어야 한다.

절대적 시간과 여유

완성도 높은 코드를 작성하기 위해서는

당연히 그만큼의 시간이 필요함.

적당한 여유가 주어진다면

적당한 품질의 코드가 나오는 것은 당연함.

일정 초과하고 야근하는 작업자의 코드가

좋은 품질의 코드가 나오는 것을 기대하면 안됨.

유연하고 합리적인 계획이 있어야

코더는 무리하지 않고 일정을 지킬수 있으며

그런 코더가 최고의 코드를 작성할 수 있게 된다.

- eof -