사용자 스토리 or 앱 만드는 이유, 목적 (User Stories)(8)

사용자 스토리

이제 프로젝트 팀을 구성했으므로 캡처 단계를 시작하겠습니다.

간단히 말해서, 에픽에서는 더 큰 개발 작업 덩어리를 정의합니다. 에픽에는 여러 이야기가 포함되어 있습니다. 그리고 각 스토리는 앱의 특정 요구 사항을 포착합니다.

더 자세히 살펴보겠습니다!

사용자 스토리 는 사용자의 요구 사항을 작업할 수 있는 항목으로 변환하는 방법입니다. 이는 요구 사항과 해당 상황을 설명하는 문장 형식을 취합니다. 강의가 끝나면 이 문장의 형식을 볼 수 있습니다. 사용자 스토리의 목표는 작업을 시작하기 전에 작업해야 할 작업을 결정하는 것입니다. 마지막 순간의 변경으로 인해 작업을 다시 실행하는 것을 피하고 싶으신가요? 사용자 스토리는 여러 스토리를 포함하는 epics 라는 더 큰 덩어리로 그룹화될 수도 있습니다 .

새로운 사용자 스토리는 제품 백로그 에 포함될 것입니다 . 제품 백로그는 수행할 수 있는 작업 항목의 목록입니다. 스크럼 팀의 모든 구성원은 제품 백로그에 항목을 추가할 수 있지만 이해관계자와의 협상에서 해당 항목의 우선순위를 지정하는 것은 제품 소유자의 책임입니다.

스크럼으로 작업할 때는 마감일을 추정하거나 시간을 할당하지 않습니다. 왜? 이런 것들은 이미 결정되어 있고 정해진 시간표인 스프린트가 있기 때문입니다 ! 스프린트는 팀이 특정 목표를 달성하기 위해 노력하는 고정된 기간입니다. 스크럼에서 스프린트는 일반적으로 2주 동안 진행됩니다. 스프린트는 짧은 피드백 주기를 허용하므로 빠른 결과를 얻는 데 도움이 됩니다!

마지막으로, 서사시는 스토리를 더욱 체계적으로 구성하는 좋은 방법입니다. 각 에픽에서 사용자 스토리를 추가 및 제거하고, 에픽 소유자를 할당하고, 완료된 스토리의 진행 상황을 확인할 수 있습니다.

스프린트의 이러한 요소를 더 자세히 살펴보겠습니다. 폭포수와 같은 전통적인 개발에서는 기능적 요구 사항을 설정한 다음 이를 충족하는 데 필요한 시간과 리소스를 협상합니다. 민첩하고 가치 중심적인 방법론을 통해 시간과 리소스가 설정됩니다. 사용자에게 제공할 기능의 가치는 다양합니다. 즉, 할당된 팀과 함께 주어진 시간 내에 수행할 수 있는 작업의 양입니다. 스프린트가 끝날 때까지 사용자 스토리를 완료할 수 없으면 단순히 다음 스프린트로 이동됩니다. 이를 염두에 두고 팀은 가치가 높은 스토리를 먼저 작업하고, 덜 중요하고 있으면 좋은 기능은 팀에 아직 시간이 있으면 나중에 완료합니다.

사용자 스토리를 만들 때 고려해야 할 세 가지 사항은 다음과 같습니다.

• 내 앱의 최종 사용자는 누구인가요? [사용자 유형]
• 최종 사용자는 무엇을 해야 합니까? [사업 가치]
• 그들이 그렇게 하도록 어떻게 도울 수 있나요? [무엇]

그런 다음 다음과 같은 간단한 사용자 스토리 템플릿을 사용할 수 있습니다. [사용자 유형]으로서 나는 [무엇]을 원하므로 [비즈니스 가치]를 원합니다.