실용주의 프로그래머 9장 - 실용주의 프로젝트

나의 키워드

• 실용주의 팀
• 코코넛만으로는 부족하다
• 사용자를 기쁘게 하라
• 오만과 편견

소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다. (p.377)

실용주의 팀

• 우리가 말하는 팀은 작고 보통은 그 자체로 안정적인 존재다. 50명은 팀이 아니다. 큰 무리다. 구성원이 계속 다른 업무에 끌려가고, 아무도 서로를 모르는 팀도 사실 팀이 아니다. (p.379)
• 실용주의 팀은 작다. 구성원이 대략 10 ~ 12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로를 잘 알고, 신뢰하며, 의존해야 한다. (p.379)
• 품질은 팀의 문제다. 아무리 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면, 자질구례하게 계속되는 문제를 고치는 데 필요한 열정을 유지하긴 어려울 것이다. 개발자가 이런 수정 작업을 하느라 시간을 쏟는 것을 팀이 적극적으로 방해하고 나선다면 문제는 더욱 커진다. (p.379)
• 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다. (p.380)
• 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의했겠거니 하고 여긴다. 제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다.(p.380)
• 이에 맞서야 한다. 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. (p.380)
• 새로운 기능을 만드는 것 외에도 해야 할 일들이 있다. 예를 들면 다음과 같다. (p.381)
  • 구현 시스템 유지 보수: 우리는 이 일을 구석에 치워 두려고 하는 팀들을 많이 만났다. 팀이 이 업무를 맡고 있다면, 진짜로 수행하라.
  • 프로세스 회고와 개선: 지속적인 개선이 일어나려면 주위를 둘러보고 무엇이 잘되고 무엇이 잘되지 않았는지 확인한 다음 변화를 일으킬 시간이 있어야 한다. 계획을 세우고, 고쳐라
  • 새로운 기술 탐험: 후보 기술로 프로토타입을 만들어 보고 신중하게 조사할. 새로운 것을 시도해 보고 결과를 분석하는 업무를 일정표에 추가하라.
• 개인적으로 배우고 역량을 키우는 것은 좋은 시작점이다. 하지만 많은 기술이 팀 전체로 퍼졌을 때 더 효과적이다. (p.382)
• 외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀이야말로 최악이다. 그런 팀의 회의는 아무런 체계가 없고 침묵만 가득하다. (p.382)
• 훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 사람들은 이 팀과의 회의를 기대한다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문이다. (p.382)
• 만약 질문을 하거나 여러분의 상황을 공유하기 위해 일주일 남은 팀 회의 시간까지 기다려야 한다면 엄청 껄끄러운 커뮤니케이션이다. (p.383)
• 프로젝트팀은 프로젝트의 여러 분야에서 수많은 기술을 섭렵하고 다양한 과제를 해결해야 한다. 요구 사항을 이해하고, 아키텍처를 설계하고, 프론트엔드와 서버 코드를 쓰고, 테스트를 돌리는 모든 일을 해내야 한다. 그런데 이런 활동들과 과제들을 독립적으로 따로따로 수행할 수 있을 거라고 많이 오해한다. 하지만 그런 일은 불가능하다. (p.384)
• 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다. (p.384)
• 팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. (p.385)

코코넛만으로는 부족하다

• 눈에 잘 띄는 결과물을 만드는 데만 투자하면서 기반이 되는 작업이 마법처럼 끝나 있기를 소망한다.(p.387)
• 예를 들어 우리가 직접 만나본 팀 하나는 자신들이 스크럼을 사용한다고 주장했다. 하지만 가까이에서 지켜봤더니 그들은 일일 스탠드업 미팅을 일주일에 한 번씩만 하고, 반복 주기는 4주 단위였는데 6주나 8주로 늘어지는 경우가 잦았다. 그런데도 그들을 널리 쓰이는 ‘애자일’ 일정 관리 도구를 사용하니 아무런 문제가 없다고 생각했다. (p.387)
• 속아 넘어가지 말라. 특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다. (p.388)
• 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
• 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다. 그러니 인기 있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌려야 한다. (p.389)
• 진짜 목표는 당연히 “스크럼을 한다”나 “애자일을 한다”, “린을 한다” 같은 종류가 아니다. 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다. (p.390)

사용자를 기쁘게 하라

당신이 사람들을 황홀하게 만들 때, 당신의 목표는 그들로부터 돈을 벌거나, 당신이 원하는 일을 시키는 것이 아닙니다. 사람들을 커다란 기쁨으로 충만하게 하는 것입니다. - 가이 가와사키

• 개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. (p.402)
• 그러면 어떻게 사용자들이 기대하는 것을 밝혀낼 수 있을까? 단순한 질문을 던져라. (p.402)
  • 이 프로젝트가 끝나고 한 달(혹은 일 년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을까요?
  • 대답을 들으면 여러분은 아마 놀랄 것이다. 제품 추천을 개선하는 프로젝트라도 실제로는 고객 잔존율로 성공을 판단할 수 있다.
  • 두 데이터베이스를 통합하는 프로젝트는 데이터의 품질로 판단할 수 있고, 절감한 비용으로 판단할 수 있다.
  • 어쨌든 소프트웨어 프로젝트 자체가 아니라 이런 성공 척도가 진짜로 의미 있는 사업 가치다.
  • 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.

오만과 편견

• 실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성을 널리 알려지는 것을 기뻐한다. (p.404)
• 코드에는 주인이 있어야 하지만 꼭 개인일 필요는 없다. 실제로 켄트 백의 익스트림 프로그래밍에서는 코드의 공동 소유권을 제안한다. 하지만 이는 익멱성의 위험을 예방하기 위해 짝 프로그래밍과 같이 추가 실천 사항을 필요로 한다. (p.405)
• 우리는 소유권에 대한 긍지를 보고 싶다. “내가 이걸 만들었고, 내 작품의 품질을 보증합니다.” 여러분의 서명이 품질의 보증 수표로 인식되게 해야 한다. 사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성되었으며 제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자. 전문가가 만든 진정으로 전문가다운 결과물. 실용주의 프로그래머. (p.406)

도전해볼 것

• 회사 차원에서 정말 애자일하게 반복 주기를 잡고 진행하면 어떨까요 ? (p.387)
• 이 프로젝트가 끝나고 한 달(혹은 일 년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을까요? (p.402) 에 대한 각 팀 별 의견을 모아보기 ?