🌈 Chapter 3: 피처 단위 개발을 위한 가이드라인

• 프로젝트를 진행할 때 가장 먼저 알아야 할 것은 마감 일정이다.
• 마감일까지 모든 것을 다해야 하지만, 게획대로 진행되지만은 않다.
• 마감일 이후에는 모든 피처를 추가하라고 요구한다.
• 원하는 피치 모두를 얻을 수는 없다.
• 프로젝트를 그대로 두기보다는 현실적으로 관리해보자.

📚 소프트웨어 프로젝트가 진행되는 일반 과정

• 수많은 프로젝트는 활동(activity)을 기반으로 계획을 세운다.
• 분석, 설계, 코딩 그리고 마지막으로 테스트 과정을 거친다.
• 소프트웨어을 직접 보기 전까지는 프로젝트 진행 상황을 알 수 없다.
• 코드를 테스트하는 단계가 오면 보통 좋은 일은 일어나지 않는다.

📚 더 나쁜 것은... 프로젝트가 계획대로 가는 일은 정말 드물다는 것입니다.

• 코드를 살펴보고 테스트할 때가 왔다. 실제로 진행해왔던 일은 잘 진행되지 않았다.
• 실제로 할 수 있는 것보다 더 많이 요구됐다. 무언가를 진행하기에 이미 때가 늦었음을 깨달았다.
• 이제 몇 가지 선택지만이 남았다.
• 하나는 프로젝트 실패를 선언하는 것이다.
• 또는 이대로 끈기를 잃지 않고 느릿느릿 프로젝트를 진행하는 것이다. 조직이 포기하기 전에 무엇이라도 배포하길 바라면서.. 두 방법 모두 좋지 않다.

📚 활동을 기반으로 한 제품은 100kg짜리 돌덩어리 같습니다.

• 프로젝트는 막바지에 들어서면 비용을 줄일 방법이 거의 없다.
• 모든 피처를 한꺼번에 계획하고 개발하는 일은 모두를 힘들게 한다.
• 변경할 시간도 없고, 시간이 있다 하더라도 어떻게 할 도리가 없다.
• 이제부터는 처음부터 여러 배포 일정을 계획해야 한다.
• 배포 일정을 여러 번으로 계획하면 가치를 빨리 전달할 수 있고 프로젝트를 관리하기 쉽다.
• 심지어 그렇게 계획하는 것만으로도 소프트웨어를 더 쉽게 개발할 수 있다.

📚 피처 단위로 프로젝트를 진행한다면 더 잘 예측할 수 있습니다.

• 실제로 일어나는 일, 가치 있는 피처들을 주기적으로 보여주면 무엇이 일어나는지 바로 알 수 있다.
• 소프트웨어를 볼 수 있는 것이다.

📚 피처 단위 개발은 더 나은 정보, 더 나은 가이드, 더 많은 결과물을 만듭니다.

• 피처 개발이 얼마나 끝났고 얼마나 빨리 진행 중인지 볼 수 있다.
• 주어진 기간에 얼마나 많은 것을 할 수 있을지 더 쉽게 예측할 수도 있다.
• 우리는 다음에 개발할 가장 중요한 피처를 선택해야 한다.
• 그리고 원하는 배포 일정에 가장 가능성 있는 제품의 형태를 만들어 나간다.
• 심지어 더 나은 아이디어가 생기거나 사용자의 요구가 변경하거나 새로운 피처를 추가할 수도 있다.
• 프로젝트를 피처 단위 개발로 진행할 때는 현재 어떤 일을 진행하고 있는지 알 수 있다.
• 비즈니스 담당자나 경영진의 요구 사항이 변경돼도 적절하게 대응할 수 있다.