🌈 Chapter 18: 속도를 내기 위한, 특별한 빌드 기술

팀은 이렇게 말한다. "우리는 이 모든 피처를 2주 내로 끝낼 수 없습니다."

• 이 경우 시간을 더 주는 것 대신 작은 피처를 개발하게 하는 것을 추천한다.
• 그리고 개발팀에게 2주가 아닌 1주 안에 완성해달라고 요청한다.
• 보통 추가할 피처들을 만드는 것이 왜 어려운 것인지에 대한 대화로 시작한다.
• 그 이유는 대부분 빌드 시간, 통합 시간, 그리고 테스트 시간에 있다.

팀은 이렇게 말한다. "테스트하기 전까지는 그 어떤 것도 배포를 준비할 수 없습니다."

• 제품 책임자난 경영진 입장에서는 받아들일 수 없는 말이다. QA팀으로부터 결함을 받을 때 개발팀은 비즈니스 계획을 방해한다.
• 추가했던 피처들은 다시 점검해야 하고 비즈니스 목표에 집중할 수 없게 되기 때문이다.
• 해결책은 개발팀이 QA팀으로 소프트웨어를 전달할 때, 그것이 결함과 함께 돌아오지 않을 것이라고 확신해야만 한다.
• 우리는 스스로 인수테스트 주도 개발과 테스트 주도 개발등으로 이 과정을 수행할 수 있다.
• 개발팀은 반드시 인수테스트 주도 개발과 테스트 주도 개발에 전문적인 지식을 보유해야만 한다.
• 때로는 외부 의존성을 가지는 것이 테스트 대상이 아닌 다른 자원으로 분류될 때가 있는데, 해결책은 개발팀을 크로스펑셔널 팀으로 만드는 것이다.
• 즉 앞에서 설명한 기술들을 개발팀이 지니고 있도록 만들어야 한다.
• 중요한 프로젝트에는 각 분야로부터 이런 사람들을 지니고 있도록 만들어야 한다.

하지만 팀은 이렇게 말한다. "일을 제대로 끝내려면 아직 시간이 필요합니다."

• 처음에는 이 방법으로 개발을 완료하는 데 시간을 들인다.
• 스크럼에는 우리를 도와줄 개념이 한가지 있는데 바로 진화하는 완성의 정의이다.
• 그리고 이 완성의 정의는 시간이 지날수록 엄격해져야 한다.
• 단 한 번의 빌드로 하나의 개발 컴퓨터에서 모든 피처가 작동할 수 있도록 말이다.
• 이후 피처들이 모두 제품에 통합된 것을 확인할 수 있지만, 잘 작동하지는 않는다.
• 테스트가 더 필요하기 때문에 완성의 정의에 테스트 표준을 추가해야 한다.

이제는 모두가 말한다. "진행이 꽤 느린데요."

• 처음에는 느리다고 느낀다. 하지만 조금 지나면 이 방법이 유연하며 효율적으로 느껴지고 절대 서두르지 않게 된다.
• 배포할 수 있는 제품이 개발 주기마다 성장한 상태로 있어야 한다.
• 이를 달성하려면 개발한 피처는 설계, 테스트, 모든 면에서 완벽해야 한다.
• 더디다고 느끼는 이유는 모든 피처를 완벽하게 개발하도록 노력하기 때문에 더딘 느낌은 착각일 뿐이다.
• 두 번째로, 우리가 높은 가치를 우선순위로 제품에 피처를 추가할 때마다 배포 일정 전에 유용한 가치를 전달할 기회가 생긴다. 하지만 소프트웨어가 실제로 작동했을 때만 성립한다.

📚 요약하자면...

• 개발 속도를 올리기 위해 우리가 할 수 있는 가장 가치 있는 일은 바로 개발팀의 빌드 기술을 향상시키는 것이다.
• 빌드 기술 향상에 투자하면 결함을 수정하는 데 들이는 시간을 줄여주고, 부드러운 개발과 같은 형태를 통해 빠르게 되돌아온다.
• 효율적인 성과를 채찍질하는 것과 혼동해서는 안되고 가장 빠른 개발 팀은 유연하고 우아하게 일을 진행한다.