BDD는 모든 작업을 ‘불평’의 형태로 공식화하는 단순한 원칙을 따릅니다. ### ‘버그’의 광범위한 정의 Mozilla는 2002년부터 모든 코드 변경을 “버그” 수정으로 처리했습니다. 여기서 ‘버그’는 실제 결함 외에 기능 개선, 변경 요청 등 모든 소프트웨어 수정 요청을 포함합니다. 따라서 기능 요청이나 질문도 “마음에 들지 않아요.”라는 불평 형식으로 표준화되어 제출됩니다. ### BDD의 주요 이점: 노이즈 감소 BDD의 핵심 장점은 ‘노이즈 감소’입니다.
-
제기자의 책임감: 불평은 작성자에게 강력한 근거와 구체적인 문제 명시를 요구하여, 모호한 요청을 줄입니다.
-
개발자의 실질적 기여: 개발자는 단순한 답변 대신, 코드베이스에 실질적인 기여(패치)를 통해 문제 해결을 증명해야 합니다. ### 유형의 결함과 코드 패치 좋은 불평은 소스 코드와 같은 ‘유형의 것’의 결함을 식별하며, 그 해결책은 해당 소스 코드에 대한 패치입니다. 이는 팀이 결함 해결에 집중하여 생산성을 극대화하는 데 기여합니다. ### 도입의 어려움 및 비즈니스적 통찰 BDD는 팀의 사고방식을 ‘노이즈 생성자’에서 ‘결함 발견자’로 전환해야 하므로 도입이 어렵습니다. Jeff Atwood는 고객에게 초안을 제공하고 그들의 불평을 통해 실제 가치를 찾아내는 ‘불평 주도 개발’을 제안하며, 고객 불평에 귀 기울이는 것이 더 큰 가치를 전달한다고 강조합니다.