[4부 프로그래머의 무리] Chapter17 여기 우리 함께 서 있네

팀워크와 개인 프로그래머

 

대부분 생산되는 코드를 훌륭한 팀워크의 결과이다.

팀워크는 프로젝트의 생존을 위해서 극히 중요한 요소이다.

 

소프트웨어 개발팀 - 큰 그림

개인은 하나의 팀에만 속하는 것이 아니라 상위 팀에도 속할 수 있다. 즉, 여러 팀에 속하게 되는 것이다.

개인

소프트웨어 개발에 관한 전문 기술

지적인 스킬

학습

동기

팀

사회적인 효과

팀 내의 영향력

프로젝트

의사소통

계획

자원 관리

사업부

사내 정치

문화

절차

회사

다른 회사와의 상호작용

비즈니스 전략

인센티브 계획

사회적인 상호 작용, 협동, 의사소통 스킬이 필요하다.

팀워크 스킬이 소프트웨어에 영향을 미치는 곳이 바로 이곳이다.

 

팀의 조직

팀 관리의 접근 방법

프로젝트는 동료를 기반으로 관리될 수 있다.

책임의 분할

수직형 팀조직

수평형 팀 조직

팀 조직과 코드의 구조

코드는 상호 작용하는 팀들의 구조와 영향력에 의해 반드시 영향을 받는다.

팀은 시스템의 분할을 촉진한다; 우리가 좋은 의도를 갖고 있더라도 설계는 팀의 구성에 의해 강제로 결정 된다.

 

팀워크를 위한 툴

소스 컨트롤

개발팀은 소스 코드를 중심으로 돌아간다. 코드를 담는 장소

결함 데이터베이스

테스트와 코드 정정을 조직화, 우선순위를 설정, 문제를 할당, 미결 상태 원인을 추적할 수 있게 한다.

그룹웨어

효과적인 의사소통을 인프라스트럭처가 필요.

방법론

널리 알려진 개발 방법론을 사용해라.

그렇지 않으면 임기응변식으로 업무가 수행될 수 있다.

프로젝트 계획

프로젝트를 에측대로 시간에 맞춰하기 위해서는 조직화가 필요하다.

 

팀이 걸리는 질병

바벨탑

대규모 의사 소통의 붕괴.

의사소통 능력이 떨어지면 사람들은 나름대로 추측으로 일을 진행

다른 배경, 다른 방법론, 다른 프로그래밍 언어, 다른 성격으로 인해 분열을 겪게 되어 발생한다.

경고 사인

개발자들이 서로 질문을 하지 않고, 그런 질문은 힘들어서 할 필요도 없다고 느낄 때

상세 규격서가 없거나, 코드에 관한 약속이 모호할 때 슬며시 일어난다.

방향 바꾸기

사람들에게 말을 계속 걸어라.

친목도모를 위한 무언가를 해서 팀을 각성시켜라.

페어 프로그래밍을 도입해라.

성공 전략

좋은 코드를 작성하기 위해서는 반드시 충분한 규율이 서야 한다.

독재

고도의 스킬을 가진 한 명의 프로그래머에 의해 이끌려지는 팀

인자한 팀장과 이를 존경하는 팀원이라면 문제가 없다.

경고 사인

독재자는 역할의 초점을 빠르게 변경하지 못하고 자기 권한의 수준을 나름대로 생각해서 결정

팀의 구조가 느리고 아주 조금씩 발전하게 되는 경향이 있다.

방향 바꾸기

독재자를 왕위에서 몰아내라.

몰아내고 팀을 재편성하거나 새로운 왕을 구해야 한다.

성공 전략

팀이 제대로 돌아가는지 여부와 별개로 독재가 이루어지고 있다면 당신의 권한 수준과 책임을 확인해라.

독재자에게 함부로 대하거나 무례하게 굴지 말아라.

그러면 팀의 사기만 떨어지고, 당신은 더욱 화가 날 것이다.

개발의 민주주의

비슷한 수준의 스킬을 갖는 서로 보완하는 성격의 프로그래머들의 팀

오픈 소스 개발이 대개 이런 패턴

최악의 경우 하나의 이슈로 끝없는 논쟁, 철학적 명상으로 아무것도 이루지 못하게 된다.

팀장이 무능하면 이렇게 될 수 도 있다.

경고 사인

팀장이 쩔쩔매면 사람들은 팀장을 무시하고 결정의 비율이 낮아진다.

팀장 역할을 하는 사람이 없으면 업무의 책임을 할당하는 사람도 없다.

몇 주가 지나도 완료되는 게 없을 것이다.

방향 바꾸기

팀 안에서 팀장 역할이 자유롭게 바뀌어야 하고, 팀장의 교체가 쉽게 이루어지도록 보장돼야 한다.

모든 사람들이 문제점을 볼 수 있어야 하며, 문제점이 누구의 책임인지 반드시 분명하게 해야 한다.

성공 전략

우유 부단한 사람을 피해라

프로젝트에서 잘 정의 된 부분을 할당 받았는지 확인하고, 명료하고 현실적인 데드라인을 가져라.

이는 몰아치는 파도에 떠내려가지 않게 버티는 닻과 같은 역할을 할 것이다.

위성 기지

팀 일부가 쪼개져 나간 경우

프로그래밍은 팀의 친밀한 상호 작용을 필요로 한다.

물리적으로 떨어져있으면 커피 자판기 옆에서 무의식적으로 비공식적인 대화를 할 기회가 사라진다.

사물을 바라보는 수준을 공유하고, 코드에 대해 다 같이 이해하는 일도 없어진다.

개발 응집력이 떨어진다.

친밀성이 부족해 사고 방식이 다르게 된다.

경고 사인

지리적으로 떨어진 팀은 쉽게 눈에 들어오지만 같은 사무실에서 분리된 팀들도 주의 깊게 봐야 한다.

부서간 분리도 조심해야 한다.

방향 바꾸기

신중한 모니터링과 관리가 필요하다.

모든 팀원들이 일찌감치 얼굴을 마주하는 모임을 갖는 것.

성공 전략

다른 사이트에 있는 사람들과 같이 일을 해야 한다면 그 사람들에 대해서 잘 알아두어야 한다.

그랜드 캐년

스킬 수준과 경력이 완전히 극과 극인 사람들로 구성

고급 개발자들은 지겨운 일을 초급개발자에게 뭉텅이로 넘겨준다.

초급 개발자들은 더 흥미로운 프로그래밍을 할 기회를 잃어버리게 되어 실망과 환멸을 느끼게 된다.

경고 사인

팀이 성정하는 과정을 지켜봐라. 팀원들의 분포를 신중하게 살피고 일이 어떻게 할당되는지 지켜봐라.

방향 바꾸기

자리 배치를 바꿔 파벌들이 서로 섞이게 해라.

고급 프로그래머와 초급 프로그래머가 혼성된 페어 프로그래밍을 시작해라.

초급 개발자들을 훈련 시키는 수습 교육을 시작해라.

성공 전략

당신이 고급 프로그래머라면 초급들이 배울 필요가 있다는 사실을 인정해라. 흥미로운 프로그래밍 작업을 독점하지 말아라.

당신이 초급 프로그래머라면 더 해볼만한 일을 달라고 요청해라. 배움을 추구하고 그 일을 정말 잘 해내라.

모래 구멍

좋은 팀을 만들기 위해서는 좋은 프로그래머가 많이 필요하지만, 나쁜 팀을 만들기 위해서는 나쁜 프로그래머 한 명이면 충분하다

기술적으로 무능한 프로그래머

사기를 떨어뜨리는 사람

경고 사인

팀과 조화를 이루지 못하는 한 놈만 찾으면 된다.

모든 사람이 불평하는 대상이거나, 항상 혼자서 일을 하는 프로그래머이다.

방향 바꾸기

모래 구멍을 제거하는 것.

이 사람이 일으키는 혼란을 최소화할 방법을 찾거나, 이 사람을 팀에 더 잘 통합시키는 방법을 생각해 내야만 한다.

성공 전략

가장 중요한 것은 모래 구멍이 되지 말아라!

모래 구멍과의 접점을 줄이기 위해 자신을 격리시켜라.

과민반응도 하지 말아라.

레밍스

팀이 필요로 하는 것이 아닌 요구된 것만해서 넘기는 것에 집중하게 된다.

비전을 가진 팀원이 없다.

특히 신생 회사에 취약하다.

급하니까 이렇게 하고 나중에 제대로 하자

경고 사인

현재 작업의 규격서가 만족스럽지 않다면 레밍스 팀에 속해있을 가능성이 높다.

방향 바꾸기

당신의 팀이 무엇을 하고 있는지 다시 검토.

근시안적 해킹이 아닌지 의문을 가질 것.

성공 전략

일의 동기를 알고 주어진 일에 의문을 가져라.

나중에 고칠 수 있을 것이라고 절대 생각하지 말아라.

 

좋은 팀워크에 도움이 되는 개인의 스킬과 성격

의사소통

의사소통을 하지 않으면 팀워크는 죽는다.

효과적으로 하기 위해서는 관련된 모든 당사자들이 참여해야 한다.

필요한 능력

규격서를 모호하지 않게 작성할 수 있어야 한다.

규격서를 올바로 읽고 이해할 수 있어야 한다.

현대에도 얼굴을 맞대고 대화하는 구식 방법이 가장 효과적이다.

겸손

다른 사람의 의견에 귀를 기울이고 존중해라.

내 의견만이 유일한 솔루션이 아니다.

갈등 처리하기

성숙하고 책임감 있는 태도를 취해야 하고, 갈등 상황을 예방하는 방법을 배워야만 한다.

갈등과 증오는 팀의 효율성을 심하게 떨어뜨린다.

배우고 적응하기

새로운 기술적인 스킬을 끊임없이 배워야 하지만 팀으로서 일을 하는 방법도 배워야 한다.

적응력은 학습과 밀접한 관련이 있다.

적응력이 있는 프로그래머는 새로운 스킬을 신속하게 배워서 그런 빈틈을 메우고 팀에 기여한다.

너 자신의 한계를 알라

당신이 할 수 없는 일이나, 당신이 완료할 수 없는 일을 맡게 되었으면 가능한 빨리 관리자에게 알려라.

한계를 시인하는 것이 팀의 실패 지점이 되는 것보다 훨씬 낫다.

또한 한계를 시인하면 관리자는 당신이 그 일을 하는 것을 돕는 특별한 자원을 제공한다.

이 과정에서 배우게 될 것이다.

 

팀워크의 원칙

코드의 공동 소유

코드는 개이니 만들었어도 팀의 역작.

코드의 주인이 아니라 집사라고 생각해라.

다른 사람의 코드를 존중하라

코드 가이드라인

협동 개발을 하려면 코드 가이드 라인이 있어야 한다.

성공을 정의하라

단기 목표로 삼을 작은 이정표들을 많이 정의해라.

그리고 일정에 맞췄을 때 축하해줘라.

책임을 정의하라

탈진을 피하라

팀의 목표가 불가능한 것이면 안 된다.

힘들고 위험한 일을 몇 명에게 부여되지 않도록 해라.

 

팀의 라이프 사이클

팀의 생성

의사소통 대상을 명확히 해라.

단독으로 고성능 단위가 될 수 있는 능력 있는 팀원이 필요하다.

적절한 팀워크 모델을 골라서 의견 교환

단순한 집단을 만드는 것 이상으로 의욕적이고 공통된 목표를 갖는 응집된 작업 인력 단위이다.

팀이 무엇을 하기 위해 존재하는지 정말 알기 전까지는 팀원들을 불러 모으지 말아라.

팀의 성정

팀의 내적인 성정

팀 작업 패턴 정착, 코딩 문화 확립

회의 주의나 악의적인 마음을 갖는 사람이 없도록 경계

팀의 외적인 성장

팀이 외적으로 성장할 때 팀원들이 점진적으로 추가

협동 작업

팀에 속하는 사람들이 모두 제자리에 있고, 팀이 완전히 기능을 하는 시점

팀에 변화가 일어나면 그에 적응해야 한다.

팀의 종결

어느 날 갑자기 팀이 해체되지 않는다. 비탈길을 미끄러져 내려갈 것이다.

사람들이 팀을 떠나갈 때 정보가 손실되지 않도록 주의해야 한다.

프로젝트가 끝에 도달한 팀은..

유지보수를 한다.

새로운 개발 (새로운 버전)을 시작한다.

실패했다면 원인 분석

여러 개의 프로젝트에서 일을 하기 위해 팀을 나눈다.

 

좋은 프로그래머는…

• 자기가 작성한 코드에 대해 영역권을 주장하지 않는다.
• 소프트웨어 시스템을 더 좋게 만들 수 있다면, 어떤 종류의 개발 업무든 수행할 것이다
• 팀에 기여하면서 배우고 성장한다; 팀을 희생시키지 않으면서 성취할 수 있는 개인적인 목표를 세운다
• 의사소통을 잘 할 수 있다. 항상 다른 팀원들의 말에 귀를 기울인다
• 겸손하고, 팀에 도움이 되고, 다른 팀원들을 존중하고 가치 있게 평가한다

나쁜 프로그래머는…

• 자기만의 코드 제국을 건설하고, 자신을 아주 중요한 사람으로 만들려고 노력한다
• 자기만의 일을 하고 싶어 하고, 가장 매력적인 일을 찾아다닌다
• 팀의 효율성을 희생시켜가면서 자기가 하고 싶은 일을 수행한다
• 항상 자기의 개인적인 의견을 주장하고 싶어 한다
• 팀이 자기에게 봉사하기 위해 존재한다고 생각하고, 자기가 팀의 최고 팀원이라고 생각한다 - 자기가 코딩 커뮤니티에 내린 신의 선물이라고 생각한다