행동 기반 개발이 프로젝트에 적합합니까?

BDD (Behavior-Driven Development) 에 대해 들어 보지 못했다면 실제로는 10 년이 조금 넘는 시간 동안 꽤 최근에 있었던 것으로 간주됩니다. 점점 더 크고 작은 개발 팀이이 애자일 방법론을 신뢰하고 있으며 더 잘 알려져 있고 확립 된 다른 개발 전략을 대체하기도합니다.

다른 소프트웨어 개발 방법론은 제품에 관심을 기울이는 경향이 있지만, BDD는 사용자를 전환하고 사용자와이 사용자가 한 줄의 코드가 작성되기 전에 프로세스에 어떻게 행동 하는지를 보여줍니다 .

소프트웨어 개발 방법론의 간략한 역사

프로젝트의 수명주기를 5 개의 주요 단계로 포함하는 Waterfall 개발 과 같은 또 다른 인기있는 개발 방법론을 고려하십시오 .

• 요구 사항 ,
• 디자인 ,
• 구현 ,
• 확인 및
• 유지

일반적으로 Waterfall에서는 이전 단계를 완료 한 경우에만 각 단계를 시작하려고합니다. 그래서 이상적으로는 프로젝트 추정치의 최소 30 % -40 %를 처음 두 단계 (요구 사항 및 설계)에 투자 할 것입니다.이 단계에서 작동하지 않는 항목을 수정하는 것이 아니라 수정하는 데 비용이 덜 들기 때문입니다. 나중에 구현 또는 확인 중에.

요구 사항과 디자인이 잘 계획되고 강력하더라도 각 작업 단위가 독립적으로 작동 하고 끝에 있는 ' 작업 완료 '버튼을 누르는 전제라는 점 에서 적어도 " 순수 폭포 "에 대한 비판 그들의 단계는 예측 불가능 함, 비즈니스 목표의 변화, 무시 된 가정이 설명되지 않았 음을 의미 하며, 당신은 그것을 짐작했습니다. 그것은 전체 프로젝트를 망칠 것입니다.

Rapid Application (또는 Software) Development 와 같은 다른 Agile 방법론이이 모델에서 발전했습니다 . RAD 는 개발 및 제공에 더 중점을 두며 종종 엔지니어의 노력을 주도하기 위해 프로토 타입에 크게 의존합니다. 공정하게 말하면 RAD는 속도에 중점을두기 때문에 일반적으로 프로젝트 유지 관리 단계와 관련이 있으며 수정 된 버전은 제품 디자인의 악센트 부족을 해결하려고 시도했습니다.

Sprint 기반 개발 (또는 Scrum 이라고도 함) 은 전달 및 속도에 중점을 둔 개발과 동시에 모든 팀 구성원의 참여를 활용하는 개발 간의 격차를 메우려 고합니다.

아이디어는 팀을 10 명 이하로 작게 유지하고 연속적이고 진보적 인 목표 (또는 Sprints )로 발전하는 것 입니다. 이제이 접근 방식은 팀 이 즉석에서 올바른 코스로가는 경로를 제공 하는 이점 이 있습니다. 비즈니스가 다른 방향으로 이동하기로 결정한 경우 한 스프린트에서 다음 스프린트로 목표를 조정하는 것은 매우 쉽습니다.

불행히도 스크럼 의 페이스 강도 는 팀의 소진에 영향을 미칠 수 있습니다. 나는 스크럼 시스템에서 일하는 많은 개발자를 만났는데, 그들은 몇 번의 스프린트 후에야 막히고 피곤함을 느끼게됩니다. 마찬가지로, 모델의 전제는“ 문제 ”를 미리 이해할 수 없기 때문에 팀이 작업을 진행할 때 인식되어야하며, 이러한 기능이 전체 생태계와 제품 및 새로운 기능 을 통합하는 것에 대한 생각을 줄여야 합니다. 출시 될 예정입니다.

마지막으로 스크럼 마스터 의 주요 인물을 고려하는 것이 중요합니다 . 이 사람의 지위는 각 팀원의 제품과 기술에 대한 상당한 이해를 필요로하는 각 반복의 진행에서 큰 역할을합니다 . 불량 스크럼 마스터는 빠르게 진행되는 다층 프로젝트에 큰 책임이 될 수 있습니다.

그렇다면 행동 기반 개발은 어떻습니까?

BDD는 사용자의 중요성과이 사용자와 제품 간의 상호 작용을 확인합니다. 이러한 시너지는 일반적으로 개발 기간 동안 단위 테스트, 종단 간 테스트, 사용성 테스트 등에 매핑됩니다.

주로 BDD의 주요 옹호자로 간주되는 Dan North 는 개발자가 이러한 테스트를 작성하는 방법을 발견 하면서 개념 을 어떻게 생각해 냈는지에 대해 언급했습니다 .

그런 다음 "should"라는 단어로 테스트 메서드 이름을 시작하는 규칙을 발견했습니다. 이 문장 템플릿 — 클래스 는 무언가 를 해야합니다 — 현재 클래스에 대한 테스트 만 정의 할 수 있음을 의미합니다. 이렇게하면 집중할 수 있습니다. 이름이이 템플릿에 맞지 않는 테스트를 작성하는 경우 해당 동작이 다른 곳에 속할 수 있음을 암시합니다.

예를 들어 가격 계산기에서와 같이 자동차 가격을 표시하는 것이 목표 인 구성 요소가있는 경우 테스트는 다음과 같이 시작할 수 있습니다.

Price Calculator Test
-The COMPONENT-
SHOULD
  add all the price of all the features of the car plus taxes and other fees
  AND show the final price

나는 TDD와의 거래에서“테스트”대신“행동”이라는 단어를 사용하기 시작했고 그것이 적합 해 보였을뿐만 아니라 코칭 질문의 전체 범주가 마술처럼 해체되었다는 것을 발견했습니다. 이제 TDD 질문에 대한 답을 얻었습니다.

여기서 TDD는 테스트 주도 개발을 의미합니다. 따라서 이전 가격 계산기와 같은 테스트는 다음과 같이 보이기 시작했습니다.

Price Calculator Behavior
-The COMPONENT-
SHOULD
  add all the price of all the features of the car plus taxes and other fees
  AND show the final price

이시기에 2004 년경 Eric Evans의 저서“Domain-Driven Design”이 베스트셀러가되었고 North 는 DDD의 많은 개념이 핵심에서 활용 될 수 있음을 깨달았습니다. 그는 다음과 같이 요약합니다.

… 비즈니스 영역을 기반으로 한 유비쿼터스 언어를 사용하여 시스템을 모델링하여 비즈니스 용어가 코드베이스에 바로 스며 들도록합니다.

사용자 스토리를 설명하는 전통적인 방법은 다음 템플릿을 따릅니다.

As a [X]
I want [Y]
so that [Z]

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

행동 주도 개발의 심리학

a의 사용으로 일반 도메인 (언어), 우리는 이미 비 기술적 인 팀 구성원 가까이 개발 단계에 일해야하는 장점이있다.

또한 이전에 논의 된 많은 Agile 방법론에서 산출물 자체에 대해 이야기 하면서 제품에 중점을 둡니다 . 그리고 최종 제품에 집중하는 것이 일반적으로 좋습니다. 그러나 사용자와 제품 의 상호 작용은 요구 사항의 초기 단계에서 만든 많은 가정을 매우 잘 분리 할 수 ​​있습니다.

제품 개발의 20 %가 될 수있는 기능이 있다면 사용자가 최소한 20 %의 시간 동안 사용하고 활용할 기능이 더 좋습니다. 사용자가 해당 기능을 사용하지 않으면 어떻게됩니까? 본질적으로 실제 사용자 요구 사항에 대해 검증 된 적이없는 요구 사항에 수천 달러를 투자하고 있습니다.

당신이 디자인 할 때 사용자 스토리 에 기초하여 사용자 , 당신은 충분히 사용자 토론을 이끌시키는 그 개발을위한 로드맵을 제공하고 있습니다 - 실제 - 필요 .

행동 기반 개발의 예

Dan North는 신용 카드의 예를 제안합니다. 일반적인 사양 작성은 다음과 같이 작성할 수 있습니다.

+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

우리의 생각을 시나리오로 전환하면 이러한 사양을 리모델링하고 다음을 추가 할 수 있습니다.

+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

+Scenario 2: Account is overdrawn past the overdraft limit+
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned

세 친구

행동 중심 개발을 선호하는 주요 포인트 중 하나는 이러한 시나리오를 만들 때 모든 팀 구성원 의 참여입니다 . QA, 개발, 제품 소유자와 같은 이해 관계자는 토론에 참여하여 개발 노력을 주도 할지도가 될 이러한 시나리오를 생성합니다.

이 " 발견 회의"또는 회의는 제품 소유자가 확장 할 스토리에 대한 로드맵을 제공합니다. 프로젝트의 범위가 예산과 일정 내에서 구성되어야하므로 우선 순위 지정 및 검증은이 단계에서 큰 역할을합니다.

이 회의는 단일 소스 소스를 유지하기위한 공동 노력 인 Specification by Example 과 밀접한 관련이 있습니다. 이러한 예가 테스트를 대체하지는 않지만 확장 할 허용 기준에 대한 매핑을 제공합니다.

BDD 상태

Jira, Asana, 특히 Cucumber는 모두 시스템에 BDD를 적용하는 방법에 대한 일종의 플러그인 또는 문서를 가지고 있습니다. 즉, 좋아하는 애자일 소프트웨어를 사용하여 행동 중심 개발을 사용하여 프로젝트를 추적 할 수 있습니다.

현실은 BDD 모델로 작업하는 팀의 증가가 광범위하거나 비싸지 않다는 것입니다. 최소한 몇 가지 요소가 필요합니다.

• 도메인 전문가 ( 주제 전문가 라고도 함 ) : 개발 프로세스의 각 기둥에는 팀 전체에서 사용되는 언어를 평탄화하는 데 도움이 될 수있는 가시적 인 리드가 있어야합니다.
• 사용자 및 사용자 요구 사항에 대한 명확한 이해 : 견인의 기본 원천은 사용자의 행동 방식에 대한 완전한 지식입니다. 이는 제품 소유자뿐 아니라 이상적으로는 팀의 모든 구성원을 의미합니다.
• 사용자 스토리에 대한 적절한 인식 . Dan North는 이 기사 에서 사용자 스토리를 정의합니다 . 스토리가 잘 작성되지 않으면 전체 프로세스가 위쪽으로 떨어집니다. 몇 가지 주요 규칙을 언급하기 만하면됩니다. 제목 은 작업을 설명해야하고, 내러티브 는 역할을 포함해야하며, 이벤트 는 기능을 설명해야합니다.
• 있다는 주장 테스팅 과 같다 중요한 으로 개발 .
• 자동화 극대화 . 테스트의 중요성을 고려할 때 대부분의 사용 사례를 다루고 오작동을 조기에 감지하도록 테스트를 재구성해야 할 수도 있습니다.

코드 테스트에서 지식을 확장하고 활용하는 다양한 방법을 알아보십시오.

Javascript Testing : Jest Spies and Mocks JavaScript를 사용하여 데이터를 적절하게 저장 : 스스로에게 물어볼 6 가지 질문

추가 읽기 :

• Dan North의 블로그

LinkedIn , Medium , GitHub 에서 저를 찾으십시오 .