<함께 자라기> 후기

Roeniss Moon·2023년 3월 19일

독서

목록 보기

23/33

요즘 내가 하는 생각 ("measure") 과 맞닿아 있는 부분이 많아 감명깊게 읽었다.

"우리가 함께"(협력) "매일매일"(방법) "자랄 수 있을까"(학습) 에 대한 대답

인상깊은 구절들

일부 편집.

전문가는 문제를 이해하는데 시간을 더 많이 쓴다
"의도적인" 수련이 필요하다. 당신은 이닦기에 전문가인가?
만들기, 만드는 법을 개선하기, 만드는 법을 개선하는 방법을 개선하기 (사고방식과 상호작용방식) << 이 부분은 내가 요즘 하는 생각과 매우 밀접하게 관련이 있다. 이른바 '메타-측정'. 측정을 올바로 하기 위해 측정법을 측정한다는... 아직은 흐리멍텅한 그런 생각을 하고 있다.
올해 몇 권 읽었는지 자랑하지 말고 그 지식을 얼마나 어떻게 활용하는지 반성하라
일찍, 자주 실패하고, 그 안에서 학습하라.
"아직 1년도 되지 않아서 누굴 도와줄 처지가 아닙니다" vs "아직 1년도 안되어서 시간이 많아 다른 분들을 돕고 있습니다"
달인이 되기위한 조건 = 나아지려는 동기 갖기 + 구체적이고 시기적절한 피드백 받기
타당성(=확실한 인과) 및 빠른 피드백 = 전문가가 되기 좋은 영역. 그러나 프로그래밍은 그런 분야가 아니다! 그러나 개인적 차원에서는 충분히 그런 식으로 유도할 수 있다
쉬운 태스크는 난이도를 높여서 재미를 붙여라 (리팩토링 등 요구되지 않은 것들도 포함) << 나는 시간제한을 거는 편을 즐긴다. 몰입하기 쉬운 길이라 생각한다
(TDD를 언급하며) 어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본 및 사회적 기술이 필요하다 << 모든 것은 관계다
초기단계에 일을 딱 딱 나누는 것은 분업이지, 협력이 아니다
상시 대면 의사소통이 되는 공간이 생산성 향상 혹은 팀 차원의 몰입에 도움이 된다 << 어떤 태스크냐에 따라 상당히 효과가 달라질 것 같음. 경험상.
관리자들은 (본인이 하는) 관리 방법을 바꾸기보다 도구 (IDE 등)을 바꾸는 식으로 상황을 개선하려고 하는데, 사실 이는 제일 효과가 미미한 행동이다 << 아, 매니저!
(서로 다른 시각의 두 사람에 의한) 페어 프로그래밍은 소프트웨어의 추상화를 자연스럽게 유도한다. 대화를 통해 코드를 만드는 것이다
share one? share best? No. share multiple (방어 기제를 누그러뜨리는데 도움이 됨)
결국 결정하는 것은 사람
중요한 것은 전문가가 몇명이냐가 아니라 얼마나 대화하는가
구글이 연구한 탁월한 팀의 조건 : 서로 협력하는 업무방식과 압도적인 심리적 안정감
- 심리적 안정감을 높이는 법 : 마이크로 인터랙션. 매 순간 순간의 대화를 신경써라
속도가 빠른 팀은 새로운 수술 방식의 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다. 함께 (더 잘) 일하는 새로운 방법을 배울 기회로 인식한 것이다. 동시에 리더는 기회, 가능성, 큰 변화의 흐름에 동참한다는 것의 중요성과 즐거움을 강조했다. 반면 속도가 느린 팀은, 학습에 대하여 개인의 과제라는 측면을 강조했다
(협력하지 않을 때) 7명의 개발자가 데드라인에 대해 90% 의 확신을 가지고 있을 때, 실제 프로젝트가 무사히 끝날 확률은 0.9^7 = 48%
12명에게 12가지 일을 하나씩 주지 말라. 대신 3개의 일만 주고 협력하게 만들어라. 그 3개가 끝나면 다음 3개를 제시하라. '관심사의 섞임'을 통해 서로에 대해 아주 많이 아주 빠르게 배울 수 있을 것이다. 이 방법을 통해 '단 한 사람에 의한 모델링' 문제를 회피할 수 있다
그런에 옆자리의 동료가 점심시간이라 자리를 뜨면서 화면을 흘긋 보더니 "어? 버전업 작업하시네요? 고생 꽤나 하실거에요" 하면서 나가는 것이었습니다 << 아주 소름돋는 부분이었다. 옆자리의 동료는 특별히 악의가 없었을 것이다. 어쩌면 "당신도 버전업 작업을 통해 고통을 겪으면 나처럼 한 층 더 성장할 수 있을 것이다. 화이팅!"라는 정말 순수하게 응원의 메시지를 보낸 것일 수도 있다. 마라톤을 대신 달려 준다고 도와주는건 아닌 것처럼. 그러나 이 책은 그게 정답이 아니다... 라는 얘기를 했다. 나는 이 구절이 이 책의 핵심이라고 생각한다.
애자일은, 좋은 일을 OR 조건으로 바꾸고, 나쁜 일은 AND 로 바꾸도록 유도한다 << 한 사람의 좋은 일은 모두에게 좋은 것. 모든 사람이 나빠지기 전까진 나쁜 일도 아직 나쁘지 않은 것.
애자일의 씨앗 : 고객에게, 매일, 가치를, 전하라
- 누가 진짜 고객인가?
- 어떻게 매일 (조금이라도) 가치를 전할 것인가?
- 우리가 진짜 가치를 만들고 있는가?
- 고객에게 정말로 전달이 잘 되고 있는가?
애자일 실천법 중 성과에 직접적으로 도움이 된 것들 : 고객 참여 & 짧은 반복 개발 주기 > 리팩토링 > 코딩 후 자동화 테스트 붙이기 > 코드 공유
애자일 초보들은 쉽고 안심이 되는 것들 (코드 공유 등)에서 시작한다. 그런데 그것은 효과가 매우 작다. 고객 참여를 반드시 도입하라. 그러지 않으면 우리들만의 잔치로 끝난다
기술에 집착하지 마라. 베스트 프랙티스가 잘 먹힌다면 그건 예측이 가능한 단순한 도메인이다. 중요한 것은 누가 참여하느냐다
애잘을 진행할 때 가장 빈번하게 빚어지는 폐단 : 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 확실한 토대 위에서 진행하려는 것

여담1

지속적으로 자신과 팀을 돌아보면서 더 빠른 피드백, 더 편안한 안정감, 더 즐거운 분위기를 만들어내는 것은 말도 안나오게 고차원적인 의식활동이라고 생각한다. 그러나 또 한편으로는, 그 모든 것의 근간을 이루는 동기... 더 대단해지려는 의지를 놓지 않는 것만으로도 좋은 출발점이 아닌가 싶다. 그러한 강한 동기를 가지려면 목표가 있어야 한다. 아주 먼 목표부터 아주 가까운 목표까지. 그것들이 일직선일 필요는 없지만, 나에게 영감을 주어야 한다. 어느 순간 그런 것들에 대한 확신이 희미해져서 (좋은거다. 내가 목표에 대해서 고민이 많아졌다는 뜻이니까) 심란하긴 한데, 좋아지겠지.

여담2

이 책에서 bootstrap 이라는 단어의 뜻을 설명한다. 컴퓨터를 킬 때 쓰는 부팅 말이다. 설명을 보면 전혀 비과학적이지만, 어쨌든 컴퓨터는 해낸다. 나라고 못할쏘냐.

여담3

http://egloos.zum.com/agile/v/5265969

아, 나 잘 가고 있는듯.

내가 했던 생각을 누군가가 했다는 사실은 참 위로가 많이 된다.

관련 영상

각주로 딸려있는 링크 중 https://agile.egloos.com/5742985 가 안열려서... 그냥 넘어가려다가 구글에 쳤더니 아주 꿀같은 영상을 주웠다. (상당 부분 이 영상에서 차용한 듯)

검색하는 URL 구조를 바꿔야 될 듯. http://egloos.zum.com/agile/v/4368289 이런 식으로 호출하면 됨!

"TDD를 도입하고 싶어서 한 두 달 정도 시간을 들여서 공부했다면, 당신은 TDD를 성공적으로 도입할 가능성이 거의 없을 것이다"
성공한 창업가들은, MBA 졸업생들이나 포츈 500대 회사의 고위 매니저랑 행동이 다르다. 불확실한 상황 (무슨 문제가 존재하는지도 모름)은 리스크가 있는 상황 (여러 대안이 놓여진 상황)과 다른 식으로 대처해야 한다는 것이다.
개인이 조직에 변화를 가져오는 상황은 불확실한 상황. 창업가들의 행동을 좇아보자.

목표를 정하고 수단을 찾는게 아니라, 내가 할 줄 아는 방법에서부터 최적의 목표를 도출한다 : "What I know, Whom I know, WWho I am" ==> "내가 성취할 수 있는게 뭘까?"
경쟁자를 분석하는게 아니고, 사람들을 내 편으로 끌어들인다 : 초기부터 같이 한다. 그러지 않으면 사람들과 "같이, 같은 높이에서" 갈 수 없게 된다.
ROI를 따지는게 아니라, 잃어도 되는 돈을 계산한다 : 오래 살아남는게 중요하다. 감당할 수 있는 수준에서, 다양한 옵션들을 살펴보면서 조금씩 내 편을 늘리는 것이다.
예상하지 않되, 통제한다 (이 슬라이드 참고) : 불확실한 미래를 고민하는 대신, 능동적으로 통제할 수 있는 것부터 개선해 나간다.