사용자 스토리 작성 방법: 전체 가이드

사용자 스토리는 적절한 애자일 소프트웨어 개발의 중요한 부분입니다. 역할을 살펴보고 사용자 스토리를 작성하는 방법을 알아보겠습니다.

애자일 프레임워크는 소프트웨어 개발을 구조화하고 작업을 위임하는 대중적이고 효과적인 방법입니다. 사용자 스토리 작성(평가 작성 방법과 혼동하지 말 것)은 개발자가 수행해야 할 작업과 요구 사항을 충족하는 방법을 이해할 수 있도록 하는 애자일 개발 도구입니다. 그것은 그것들을 매우 중요한 출발점으로 만들지만 그것은 또한 그것들이 신중하게 건설되어야 한다는 것을 의미합니다. 여기 당신이 알아야 할 것이 있습니다.

사용자 스토리란 무엇입니까?

애자일 프레임워크 내에서 소프트웨어 개발에 사용되는 용어입니다. 사용자 스토리는 일반적으로 애자일 프로젝트에서 가장 작은 단위 또는 요구 사항 충족의 첫 번째 단계로 간주됩니다. 프로젝트가 완전히 계획되면 생성됩니다.

그게 정확히 무슨 뜻인가요? 모든 소프트웨어 기능은 프로젝트에 추가될 때 특정 목적을 갖습니다(또는 가져야 합니다). 그 목적은 전체 개발과 전체 프레임워크에 통합되는 방식에 영향을 미쳐야 합니다. 개발자는 의사 결정, 특히 목표를 세분화하는 방법과 우선 순위를 지정하는 방법에 대해 필요할 때마다 이 목적을 참조할 수 있습니다. "사용자 스토리"는 단순히 기능의 목적을 설명하는 방법입니다.

사용자 스토리는 일반적으로 한두 문장으로 사용자의 관점에서 작성됩니다. 그들은 사용자의 관점과 사용자가 원하는 것을 포착합니다. 완료되면 좋은 사용자 스토리는 전략적 목표, 안전하게 폐기할 수 있거나 추가해야 하는 기능 등에 대해 쉽게 이야기할 수 있는 방법입니다.

사용자 스토리 작성 방법

1단계. 입력 받기

소유자, 잠재 사용자 및 프로젝트 관리자로부터 의견을 얻으십시오. 강력한 사용자 스토리는 정확하기 위해 많은 입력이 필요합니다. 그들이 하고 싶은 일에 대해 이 그룹들로부터 명확한 설명을 받으세요. 이것은 사용자 스토리로 직접 변환되어서는 안 되지만 필요한 정보를 제공한다는 점을 기억하십시오. 소유자는 "내 앱에서 PayPal로 결제할 수 있는 사람들이 필요합니다"라고 말할 수 있습니다. 이는 매우 유용하지만 사용자 스토리 자체는 아닙니다.

2단계. 사용자 스토리 생성 방법 결정

이는 작업 흐름에 따라 다릅니다. 초기 단계에서는 전체 프레임워크를 계획하면서 사용자 스토리를 인덱스 카드나 포스트잇에 기록합니다. 나중에 프로젝트 관리 소프트웨어에 통합됩니다. 어떤 팀원은 포스트잇 단계를 건너뛰고 다른 팀원은 포스트잇에 의존합니다.

3단계. 정의, 정의, 정의

사용자 정의: 이제 입력을 통해 사용자를 정의할 수 있습니다. 이것이 항상 제품 기능의 최종 사용자는 아니라는 점을 명심하십시오. 사용자 유형에 따라 다를 수 있습니다. 필요한 경우 사용자 페르소나를 만듭니다. 사용자가 취하는 조치를 정의하고 이 조치를 취하는 사용자의 목표를 정의하십시오. 사용자 스토리를 작성하여 대상 고객에게 전달할 때 이 핵심 정보를 포함하십시오.

4단계. 이야기 쓰기

사용자 스토리 작성을 시작하세요. 독자의 관심을 끌 수 있도록 한두 문장으로만 작성해야 합니다. 여기에서 정확하고 기술적인 것이 유혹적이지만 사명 선언문과 같은 광범위한 언어가 도움이 될 수 있습니다. 이야기를 명확하게 하고 해결하거나 완료할 수 있는지 확인하여 "예, 사용자는 이제 이것을 할 수 있습니다!"라고 되돌아보고 확인할 수 있습니다.

5단계. 추가 단계로 나누기

사용자 스토리는 최종 목표에 도달하기 위해 여러 단계가 필요할 수 있으며 사용 중인 애자일 프레임워크에 따라 약간의 재구성이 필요할 수 있습니다. 사용자 스토리는 항상 프레임워크에서 가장 작은 단위라는 점을 기억하십시오. 이 세분화된 수준에서 사용자 스토리를 구현하는 데 며칠이 걸립니다.

훨씬 더 오래 걸릴 것 같으면 다시 방문하여 사용자 경험을 더 세분화하고 재구성해야 하는지 확인해야 한다는 신호입니다. 새로운 요구 사항이 추가되면 사용자 스토리로 세분화해야 합니다. 이 몇 문장이 효과적인 사용자 스토리의 핵심이지만 개발이 진행됨에 따라 확장될 수도 있습니다. 자세히 살펴보겠습니다.

사용자 스토리의 3C는 무엇입니까?

카드 : 카드 단계는 개발팀을 위한 사용자 스토리를 한두 문장으로 작성하는 것을 말합니다. 사용자 스토리는 원래 인덱스 카드에 작성되었고 많은 팀이 여전히 그런 방식을 선호하기 때문에 카드라고 합니다. 카드는 특정 소프트웨어 요구 사항의 핵심이자 모든 토론의 출발점입니다. 또한 사용자 스토리가 너무 긴지 쉽게 확인할 수 있습니다. 모든 사람이 읽을 수 있는 색인 카드에 맞지 않으면 줄여야 합니다.

대화 : 카드 문장이 만들어지면 세부 사항을 다듬을 차례입니다. 이것은 일반적으로 "이것을 구현하는 데 얼마나 걸릴까요?"와 같은 개발자 간의 일련의 질문으로 시작됩니다. 또는 "이 작업을 어떻게 통합할 수 있습니까?" 또는 "이 사용자 스토리가 여기에 필수적인가요?" 등등.

이러한 사용자 스토리에 대한 면밀한 조사는 필요에 따라 대화에 참여해야 하는 프로젝트 관리자와 제품 소유자에게 추가 질문을 생성할 수 있습니다. 대화가 계속됨에 따라 모든 사람이 같은 페이지에 있을 때까지 사용자 스토리가 변경, 개선, 병합 또는 제거될 수 있습니다. 사용자 스토리가 완성되면 구현 단계로 이동하여 대화가 본질적으로 끝났다는 신호입니다.

확인 : 확인은 수락 기준, 즉 수락 테스트에 관한 모든 것입니다. 변경 사항이 구현되고 개발자가 준비가 되었다고 보고하면 사용자 스토리가 만족스러워집니다. 이제 테스트할 시간입니다.

수락 테스트는 제품 소유자의 입력으로 생성되어야 하며 사용자 스토리에 직접 연결되어야 합니다. 최상의 시나리오는 사용자가 사용자 스토리가 나타내는 대로 시도하고 가능한지 확인하는 것입니다. 그러나 수락 테스트는 다양할 수 있으며 항상 사용자 스토리를 염두에 두고 만들어지는 것은 아닙니다. 이로 인해 문제가 발생하면 수락 테스트와 사용자 스토리가 적절하게 정렬될 때까지 대화 단계로 돌아가야 합니다. 모든 수락 테스트가 완료되면 사용자 스토리가 기뻐합니다. 이제 제품 개발의 다음 단계로 이동하거나 기능을 릴리스할 때입니다.

4세기? : 흥미롭게도 일부에서는 필수적인 4th C: Context가 있다고 주장합니다. 이 경우 사용자 스토리는 프로젝트의 더 큰 프레임워크에서 다른 사용자 스토리와 함께 표시됩니다. 여기에서 개발자는 사용자 스토리가 다른 사용자 스토리를 원활하게 보완하는지 또는 사용자 스토리 간에 누락된 사용자가 수행해야 하거나 이해해야 하는 간격이 있는지 묻습니다.

이상적으로는 대화 단계에서 발견되지만 항상 그런 것은 아닙니다. 일부 개발 팀은 완성된 사용자 스토리가 더 큰 전체에 어떻게 부합하는지, 추가 작업이 필요한지에 대한 최종 검토를 원할 수 있습니다.

사용자 스토리에 적합한 형식은 무엇입니까?

사용자 스토리 문장을 만들 때 매우 유용한 두 가지 서식 지정 기술을 살펴보겠습니다. 첫 번째는 매우 간단합니다. "누가, 무엇을, 왜?" 문장 템플릿에서 다음과 같이 설명할 수 있습니다.

[사용자는 누구인가]로서 [사용자가 원하는 것]을 원합니다([사용자가 원하는 이유]).

이 템플릿은 단순화된 용어로 "[역할]로서 [행동]을 원합니다. 이 기본 형식을 따르면 대부분의 사용자 스토리를 만들 수 있습니다. 일반적으로 필요한 모든 것이며 각 사용자 스토리에 사용할 때 많은 시간을 절약할 수 있습니다.

그러나 때때로 사용자 스토리는 더 복잡한 프로젝트에서 정의하기 더 어렵습니다. 이 경우 두 번째 사용자 스토리 템플릿 기술이 유용할 수 있습니다. 다음을 나타내는 약어인 INVEST라고 합니다.

• 독립성 : 스토리는 서로 완전히 독립적이어야 하며 결과적으로 스토리는 비순차적으로 작업할 수 있어야 합니다.
• 협상 가능 : 스토리는 프로세스의 대화 부분에서 변경되도록 설계되어야 합니다.
• 가치 있음 : 사용자 스토리는 프로젝트에 대한 명확한 가치를 보여주어야 합니다. 그렇지 않으면 자원 낭비일 수 있습니다.
• Estimable : 사용자 스토리는 중요도에 따라 작업할 대상을 결정하는 데 도움이 되도록 가치와 우선순위를 측정해야 합니다.
• 작음 : 사용자 스토리는 기능의 가장 작은 단위여야 하며 그렇지 않으면 더 세분화되어야 합니다.
• 테스트 가능 : 사용자 스토리는 확인 프로세스 중에 테스트 가능한 방식으로 명시되어야 합니다.

사용자 스토리 작성 방법에 대한 FAQ

게임 리뷰를 작성하는 방법에 대한 가이드에 관심이 있을 수도 있습니다.