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

전체 팀을 포함하고 사용자의 행동에 초점을 맞춘 제품 / 소프트웨어 개발을위한 접근 방식

Unsplash에 Marvin Meyer의 사진

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

사용자로 시작하는 BDD 모델

제품 개발의 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 가지 질문

추가 읽기 :

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

Suggested posts

Jetpack Compose로 IntelliJ IDEA의 스플래시 화면 모방

Jetpack Compose로 IntelliJ IDEA의 스플래시 화면 모방

IntelliJ IDEA의 최신 버전 (이 출판 당시 2021.1)에는 아래와 같이 다양한 색상의 모양을 포함하는 그리드를 기반으로하는 멋진 스플래시 화면이 있습니다.이 게시물의 목표는이 패턴을 모방 한 Jetpack Compose 컴포저 블을 구현하는 것입니다.

Vue 3 및 JavaScript를 사용하여 JSON-CSV 변환기 만들기

Vue 3 및 JavaScript를 사용하여 JSON-CSV 변환기 만들기

Vue 3는 프런트 엔드 앱을 만들 수있는 사용하기 쉬운 Vue JavaScript 프레임 워크의 최신 버전입니다. 이 기사에서는 Vue 3 및 JavaScript와 함께 JSON을 CSV로 만드는 방법을 살펴 보겠습니다.

Related posts

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

프로그래밍은 당신이 아는 것에 관한 것이 아닙니다. 그것은 당신이 알아낼 수있는 것에 관한 것입니다.

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

"더 나은 오류 메시지를 작성하지 말고 필요하지 않은 코드를 작성하십시오." — Jason McDonald Backend Development — 대부분 웹, 소프트웨어 또는 앱에서 모든 것이 작동하는 방식에 관한 것입니다. 대부분은 애플리케이션 작동 방식의 중추입니다.

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

코딩과 기술력뿐만 아니라 3 년 전, 저는 사물이 어떻게 생겼을 지에 대한 수많은 가정과 기대를 가지고 기업 세계에 처음 발을 들여 놓았습니다. 내가 얼마나 잘못이 증명 될지 거의 알지 못했습니다.

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

"자동화되기를 바라는이 사소한 것이 있습니다."— 사소한 일이 아닐 것임을 알고 이것을 얼마나 자주 듣지 못했습니까? 아니면 당신이 더 잘 알면서도 직접 말 했나요? 왜 단순한 것들은 소프트웨어 개발에서 결코 단순하지 않고, 여기저기서 몇 가지 작은 것들이 빠진 것과 당신이 만들어야했던 몇 가지 지름길을 아는 것에 대한 좌절없이 우리가 기능을 "적절하게"구현하는 것을 방해하지 않는가? 프로젝트의 다음 기한을 잡을 수있을만큼 모든 것이 제대로 작동하도록하려면? Europe Elects의 다른 사람들과 함께 여러 유럽 국가의 여론 조사에서 주요 데이터를 수집하는 약간의 취미 프로젝트가 있습니다. 이 프로젝트에서는 모든 정보를 수집 할 수있는 인프라를 설정해야합니다.

해독 : 얻을 수없는 테스트 안정성 (아니면?)

해독 : 얻을 수없는 테스트 안정성 (아니면?)

Detox는 모바일 앱용 그레이 박스 테스트 솔루션으로, 테스트 코드와 앱 간의 동기화를 관리하므로 사용자가 수동으로 수행 할 필요가 없습니다. 사용자의 필요와 풍부한 문서 및 가이드가 없어도 개발자와 테스터는 여전히 사용 패턴, 잘못된 구성, 열악한 테스트 안정성으로 어려움을 겪을 수 있습니다.