함께 자리기
애자일로 가는 길
애자일 마스터
기업/그룹 강의
요즘, 임팩트를 남기려면 혼자서는 되는게 없다.
우리와 먼 이야기들…
요즘은 어떤가?
어쩌라고…
실패할 기회가 주어지는가?
실패할 수 있는 시기가 정해져 있다?
꼭 자라야 하는가? → 학습
기본 소득이 필요하다!
혼자 할 수 없는가? → 협력
우리에게 주어진 현실적인 목표는 무엇인가?
제도권 학교의 학습과 다르다.
불확실성이 높을수록 야생 학습이 중요시 된다.
과연 그런가?
평가는 단순하지 않고 경험도 무시할 수 없다.
0.20 이하는 크게 상관 없다고 평가할 수 있다.
연차와 실력은 무관할 수 있지만 경험과 실력도 무관할까?
실력이 뛰어난 사람은 문제를 이해하는 데 시간을 적게 쓴다.
누구를 채용해야 하는가?
엔지니어링 → 효율 → 돈 → 인건비
그리고 잘 성장시키기도 중요하다.
1만 시간의 법칙. → 10만 라인의 코드…
=
Agility + Iteration의미있는 수련을 바탕으로
평가와 피드백을 빠른 주기로 얻는 것!
직장인 통계 자기계발 시간
이 시간은 복리로 동작한다.
→ 과연 이 시간을 낼 수 있을까?
진짜 복리로 동작하게 하려면 꾸준해야 한다.
성장은 우리 안에 뭔가를 남겨두고 커진다.
소프트웨어 자신에게도 자주 사용되는 용어;
학습 프레임이 갖추어진 주니어의 기대치가 높다.
지각과 조작, 창의적 지능, 사회적 지능
컴퓨터 프로그래머 vs 소프트웨어 개발자
협상과 설득이 왜 필요한가?
강한 동기(motivation), 구체적이고 적절한 타이밍의 피드백
직관이 가치를 가지려면 타당해야 하고, 피드백을 받을 수 있어야 한다.
타당성과 피드백이 없는 환경에서는 전문성을 높일 수 없다.
소프트웨어 개발은 중간 정도 가진다.
양적인 부분, 그리고 질적인 부분을 고려해야 한다.
Pervasive 코드
토이 프로젝트 구현을 넘어 기여하는 코드 작성
질문을 잘하자.
전문성을 얻어내기 위한 전문가 되기.
실수 예방이 아니라 실수를 조기에 발견하고 관리할 것.
→ 세상이 엉망이 아닌 이유;
심리적 안정감도 문화의 일부. 실수 훈련 같은 기법도 활용.
→ 실수 격리 노하우가 필요하다.
아무리 좋은 가르침에도…
가르치는 사람의 메타 인지 능력에 따라
학업성취도 영향에 큰 효과를 가져다 준다.
뛰어난 연구자는 같은 부탁을 해도
훨신 짧은 시간에 타인의 도움을 받아냄.
뛰어난 개발자일수록
타인과 인터렉션에 더 많은 시간을 사용함.
프로그래밍 실력은 좋은데
의사소통 능력은 부족하다라는 평가는 변했다.
프로그래밍을 잘 한다의 정의에
뛰어난 의사소통 능력이 포함되어 있다.
주변 사람들과 매일 주고 받는
인사, 대화, 문답 등에 신경을 쓰도록;
일을 잘 나눌 수 있는 때는
프로젝트가 완료된 시점
조엘 온 소프트웨어의
조엘 테스트를 맹신하지 말라.
이것도 제대로 못하는게 현실인데?
비싼 툴이 대부분 더 좋은게 사실
지속 가능 개발
Sustainable Development
등에 들어가는 비용의 합.
Case by case
우리 회사 개발팀(실)의 경우…
하지만 관리자가 도구에 집작하는 것은
패착이 될 확률이 높아짐
도구는 도구를 다루는 사람이 잘 압니다…
소프트 스킬
소프트 스킬에 대한 관심이 늘어나고 있다.
집단의 퍼포먼스 측정 모델
협업의 장점이 없어 보이는 경우가 종종 있다.
파이 모델이 효과를 내기 위해 필요한 조건들이 있다.
시각화 도구(중간 매개체)를 통해 커뮤니케이션해야 한다.
톱니바퀴 실험에서 협업 모델의 참여자들이
추상화 규칙을 찾아내는 속도가 빨랐다.
커뮤니케이션을 위해
추상화 단계가 필요했기 때문이다.
디자인 패턴을 공부하며 배우는
대부분의 주제가 담고 있는 목표.
추상화를 높이는 쉬운 방법은 협업하기
신뢰 자산이 높을수록 커뮤니케이션 비용이 낮아진다.
신뢰를 샇는데 필요한 건
IT업계에서 사용되는 용어가
자연어가 아니기 때문에
설명을 잘 하는 것도 능력이 된다.
품질은 상대적이다.
설득에는 객관성이 필요하다.
결국 결정하는 것은 사람이기 때문에
객관성은 주관적일 수 밖에 없다.
즉, 감성과 이성을 분리하는 것은 불가능하다.
설득을 하려면 신뢰가 필요하다.
MBTI?
홍춘이가 잘못했다.
vs
’이런거 알려주는 사람 나 밖에 없어.’
당연히 뛰어난 전문가는
탑다운과 바텀업을 섞어 문제를 해결한다.
복잡하고 어려운 문제일수록 사고흐름은 예측할 수 없고
추상성이 높아졌다가 낮아졌다가를 반복한다.
vs
’언제까지 돼요?’
단계별로 접근하자 라는 명제는 수준 낮은 접근 방법이다.
실제로 전문가일수록 자신의 계획을 수정하는 경우가 많다.
컨텍스트 유지 비용을 낮추는 방법
의사소통이 원활해야 한다.
사실은?
물리적인 거리: 가까울수록 좋은데…
협업하지 않는 전문가 집단은
비전문가 집단보다 못한 성과를 내는 경향이 있다.
어려운 일일수록 새로운 학습이 필요하고
이전 경험과 지식은 학습 속도에 영향을 주지 않을수 있다.
대신 리더가 팀 학습 속도에 영향을 준다.
팀 리더는 팀원을 뽑을 때부터 협동적이었다.
선발 기준도 단순 업무 수행 능력이 아니었다.
냉소는 별로 도움이 안됨.
통계상 추정시간의 2~3 배를 곱해야
80% 정도의 확률로 마무리 할 수 있었다.
공유되지 않는 업무는 제 시간에 완성되기 어렵다.
잘 모름;
가이드
상황/현상을 판단하는 능력이 필요한데…
코드가 아니더라도…
왜 이런 코드가 생산되었는지…
문제 해결을 위해 제시한 방법(주로 PR) 이외에
또 다른 방법이 있는지 고민할 수 있는 선택지를 제공한다.
프로젝트의 맥락을 잘 파악하기;
가이드라인을 잘 따르고
코드 품질을 신경쓰면서
기술부채가 어떤지 알고 있어야 한다.
시간에 양보하지 말자.
답답한 부분은 무엇이고
어떤 분위기로 협업이 이루어지는지
눈치채고 있어야 한다.
단순히 이 기능에 대한/이 버그에 대한 해결이 아니라
종합적인 면으로 전체 솔루션의 맥락을 이해해야 한다.
작은 변경이라도 전체를 조망하고 있어야 한다.
메인테이너가 아니더라도
코드 변경에 대한 책임감을 느껴고 있어야 한다.
당연히 그만큼의 시간이 필요함.
적당한 품질의 코드가 나오는 것은 당연함.
좋은 품질의 코드가 나오는 것을 기대하면 안됨.
코더는 무리하지 않고 일정을 지킬수 있으며
그런 코더가 최고의 코드를 작성할 수 있게 된다.