제품에 대한 작업을하고 있고 사용자 스토리를 작성하기 위해 Pivotal Tracker를 사용하고 있지만 BDD와 XP에 익숙하며 Cucumber에 새로 도입되었습니다. 그래서 약간의 용어로 혼란스러워지고 있습니다. 이야기와 오이 기능의 차이점은 무엇입니까? 둘 다 배우, 행동 및 비즈니스 가치의 세 부분으로 구성된 간단한 설명입니다. 권리? 따라서 이미 Pivotal Tracker로 쓰여진 이야기가 있다면, 바로 그 내용을 Cucumber 기능으로 직접 복사해야합니까? 한 이야기에 여러 기능이있을 수 있습니까?행동 주도 개발의 "기능"과 "스토리"의 차이점은 무엇입니까?
당신은 어떻게 생각하십니까?
기능은 본격적인 기능을 갖춘 기능이며 실제로 사용할 수 있습니다. 예를 들어 기능은 등록 페이지, 유효성 검사, 그림 등으로 완성 된 사용자 프로필 일 수 있습니다.
BDD- 용어에서 이야기는 기능을 통해 제공되는 작은 조각으로 우리가 얻을 수 있습니다 피드백. 예를 들어, 프로필 페이지없이 유효성 검사없이 등록을 생성 할 수 있습니다. 유효성 검사는 또 다른 이야기 일 수 있습니다. 사진은 다른 사진 일 수 있습니다.
아키텍처, 신기술, 도메인 학습 등을 고려하면 좀 더 복잡한 기능을 만드는 데 몇 주가 걸릴 수 있습니다. 따라서 이야기를 통해 우리는 이보다 더 빨리 피드백을 얻을 수 있습니다.
분석 공간에서 피쳐 주입 - BDD에 대해 배우고 싶을 수도 있습니다. 내가 뭘 내가 뭘하는만큼 내가으로 피드백을 받고 있어요 같은 기능이나 이야기인지에 대해 너무 많이 걱정하지 않는 경향이
In order to <achieve a goal>
As <the stakeholder who wants the goal>
I want <something>
: 우리는 템플릿을 이야기와 기능 모두 꽤 많이 사용 최대한 빨리
"이야기"는 함께 목표를 달성하는 일련의 개발 작업입니다. 개발자가 사용하는 장치입니다.
"기능"은 비즈니스 담당자가 자신의 응용 프로그램에서보고 싶은 기능입니다. 기능을 구현하려면 일반적으로 스토리가 "너무 크면"더 관리하기 쉬운 작은 스토리로 분류되기 때문에 하나의 스토리 또는 다수가 필요할 수 있습니다.
BDD는 TDD (Test Driven Development)의 변형입니다. 내가 이해할 수 있듯이 BDD의 의미는 TDD의 의미보다 구현이 덜합니다. 대신 '사용자가 시스템을로드해야합니다.'대신 DAO에 의해로드 된 후 사용자 인스턴스가 null이 아니어야합니다 "- 실제 구현의 특정 세부 사항과 반대되는 시스템 동작 (기능 세트)을 설명합니다. 결국, 그들은 모두 올바르게 행해지면 똑같은 것을 테스트합니다.
그리고 주제에 관해 이야기의 개념은 BDD와 직각을 이룹니다. 스토리가 있고 BDD가없는 개발 사례가 있습니다.
불행하게도 기능은이 공간에서 많이 오버로드 된 단어이며 오이 기능은 완전히 기능을 갖춘 기능과는 아주 다른 것입니다.
'오이 지형지 물'과 사용자 스토리 중 가장 흥미로운 점은 기능이 구현 된 경우 기능이 현재 애플리케이션 상태를 나타내는 반면 사용자 스토리는 역사적인 문서라는 점입니다.
이 차이는 (IMO) 세분성이나 크기의 차이보다 훨씬 중요합니다. 많은 사용자 스토리에 의해 유도/영감을받은 오이 기능을 사용할 수 있으며 많은 오이 기능이있는 단일 사용자 스토리를 만들 수 있습니다.
일단 오이 기능을 실행할 수 있으면 코드입니다. 이는 리팩토링되고 변경되는 경향이 훨씬 더 높음을 의미합니다. 이를 실행할 때마다 응용 프로그램의 현재 상태에 대한 정보를 제공합니다. 사용자 스토리는 응용 프로그램에서 수행해야 할 작업을 알려줍니다. 또는 스토리의 작성자가 스토리 작성 당시에 어플리케이션이 수행해야한다고 생각했던 것보다 정확하게 말입니다.