Từ điển quản lý

User Story

"User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality" - Mike Cohn, a main contributor to the invention of Scrum software development methodology.

Câu chuyện của người dùng

"Câu chuyện của người dùng là một phần của phương pháp tiếp Agile giúp chuyển trọng tâm từ viết về các yêu cầu sang nói về chúng. Tất cả các câu chuyện của người dùng nhanh đều bao gồm một hoặc hai câu viết và quan trọng hơn là một loạt các cuộc trò chuyện về chức năng mong muốn" - Mike Cohn , người đóng góp chính cho việc phát minh ra phương pháp luận phát triển phần mềm Scrum

Basic Concepts of User Story

A user story is a lightweight method for quickly capturing the "who", "what" and "why" of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are "to-do" lists that help you determine the steps along the project's path. They help ensure that your process, as well as the resulting product, will meet your requirements.

Các khái niệm cơ bản về câu chuyện của người dùng

Câu chuyện người dùng là một phương pháp gọn nhẹ để nhanh chóng nắm bắt "ai", "cái gì" và "tại sao" của yêu cầu sản phẩm. Nói một cách dễ hiểu, câu chuyện của người dùng là những ý tưởng được nêu về các yêu cầu thể hiện những gì người dùng cần. Câu chuyện của người dùng rất ngắn gọn, với mỗi phần tử thường chứa ít hơn 10 hoặc 15 từ mỗi câu chuyện. Câu chuyện của người dùng là danh sách "việc cần làm" giúp bạn xác định các bước trên lộ trình của dự án. Chúng giúp đảm bảo rằng quy trình của bạn, cũng như sản phẩm thu được, sẽ đáp ứng các yêu cầu của bạn.

A user story is defined incrementally, in three stages:

• The brief description of the need

• The conversations that happen during backlog grooming and iteration planning to solidify the details

• The tests that confirm the story's satisfactory completion

Một câu chuyện của người dùng được xác định dần dần, trong ba giai đoạn:

• Mô tả ngắn gọn về nhu cầu

• Các cuộc trò chuyện xảy ra trong quá trình chuẩn bị tồn đọng và lập kế hoạch lặp lại để củng cố các chi tiết

• Các bài kiểm tra xác nhận sự hoàn thành hài lòng của câu chuyện

User Stories - INVEST

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

Câu chuyện của người dùng - INVEST

Từ viết tắt INVEST giúp ghi nhớ một bộ tiêu chí hoặc danh sách kiểm tra được chấp nhận rộng rãi để đánh giá chất lượng của một câu chuyện người dùng. Nếu câu chuyện không đáp ứng được một trong những tiêu chí này, nhóm có thể muốn đặt lại câu chuyện hoặc thậm chí cân nhắc viết lại (thường được hiểu là xé thẻ câu chuyện cũ và viết một câu chuyện mới).

A good user story should be - INVEST:

• Independent: Should be self-contained in a way that allows to be released without depending on one another.

• Negotiable: Only capture the essence of user's need, leaving room for conversation. User story should not be written like contract.

• Valuable: Delivers value to end user.

• Estimable: User stories have to able to be estimated so it can be properly prioritized and fit into sprints.

• Small: A user story is a small chunk of work that allows it to be completed in about 3 to 4 days.

• Testable: A user story has to be confirmed via pre-written acceptance criteria.

Một câu chuyện người dùng tốt phải có tiêu chí – INVEST (viết tắt):

• Độc lập (I): Mô tả nội dung có thể hiện thực độc lập mà không phụ thuộc vào vấn đề khác khi hiện thực.

• Có thể thương lượng (N): Để nắm bắt rõ được nhu cầu người dùng, hãy chừa không gian để trao đổi, không tiến hành cứng nhắc giống như hợp đồng.

• Có giá trị (V): Mang lại giá trị cho người dùng cuối.

• Có thể ước tính (E): Các câu chuyện của người dùng phải có thể được ước tính để có thể được ưu tiên một cách hợp lý và phù hợp với sprint.

• Nhỏ (S): Một câu chuyện của người dùng là một phần nhỏ công việc cho phép hoàn thành trong khoảng 3 đến 4 ngày.

• Có thể kiểm tra (T): Một câu chuyện của người dùng phải được xác nhận thông qua các tiêu chí chấp nhận được viết trước.

User Story Template

User stories only capture the essential elements of a requirement:

• Who it is for?

• What it expects from the system?

• Why it is important (optional?)?

Biểu mẫu viết User Story

Câu chuyện của người dùng chỉ nắm bắt các yếu tố cần thiết của một yêu cầu:

• Nó dành cho ai?

• Mong đợi gì từ hệ thống?

• Tại sao nó lại quan trọng (tùy chọn)?

User Story Examples:

• As a [customer], I want [shopping cart feature] so that [I can easily purchase items online].

• As an [manager], I want to [generate a report] so that [I can understand which departments need more resources].

• As a [customer], I want to [receive an SMS when the item is arrived] so that [I can go pick it up right away]

Ví dụ về câu chuyện của người dùng:

• Là [khách hàng], tôi muốn có [tính năng giỏ hàng] để [tôi có thể dễ dàng mua hàng trực tuyến].

• Với tư cách là [người quản lý], tôi muốn [tạo báo cáo] để [tôi có thể hiểu bộ phận nào cần thêm tài nguyên].

• Với tư cách là [khách hàng], tôi muốn [nhận được SMS khi hàng được chuyển đến] để [tôi có thể đến lấy ngay].

Lifecycle of a User Story

In a broad sense, there are six main states for each user story throughout a software project:

Vòng đời của một câu chuyện người dùng

Theo nghĩa rộng, có sáu trạng thái chính cho mỗi câu chuyện của người dùng trong suốt một dự án phần mềm:

Pending

Through the communication between user and project team, user stories are found. At this state, the user stories have nothing more than a short description of user's need. There is no detailed discussion of requirements, no system logic and no screen design yet. In fact, the only purpose of user story, for now, is just for reminding all parties for a future discussion of user's request written in this user story (card). It is possible that the user story will be discarded in the future.

Chưa giải quyết

Thông qua giao tiếp giữa người dùng và nhóm dự án, các câu chuyện của người dùng được tìm thấy. Ở trạng thái này, câu chuyện của người dùng không có gì khác hơn là một mô tả ngắn về nhu cầu của người dùng. Không có thảo luận chi tiết về các yêu cầu, không có logic hệ thống và chưa có thiết kế màn hình. Trên thực tế, mục đích duy nhất của user story hiện tại chỉ là để nhắc nhở tất cả các bên thảo luận trong tương lai về yêu cầu của người dùng được viết trong user story này (thẻ). Có thể câu chuyện của người dùng sẽ bị loại bỏ trong tương lai.

To-do

Through a discussion between different stakeholders, the user stories to be addressed in the next few weeks are decided, and are put into a time-box called a sprint. Such user stories are said to be in the to-do state. No detailed discussion has yet been carried out in this state.

Làm

Thông qua cuộc thảo luận giữa các bên liên quan khác nhau, câu chuyện của người dùng sẽ được giải quyết trong vài tuần tới sẽ được quyết định và được đưa vào một hộp thời gian gọi là sprint. Những câu chuyện của người dùng như vậy được cho là ở trạng thái việc cần làm. Không có cuộc thảo luận chi tiết nào đã được thực hiện trong trạng thái này.

Discussing

When a user story is in the Discussing state, the end user will communicate to the development team in confirming the requirements as well as to define the acceptance criteria. Development team will write down the requirements or any decisions as conversation notes. UX specialist may create wireframes or storyboards to let user preview the proposed features in visual mock-ups, and to feel it. This process is known as user experience design (UX design).

Thảo luận

Khi một câu chuyện của người dùng ở trạng thái Thảo luận, người dùng cuối sẽ giao tiếp với nhóm phát triển để xác nhận các yêu cầu cũng như xác định các tiêu chí chấp nhận. Nhóm phát triển sẽ viết ra các yêu cầu hoặc bất kỳ quyết định nào dưới dạng ghi chú hội thoại. Chuyên gia UX có thể tạo khung dây hoặc bảng phân cảnh để cho phép người dùng xem trước các tính năng được đề xuất trong mô hình trực quan và cảm nhận nó. Quá trình này được gọi là thiết kế trải nghiệm người dùng (thiết kế UX).

Developing

After the requirements are clarified, the development team will design and implement the features to fulfill user's requests.

Đang phát triển

Sau khi các yêu cầu được làm rõ, nhóm phát triển sẽ thiết kế và triển khai các tính năng để đáp ứng yêu cầu của người dùng.

Confirming

Upon the development team has implemented a user story, the user story will be confirmed by the end user. He/she will be given access to the testing environment or a semi-complete software product (sometimes known as an alpha version) for confirming the feature. Confirmation will be performed based on the confirmation items written when detailing the user story. Until the confirmation is done, the user story is said to be in the Confirming state.

Xác nhận

Sau khi nhóm phát triển đã triển khai câu chuyện người dùng, câu chuyện người dùng sẽ được xác nhận bởi người dùng cuối. Anh / cô ấy sẽ được cấp quyền truy cập vào môi trường thử nghiệm hoặc sản phẩm phần mềm bán hoàn chỉnh (đôi khi được gọi là phiên bản alpha) để xác nhận tính năng. Xác nhận sẽ được thực hiện dựa trên các mục xác nhận được viết khi trình bày chi tiết câu chuyện của người dùng. Cho đến khi quá trình xác nhận được thực hiện, câu chuyện của người dùng được cho là ở trạng thái Đang xác nhận.

Finished

Finally, the feature is confirmed to be done, the user story is considered in the Finished state. Typically, this is the end of the user story. If user has a new requirement, either it is about a new feature, or it is an enhancement of the finished user story, the team would create a new user story for the next iteration.

Hoàn thành

Cuối cùng, tính năng được xác nhận là xong, câu chuyện của người dùng được coi là ở trạng thái Đã hoàn tất. Thông thường, đây là phần cuối của câu chuyện người dùng. Nếu người dùng có yêu cầu mới, đó là về một tính năng mới hoặc đó là sự nâng cao của câu chuyện người dùng đã hoàn thành, nhóm sẽ tạo một câu chuyện người dùng mới cho lần lặp tiếp theo.

Icon email Icon phone Icon message Icon zalo