BDD 개념을 채택하기를 꺼려하는 팀에 BDD 개념을“판매”하기 위해 어떤 주장을 사용할 수 있습니까?

나는 행동 주도 개발 방법론 (일명 BDD)의 보컬 지지자입니다. 저는 2 년 동안 BDD를 적용 해 왔으며 DotNet 애플리케이션을 개발할 때 StoryQ 를 선택한 프레임 워크로 채택 했습니다 . 몇 년 동안 단위 테스트를 해왔고 이전에 테스트 우선 접근 방식으로 전환했지만, 테스트에서 요구 사항의 의도를 상대적으로 파악하기 때문에 BDD 프레임 워크를 사용하면 훨씬 더 많은 가치를 얻을 수 있습니다. 내 코드 내에서 명확한 영어를 사용하고 내 테스트에서 테스트를 중간에 끝내지 않고 여러 개의 어설 션을 실행할 수 있기 때문에 디버깅하지 않고도 특정 어설 션이 한 번에 통과 / 실패하는 것을 확인할 수 있습니다.

테스트와 구현 코드를보다 목표 된 방식으로 디버깅 할 수 있으며 결과적으로 생산성이 크게 향상되었으며 더 많은 것을 할 수 있음을 알았으므로 이것은 빙산의 일각이었습니다. 빌드 로그로 들어가는 출력으로 인해 통합 빌드에 문제가 발생하는 경우 장애가 발생하는 위치를 쉽게 판별 할 수 있습니다. 또한 StoryQ API는 배우기 쉽고 유창한 구문을 사용하여 특별한 방법으로 적용 할 수 있으며 외부 의존성이 없어도 사용할 수 있습니다.

따라서 이러한 모든 이점을 통해 나머지 팀에 개념을 쉽게 도입 할 수 있다고 생각할 것입니다. 불행하게도, 다른 팀원들은 StoryQ를보고 그것을 제대로 평가하기를 꺼려하고 (BDD를 적용한다는 아이디어는 물론) 서로의 핵심 테스트 프레임 워크에서 많은 StoryQ 요소를 제거하려고 시도했습니다. 원래 StoryQ 사용을 지원했지만 제거하려는 코드가 테스트 시스템의 다른 부분에는 영향을 미치지 않더라도 말입니다. 그렇게하면 실제 업무 경험을 통해 특정 작업 환경에서 테스트 우선 방식으로 작업하는 것이 더 좋은 방법이며 더 큰 결과를 가져올 수 있다는 사실을 확신 할 수 있기 때문에 전반적인 작업량이 전체적으로 크게 증가하고 실제로 결정에 반대하게됩니다. 다음과 같은 경우 소프트웨어 품질 개선 ve는 BDD를 사용하여 테스트를 먼저 수행하는 것이 더 쉽다는 것을 알았습니다. 더 명확하게 설명하자면, 우리가 수행 한 단위 테스트의 대부분은 상당히 취약하고 유지하기 어려운 경향이 있으며, 테스트 중심 프로세스를 고수하지 않는 몇 년 동안의 잘못 적용 된 테스트에서 개발자가 오래된 습관에 빠지는 것을 보았습니다. 프로젝트가 끝날 때 모든 테스트를 수행하십시오 (이러한 사람들은 민첩하다고 주장합니다!).

따라서 질문은 실제로 다음과 같습니다.

1. 이 팀이 StoryQ를 사용하는 것이 좋거나 최소한 BDD 방법론을 채택하는 것이 더 나을 것이라는 점을 실제로 추진하기 위해 어떤 주장을 사용할 수 있습니까?
2. BDD를 표준 선택 방법으로 채택하겠다는 주장을지지하는 데 사용할 수있는 일화적인 증거를 말씀해 주시겠습니까?
3. 팀이 BDD를 채택하도록 장려하려는 나의 소망이 잘못되었을 수 있다고 생각할 수있는 반론은 무엇입니까? 그렇습니다. 나는 그 주장이 건전한 것이 아니라면 잘못 입증되어 기쁘다.

참고 : 테스트를 완전히 다시 작성하는 것이 아니라 향후 모든 테스트 작업을 위해 다른 방식으로 작업을 시작하는 것이 바람직하며 고객과의 관계를 유지하는 것이 좋습니다.

BDD에 대해 더 배우고 자하는 사람들에게는 다음 링크가 유용 할 수 있습니다.

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{자세한 내용에 관심이있는 사람들을 위해 우리는 약 5 개의 큰 프로젝트를 수행하는 4 명의 소규모 팀입니다. BDD에 대한 "파일럿 시험"은 초기에 약 2 개월 동안 실행되었으며, 또 다른 약 4 개월이 뒤따 랐습니다. 팀은 내가 계속 이런 식으로 일해야하고 그들 자신의 시련을해야한다는 것을 받아 들였다. 나는 재판이 끝난 후 약 2 년 동안 BDD를 해왔으며, 다른 사람들은이 문제를 다루는 데 능숙 해졌습니다. 이 문제에 대해 "대결"을 강요하기보다는 팀을 부드럽게 설득하여 집단적인 배후에서 벗어나 시간을내는 방법을 찾고 있습니다.}

StoryQ를 사용하는 것이 더 좋거나 최소한 BDD 방법론을 적용하는 것이 더 나을 것이라는 점을 실제로 추진하기 위해 어떤 주장을 사용할 수 있습니까?

"고객이 원합니다."

IMO 귀하는 최소한 개발 팀만큼 고객 / 도메인 전문가에게 BDD를 판매하려고합니다.

BDD는 여러 이해 관계자가 참여하는 협업 외부 프로세스입니다. BDD의 이점은 개발자가 승인 테스트에서 테스트 코드를 자동으로 유추하는 것뿐만 아니라 기술 및 비즈니스 사람들 사이에서 창의적 협력을 통해 시스템의 의도 된 동작에 대한 귀중하고 잘 정의 된 사양을 생성합니다.

고객 / 비즈니스 분석가가 각 실행 사양을 실행하고 상태를 제어하며 구현 진행 상황을 확인할 수있는 인터페이스에 대한 액세스 권한을 부여하면 일반적으로 매우 감사합니다.

Dan North가 비즈니스에 BDD를 판매하는 방법에 대한 프레젠테이션이 있습니다. http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. BDD 채택을 꺼려하는 팀에는 동료를 본격적으로 채택하는 데 사용할 수있는 "인수"가 없을 것입니다.
    
   나는 당신이 할 수있는 최선의 방법은 그들 에게 시도 ( "연기 테스트", "드라이 런", "파일럿 프로젝트") 를하도록 설득하는 것입니다. 부정적입니다.
2. 일화적인 증거를 찾기위한 당신의 접근 방식은 그것을 시도하도록 설득력있는 팀의 아이디어에 완벽하게 맞습니다. 이를 위해 웹에서 "동작 기반 개발 성공 사례" 와 같은 내용을 검색하고 사용하기 편한 것을 선택했습니다.
3. 내가 생각할 수있는 몇 가지 반론이 있는데, 팀 노력을 BDD로 전환하려는 소망이 잘못되었을 수 있습니다.
    
   이들 중 어느 것도 특히 "변호 지지자"의 관점에서 볼 때 건설적인 것은 아니지만 불행히도 정확하게 이런 종류의 수사법 ( BTDTGTTS ) 을 다루어야 할 것입니다 .
    
   • 전반적인 팀 생산성 향상을 보장 할 수는 없습니다
   • BDD 도입에 투자 한 노력이 상당한 ROI 를 제공한다고 보장 할 수는 없습니다
   • 팀이 BDD없이 충분히 잘하고 있었으며 현재 접근 방식의 변경 위험이 정당화되지 않았습니다.
   • Google (또는 Microsoft 또는 IBM- "중요한"소프트웨어 공급 업체의 이름 만 입력)은 BDD없이 잘 작동하므로 BDD가 필요하지 않다는 것을 "증명"합니다
   • 비 BDD 접근법은 비교 테스트에서 공정한 기회를 얻지 못했습니다.
   • BDD는 일반적으로 괜찮을 수 있지만 이것과 해당 모듈 / 프로젝트 에는 적용되지 않습니다

내 경험에 따르면 위에 나열된 것과 같은 반론을 해결하는 가장 고통스러운 방법 은 제안 된 변경에 대해 제한된 제어 테스트 실행 을 수행하는 것입니다.

"제한된 테스트"상태 는 성공 사례 에 대한 일화적인 증거 를 제공함으로써 반박 할 수있는 "존재하는 벤더"에 대한 하나를 제외하고는 위의 네 가지 주장 중 세 가지 주장을 본질적으로 무효화 합니다. 제한된 테스트로 충분합니다).

변화가 실제로 가치가 있고 테스트 실행이 적절하게 준비되면 팀과 경영 태도가 긍정적으로 변화하여 본격적인 변화로 매끄럽고 쉽게 전환 할 수 있습니다.

제한된 테스트 실행의 또 다른 이점은 너무 많은 문제를 일으키지 않고 아이디어에 대한 "평판 손상"위험을 줄이면서 대상 프로세스 세부 사항을 명확하게하고 조정할 수 있다는 것입니다. 이러한 테스트 실행에 참여할 때마다 테스트 실행시 가장 중요한 세부 사항을 설정하고 명확하게 정식 채택으로 전환하는 것이 얼마나 순조로 운지 알게되어 기뻤습니다.

경영진을 모집해야 할 때입니다. 시도를했지만 확실한 결과를 보았지만 팀이 밟고 있다면 경영진이 참여해야 할 수도 있습니다.

그들이 회사의 가장 생산적인 팀원을 해칠 경우 특히 그렇습니다. 반발에 대비하십시오. 경영진에게 접근하여 테스트 사례를 취해 팀이 당신을 깎지 못하게하려고 시작할 수 있습니다.