BDD 사양 워크숍에서 성공하는 방법?

오늘 우리는 사양 워크샵을 통해 소프트웨어 개발 프로세스에 BDD를 도입하려고 시도했습니다.

이 워크샵에는 2 명의 개발자, 1 명의 테스터 및 1 명의 비즈니스 분석가가있었습니다. 워크샵은 1 시간 30 분 동안 지속되었으며, 그 결과 새로운 기능에 대한 일부 BDD 시나리오를 파악할 수있었습니다. 우리는 놓칠 수있는 시나리오와 어려운 시나리오를 찾는 데 중점을 두었습니다.

워크샵이 끝나면 일부 사람들은 실제로 워크샵에 만족하지 못했습니다.

한 개발자 는 비즈니스 분석가가 직접 시나리오를 제공하고 그녀와 함께 검토하는 데 익숙해 져서 시간 을 낭비 한다고 느꼈습니다 . 비즈니스 분석가는 우리의 시나리오 적용 범위에 대해 확신을 갖지 못했지만 (다른 중요한 것들을 놓칠 수 있다고 생각 했음) 이 워크샵은 그녀가 모든 시나리오를 스스로 알아낼 수 있었기 때문에 시간 낭비라고 생각했습니다. 그리고 더 짧은 기간에 .

이 실험 워크샵은 1 시간 30 분 동안 지속되었으며, 그 결과 우리가 한 일에 대해 확신이 없었습니다 ... 더 많은 시간을 할애 할 수 있었지만 솔직히 대부분의 사람들은 1 시간 30 분의 브레인 스토밍으로 사업을 시작했습니다. BA 뇌의 규칙.

제 질문은 그런 종류의 작업장이 실제로 어떻게 작동 할 수 있는가입니다. 이론적으로 개발할 새로운 기능이 있다고 가정하면 트리 'amigos'(dev / tester / ba)를 같은 방에 배치하여 예제를 사용하여 새 기능에 대한 다른 요구 사항을 작성하는 데 협력 할 수 있습니다. 그로부터 모든 혜택을 볼 수 있습니다. 특히 지식 공유 및 공통 제품 / 종료 목표 / 완료 비전 측면에서.

이 실험에서 우리의 결론은 실제로 더 효과적인 비용이었다 먼저 예에 자신의 작품에 대한 학사 학위를 가지고 만 3 '아미고'로 재 작업 / 검토 할 수있는 시나리오를 가지고 다음. BA가 자체적으로 작업하게함으로써 실제로 우리는 물건을 놓치지 않을 것이라는 확신을 갖게됩니다. 우리는 나중에 이중 점검으로 시나리오를 검토하게됩니다. 우리는 단순한 일회성 브레인 스토밍 / 심의 디스커버리 세션이 실제로 새로운 기능에 대한 모든 요구 사항을 심각하게 다루기에 충분하다고 생각하지 않습니다. 비즈니스 분석가는 실제로 그런 종류의 물건에 가장 적합한 사람입니다. 우리가 할 수있는 최선의 방법은 그녀가 작성한 것을 검토하여 공통의 이해가 있는지 확인하는 것입니다 (그러면 그녀의 시나리오 중 일부를 다시 작성하거나 놓칠 수있는 새로운 시나리오를 추가 할 수 있음).

실제로 어떻게 효과적으로 작동하게 할 수 있습니까?

설명에서 시나리오를 도출 할 수 있으면 완료된 것입니다.

BDD에서 자주 볼 수있는 반 패턴은 모든 시나리오를 자세히 이야기하고 기록해야하는 사람들 입니다.

일부 시나리오는 간단한 설명에서 도출하기에 충분하다는 것을 잘 알고 있습니다. 예를 들어, "이번 주에 로그인 기능을 원합니다"라고하면 어떤 모양인지 알 수 있습니다. 올바른 비밀번호, 잘못된 비밀번호, 잘못된 사용자 이름에 대한 시나리오가 있음을 알고 있습니다. 우리는 그것들을 통해 이야기하거나 상세하게 캡처 할 필요가 없습니다.

마찬가지로, "사용자 등록 양식이 있습니다. 새로운 사용자를 생성하고, 세부 정보를 편집하고, 삭제하는 것이 실제로는 삭제되지 않아야한다는 점을 제외하고는 삭제해야합니다. 삭제 된 것으로 표시해야합니다. 원하는 경우 계정을 복구 할 수 있습니다. "

"계정 복구가이 기능의 일부입니까?"

"원한다면 두 가지 기능이 될 수 있습니다."

"좋아요, 우리는 작성, 읽기, 업데이트, 삭제 시나리오가 있습니다. 충분히 쉬워야합니다. 계정 복구에 대해 이야기 해 봅시다. 더 흥미로운 것 같습니다."

일반적으로, 행동 설명이 개발자 팀이 시나리오를 도출하기에 충분하다면,이를 설명 할 필요가 없습니다. 확실하지 않은 경우 그렇게 할 수 있지만, 캡처해야 할 시나리오를 캡처하고 싶을 수도 있습니다.

전에 한 번도 해본 적이 없거나 확실하지 않은 경우 시나리오를 통해 이야기하십시오.

특히 이전에 해 본 적이없는 기능이있는 경우 비정상적인 영역에 초점을 맞 춥니 다. 대화를 나누고 나오는 놀라운 예를 적어 두는 환상적인 장소입니다. 일반적으로 BDD 템플릿에 따라 두 가지 질문을합니다.

주어진 상황
이벤트가 발생
하면 결과가 발생해야합니다.

• 같은 사건에서 다른 결과를 낳는 다른 맥락이 있습니까?
• 중요한 다른 결과가 있습니까?

테이블의 모든 사람들이 지루해 보인다면 당신이 말하는 기능이 잘 이해 될 것입니다. " X 처럼 작동 하지만 Y 대신 작동해야합니다."라고 말하는 것만으로도 충분합니다 . 이것이 Dan North가 Ginger Cake 패턴 이라고 부르는 것 입니다. 초콜릿 케이크의 레시피와 비슷하지만 초콜릿 대신 생강이 들어 있습니다.

비즈니스 이해 관계자가 시나리오를 직접 도출 할 수 있더라도 개발자 팀이 그와 대화하고 언어를 익히고 내면화하는 것이 매우 중요합니다. 그런 다음 해당 언어가 코드로 전달되어 향후 더 나은 대화를 할 수있게되며, 프로젝트를 처음 접하는 사람들이 현재 상황을 이해하도록 돕습니다. 개발자가 언어 를 구사 하지 못하면 언어를 사용 하지 않습니다 .

비즈니스 이해 관계자 또는 분석가가 세션에서 사물을 캡처하는 데 시간을 소비하고 싶지 않다면 개발자가 테스터와 협력하여 시나리오를 작성한 다음 검토를 요청했습니다. 이것은 다른 방식보다 오해를 폭로 할 가능성이 높습니다.

때때로 BDD가 작동하지 않습니다.

또 다른 가능성은 비즈니스 이해 관계자가 확실하지 않은 시나리오를 찾는 것입니다. "아, 나는 그것을 생각하지 않았다! 확실하지 않다." 비즈니스를 중단시키고 확실하게 비즈니스를 처벌하는 것보다이 시점에서 BDD를 포기하고 피드백을 얻기 위해 간단한 것을 시도하고 비즈니스가 반복 할 수있는 것을 제공하는 것이 좋습니다. 상황을 쉽게 이해하고 나면 쉽게 변경하고 시나리오를 작성하십시오.

BDD가 잘 수행되면 실제로 불확실성을 발견 할 수 있습니다. 수행 할 가치가있는 모든 프로젝트에는 새롭고 이전에 수행 된 적이없는 일부 측면이 있으므로 어딘가에 불확실성이 있습니다. 의도적으로 무지를 발견 하는 데 도움이되는 시나리오를 사용하는 데 집중 하면 학습 속도가 빨라지고 학습은 대개 프로젝트에 소요되는 시간의 큰 부분입니다.

또한 더 많은 개발 팀이 이러한 방식으로 공동 작업을할수록 비즈니스가 불확실성으로 팀을 신뢰할 준비가 더 많이되고 더 많은 혁신이 시작된다는 것을 알게되었습니다. 혁신적인 회사는 본질적으로 프로젝트에 많은 불확실성을 가지고 있습니다.

나는 Cynefin에 잠시 동안 블로그 게시물을 썼습니다 . 네 도메인을 읽고 이해하면 내가 사용하는 규칙은 다음과 같습니다.

• 간단하고 복잡한 것들 (알려진)은 종종 잘 이해되고 있으며 시나리오를 자세히 이야기 할 필요가 없습니다.

• 매우 복잡한 것 (알 수 없음)은 전혀 이해되지 않습니다. 시나리오를 통해 이야기함으로써 이것을 발견 할 수 있습니다. 확실성이 없다는 것은 BDD가 여기서 작동하지 않기 때문에 변경하기 쉬운 것을 반복하고 대신 빠른 피드백을 얻습니다. AB 테스트와 같이 옵션을 유지하는 모든 방법도이 공간에서 훌륭합니다.

• BDD는 지식을 전달하고 다른 두 공간을 발견하는 메커니즘으로 (알 수있는) 사이의 공간에서 훌륭하게 작동합니다. 망치가 아니며 모든 것이 못이 아닙니다. 실제로, 대화에 소비 한 시간에 초점을 맞출 수 있다면 찾을 수있는 예제가 아닙니다. 그것은 당신이 할 수없는 예제를 찾는 것 입니다.

회의 시간은 문제가 아닙니다. 회의가 오래 지속되는 것은 괜찮습니다. 그러나 모든 사람들은 자신감을 가지고 나와야합니다. 그들이하지 않았다는 것은 당신의 문제입니다.

요구 사항에 대해 논의하기 위해 짧은 회의를 제안합니다. 며칠 후에 두 번째 모임을 예약하면 모든 사람은 그때까지 준비해야한다는 것을 알게됩니다.

그런 다음 BA와 테스터는 각각 서로 다른 방식으로 소프트웨어를 보므로 시나리오를 제시해야합니다. 적어도 두 번째 모임 전날 어딘가에 카드에 적어서 보드에 붙인 다음, 모두 자신의 시간을 들여다보고 생각하게하십시오. 복제본을 버리고 고려되지 않은 시나리오를 펼치십시오.

동의하지 않는 것을 버리지 말고 논쟁적인 것으로 표시하십시오. 그것을 쓴 사람과 아주 간단한 대화를하면 도움이 될 것입니다.

그런 다음 계획 / 디자인 회의가 있습니다. 그 회의를 위해 탄탄한 의제를 갖고 (카드 더미에서 시작하여, 논쟁의 여지가있는 것들을 맨 위에 놓으십시오), 궤도에서 벗어나지 못하게하십시오. 모든 분쟁 지점이 해결 된 상태에서 해당 회의에서 나오도록하십시오.

항상 회의의 모든 사람이 회의의 주제에 대비해야합니다!

어떤 것도 함께 "브레인 스토밍"하기 위해 회의를 사용하지 마십시오. 모두의 시간을 낭비합니다.

효과적인 회의를위한 일반적인 레시피 :

• 누군가 토론 할 항목을 준비하게하십시오
• 모든 참가자가 해당 항목을 연구 (읽기만이 아니라) 공부해야합니다
• 사전에 의견을 모으고 모든 참가자에게 그 내용을 연구 (읽기만이 아님)해야합니다.
• 결정을 내릴 회의를 개최

불만 사항 정보 ...

이것들부터 시작해 봅시다 :

한 개발자는 비즈니스 분석가가 직접 시나리오를 제공하고 그녀와 함께 검토하는 데 익숙해 져서 시간을 낭비한다고 느꼈습니다.

그가 워크숍에서 무엇을하고 있 었는가. 그래서 그것은 나에게 변덕스럽고 나쁜 변명처럼 보입니다. 이 개발자가 워크샵의 조사와 일정 제약을 좋아하지 않는다고 생각합니다.

비즈니스 분석가는 시나리오 적용 범위에 대해 확신을 갖지 못했습니다 (다른 중요한 사항을 놓칠 수 있다고 생각했습니다).

더 많은 사람들이 그것을 본다는 사실을 제외하고는, 이것이 그녀가 그것을 할 때와 어떻게 다른가? 나는 이것이 단지 워크샵이 약간 혼란 스러울 수 있다고 생각합니다. 테스트를 구현하고 통합하여 테스트가 충분하다는 확신을 얻을 수 있습니다. 모든 버그를 발견했다고 확신 할 수 없으며 커버리지와 관련하여 가장 좋은 방법은 사용자 스토리에서 버그를 다이어그램으로 작성하는 것입니다.

그러나 더 중요한 것은이 워크샵이이 모든 시나리오를 스스로 그리고 더 짧은 기간에 알아낼 수 있었기 때문에 시간 낭비라고 생각했습니다.

그렇습니다. 전적으로 자신의 벽으로 둘러싸인 정원에서 지식을 공유하지 않습니다. 미래의 워크샵을 수행함으로써 모든 참가자가 이러한 것들에 접근하는 방법에 대한 약간의 지식을 얻었으므로 더 생산적 일 수 있습니다.

아마 이번 회의가 느려졌을 수도 있습니다. 그리고 외부 개인으로서, 나는이 권리를 얻기 위해 약간의 훈련을 받았으며, 단일 독재자와 다른 사고 방식을 가진 3 명의 참가자가있는 워크샵에서 적용 범위가 더 낫다는 확신을 얻었습니다.

또한 개발자가 이미 이러한 시나리오를 검토해야 할 필요가 있다면 워크숍에서 "내가하는 일만하고 물건을주는 것보다 훨씬 빠르고 효율적입니다."라고 확신합니다. 당신은, 당신은 그것을 혼자 검토하고 나에게 돌아와서 이것을 다시 해 보자 "접근.

제안

• 프로세스가 바르면 더 나아질 것이라고 긍정적이고 강조하십시오.

• 워크숍을 능률화하고 제대로 진행하십시오.

• 모든 사람이 스스로 시나리오를 디자인하고 (워크숍 이전에 더 나은 경우도 있음) 워크숍을 시작한 다음 심사하고 병합하여 "고독한 늑대"분석을위한 공간을 제공 할 수 있습니다.

그리고 브레인 스토밍이 필요하다고 생각하지 않는다면, BA를 단독 으로 운영하고 최소한 작업장으로 검토 하는 것이 좋습니다. Eric S. Raymond 의 Linus 법칙 을 인용하면 안구가 많을수록 좋습니다 .

Given enough eyeballs, all bugs are shallow.

여기에 꽤 좋은 답변이 있으므로 지금까지 간과 한 작은 측면에 중점을 둘 것입니다. Three Amigos의 역할은 세션에 전달할 수 있어야합니다. 그들은 각각 다른 방식으로 가치를 제공하며, 서로 다른 제약 조건을 이해합니다.

일반적으로 BA는 세션에 주요 경로를 제공 할 수 있어야하며 비즈니스 관점에서 주요 실패 시나리오를 제공 할 수 있어야합니다. 테스트 전문 지식은 모든 상황에서 시스템이 작동하는지 입증하는 데 필요한 주요 사례와 추가 시나리오를 식별 할 수 있어야합니다. 개발자의 임무는 실제로 시나리오를 추가하는 것이 아니라 종종 기술적 인 실패에 대한 것이기도하지만 요구 사항을 완전히 이해하여 함의를 전달하고 최소한의 추가 커뮤니케이션으로 요구 사항을 구현하는 것입니다.