[실용주의 프로그래머] 실용주의 팀

[실용주의 프로그래머] 실용주의 팀

[실용주의 프로그래머] 실용주의 팀, 기능 중심 팀, 깨진 창문을 없애라, 반복하지 마라, 삶은 개구리, 자동화, 적당히 괜찮은 소프트웨어

깨진 창문을 없애라.

품질은 팀의 이슈다.

만약 가장 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면 귀찮은 문제를 고치는 그의 열정은 줄어들 것이다.

팀 전체가 깨진 창문(아무도 고치려고 하지 않는 사소한 결점)을 용납하지 않아야 한다.

팀은 상품의 품질에 책임을 져야만 한다.

팀은 '깨진 창문을 없애라' 철학을 이해하는 개발자들을 지원하고 그렇지 못한 개발자들은 이해하도록 격려해야 한다.

개인보다는 팀이 삶은 개구리가 되기 쉽다. (서서히 도태된다.)

사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요구하는 변화에 대해 팀 리더가 이미 오케이 했거니 하고 여긴다.

제 아무리 단단히 통제되는 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에 대해 둔감할 수 있다.

모든 사람이 적극적으로 환경 변화를 감시해야 한다.

수석 온도 감시자를 선임해야 할지도 모른다.

그로 하여금 범위의 확장, 시간 척도의 감소, 추가 기능, 새로운 환경 등 무엇이건 간에 애초 합의사항에 있지 않았던 것들을 항상 점검하도록 하라.

새 요구사항에 대해서는 수치를 보유하라.

이미 일어난 변화를 거부할 필요는 없다.

단지 그런 일이 벌어지고 있다는 것을 알고 있으면 된다.

팀은 나머지 세상과 명확히 의사소통해야 할 필요가 있는 존재다.

훌륭한 프로젝트 팀은 뚜렷한 특성을 갖는다.

모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문에 사람들은 회의를 기대한다.

그들이 생산해 내는 문서는 깔끔하고 정확하며 일관적이다.

팀은 한 목소리로 이야기한다.

심지어 유머감각도 있을 것이다.

팀이 하나로서 의사소통하게 도와주는 간단한 마케팅 비결이 있다.

프로젝트를 시작할 때 이름을 지어주는 것이다.

유별난 이름이라면 더 좋겠다.

반복하지 마라.

중복은 노력을 낭비하게 하고, 결국 유지보수의 악몽을 끌어들일 수 있다.

여기에는 훌륭한 의사소통이 분명 도움이 된다.

어떤 팀은 팀원 한 명을 프로젝트 사서로 임명하여 문서와 코드 저장고를 관리하는 책무를 맡긴다.

다른 팀원들은 어떤 정보를 찾을 때 이 사람을 첫 번째로 찾아간다.

프로젝트가 한 사람의 사서가 감당하기에는 너무 클 경우(혹은 아무도 그 역할을 맡으려고 하지 않을 때), 작업의 다양한 기능적 측면의 핵심 사안별로 사람을 임명하라.

프로젝트의 여러 활동(분석, 설계, 코딩, 테스팅)이 독립적으로 이루어진다는 생각은 잘못이다.

그런 일은 불가능하다.

그것들은 동일한 문제의 다른 관점이고, 인위적으로 각각을 분리하는 것은 많은 문제를 야기할 수 있다.

팀을 기능 중심으로 조직하라.

기능중심으로 팀을 조직하면, 변화가 생기더라도 전체가 영향받는 일이 없게 된다.

그러나 이 기법은 책임감 있는 개발자들과 강력한 프로젝트 관리가 있을 경우에만 효과가 있다.

자율적으로 팀을 여럿 만들고 리더십 없이 그냥 제멋대로 내버려두면 재앙이 벌어진다.

일관성과 정확성을 보장하는 훌륭한 방법은, 팀이 하는 모든 일을 자동화하는 것이다.

자동화는 모든 프로젝트팀에게 필요불가결한 요소다.

팀은 개인들로 이루어진다는 사실을 명심하라.

각 팀원이 자신의 방식대로 빛나게 해 주어라.

그들을 지원하기에, 그리고 프로젝트가 요구사항에 맞게 이루어지기에 딱 좋을 만큼의 구조를 제공하라.

그리고 나서 적당히 괜찮은 소프트웨어에 나오는 화가처럼, 계속 덧칠하려는 욕구를 참는 것이다.