🌈 Chapter 6: 피처 단위로 개발하기

• 피처 단위로 개발하는 제품은 더 나은 가치를 제공한다.
• 개발팀이 작동하는 소프트웨어를 보여주니 관리와 계획이 간결해기지 때문이다.

📚 짧은 주기마다 작지만 완전한 제품을 완성하세요.

• 프로젝트를 진행할 때 한 주기를 짧게는 1주, 또는 2주 정도로 계획한다.
• 주기마다 다음에 개발해야 할 피처와 그 피처의 테스트 방법을 정리해야 한다.
• 그 후 개발팀이 주어진 피처를 개발하면 테스트를 제대로 통과하는지 검증한다.
• 주기마다 하나의 완성된 제품을 만들도록 목표를 세운다. 이렇게 하면 언제든 제품을 배포할 준비가 갖춰진다.
• 각 주기가 지날수록 예측은 더욱 정확해지고 배포할 수 있는 제품의 버전도 다양해진다.
• 조직은 주기마다 얼마나 많은 것들을 할 수 있는지, 만들기로 게획한 피처들이 얼마나 테스트됐는지 알 수 있고, 낭비 없이 가장 효율적으로 피치를 만드는 방법, 프로그램의 코드와 설계를 명확하게 유지하면서 피처 단위로 제품을 개발하는 방법에 대해 배울 수 있다.

📚 제품이 가진 특징을 다듬으세요.

• 피처 단위 개발을 할 때는 주기마다 개발해야 하는 피처를 개발팀에 요청하는데 이해하기 어려운 기술적인 무언가가 되면 안 된다. 실제로 눈에 보이고 작동하는 피처여야 한다.
• 그런 의미에서 비지니스 담당자는 거대하고 모호하며 광범위한 요구 사항을 작고 실질적인 피처들로 분리하는 능력을 길러야만 한다.
• 이것은 걸코 작은 일이 아니고 성공하기도 어렵다. 그러므로 제품에 반드시 있어야 하는 피처와 단순히 있으면 좋은 피처를 구분하여 제품이 가진 특징을 더욱 뚜렷하게 만들어야 한다.
• 이런 노력이 소프트웨어에 눈에 띄는 결과물을 가져오게 된다.

📚 가장 높은 가치를 가진 피처를 먼저 개발하세요.

• 가장 중요한 피처를 가장 먼저 개발하는 것이 중요하다.
• 어떤 피처가 더 적은 비용으로 높은 가치를 주는지 구분하려면 모든 팀이 함께 노력해야 되고 조직은 한정된 시간과 돈으로 가장 좋은 제품을 개발하는 방법을 배우게 된다.
• 이 과정은 반드시 투명하게 진행되어야 하고 조직 내 모든 사람이 실제로 진행되는 상황을 볼 수 있어야만 한다.
• 모든 피처를 반드시 완료 또는 미완료로 구분해야 한다.

📚 실제 진행 상황을 확인하세요.

• 프로젝트가 진행될수록 눈에 보이는 진행 상황과 실제 진행 상황을 구분하는 방법에 대해 배우게 된다.
• 각자의 고유한 상황 안에서 완료 시점이 정말로 언제인지에 대해 이해도를 높일 수도 있을 것이다.
• 실제 진행 상황과 실행 가능한 피처들을 볼 수 있게 된다면 이제는 프로젝트 상황에대해 더 명확한 정보를 볼 수 있게 된다.

📚 테스트-수정 과정이 완료 단계에서만 있어서는 안 됩니다.

• 피처 단위 개발을 적용하는 과정에서는 주기마다 배포할 수 있는 제품이 나오도록 해야 하며, 얼마나 걸릴지 알 수 없는 테스트-수정 과정을 줄이거나 없애는 방법을 습득하는 과정이 필요하다.
• 피처 단위 개발을 제대로 적용하려면 각 주기마다 끝나는 시점에서는 소프트웨어의 결함이 없어야 한다.
• 그뿐만 아니라 모든 개발 기간에도 소프트웨어에 결함이 있어서는 안 된다.
• 결함이 없다는 것을 확신하려면 항상 모든 것을 확인해야 한다.

📚 제품이 성장할 때마다 설계를 확장하고 개선해야 한다.

• 제품이 성장할 때마다 소프트웨어의 설계를 개선해야 한다. 많은 것을 설계해도 그만큼 많은 피처를 가질 수는 없다.
• 반대로 피처 구조를 너무 조금씩 설계한다면 그 피처가 역할를 제대로 수행할 수 없게 되고 개발 속도는 더뎌지고 완성된 피처들은 눈에 띄지 않으며 희미해질 수 밖에 없다.
• 피처들을 적용하는 기간(작업 속도)를 잘 관찰해야 한다. 이 속도를 관찰함으로써 설계가 얼마나 알맞게 진행됐는지 배울 수 있다.
• 너무 많이 설계하거나 너무 조금 설계하면 작업 속도가 느려진다.
• 설계를 바꿔보고 관찰하고 이를 기반으로 다시 설계를 바꿔야 한다.