🌈 Chapter 5: 피처 단위로 계획하기

• 소프트웨어를 자주 배포한다면 문제가 생길 일이 크게 줄어든다.
• 가치는 빠르고 더 좋은 방향으로 성장한다. 주기가 짧으니 경영진도 프로젝트 진행 상황을 잘 알 수 있다.
• 개발자도 명확화고 규모가 작은 목표에 최대한 집중할 수 있다.

📚 계획은 없어서는 안 될 부분입니다.

• 프로젝트에는 계획이 필요하다.
• 먼저 개발해야 할 핵심 피처를 추리는 것이 중요하다.
• 가치가 낮은 피처는 최대한 뒤로 미루어야 한다.
• 좋은 아이디어 몇 가지를 얻기 위해 수많은 나쁜 아이디어를 골라내야만 한다.
• 그러니 계획을 세우되, 언제든지 변화를 줄 수 있는 환경을 만들도록 한다.

📚 세부 계획은 필요 없습니다.

• 우리는 시간과 자원은 한정되어 있으므로 각각의 아이디어를 구현하는 데 얼마나 걸리는지 예상해봐야 한다.
• 먼저 시간과 예산을 정해 두고 가장 중요하고 가치 있는 피처를 우선으로 제품을 개발한다.
• 제품을 언제든지 배포할 수 있는 상태로 준비한다. 그리고 시간이 지나면 모든 것을 중단한다.
• 때로는 배포일이 다가오기도 전에 프로젝트가 끝날 수도 있다. 가장 중요한 피처는 이미 개발이 끝났으니까.
• 이렇게 하면 더 적은 예산으로 더 빠른 시간에 여러 가치를 지닌 제품을 배포할 수 있다.

📚 시작해봅시다!

• 이론상으로 프로젝트는 출발 신호와 동시에 시작한다. 아이디어를 얻고 충분히 고려해본 뒤, 작은 팀과 함께 개발을 시작한다.
• 아이디어가 가치로 바뀔 수 있는지, 기간은 얼마나 걸릴지를 빨리 알 수 있다.
• 그다음에는 프로젝트를 계속 진행할지 예산을 그만 투입할지 아니면 더 많이 투입할지 정할 수 있다.

📚 지속적인 계획: 피처 분리

• 프로젝트를 시작할 때 계획을 세우는 것만으로는 충분하지 않다.
• 프로젝트는 가치를 우선하므로 계획은 프로젝트 기간 내내 필요하다. 프로젝트에 참여하는 개발팀은 일정한 작업 속도를 유지해야 한다.
• 보통 1~2주를 하나의 주기(스프린트)로 개발을 진행하며 각각의 피처는 2~3일 정도 작업할 분량일 때 가장 좋은 결과를 낼 수 있다.
• 프로젝트를 진행할 때, 커다란 피처를 태스크라는 단위로 쪼개는 방법은 추천하지 않는다.
• 태스크 단위를 사용한다면 개발자가 아닌 사람들은 피처 개발이 어떻게 진행되는지를 명확하게 파악할 수 없다.
• 커다란 사용자 스토리는 개발자가 아닌 사람들도 쉽게 이해할 수 있는 작은 사용자 스토리로 쪼개는 것이 더 낫다.

📚 프로젝트에 참여하는 개발팀은 하루에 얼마나 많은 일을 해야 할까요?

• 개발 주기에 얼마나 많은 일을 해야 할지는 팀 스스로가 결정한다. 그 어떤 사람보다 팀 스스로가 상황을 더 잘 알고 있다. 계다가 자신이 작업해야 할 시간을 직접 결정한다면 더욱 책임감 있게 일할 것이다.
• 팀이 얼마나 많은 것을 할지 결정을 도와주는 연습 방법이 있는데 어제의 날씨라는 방법이다.
• 오늘은 어제의 업무량만큼 일할 수 있다. 이 원리를 반복 개발 주기를 사용하는 프로젝트에 적용한다. 가장 최근 주기의 작업량을 기준으로 업무량을 계획하는 것이다.
• 업무량을 개발 주기가 시작되기 직전에 계획한다. 업무량을 결정하려면 헌재 진행 중인 피처를 이해하고 있어야 한다. 그리고 각 개발팀은 업무량 결정에 대해 논의해야 한다.
• 업무량을 개인별로 추정하는 것은 결코 권하지 않는다. 개인이 아닌 팀 전체를 이해하고 팀이 할 수 있는 양을 추정해야 한다.

📚 추정은 위험합니다!

• 추정에는 심각한 위험 요소가 존재하는데 우리는 과장하거나 비교하려는 어쩔 수 없는 욕구를 가지고 있기 때문이다.
• 비즈니스와 프로젝트 관리는 반드시 완료돼야 할 일과 그렇지 않은 일을 구분했을 때 최선의 결과를 가져온다는 사실을 기억하라.
• 추정에 너무 집중하면 이런 책임감에서 멀어지게 되며, 정확한 추정을 해야 한다는 생각 때문에 보수적으로 추정하기 쉽다.
• 해야 할 일을 잘게 부순다. 보통은 가치 있는 사용자 스토리 하나를 테스트할 수 있는 수준까지 쪼갠다. 그런 다음 작업을 시작한다.
• 개발이 얼마나 걸릴지 예측해야 할 때는 단순히 완료된 것을 세어 봄으로써 쉽게 추측할 수 있다.

📚 무리한 목표는 자멸하는 길입니다.

• 프로젝트를 계획할 때는 더 큰 목표를 계획하거나 피처를 하나만 더 추가하자고 개발팀을 설득하고 싶을 것이지만 그렇게 하면 절대 안 된다.
• 이런 행동은 프로젝트 전체에 치명적인 손상을 입힌다.
• 그렇게 부탁하거나 목표를 더 많이 잡으면 개발팀은 정말로 그렇게 해보고자 무의식적으로 서두르게 된다. 몇 가지 테스트는 생략하겠죠.
• 서두르다 보면 결함을 더 많이 심게 된다. 결함을 방지하는 것보다 수정하는 데 훨씬 오래 걸리므로 프로젝트 일정도 지연시킬 수 있다.
• 최악은 프로젝트가 막바지에 다다라 더 늦어지면 안 될 때 이 현상이 더 심해진다는 점이다.
• 지저분한 코드도 일정을 지연시킨다.
• 때문에 압박하는 행동은 치명적이다. 절대 하지 마라.

📚 추정 없이 진행해봅시다.

• 소프트웨어 개발에서 프로젝트 추정은 아직도 논란이 많다.
• 추정과 세부 계획이 필요하다고 생각하는 사람도 있지만, 안타깝게도 그런 생각이 프로젝트 추정에서 터무니없이 많은 목표를 세우는 원인이 된다.
• 프로젝트를 진행하는 팀에게 추정은 항상 내부 문제가 되며 시간만 낭비하는 꼴이 된다.

📚 자주 계획하고, 다음에 할 일을 정하세요. 과욕은 금물입니다.

• 짧은 개발 주기마다 계획을 세우며 다음에 할 가장 중요한 것들을 정하는데, 항상 가장 가치 있는 아이디어를 먼저 선택해야 한다. 그것이 바로 가치를 빨리 전달하는 방법이다.
• 팀이 감당할 수 있는 업무보다 일이 주어질 때가 있을 것이다.
• 그러나 절대 업무량을 초과해 일하면 안 된다. 초과 업무는 팀을 무력하게 만들고 건강을 해친다. 무기력하고 건강하지 못한 코드로는 제대로 일할 수 없다.
• 팀이 감당할 수 있는 업무보다 일이 많다고 깨달았다면 그 즉시 업무를 덜어내야 한다. 프로젝트가 끝날 때까지 팀이 버틸 수 있도록 업무량을 관리해야 한다.