개발자로서 사용자 스토리를 작성하려면 어떻게해야합니까?

시스템 소유자와 본인 모두 개발자 인 시스템을 작성 중이며 현재 시스템에 대한 '요청'또는 요구 사항의 유일한 소스이며 기능과 관련된 사용자 스토리를 캡처하고 싶습니다 {1}. 저의 시급한 우선 순위는 잡을 수없는 백 로그를 얻는 것입니다. 너무 기술적이지 않은 사용자 스토리에서 작업하는 데 익숙한 기술 사양 수준을 캡처하려면 어떻게해야합니까?

{1} 민첩한 프로젝트 관리 서비스 TargetProcess를 평가하고 있으며 각 사용자 스토리는 상위 기능과 연결되어 있어야합니다. 시스템이 적합 해 보이므로이 작은 제약 조건이 해결 방법보다 오히려 내가 사용하는 것입니다.

project-management agile scrum

— 교수
소스

일반적인 스토리 템플릿은 시각화하기가 매우 쉽습니다.

As a [ROLE] I need to [WHAT] so that/because [WHY].

흥미로운 점은 구성 요소의 중요성이 바뀌 었다는 것입니다.

WHAT 가 WHAT 보다 더 중요한 이유 와 ROLE 보다 더 중요한 이유

이 질문을 사용한 예

소프트웨어 개발자는 백 로그에 초안을 채워 기능에 대한 토론을 시작하고 해당 기능에 할당 된 포인트를 얻을 수 있도록 사용자 스토리를 작성하는 방법을 배워야합니다.

더 많은 것은 User Stories의 의도와 구현을 복잡하게 만드는 것 이상입니다.

추가 도구 (통합이 가장 좋습니다)

포인트 / 추정을 할당하기 위해 토론 할 때 캡처 된 스토리에 대한 추가 세부 정보 를 캡처하는 데 도구를 사용할 수 있지만 해당 세부 사항은 스토리 자체의 일부가 되어서는 안됩니다 . 토론 당 세부 정보 / 기록을 작성하기 위해 스토리 당 1 페이지의 Wiki처럼 간단한 것이 충분한 솔루션입니다. Excel 스프레드 시트는 끔찍한 솔루션입니다.

온 포커스 무엇 과 왜의 와 피할 방법이있어 사용자의 이야기를 쓸 때.

당신이 직면하는 것은 실제로 모든 개발자에게 매우 좋은 운동입니다. 간단한 비즈니스 용어로 요구 사항을 표현할 수 있다는 것은 중요한 기술입니다.

콤보 박스 나리스트 박스 또는 특정 루틴을 트리거하는 모든 것을 사용하는 대신에 사용자가 Foo 액션을 활성화 할 수 있도록 "객체의 드롭 다운리스트에서 단일 선택을 할 수 있어야한다"와 같은 일반적인 요구 사항에 중점을 두어야합니다. .

이것에 접근하는 또 다른 방법은 기본 코드베이스 / 프레임 워크가 거의 완벽한 블랙 박스 인 것처럼 가장하는 것입니다. "객체 XYZ 사용"이라고 말하면 블랙 박스 시스템에서이를 알고 있는지 확인하여 자체 점검 할 수 있습니다.

업데이트 :
IMO, 정보에 필요한 세부 수준을 나타내는 사용 사례에 세부 정보를 넣는 것이 좋습니다. 예를 들어, 등록 시스템을 사용하면
-성; 필수 필드
-이름; 필수 필드
-계정 ID; 시스템은 입력이 필요하지 않습니다
-점성 학적 기호; 선택 필드-(추천) 생년월일 입력 조회를 제공합니까?
-등등 ...

핵심은 해당 정보 의 기술적 방법 을 지정하지 않는다는 것 입니다. 성에 "문자열 클래스 / 문자 배열 또는 varchar 필드 사용"이라고 말하면 과도하게 지정되어 있다는 것을 알 수 있습니다.

다국어를 사용하는 경우 리트머스 시험으로 두 가지 다른 언어를 사용하십시오. 예를 들어 C의 문자열은 일반적으로 char (acter) 배열이지만 C ++, Java 및 C # (좋아요 거의 모든 사람 ...)은 실제 String과 같은 객체를 갖습니다. 해당 언어 중 하나를 사용하여 사양이 무효화되면 사양이 초과되었음을 알게됩니다.

User Story 와 반대로 유스 케이스 라는 용어를 구체적으로 사용하고 있음을 주목할 필요가 있습니다. 유스 케이스의 목표는 진행 상황 (가장 엄격한 의미의 사용자 스토리)에 대한 개요를 제공하고 필요한 액터, 시스템 및 일반 기능을 통해 작업하는 것입니다. 내 접근 방식은 Cockburn의 접근 방식과는 반대로 Wikipedia 기사에서 Fowler가 제안한 것에 더 가깝습니다.

따라서 등록 시나리오 또는 작업 항목에 대한 단일 사용 사례가 있습니다. 그것이 정말로 복잡하다면, 나는 그것을 배수로 나눌 것입니다, 그러나 그것은 큰 문제가 아닙니다. 그런 다음 필요에 따라 사용 사례를 개별 작업으로 분류 할 수 있습니다. 특정 스크럼에 던져지는 것은 많은 변수에 달려 있지만,이 접근법에는 스크럼의 끝에서 입증 할 수있는 구성 요소가없는 것을 막을 수있는 방법이 없습니다.

"드롭 다운 목록"이라고해도 과도하게 지정 될 수 있습니다.

— Donal Fellows

@DonalFellows-좋은 지적이었고, 나는 그 점을 조금 숙고했습니다. 드롭 다운은 와이어 프레임과 함께 볼 수있는 일반적인 표준 UI 요소이기 때문에 함께했습니다. 리스트 박스와 콤보 박스는 드롭 다운리스트를위한 특정 언어 구성입니다. 댓글에 +1

@ GlenH7 나는 이것을 이해하지만 내 문제는 기술적 인 물건을 어디에서 캡처 해야할지 모르겠다는 것입니다. 예를 들어 신입 사원에게 특정 필드가 필요한 경우 각 필드에 대해 스토리를 사용하고 싶지 않지만 "사용자는 필드 x와 y를 캡처해야합니다"와 "필드 q와 z를 캡처하도록 선택할 수 있습니다" "유형의 것. 여기에 나의 빠른 예가 올바른 방향이라면, 더 많은 운동을 해보도록하겠습니다.

— ProfK

@ProfK HR 관리자로서 신입 사원에 대한 정보를 입력하여 급여, 401K 및 보험 혜택 시스템에 등록 할 수 있어야합니다. 이것은 좋은 이야기가 될 것입니다. 다른 모든 것에 대한 세부 사항은 위키 페이지 또는 다른 문서에 문서화되어야하는 세부 사항입니다. 다른 새로운 기능의 사례를이 스토리에 추가해야하는 경우 누락 된 특정 요구 사항이있는 새로운 스토리는 시스템에서 새로운 스토리가됩니다. 스토리는이 활동이 ROLE에 의해 고객 승인에 의해 완료 될 수있을 때 수행됩니다.

@ProfK-귀하의 질문에 대한 답변으로 내 답변을 업데이트했습니다. IMO, 당신이 올바른 길을 가고 있다고 생각합니다. 나는 많은 다른 방법론을 사용해 왔으며, 기억해야 할 중요한 측면은 상황에 맞게 작동시키는 것입니다. 공식 사용자 스토리가 제공하는 것보다 조금 더 필요한 것 같습니다. 따라서 사용자 스토리를 생성하는 방법을 조정하고 계속 발전하십시오. 일부는 아마도 의견에 대해 나를 화나게 할 것입니다. 그러나 솔직히 요점은 코드를 작성하고 프로젝트를 계속 진행하는 것입니다.