사용자 스토리와 기능의 차이점은 무엇입니까?


25

icescrum을 사용 하면서 사용자 스토리와 사용자 기능의 차이점을 이해하지 못한다는 것을 깨달았습니다.

누군가 차이점을 설명 할 수 있습니까?

답변:


23

기능은 비즈니스에 기능을 제공 할 수있는 고유 한 기능 요소입니다.

이야기는 이해 관계자로부터 피드백을 받고 잘못된 일이 있는지 알아내는 데 사용할 수있는 기능의 작은 측면입니다.

예를 들어 기능은 "사용자가 기사에 댓글을 달 수 있도록"할 수 있습니다. 해당 기능과 관련된 스토리는 다음과 같습니다.

  • 댓글 저장
  • 무례한 단어에 대한 댓글 필터링
  • 댓글을 400 자로 제한하고 사용자에게 피드백
  • 봇이 사이트 스팸을 차단하는 보안 문자 추가
  • 사용자가 Google ID를 통해 로그인하도록 허용

기타

각 단계에서 우리는 우리가 취하는 방향이 유용한 지 여부에 대한 피드백을 얻을 수 있습니다.

일부 팀은 기능을 스토리로 나누는 것을 귀찮게하지 않습니다. 괜찮아.


13
사람들은하지 않는 이야기 관련 실제로 사용자 스토리 작업을? 나는 그들이 말할 것입니다. 사용자 스토리는 다음과 같습니다 . 사용자로서 기사 내용을 개선하거나 우려 사항을 표현할 수 있도록 기사에 댓글을 달고 싶습니다. 이 사용자의 이야기는 당신이 ... 설명하는 것이 과제로 분류 될 것이다
— 로버트 Koritnik

4
피드백을 얻기 위해 수행해야 할 작업이지만 데이터베이스 테이블 만들기와 같이 피드백만으로는 얻을 수없는 작업이라고 생각합니다. 첫 번째를 제외한 모든 스토리는 배송 가치를 유지하면서 제거 할 수 있습니다. 작업은 일반적으로 내 세상에서 가로로 분할됩니다. 그러나 다른 정의가 있다면 괜찮습니다. 세분성은 완전히 별개의 것이 아니며, 모든 목표는 다른 목표의 하위 목표이며, 실용적이라면 무엇이든해야한다고 생각합니다. 많은 팀과 마찬가지로이 분류가 유용하다는 것을 알았습니다.
— Lunivore

16

기능 == 사용자 스토리.

사용되는 주어진 애자일 방법론 에 따라 언어가 결정됩니다 .

다른 방법론은 다른 용어를 사용하여 기능을 나타냅니다. 사용할 방법론이나 용어를 결정하는 것은 팀의 책임입니다. 익스트림 프로그래밍 (XP)은 사용자 스토리 또는 스토리라는 용어를 사용하여 기능을 나타냅니다. Scrum은 제품 백 로그를 사용하여 기능 목록을 설명합니다. 기능 중심 개발은 기능을 사용합니다. DSDM은 요구 사항을 사용합니다. 마찬가지로 요구 사항 및 / 또는 사용 사례를 사용하여 점차적으로 제공 가능한 기능을 정의하는 다양한 경량 버전의 Unified Process 또는 Agile UP이 있습니다. 궁극적으로 목표는 동일합니다. 비즈니스 가치를 정기적으로 조금씩, 더 빨리 또는 더 빨리 제공하는 것입니다.


+1, 이것은 잘 설명합니다. 비즈니스 가치 또는 고객 가치에 대해 이야기 할 때를 제외하고는 반드시 feature == user story라고 말하지는 않습니다. 다른 경우에는 각각의 용어에 의미가 없을 수도 있습니다.
— murrekatt

2
나는 그들이 관련 용어 인 경우에도 동일하다고 말할 수는 없다고 생각합니다. 여러 사용자 스토리에 걸친 기능은 어떻습니까?
— sleske

@sleske 순수한 Scrum 접근 방식의 사용자 스토리는 사용자에게 부가 가치를 부여해야합니다. 우리가 기능을 중요한 Epics로 분류하려고한다면 괜찮지 만 최종 결과는 가치를 제공하는 사용자 스토리입니다.
— Aaron McIver

1
@AaronMcIver : 그렇습니다. 그러나 때로는 사용자에게 실제로 유용한 기능의 최소량 (= 기능)이 사용자 스토리 (또는 반복)에 너무 많은 경우가 있습니다. 이 경우 기능을 여러 스토리로 나누어야합니다.
— sleske

BTW, 관련 질문 및 답변 : stackoverflow.com/questions/1714557/…
— sleske

7

사용자 스토리는 고객의 소원을 달성하는 것을 무언가의 의도를 포착 고객의 언어로 비공식 문입니다. 사용자 스토리 를 비공식 요구 사항 진술로 생각할 수 있습니다 .

소프트웨어 기능은 소프트웨어의 독특한 특징 인 소프트웨어의 전체적인 디자인과 기능에 기여.

몇 가지 주요 고려 사항 :

  • 이야기 기술 할 수있다 기능을 하지만, 기능은 설명하지 스토리 .
  • 스토리는 직접 설명하지 않을 수 있습니다 특징 .
  • 스토리는 다수의 포함을 의미 할 수있다 특징 .
  • 기능은 - 단독 또는 컬렉션의 구성원으로 특징 - a의 의도를 캡처 할 수 있습니다 이야기 .

이 모든 것을 염두에두고 이야기를 설명이라고 생각하는 경향이 있습니다. 기본적으로 비공식적 인 요구 사항으로 고객이 원하는 것을 알려줍니다. 반면에 특징은 고객 요구 사항을 충족시키기 위해 시스템이 어떻게 작동해야 하는지를 알려주는 사양으로 생각하는 경향이 있습니다.


3

두 용어는 서로 밀접한 관련이 있지만 약간의 차이가 있습니다.

첫째, 그들은 다른 영역에서 왔습니다. "기능"이라는 용어는 소프트웨어 기능의 일부에 대해 상당히 일반적인 용어 인 반면, "사용자 스토리"는 민첩한 소프트웨어 개발을 위해 고안되었으며 실제로 만 사용됩니다.

실제로, 그들은 하나의 사용자 스토리가 특정 기능을 구현하는 것으로 구성되어 있기 때문에 종종 일치합니다.

그러나 상황에 따라 다를 수 있습니다.

  • 단일 사용자 스토리에는 기능이 너무 많은 경우가 많습니다. 사용자 스토리는 너무 크지 않아야합니다 (일반적으로 며칠을 넘지 않아야하며 최대 1-2 주간의 작업). 분명히 많은 기능이 훨씬 더 큽니다. 이 경우 많은 사용자 스토리에 기능이 구현됩니다. 일부 사람들은 "에픽"을 사용하여 사용자 스토리를 그룹화합니다.이 경우 해당 기능이 서사적이라고 말할 수 있습니다.
  • 비 기능적 요구 사항 (성능, 보안, 호환성 등)도 사용자 스토리로 처리 할 수 ​​있습니다 (일반적으로 수용되지는 않음). 이 경우 사용자 스토리의 결과는 일반적으로 기능이라고 할 수 없습니다 ( "응용 프로그램이 거의 충돌하지 않음"이라고 부르지 않는 한).
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.