소프트웨어 장인 - Part 2 : 완전한 전환 (13 ~ 14장) (Software Craftsman)

[이전 장]

https://yrok.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%A5%EC%9D%B8-Software-Craftsmanship-Part-2-%EC%99%84%EC%A0%84%ED%95%9C-%EC%A0%84%ED%99%98-11-12%EC%9E%A5

소프트웨어 장인 - Part 2 : 완전한 전환 (11 ~ 12장) (Software Craftsmanship)

[13장] 배움의 문화

[잘못된 방향으로 동기 부여하기] - p244

'사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어 내야 한다.'

배움의 문화까지는 정착 시킬 수 있을 것 같지만 실천은 정말 개개인의 몫이다. 또한 퀄리티 조차도 중요한 것 같다. 여기서 퀄리티는 학습 주제는 물론 방식과 개개인의 참여도를 의미하고 싶다. 좋은 문화를 만들기 위해서는 강력한 동기 부여가 필요하지만 이 또한 개개인별로 다르기에 쉽지 않다.

 

[배움의 문화 만들기] - p246

<북 클럽에 가입하기>

요새 주변에 '트레바리' 이용하는 사람들 많던데...

우선 월 1권이상 독서 잘 지키고 있으니!

 

<테크 런치 진행하기>

비슷하게 '기술 세미나' 문화가 있었는데 없어져서 아쉽다. 물론 다른 스터디 등으로 대체 가능하긴 하지만... 아쉽다.

 

<그룹 토론회에 참여하기>

-

 

<업무 교환하기>

'개발자 교환을 통해서 매너리즘을 해결할 수 있다. 기존 결정들에 대한 재검증 / 지식의 공유 / 개선 / 공동 학습'

이게 우리나라에서도 자리 잡을 수 있긴 한 문화일까? 아니면 대기업이라 불가능한 걸까? 혹은 산업군별에 따른 문화 차이로 불가능한 걸까?

 

<얼마 동안만 업무 교환하기>

-

 

<그룹 코드 리뷰하기>

'그룹 코드 리뷰 시간에 커밋 히스토리를 뒤지지 않는다. 비난할 사람을 찾기 위해 과거를 파헤치지 말고 미래를 변화시키는 데 집중한다.

주석은 반드시 객관적이고 생산적이어야 한다. 왜 그것이 엉망인지가 아니라 어떻게 코드를 개선할지에 집중해야 한다. 누군가를 비난하는 상황이 생기지 않도록 한다. 큰 진전을 이룰 것이라 기대하지 않는다. 이슈 한 가지에 대해서 너무 오랫동안 이야기되더라도 개발자들이 원한다면 그냥 그렇게 한다.'

코드 리뷰는 테스트 자동화와 더불어 가장 중요한 프로세스 중 하나라고 생각한다. 하지만 테스트와 마찬가지로 그저 '선택사항'으로 치부되고 있는 현실이 너무 슬프다...

 

<코딩 실습하기>

-

 

<사용할 기술은 가능한 자유롭게 선택하기>

-

 

<내부학습 모임을 만들기>

-

 

<회사에서의 펫 프로젝트 시간을 허용하기>

-

 

<외부 기술 커뮤니티와 교류하기>

이게 정말 필요하다... 너무나도 고인물 아닌가...

 

[아무도 참여하려 하지 않는다면] - p257

<모범을 보여라>

-

 

<관심을 보이는 사람들에게 집중하라>

-

 

<강제하지 마라>

-

 

<모두를 변화시키려 들지 마라>

-

 

<모임에 대한 약속을 제때하라>

-

 

<허락을 구하지 마라>

'심지어 업무 시간에 공부를 하더라도 상사에게 허락을 구하지 않는다. 책임있게 행동하면 될 뿐이다.'

저자의 말에 용기를 얻어 도전 해보자!

 

<투덜대지 마라>

-

 

<리듬을 만들라>

-

 

[14장] 기술적 변화의 실행

'사춘기적 맹신. 자기만의 비법이 있다고 생각하고 다른 것들은 무시해 버린다.'

이건 때때로 발동하는 것 같다. ㅎㅎㅎ C++ & Python만이 최고인 것 같다. ㅎㅎ

 

[회의론의 종류] - p260

할말하않... 저자가 꽤나 세부적으로(?) 분류를 해두었다.

'무지 - 자신이 일하고 있는 좁은 책상에만 갇힌 채 밖에서 어떤 일이 일어나고 있는지 이해하려 노력하지 않는다.

대중 - 어떤 결정을 내리기에 자신의 경험이 충분치 않다고 생각한다. 자신감이 부족하다.

냉소주의 - 논쟁을 좋아하고 지속적으로 자신이 남보다 잘났음을 증명하려 든다.

트라우마 - 과거 특정 실행 관례나 도구를 사용하려 시도했으나 실패한 경험이 있는 사람들이다. 새로운 것에 대한 좋은 경험이 없기 때문에 다시 반복하고 싶어하지 않는다.

너무 바쁜 - 어떤 일의 장기적인 비용을 보지 못하고 근시안적인 판단을 한다. 이들의 눈에 보이는 것은 너무 바빠서 일하는 방식을 바꿀 시간이 없다는 것뿐이다.

상사 - 상사가 기술 배경이 없다면 당신이 제안하는 것들이 어떤 장점이 있는지 이해하지 못할 가능성이 높다.

몰상식 - 가장 최악. 논리적으로 반대할 내용이 없으면 이 문제에서 저 문제로 끊임없이 옮겨 다닌다.말이 막힐 때마다 이 부분에서 저 부분으로 아물너 합리적 근거도 없이 생트집을 잡는다.

무념무상 - 이들은 그냥 뭐가 어떻게 되든 아무런 상관을 하지 않는다.

피해망상 - 자신이 일하고 있는 회사를 싫어하고 불평불만과 회사에 대한 험담이 잦다. 이런 사람의 존재는 팀을 파괴하고 개발자들끼리 서로 비난하게 된다.

무능력 - 이들은 제안의 본질을 파악하지 못한다.인지능력, 이해능력의 부족을 보인다.

상아탑 아키텍트 - 모든 것을 알고 있다고 생각한다.

좌불안석 - 이들은 자신이 다른 사람으로 대체되어 직무를 잃거나 해고될까 봐 걱정한다.

팬보이 - 특정 주제나 관점에 광적으로 완전히 전념하는 사람들이다.'

 

[준비] - p265

저자의 주옥같은 멘트들이 많지만 전부 인용할수는 없으므로 키워드로 남겨볼까 한다.

용기, 정직함, 투명함, 자신감, 단순함(명료함), 소통, 이해, 존중, 경청.

 

[기술적 변화를 시작하는 방법] - p267

<신뢰를 쌓으라>

열정으로 절대 해결할 수 없다... 아마 혼자 불타버리고 말 것이다. 신뢰가 중요한데... 역량을 쌓으면 신뢰를 얻을 수 있다.

하지만 역량을 어떻게 드러내느냐도 쉽지 않은 것 같다.

 

<전문성을 확보하라>

전문성이 있으면 신뢰가 저절로 쌓이지 않나 싶다... 맹목적으로... 경험상 그렇다.

 

<모범을 보여 사람들을 이끌라>

-

 

<신중하게 싸울 곳을 정하라>

이건 저자의 말을 두고두고 새길 필요가 있다고 생각하므로 인용해본다.

'"나한테 권한만 있다면..." 너무나 편협하고, 비효율적이고, 잠재적으로 스스로에게 해로운 생각이다. 혼자서 모든 이슈와 조직 전체를 상대로 두고 싸울 수는 없다. 한 번에 한 가지씩 신중하게 싸울 곳을 골라야 한다. 당신이 준비되어 있지 않다면 조직의 소프트웨어 개발 절차를 바꿀 수 없다. 모든 부분에서 싸움을 시작하지 말자. 싸움에 우선순위를 두자.'

 

<점진적으로 반복, 관찰, 수용하라>

-

 

[두려움과 자신감 부족] - p272

'두려움이 있는 데다가 자신감이 부족하면 회사는 관료적이고 정치적으로 변한다.' => 흠...

'프로페셔널 개발자라면, 진정한 소프트웨어 장인이라면, 그에 맞는 윤리의식과 행동원칙이 있다. 승진하기 위해 정치 게임을 해야 할 이유도, 일자리 하나에 목을 매야 할 이유도 없다. 당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 잇는 최고의 개발자로 거듭나야 한다.'

끊임 없이 노력하는 '프로'가 되도록 하자.

 

[상사를 설득하는 방법] - p273

'관리자들은 일정에 맞추어서 제품이 딜리버리되고, 예산을 지키고, 버그가 없는 것에 관심을 가질 뿐이다.

무슨 일을 하든 고객에게 가치를 전달해야 한다. 일의 진척 상황에 대해서 정직하고 투명하게 말해야 한다.'

일을 투명하게 계획적으로 진행하도록 노력해야겠다. 아.. 근데 일이 명확하지 않거나 재미(?)가 없을 때가 늘 문제다... 추진력이 생기질 않는다...

그리고 테스트와 리팩토링은 타협불가한 필수사항이다. 앞으로는 꼭 지켜내도록 하자.

 

[팀이 TDD를 수용하도록 설득하는 방법] - p275

'버그에 대한 두려움 없이 코드를 리팩토링할 수 있다는 자유로움을 보여 주자.' => 일단 나부터 자유로워져 보자.

'매사에 의심이 많은 사람에게 TDD를 전파하기는 매우 어렵다. "TDD는 어렵고 느려서 가치가 없다."는 최악의 상황은 피해야 한다.'

이게 정말 어려운 것 같다... 전파시킬 수 있는 위치에도, 능력도 없다. 하지만 좋은 걸 알 때...

 

[회의론을 상대하는 방법] - p276

"'무지'에 빠진 사람에게 지식을 주고, '대중'에게 방향을 제시하며, '냉소주의자'를 납득시키고, '트라우마'에 빠진 사람을 이해할 수 있다. '너무 바쁜'이들이 걱정하는 시간 소모를 학습 곡선을 짧게 하는 방법으로 해결할 수 있다. 상사의 수준에 맞게 대화의 수준을 올려야 한다. 생산성 향상, 비용 절감, 매출 증대, 일정 준수, 버그 감소, 예측 가능하고 꾸준한 개발 속도, 비즈니스 요구사항의 충족 등 이런 것들이 상사의 사항이다. '몰상식'한 사람들은 무시하자. 팀의 여느 개발자와 같은 위치에서 제안해야 한다. '좌불안석' 타입의 회의론자로 만드는 것을 빙자할 수 있다. 종국적으로는 롤모델이 되어야 한다. '무념무상', '무능력', '팬보이' 등을 포함하여 대다수의 회의론자를 당신 편으로 만들 수 있다."

저자는 친절하게도 인간관계에 대한 조언도 빠지지 않고 해주었다. 여러 번 읽고 가슴에 새기자.

 

<상아탑 아키텍트>

-

 

<권한과 책임>

'프로'는 권한=책임 이라는 것을 안다.

 

<피해망상>

-

 

[이 모든 것을 다 챙겨야만 하는가]

-

 

[요약] - (책 발췌)

1. 배움의 문화를 만드는 것은 관리자나 애자일 코치의 전담 업무가 아니다. 개발자를 포함해서 모두가 해야 할 일이다. 시간이나 장소가 없다는 것은 변명이 될 수 없다. 관리자로부터의 지원이 없더라도 개발자들 스스로 서로 배우고 공유하는 배움의 환경과 문화를 쉽게 만들 수 있다.

2. 배움의 문화를 만드는 것은 쉽고 비용이 거의 안드는 일이다. 열정적인 개발자들에게 좋은 환경을 제공하기만 하면 된다. 그러면 그들 스스로 무엇을 배우고 공유할지 여러 가지 방법을 찾을 것이다.

3. 개발팀에 기술적 변화를 도입하는 일은 참 어렵다. 성공적으로 변화를 일으키려면 여러 종류의 사람들마다 어떻게 다르게 대응하고 어떻게 설득할지 알고 있어야 한다.

4. 일을 잘 해내려면 소통을 명확히 해야 한다. 신뢰야말로 변화를 이끌기 위한 핵심적인 요소다. 대화하는 상대방을 이해하고, 그 사람의 생각의 바탕에 어떤 이유들이 있는지 공감할 수 있어야 한다. 자신을 준비시키고 용감해지고, 주도하자.

 

[다음 장, 마지막]

https://yrok.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%A5%EC%9D%B8-Software-Craftsmanship-Part-2-%EC%99%84%EC%A0%84%ED%95%9C-%EC%A0%84%ED%99%98-15-16%EC%9E%A5-%EB%B6%80%EB%A1%9D-%EB%81%9D

[끝] 소프트웨어 장인 - Part 2 : 완전한 전환 (15 ~ 16장 + 부록) (Software Craftsmanship)