4장 반복 속도에 투자하라

• 개발 주기 반복 속도가 빨라질수록 더 많은 것을 배울 수 있다.
  • 반대로 실수를 피하려고 너무 느리게 움직이면 기회를 놓칠 수 있다.
• 도구 제작에 투자하라.
  • 컴파일 시간, 배포 주기, 개발 소요 시간을 줄이면 시간을 절약할 수 있다.
• 시간을 절약해주는 도구를 사용하면 할수록 혜택이 복리 계산된다.
• 디버깅 작업 흐름을 최적화하라.
  • 코드가 정상 작동하는지 확인하는 데 소요되는 시간을 과소평가하지 마라.
  • 작업 흐름을 단축시키는 데 충분한 시간을 투자하라.
• 자신이 사용하는 기술의 기본을 마스터하라.
  • 매일 사용하는 개발 환경을 편하게 효율적으로 쓸 수 있게 노력하라.
  • 이러한 투자는 개발자로 일하는 내내 배당 수익을 낼 것이다.
• 개발 주기 반복 과정을 전체론적인 시각(holistic view)으로 보라.
  • 자신의 권한 범위 내에 있는 회사 또는 팀과 관련한 병목을 간과하지 마라

5장 개선하려는 사항을 측정하라

• 올바른 지표를 선택하는 건 직업적 목표뿐 아니라 개인적 목표를 달성하는 데도 중요하다.
• 지표는 가장 큰 효과를 내고 실행하기 좋으며 즉각 반응하되 견고한 것으로 정해야 한다.
• 진행 상황을 측정하라.
  • 측정하지 않은 것은 개선하기 어렵다.
  • 측정하지 않으면 어떤 노력이 가치가 있었는지 어떻게 알겠는가?
• 최고 수준의 지표를 신중하게 선택하라.
  • 측정 지표가 달라지면 가치 있는 행동도 달라진다.
  • 어떤 행동을 해야 할지 신중히 파악하라.
• 시스템을 계측하라.
  • 시스템이 복잡할수록 더 많이 계측해야 아무 정보 없이 장님처럼 비행하지 않을 수 있다.
  • 더 많은 지표를 더 쉽게 계측하게 만들면 더 자주 계측할 수 있다.
• 유용한 수치를 익혀라.
  • 진행 상황의 기준으로 삼거나 간단한 계산에 도움이 되는 수치를 외우거나 쉽게 확인할 수 있게 하라.
• 데이터 무결성을 우선시하라.
  • 나쁜 데이터는 데이터가 없는 것보다 더 나쁘다.
  • 자신이 옳다고 생각하며 잘못된 결정을 내리기 때문이다.

6장 아이디어는 일찍 그리고 자주 검증하라

• 프로젝트의 성공 가능성을 높이는 데 필요한 피드백 채널을 위한 전략
  • 피드백을 개방적으로 수용하라.
    • 피드백과 비판을 개인적인 공격이 아닌 발전의 기회로 보라.
  • 코드를 일찍, 자주 커밋하라.
    • 대규모 변경은 리뷰하기 어렵고 피드백 받는데 시간이 오래 걸린다.
  • 코드 리뷰를 철저한 비평가에게 부탁하라.
  • 팀원들에게 아이디어에 대한 반응을 요청하라.
  • 새로운 시스템의 인터페이스나 API부터 설계하라.
  • 코드에 에너지를 쏟기 전에 설계 문서를 공유하라.
  • 최대한 팀원들과 맥락을 공유할 수 있게 프로젝트를 구조화하라.
  • 논란의 여지가 있는 기능이라면 너무 많은 시간을 투자하기 전에 승인을 요청하라.
• 반복적인 방식으로 문제에 접근하여 노력의 낭비를 줄여라.
  • 매 개발 주기는 새로운 아이디어를 검증할 기회다. 빠르게 반복하고 빠르게 배워라.
• 소규모 검증으로 대규모 구현의 위험을 줄여라.
  • 노력의 일부를 투자해서 계획의 나머지 부분이 실행할 가치가 있는지 알아내라.
• A/B 테스트를 활용해서 제품 가설을 끊임없이 검증하라.
  • 제품을 점진적으로 개발하고 효과가 없는 요소를 구별해 나가다 보면 여러분의 노력이 사용자가 실제로 원하는 결과로 이어질 가능성이 커진다.
• 1인 프로젝트를 할 때는 정기적으로 피드백을 구할 방법을 찾아라.
  • 고립된 상태에서 일하는 것이 쉽고 편할 수 있지만 미리 발견했더라면 엄청난 노력의 낭비를 막을 수 있었을 무언가를 간과할 위험이 크다.
• 자신의 의사 결정을 검증하는 자세를 갖춰라.
  • 중요한 의사 결정을 내린 후 그냥 넘어가지 말고 데이터를 수집하고 작업의 가치와 효과를 평가할 피드백 과정을 만들어라.

7장 프로젝트 추정 기술을 향상시켜라

• 정확한 추정치 도출을 위한 방법
  • 프로젝트를 더 작은 작업으로 분해하라
  • 자신 또는 다른 누간가가 원하는 작업 시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하라.
  • 추정을 최상의 시나이로가 아닌 확률 분포로 생각하라.
  • 실제 업무 담당자가 추정하게 하라.
  • 기준점 편향에 주의하라.
  • 하나의 업무를 여러 방법을 사용해 추정하라.
    • 더 작은 작업으로 분해해서 각 작업을 추정한 후 상향식으로 추정치 산출
    • 과거에 비슷한 기능을 만드는 데 데이터를 수집
    • 만들어야하는 서브시스템의 개수를 계산하고 각 시스템을 만드는 데 필요한 평균 시간을 추정
  • 이상적인 인월(person-month)을 조심하라.
    • 한 여성이 아홉달 안에 아이를 낳을 수 있다고 해서 9명의 여성이 한 달 안에 아이를 낳을 수 있는 것은 아니다.
  • 기존 데이터로 추정치를 검증하라.
  • 범위가 커질 수 있는 작업을 타임 박스로 제한하라.
    • 라이브러리를 사용할지 조사하는 데 시간을 더 쓸 수 있지만, 시간 대비 수익은 줄고 일정에 따른 비용이 증가한다.
    • 조사에 3일 정도 걸린다고 추정하지 말고, 3일 이내에 찾은 데이터를 기반으로 최선의 결정을 내리려고 노력하라.
  • 다른 이들이 추정에 이의를 제기하도록 허용하라.
• 프로젝트 계획에 추정을 포함시켜라.
  • 추정을 바탕으로 특정 날짜에 계획한 기능을 모두 출시하는 것이 가능한지 결정해야 한다.
  • 불가능하다면 출시할 기능 변경 또 는 출시일 변경에 관해 논의해야 한다.
  • 원하는 목표에 맞춰서 추정치를 변경하지 마라.
• 미지의 변수를 고려해서 일정을 여유 있게 잡아라.
  • 의무적으로 해야 하는 다른 업무, 휴일, 병치레 등을 고려하라.
  • 프로젝트가 길수록 이런 일이 발생할 확률이 높아진다.
• 측정할 수 있는 마일스톤을 정의하라.
  • 명확한 마일스톤이 있으면 작업이 제대로 진행되는 중인지, 지연되는 중인지 확인할 수 있다.
  • 마일스톤을 추정치를 수정할 기회로 삼아라.
• 가장 위험한 작업을 먼저 하라.
  • 미지의 영역을 초반에 확인해서 프로젝트의 위험과 추정치 변경을 줄여라.
  • 프로젝트 초반에 하기 쉬운 일에 집중해놓고 일이 잘 진행되고 있다고 착각하지 마라.
• 초과 근무의 한계를 이해하라.
  • 결승선에 가까워지지도 않았는데 전력 질주를 시작했다가 번아웃을 경험하는 팀이 많다.
  • 일정이 지연되고 있고 어떻게 해야 좋은지 방법을 모른다고 해서 전력 질주하지 마라.
  • 초과 근무로 프로젝트를 제때 마칠 수 있다고 확신하는 경우에만 이를 활용하라.