프로젝트 초기 단계에 어떤 종류의 사용자 스토리를 작성해야합니까?

프로젝트를 시작할 때 UI, 데이터 레이어, 사이에 아무것도 없습니다. 따라서 "사용자가 자신의 foo를 볼 수 있어야합니다"와 같은 단일 스토리에는 많은 작업이 수반됩니다. 이 스토리가 있으면 "사용자가 자신의 foo를 편집 할 수 있어야합니다"와 같은 것이 더 현실적이지만 첫 번째 스토리에는 UI 계층, 프리젠 테이션 논리 계층, 도메인 논리 계층 및 데이터 액세스 계층을 설정하는 것이 포함됩니다.

이것은 내 "태스크"개념에 맞지 않습니다. 나에게는 다음과 같은 "태스크"와 같은 것이 있습니다.

• JavaScript 객체에서 파생 된 HTML로 사용자의 foo에 대한 더미 데이터를 표시합니다.
• 프리젠 테이션 로직 레이어를 설정하고 JavaScript 객체를 연결합니다.
• 도메인 로직 레이어를 설정하고 프리젠 테이션 로직 레이어를 연결합니다.
• 데이터 액세스 계층을 설정하고 도메인 논리 계층을 연결하십시오.

이 모든 것이 위의 단일 "스토리"에 해당됩니까? 그렇다면 이야기는 프로젝트 초기 단계에서 굉장히 유용한 틀이 아닌 것 같습니다. 그렇다면, 그것은 괜찮습니다 .- 내가 최선을 다해이 민첩한 방법론을 배우려고 노력하고 있기 때문에, 나는 무언가를 놓치고 있지 않은지 확인하고 싶습니다.

이것은 좋은 질문이며 아마도 그것에 대한 몇 가지 좋은 대답이있을 것입니다. 내 취지는

스토리는 사용자 스토리 이므로 사용자 에게 어떤 이점이 있는지 설명하는 용어로 정의해야합니다.

애자일과 스토리가 효과가 있다면, 시작 단계에서도 효과가 있습니다. 첫 번째 글 머리 기호는 단일 사용자 스토리 (약간 기술로 표시)이지만 다른 세 가지 기술 설명은 기술 작업 설명입니다.

프로젝트의 시작 단계에서, 때 당신이 할 수있는 장소에 적절한 프레임 워크가없는 CRUD을 ( C reate, R EAD, U pdate, D의 elete) 개발을 빠르고 쉽게, 당신의 이야기는 훨씬 작은, 점진적으로해야 조각.

"사용자는 다음과 같은 foo를 볼 수 있어야합니다" 대신

1. 사용자는 샘플 데이터가있는 페이지를 볼 수 있어야합니다
2. 사용자는 대화식 샘플 데이터가있는 페이지를 볼 수 있어야합니다
3. 사용자는 실시간 대화식 샘플 데이터가있는 페이지를 볼 수 있어야합니다

단일 스프린트로 개발하기에는 너무 큰 것처럼 보이는 대부분의 사용자 스토리 (약 8 스토리 포인트 또는 개발 일이 너무 큼)는 여전히 의미있는 조각으로 나눌 수 있음을 기억하십시오. 사용자.

스토리 / 피처는 마케팅 가능할 필요는 없으며 제품 소유자에게 의미가 있어야합니다. 위의 경우 변경된 데모와 해당 스토리가 수행 되는 방식을 보여주는 간단한 데모 조각을 넣을 수 있습니다. 예를 들어 # 3의 경우 데이터베이스에 데이터가 미리 채워진 두 명의 다른 사용자에 대한 페이지를 표시 할 수 있습니다 . 2 단계에서 모든 사용자는 동일한 데이터를 보게됩니다.

당신이 요구하는 것은 디자인을 할 수있는 합리적인 조각으로 나누기 위해 "문제 공간에 대해 어떻게 생각 하는가"입니다.

이것을 사용자 스토리, 분석, 분해, 사양 또는 요구 사항 수집이라고 부르든 결국에는 일반적으로 반복되는 몇 가지 사항이 있습니다.

원하는 정보를 사용자에게 제공해야합니다. (아마도 자신이 원하는 것을 알고 일관성이 없지만 아직 볼 수없는 것을 원할 것입니다.)

당신은 어떤 형태로 이것을 캡처해야합니다-당신은 실제로 단어 또는 그림의 두 가지 선택 만 있습니다. 둘 다 힘이 있습니다. 가능하다면 둘 다 사용하십시오. 말은 나중에 계약 분쟁의 관점에서 볼 때 더욱 강력합니다.

이를 제시하고 동의를 구해야합니다.

어떤 사람들은 비즈니스 나 다른 논리가없는 초기 시각적 프로토 타입을 수행합니다. 이 방법은 여전히 ​​강력한 기술 일 수 있습니다. 여전히 일정량의 손을 흔들기 때문입니다.

어떤 사람들은 스토리 보드를하고 발표하고 설명 할 것입니다.

일부는 엄격하고 신중하게 분석 된 문서를 작성합니다.

각 기술에는 장단점이 있습니다.

내가 준 유일한 조언은 다음과 같습니다. 솔루션을 너무 일찍 코딩하는 것은 일반적으로 나쁜 행동입니다. 수행하기 전에 WHO 및 WHY에 대해 수행 할 작업을 이해하면 일반적으로 재 작업이 줄어들고 개발 속도가 빨라집니다.

당신이 "과제"에 대해 이야기 할 때, 이것은 위의 무엇을, 누가, 왜 알아 냈는지에 대한 일종의 작업 분석과 같습니다. 사용자가 할 일의 범위로 고객이 승인 한 문서로 사용자 스토리를 이해하기 전까지는 WELL 작업을 파악할 수 없습니다. 당신이 무엇을 성취해야하는지 (출력) 알면 과제를 파악할 수 있습니다.

프론트 엔드 분석 및 문서를 작성하지 마십시오.

당신이 누락 된 것은 사용자 이야기가 사용자가 시스템을 사용하기를 기대하는 방법에 대한 이야기라는 것입니다. 비즈니스 요구 사항 을 결정하는 방법입니다 . 기술적으로해야 할 일을 직접 알려주도록 설계되지 않았으므로 원하는 것 같습니다.

이것은 프로젝트에서 가장 중요한 부분 중 하나입니다. 비즈니스 요구 사항이 맞지 않으면 시스템이 사용자에게 무용지물이됩니다.