Part 1. 가치를 이루는 것들 Chapter05. 피처 단위로 계획하기
제품이 가진 비전은 작은 한 부분이 아닌, 크고 멋진 아이디어이다.
커다란 제품 아이디어를 매우 명시적이며 제어할 수 있는 세부 피처들로 쪼갤 방법은 무엇일까?
Chapter05. 피처 단위로 계획하기
계획은 없어서는 안된다.
너무 세세한 계획은 독이다.
이것이 없으면 살 수 없을 정도로 중요한 피처.
그러한 피처를 먼저 추려내고 기록하자.
가치가 낮은 피처를 생각하는 데 시간을 낭비하지 말고 기록만 해두자.
Q. 수많은 아이디어 중에서 성과가 있던 것은 얼마나 되나요?
Q. 실제로 멋진 아이디어였던 것은 얼마나 됐죠?
Q. 쓸모없는 아이디어는 얼마나 됐나요?
- 반반일 것이다.
세부 계획은 필요 없다.
시간과 예산을 정해두고 우선순위를 정해서 제품을 개발한다.
제품을 언제든지 배포할 수 있는 상태로 준비한다.
시간이 지나면 모든 것을 중단한다.
Q. 프로젝트 예산을 추정하려면 얼마나 많은 장기적 세부 사항을 계획해야 할까요?
Q. 예산 내에서 계획을 세우는 것이 더 나을까요?
- 대부분 그러는 쪽이 더 나을 것 같다.
Q. 아니면 빡빡한 배포 일정을 세우고 그 안에서 할 수 있는 최고의 결과를 만드는 계획은 어떨까요?
- 개인적으로 배포 일정은 넉넉히 잡아도 빡빡하기 때문에 할 수 있는 한 생각한 것보다 더 넉넉히 잡아야 할 것 같다.
시작해봅시다!
Q. 경영진은 제안된 프로젝트를 얼마나 많이 알고 있어야 할까요?
- 다른 것은 몰라도 프로젝트의 의미, 왜 그 프로젝트를 하는지 목적을 정확히 이해하고 있어야 한다.
Q. 추정한 비용은 실제 비용과 얼마나 가까워야 할까?
- 경영진이 매니지할 수 있을 만큼의 오차 범위 안으로 가까워야 한다.
Q. 대강 추정한 내용만으로 성공을 향해 나아갈 수 있을까?
- 그렇다. 유연하게 제품을 기획하되 언제든지 배포할 수 있는 상태로 준비하며 우선순위대로 피처를 개발하면 된다.
지속적인 계획 : 피처 분리
보통 1~2주를 하나의 주기로 개발을 진행하며 각각의 피처는 2~3일 정도 작업할 분량일 때 가장 좋은 결과를 낼 수 있다.
커다란 피처를 태스크 단위로 쪼개면 비개발자들이 진행 상황을 명확히 알 수 없다.
항상 사용자 스토리를 기준으로 개발해야 한다.
Q, 제품이 가진 거대한 피처는 얼마나 작은 피처로 쪼갤 수 있을까요?
- 의미를 가진 사용자 스토리만큼 작게 쪼갤 수 있다.
Q. 쪼갠 피처 중에서 다른 피처보다 훨씬 더 가치가 있는 피처는 없나요?
- 있다.
Q. 훨씬 더 가치 있다고 생각하는 피처는 무엇인가요?
- 사용자에게 핵심가치를 제공하는 피처
- 프로젝트의 목적과 대응되는 피처
하루에 얼마나 많은 일을 해야 할까?
팀 스스로가 결정한다.
업무량은 개발 주기가 시작되기 직전에 모든 팀원이 참여하여 결정한다.
피처를 만들기 전에 반드시 그 피처를 이해해야 한다.
업무량은 개인별 보단 팀 전체 단위로 추정하다.
이것은 추정을 정확히 하기 위해가 아니라
제대로 된 일을 일관된 속도로 수행하기 위해 업무량을 추정하는 것이다.
추정은 위험하다.
반드시 완료돼야 할 일과 그렇지 않은 일을 구분할 때 최선의 결과를 얻는다.
정확한 추정을 위해 보수적으로 될 수 있다.
Q. 추정한 것과 실제 수치를 비교해봅시다. 추정이 더 나아지도록 도와준 것은 무엇인가요?
- 지난 경험일 것이다.
Q. 그중에서 범위를 관리함으로써 얻을 수 있는 것이 있나요?
범위를 관리한다는 것이 무슨 뜻인지 모르겠다.
Q. 그중에서 추정을 향상하는 것보다 범위를 관리함으로써 더 나은 결과물을 얻게 해주는 것은 무엇이 있나요?
- 이하동문
Q. 추정을 더 잘하려다 팀원들을 더 보수적으로 만들어도 그렇게 할 의향이 있나요?
- 적당한 중용이 필요하다. 그 기준은 신뢰를 잃지 않을 정도 만큼의 효율성 추구이다.
Q. 예측이 직접 해보는 것보다 정확할 수 있을까요?
- 없다.
무리한 목표는 자멸하는 길
더 큰 목표를 계획하거나 피처 하나만 더 추가하자고 일을 벌이면 프로그램 전체에 치명적 손상을 입힌다.
개발팀은 정말로 그렇게 해보고자 무의식적으로 개발을 서두르게 된다.
결함은 방지하는 것보다 수정하는 데 훨씬 오래걸린다.
지저분한 코드는 모든 것을 더 느리게 만든다.
압박하는 행동은 치명적이다. 절대 하면 안된다.
Q. 압박이 몰고 오는 나쁜 점은 무엇인가요?
- 조급하면 실수가 늘고 시야가 좁아진다.
Q. 결함이 늘어난 적이 있나요? 일정이 지연된 적은요?
- 거의 항상 그렇다.
Q. 유능한 사람을 잃은 적은 없는지 생각해봅시다.
- 잘해야 된다, 더 많이 이루고 싶다는 압박감은 유능한 나 자신을 시작조차 못하게 만든다.
욕심과 의심은 버릴 수록 좋다!
Q. 압박이 정말로 도움이 된 적이 있나요?
- 주위 시선은 압박이지만 효율이 높았다.
Q. 그렇다면 같은 효과를 낼 수 있는 다른 방법도 생각해봅시다.
- 스터디, 팀 구성
추정 없이 진행해보자.
프로젝트 추정은 어긋나기 마련이다.
추정은 가치가 아닌 비용과 관련된 내용이 대부분이다.
비용 추정은 중요도를 낮추고 가치 추정에 중점을 두자.
자주 계획하고 다음에 할 일을 정하세요. 과욕은 금물입니다.
팀이 감당할 수 있는 업무보다 많은 일이 주어질 때가 있다.
절대 업무량을 초과해 일하면 안된다.
무기력하고 건강하지 못한 코드로는 제대로 일할 수 없다.
10가지 일을 형편없이 진행하는 것 보다는 2가지 일을 잘 진행하는 것이 낫다.
그냥 업무를 덜어내라.