Userstory và UseCase. Cách viết Userstory / Acceptance Criteria ( Part 1 )

BrSE Jun 29, 2021

Hiện nay mô hình agile đang được áp dụng ở nhiều công ty nhiều quốc gia, không đơn thuần chỉ trong ngành IT mà còn được áp dụng cách quản lý cuộc sống thường ngày.
Vậy để ứng với cách triển khai mô hình agile cũng sẽ có nhiều thứ phải thay đổi trong quá trình thực thực hiện. Một trong số đó là cách viết tài liệu.
Chắc hẳn nói đến đây mọi người sẽ nghĩ ngay đến hai phương pháp được nhiều người biết đến nhất là Userstory UseCase.
Userstory được ưa chuộng hơn trong các dự án Agile so với Usecase. Đồng thời Usecase được sử dụng khá phổ biến trong những dự án Waterfall. Vậy lý do ở đây là gì.

Userstory :
Bằng cách sử dụng những ngôn ngữ hết sức đời thường mô tả lại nhu cầu của người dùng một cách đơn giản không quá chi tiết. Tại sao lại vậy, vì mô hình agile đề cao sự tương tác giữa các thành viên trong một nhóm. Nên người viết hoàn toàn có thời gian để dành cho việc giải thích với các dev.

UseCase :
Cũng có vài điểm gần giống như một User Story nhưng nó sẽ mô tả cách tương tác giữa người dùng và phần mềm. Đồng thời nó sẽ mô tả đầy đủ và chi tiết về tất cả những trường hợp mà người dùng sử dụng phần mềm sẽ gặp phải.  Và tất nhiên việc này sẽ làm  giảm bớt thời gian cho bạn dev phải tương tác với người viết yêu cầu.
----------------------

OK vậy các bạn đã hiểu sơ qua Userstory và UseCase là như thế nào rồi đúng không?
Vậy chúng ta cùng đi vào Userstory trước nhé.
Dưới đây mình xin chia sẻ cấu trúc UseStory đang rất thông dụng hiện tại.

Tiêu đề  ( Một dòng mô tả về câu chuyện của bạn )
Nội dung
As a [role]  -> Là 1 người bán hàng  
I want [feature] -> Tôi muốn quản lý những mặt hàng đang có trong kho của công ty
So that [benefit] ->  Tôi có thể biết được những mặt hàng hiện đang có của công ty mà không cần phải ra kho.

Tuy nhiên nếu chỉ viết như thế này thôi nội dung miêu tả rất chung chung. Và không có những rằng buộc nhất định. Khi này chúng ta thêm vào các tiêu chí để người dùng có thể chấp nhận được. Người ta gọi các tiêu chí đó = thuật ngữ
Acceptance criteria.

Vậy Acceptance criteria có ý nghĩa như thế nào trong US:
Nó đảm bảo cho việc :
-  Team phát triển lẫn khách hàng nắm được chức năng đang phát triển là gì.
- Dễ dàng covert các userstory thành các task nhỏ hơn để estimate
- Dễ dàng cho việc test

Và Acceptance criteria hiện có 3 phương pháp :
Scenario-oriented (Given/When/Then)
-> Theo hướng kịch bản ( Điều kiện ban đầu/ Khi làm gì / Sau đó cái gì xảy ra )
Rule-oriented (checklist)
-> Đưa ra các qui tắc để checklist
Custom formats
-> Format theo tuỳ chỉnh

Rồi đến đây mình sẽ đi vào từng phương pháp:
1/. Theo hướng kịch bản :  Đơn giản thôi các bạn cứ tưởng tượng ra các kịch bản có thể xảy ra như thế nào khi chủ thể hành động là bạn. Rồi chúng ta hãy cùng nhìn vào mô tả ( template ) dưới đây:
Scenario : Tên một hành động sẽ được mô tả trong Acceptance criteria
Given : Điểm đầu tiên khi start của scenario
When : Kết quả của hành động trước
And: Phần liên kết với 3 phần trước.

Để hiểu rõ hơn các bạn có thể bắt đầu với ví dụ như sau :

( cái này mình sử dụng luôn với hệ thống hiện tại mình đang phát triển liên quan đến Livestream  có tên FM )
Userstory : Là 1 Guest, tôi muốn mình có thể Sign up vào hệ thống FM 1 cách nhanh chóng = Google account của tôi.


Scenario #1 : Sign up thành công với Google account
Given: Guest sẽ được đưa đến trang Sign Úp
When : Guest clicks vào button " Sign up with Google account "
Then : Web view Google Sign Up mở ra
Then : Guest enters thông tin đăng nhập tài khoản hợp lệ
Then : Profile được tạo với email lấy ra từ tài khoản Google
And : Guest được đưa đến trang đã hoàn thành việc đăng ký

Lưu ý:
 •  Then cũng có thể có 1 hoặc nhiều
 •  Bạn có thể sử dụng Tôi ở đây thay cho Guest ( nhưng mình muốn nhấn mạnh vào role nên để luôn là Guest )
 • Bạn viết ngôn ngữ càng đời thường càng tốt
 • Chỉ nên sử dụng 1 động từ
 • Cấu trúc ngữ pháp nên đơn giản

Ok! Vậy bạn đã hiểu rồi đúng không nào. Bây giờ chúng ta cùng tiếp tục vs Scenario số #2

Scenario #2 :
Given : Guest sẽ được đưa đến trang Sign Úp
When : Guest clicks vào button " Sign up with Google account "
Then : Web view Google Sign Up mở ra
Then : Guest enters thông tin đăng nhập tài khoản hợp lệ
Then : Account được nhận diện đã tồn tại trong database
And : Guest nhìn thấy lỗi là " Tài khoản này đã tồn tại "

-> Bạn có càng nhiều các Scenario thì càng dễ dàng cho việc test cũng như các bạn dev có thể suy ra được các điều kiện để đưa vào code :D
Mình thấy mấy ông chồng hay bảo các bà vợ là tại sao phụ nữ các cô hay suy diễn thế. Có lẽ sự suy diễn của các bà vợ mà đưa vào các Scenario thì chỉ có chuẩn ko cần chỉnh =))

Bài viết Part 1 về Userstory mình xin dừng lại ở cách viết Scenario cho Acceptance Criteria. Hẹn Part 2 sẽ đề cập đến hai phần còn lại của Acceptance Criteria và Part 3 là Use case.
Thanks

Tags

Huyen Truong

Life is a Game

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.