Sep 21, 2021

Phát triển yêu cầu các bên liên quan bằng User Story

Bạn đã biết câu chuyện người dùng (hay còn được gọi với cái tên: User Story) là gì và cú pháp của một User Story (US) là gì chưa?

User Story (US) là một định nghĩa mà nhất định một người phân tích nghiệp vụ (Business Analyst - BA) cần phải nắm rõ. Ở bài viết này, BAC chia sẻ với các bạn kiến thức về US, cũng như kinh nghiệm phát triển các yêu cầu (Requirements) từ các bên liên quan (Stakeholders) bằng User Stories.

1. Định nghĩa về User Story (US)?

1.1. Cú pháp: Persona + Need + Purpose (Who + What + Why)

Một US thường được phát triển dưới dạng “persona + need + purpose”. US trả lời cho ba câu hỏi Ai? (who), Làm gì? (what) và Tại sao? (why), và không đề cập đến việc làm như thế nào? (how). US không nói lên trình tự các bước để thực hiện chức năng người dùng. Vậy thì tất cả các chi tiết liên quan, logics, kịch bản sẽ được thể hiện ở đâu? Câu trả lời là tất cả sẽ được đề cập trong các tiêu chí chấp nhận (acceptance criteria).

As a [persona], <— who
I want to [do something], <— what
so that I can [derive a benefit] <— why

Một phần mềm được tạo ra và sẽ thành công nếu đặt giá trị của người dùng vào trung tâm của quá trình phát triển. Để làm được điều này, các BAs sẽ sử dụng đến user stories, tức sử dụng ngôn ngữ phi kỹ thuật để cung cấp bối cảnh cho đội ngũ phát triển có thể hiểu được tại sao họ lại xây dựng tính năng (feature) đó và giá trị họ đang tạo ra cho các end-users là gì.

Đây là một đơn vị nhỏ nhất nhưng lại là một thành phần quan trọng của phương pháp Agile. Tuy chúng không phải là mục tiêu cuối cùng, cũng không phải là một feature, nhưng chúng thể hiện được quan điểm người dùng. Từ đó, chúng cung cấp và thúc đẩy sự hợp tác, sáng tạo và hiệu suất để hoàn thành một sản phẩm tốt hơn. US là một lời giải thích không chính thức, mô tả chung chung về một feature. US thể hiện cho quan điểm của người dùng cuối (end-user). Mục đích của US là mô tả rõ cho một feature và feature đó sẽ cung cấp giá trị như thế nào cho khách hàng.

1.2 Phân rã cú pháp:

"As a [persona]": Trả lời câu hỏi chúng ta đang xây dựng feature cho ai? Chúng ta không chỉ bàn về việc người đó là ai mà còn tìm hiểu thêm về thói quen, tính cách, suy nghĩ, cảm nhận của họ và đồng cảm với họ.
- Ví dụ:
  - As a passenger, ...
  - As a driver, ...
  - As a/ an ...

“Want to”: Trả lời câu hỏi chúng ta đang mô tả ý định của end-user muốn làm cái gì? Chúng ta xây dựng feature này để đạt được điều gì, có thực sự hướng đến mục tiêu của người dùng chưa?
- Ví dụ:
  - I want to link my credit card to my profile, ...
  - I want to add photos of my car in my profile, ...
  - I want to ..., ...

“So that”: Vấn đề lớn được giải quyết là gì?
- Ví dụ:
  - So that I can pay for a ride faster and easier without cash.
  - So that I can attract more users.
  - So that I can...

Acceptance Criteria (AC): Có nhiều cách để viết AC, chúng ta có thể viết dưới dạng checklist hoặc viết dưới dạng scenario,... Bên dưới là ví dụ cho dạng checklist:
- User story: As a passenger, I want to link my credit card to my profile, so that I can pay for a ride faster and easier without cash.
  - AC1: Verify card information
  - AC2: Identify cardholder’s information
  - AC3: Verify OTP
  - ...

1.3 Một cú pháp khác của User Story “Purpose + Persona + Need” (why + who + what)

Các cú pháp để viết US là không bắt buộc. Thậm chí, để hoàn thiện US nhanh và theo kịp với tiến độ của dự án, nhiều BAs đã lược bỏ phần “why” đi. Nhưng như BAC đã trình bày ở trên, nếu thiếu “why” thì đó cũng là một thiếu sót lớn nhất của tác giả làm US, đó cũng như thiếu đi giá trị cung cấp cho khách hàng.

Vậy nên, về sau này đã xuất hiện thêm phong cách viết “why” (purpose) lên trước, và thay cụm từ “so than I can…” bằng “In order to…”.

In order to [derive a benefit], <— why
As a [persona], <— who
I want to [do something], <— what

Thêm nữa, khi nói đến “US” sẽ thường bao gồm 2 ý nghĩa: 1 - cú pháp story (như trên), và 2 - requirement item. Từ đó ta thấy rằng, một epic hay feature cũng có thể tuân thủ cấu trúc story, nhưng quy mô & phạm vi epic cao hơn feature, và feature cao hơn US.

2. Tại sao phải phân tách User Story?

Khi xây dựng một backlog cho dự án, các BAs sẽ bắt đầu phân tích, phát triển và liệt kê lần lượt các epics, features, và US. Tại thời điểm ban đầu, không dễ để có thể xác định rõ ngay scope (phạm vi/ giới hạn) của một US đã đủ nhỏ hay chưa (scope được xác định có thể phát triển được hay không trong phạm vi một sprint).

Nếu như bạn chưa thể xác định ngay được scope đã đủ nhỏ hay chưa thì các bạn hãy thử hình dung:

Tình huống là bạn viết một US-US01 và phân tích được 4 Acceptance Criteria, từ AC01 đến AC04. Bằng cách thông thường, bạn giải thích cho nhóm phát triển và đưa US01 vào Sprint sắp phát triển (Sprint 2), và tất nhiên đây không phải là US duy nhất.

Trước khi Sprint 2 khởi động, các bạn sẽ thực hiện đo lường và lên kế hoạch xem mọi thứ vẫn nằm trong tầm kiểm soát hay không.
Khi Sprint 2 đã tiến hành được 1 tuần, việc hoàn thành các AC bắt đầu gặp khó khăn.
Sang tuần thứ 2, cả nhóm vẫn cố gắng để hoàn thành hết tất cả các ACs.
Đến cuối Sprint 2, khi chuẩn bị demo và Sprint review thì có rắc rối rằng còn 2 AC chưa hoàn thành, có thể do code chưa xong hoặc còn nhiều bugs.
Vậy nên, cả nhóm chỉ có thể demo US01 chỉ với 2 AC.
Trong buổi lên kế hoạch cho Sprint 3, cả team thống nhất chuyển 2 AC còn lại sang Sprint 3. Điều này tức là tách US01 thành 2 phần:

US01.1 với 2 AC đã hoàn thành cho Sprint 2, và
US01.2 gồm 2 AC đang đợi hoàn thành cho Sprint 3.

Ngày qua ngày, các Sprint trong Scrum cứ chạy theo hướng đó, làm cho product backlog của cả nhóm ngày càng dài ra và nhiều lên.

Các kế hoạch trên có nghĩa là chúng ta đang xử lý scope và thực thi phân tách các story tốt hơn và hiệu quả hơn.

3. Phân tách User Story như thế nào?

Dưới đây là 6 cách để phân tách một US. Khi phân tích các story và đưa vào Sprint, chúng ta cần tách thành các story nhỏ hơn, hoặc chia AC thành các AC nhỏ hơn. Chia nhỏ tới mức nào không thể nhỏ hơn nữa là được. Lưu rằng rằng sẽ chia nhỏ chứ không phải cắt vụn story ra. Dùng cách này chưa được thì dùng tiếp cách khác. Một điểm nhận diện đó là story không nên có quá nhiều AC (< 10), cũng như một epic không nên quá nhiều story (khoảng từ 10-15).

Cách 1: Phân tách theo workflow

Một workflow có nhiều bước, thay vì gộp là một story, thì chúng ta tách ra mỗi bước một US.

Thay vì viết:

As a customer, I want several available drivers to be displayed, so that I can choose the most suitable option for me.

Nên là:

As a customer, I want to…

... locate nearby drivers
... see driver reviews
… choose one driver
... wait for the driver’s acceptance
(... continue to choose another driver)

Cách 2: Phân tách theo Data Details

Trên một màn hình có nhiều trường dữ liệu để end-user phải nhập vào, có thể tách thành từng nhóm dữ liệu liên quan, mỗi nhóm một US.

Thay vì viết:

As a student, I want to view my grades for this semester’s courses, so that I can see how I’m performing.

Nên viết:

As a student, I want to view…

... my numeric grade for this semester’s courses, so that I can quantify my performance.
... my letter grade for this semester’s courses, so that I can calculate my GPA easily
... the class average for this semester’s courses, so that I understand my relative performance.

Cách 3: Phân tách theo Happy Path, Unhappy Paths

Một US nhiều khi chỉ tập trung vào sự thành công của luồng đi (còn gọi là happy path, happy case, basic, main flow), các BAs thường quên mất các luồng khác như alternative flow, unhappy case/ exception flow. Các luồng phụ (corner cases) cũng có thể trong các story khác nhau.

Thay vì viết:

As a Grab customer, I want to view information about my booked taxi, so that I can track its movement.

Nên viết:

As a Grab customer, I want to view information about…

… an on-time ride, so that I can track its movement
… a delayed ride, so that I can track its movement
… a cancelled ride, so that I can re-book another one..

Cách 4: Phân tách theo phần Cơ bản (Core) và phần Nâng cấp (Enhance)

Tập trung phần chính & đủ đơn giản trước, như một chức năng tìm kiếm với các tham số ngầm định, và tách các phần nâng cấp thành các US, như chức năng tìm kiếm với nhiều bộ lọc khác nhau.

Thay vì viết:

As a Salesforce user, I want to create revenue, profit, and growth reports, so that I can perform monthly forecasting.

Nên viết:

As a Salesforce user, I want...

... to create a revenue report for a month, so that I can view the revenue generated in that month
... to create revenue, profit, and growth reports for all months, so that I can perform forecasting for the next month.

Cách 5: Phân tách theo quy tắc nghiệp vụ (business rules) / chính sách sản phẩm (policies)

Chia theo mỗi quy tắc nghiệp vụ / quy định / chính sách sản phẩm là một story. Quy tắc nào quan trọng về nghiệp vụ và có ảnh hưởng lớn thì đưa lên trước, ưu tiên cao hơn.

Thay vì viết:

As a customer, I want to purchase the goods in my shopping basket so that I can receive my products at home.

As a shop owner, I want to track & control the orders submitted from the customer in my store, so that I'm aware of what the status of the order is.

Nên viết:

As a shop owner, I want to…

… decline orders below 10 dollars, because I don't make any profit on them;
… decline customers from outside the US, because the shipping expenses make these orders unprofitable;
… reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
… automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers;

Cách 6: Phân tách theo các chức năng quản lý / bảo trì / vận hành (operations)

Mỗi hoạt động trong quản lý / bảo trì / vận hành là một US.

Thay vì viết:

As a shop owner, I want to manage products in my online shop, so I can update price and product information if it is changed.

Nên viết:

As a shop owner, I want to…

… add new products, so customers can purchase them;
… update existing products, so I can adjust for changes in pricing or product information;
…delete products, so I can remove products that I no longer stock;
…hide products, so they cannot be sold for the time being;

Trên đây lầ các thông tin cơ bản và khá đầy đủ liên quan đến nội dung về US. BAC hy vọng sẽ có ích cho các bạn. Bên cạnh đó, nếu bạn muốn tìm hiểu thêm thông tin về các tác vụ và chuẩn chỉnh nghiệp vụ của một BA, bạn có thể tham khảo thêm các khoá học tại BAC:

Trung tâm BAC - Sân chơi lành mạnh để các bạn đam mê về công nghệ thông tin nói chung và nghề BA nói riêng cùng nhau tìm hiểu và khám phá những điều thú vị về nghề, qua đó chuẩn bị một số kiến thức chuyên môn cho công việc trong tương lai.

Để tham khảo và đăng ký các khoá học trong tháng, bạn có thể click vào đây: Check lịch khai giảng. Nếu cần tư vấn hỗ trợ những vấn đề liên quan đến khóa học, bộ phận CSKH của chúng tôi sẽ hỗ trợ bạn qua Email: info@bacs.vn ; bac.trainingba@gmail.com hoặc số Hotline: 0909310768.

Nguồn tham khảo: Thái Sơn - BAC

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất

Ban biên tập nội dung - BAC

Click để đọc tiếp

Mục đích chính của phân tích dữ liệu là gì? Ứng dụng thực tế trong công việc

Mục đích chính của phân tích dữ liệu là gì và làm thế nào để ứng dụng trong công việc là những câu hỏi thường gặp. BAC sẽ giúp bạn tổng hợp những kiến thức nền tảng thông qua các ví dụ thực tế, gần gũi.
Bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án

Bạn muốn tìm bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án? Bạn là người mới và chưa biết phải bắt đầu từ đâu? Hãy để BAC giúp bạn thông qua hướng dẫn chi tiết ở đây.
Dữ liệu thứ cấp là gì? phương pháp phân tích dữ liệu thứ cấp là gì?

Nếu bạn đang tìm hiểu về phân tích dữ liệu và gặp khái niệm dữ liệu thứ cấp thì đây là bài viết dành cho bạn. BAC sẽ giúp bạn tìm hiểu tất cả thông tin như định nghĩa, đặc điểm, ưu và nhược điểm cũng như những phương pháp phân tích.
Business Analyst thời đại AI: Cơ hội, thách thức và kỹ năng cần có để không bị thay thế

Trí tuệ nhân tạo (AI) đang thay đổi mạnh mẽ ngành phát triển phần mềm, ảnh hưởng trực tiếp đến vai trò của Business Analyst (BA). Bài viết phân tích BA cần làm gì để thích nghi, nâng cấp kỹ năng và đón đầu các cơ hội trong thời đại AI.

Bình luận

Lê Anh Tuấn

Chuyên viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi là nhân sự thuộc Trung tâm Phát triển CNTT – Khối Ngân hàng số, hiện đang đảm nhiệm vai trò kiểm thử phần mềm (tester). Việc tham gia khóa học Business Analyst đã mang lại cho tôi góc nhìn toàn diện và rõ ràng hơn về vai trò của BA trong lĩnh vực ngân hàng.

Khóa học Fundamental Business Analysis tại BAC không chỉ giúp tôi hiểu đúng bản chất công việc BA mà còn hỗ trợ phát triển tư duy nghiệp vụ – từ tiếp cận giải pháp kỹ thuật sang tập trung vào nhu cầu người dùng. Phương pháp giảng dạy kết hợp lý thuyết và thực hành thực tiễn, cùng các hoạt động mô phỏng, thảo luận nhóm đã giúp tôi nâng cao kỹ năng giao tiếp, phân tích và trình bày yêu cầu – những năng lực thiết yếu để phối hợp hiệu quả giữa các bên trong dự án công nghệ.

Xem chi tiết +
Huỳnh Cao Cường

Nhân viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi hiện đang công tác tại Trung tâm Phát triển CNTT – Khối CNTT, với vai trò là nhân sự chức năng phụ trách mảng Ngân hàng số, chuyên sâu về kiểm thử phần mềm (Tester). Trước khi tham gia khóa học Fundamental Business Analysis do BAC tổ chức, tôi từng hình dung BA chỉ đơn thuần là cầu nối giữa bộ phận kỹ thuật và nghiệp vụ.

Tuy nhiên, quá trình học đã giúp tôi nhận thức rõ hơn về bản chất và tầm quan trọng của vị trí này. BA không chỉ kết nối các bên liên quan, mà còn giữ vai trò định hình yêu cầu, đảm bảo giải pháp được thiết kế đúng mục tiêu và sát với nhu cầu thực tế. Khóa học đã trang bị cho tôi tư duy phân tích bài bản, khả năng diễn đạt yêu cầu rõ ràng, và kỹ năng phối hợp hiệu quả trong môi trường dự án đa chiều.

Với nền tảng công nghệ thông tin sẵn có, khóa học là bước chuyển hướng quan trọng giúp tôi phát triển tư duy nghiệp vụ vững chắc và sẵn sàng theo đuổi lộ trình nghề nghiệp chuyên sâu trong lĩnh vực Business Analysis tại Eximbank.

Xem chi tiết +
Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +

Professional Transfer Services in Batumi

Luxury Georgian Transfer Services – Tbilisi & Batumi

Airport Transfers in Georgia

1.2 Phân rã cú pháp:

1.3 Một cú pháp khác của User Story “Purpose + Persona + Need” (why + who + what)

2. Tại sao phải phân tách User Story?

3. Phân tách User Story như thế nào?

Nhu cầu đào tạo doanh nghiệp

Mục đích chính của phân tích dữ liệu là gì? Ứng dụng thực tế trong công việc

Bài tập phân tích dữ liệu trong kinh doanh cho người mới bắt đầu có đáp án

Dữ liệu thứ cấp là gì? phương pháp phân tích dữ liệu thứ cấp là gì?

Business Analyst thời đại AI: Cơ hội, thách thức và kỹ năng cần có để không bị thay thế

CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN BAC