Khi bắt tay vào làm BA của 1 start up product, đây là thứ làm mình đau đầu nhất khi viết requirement cho team: Độ chi tiết của document. Agile sử dụng User Stories để communicate. Nhưng trong khi làm việc, team lại muốn một document rõ ràng để họ "không cần nghĩ" và chỉ làm. Thêm vào đó, rất nhiều người nhầm lẫn giữa User Stories và Use Case khiến cho việc phân biệt rõ ràng giữa 2 document này trong team càng thêm phức tạp. Việc hiểu rõ làm sao để viết User Stories và Use Case cho đúng sẽ là bước đầu để giúp team làm quen hơn với document trong Agile.
1/ User Stories
User stories thường được thể hiện dưới 1 đoạn text ngắn, nhằm mục tiêu mô tả cái mà User muốn đạt được khi sử dụng system của chúng ta.
Format của User Stories thường có dạng
As a <who>, I want <what> so that <why>.
Ví dụ, feature login:
As an system administrator, I want to login to the admin site so that I can see all the activities of my websites which normal User can't see.
Lợi điểm của User story là nó giúp team hiểu được benefit của feature mà họ, sau khi implement xong sẽ đem lại cho end user, thay vì là làm thế nào để làm ra nó. Đó sẽ là tiền đề mấu chốt để bạn discuss về việc "Có nên làm feature này không?" hay "Nên làm feature này như thế nào?" sau này.
Tuy nhiên, như đã nói, dòng text ấy chỉ giúp team hiểu được ý tưởng và lợi ích của feature, chúng ta gọi đó là Card, vì nó thường được viết trên card. User story bao gồm:
- Card: (Như đã nói ở trên)
- Conversation: Product Owner, trong Sprint planning sẽ đem card ra và giải thích về nó. Team cũng sẽ đặc những câu hỏi xoay quan feature để giúp họ hiểu hơn về feature. Bao gồm cả việc User và system sẽ tương tác như thế nào với nhau? Gồm những form gì? Làm thế nào để làm ra nó? Và phân chia công việc giữa Front End và back End. Ở Agile process, đây chính là lúc quan trọng nhất, để giúp team chia sẽ thông tin và không máy móc khi implement.
- Acceptant criteria: Mô tả những điểm mấu chốt của feature, dể chắc chắn rằng chỉ khi nào những điểm này được thỏa mãn, thì User Story mới được gọi là hoàn thành. Đây chính là lúc mà team discuss về BDD check list (Nếu team bạn có dùng BDD).
2/ Cách viết acceptant criteria
Một trong những cách phổ biến nhất là BDD - Behavior Driven Development. Nó có format như sau:
Given .... When .... Then ....
Ở trong Sprint planning, detail về input có thể được bỏ qua. Nhưng thường là sau dó, QC và Developer sẽ thống nhất để chỉ rõ input và output data của 1 BDD note, và xa hơn nữa là biến nó thành Automation test case nếu cần.
Về mặt bản chất, Acceptance criteria chính là những Use Case quan trọng của hệ thống, được đơn giản hóa bằng cách ít đi vào chi tiết hệ thống hoạt động mà chỉ focus vào việc hệ thống sẽ cho ra output gì với những hành động của User
Ví dụ cho feature Admin login:
1/ Valid credential, User can login
Given user navigate to adminexample.com
Given user haven't logged in
When user input [email protected] into email form
And when user input 123456 into password form
And when user click Login
Then system navigate User to Admin Home page
And then system show message on top of Home page "Success Login"
2/ Invalid email format, User cannot login
Given user navigate to adminexample.com
Given user haven't logged in
When user input nguyenduonghai_wrong into email form
And when user input 123456 into password form
And when user click Login
And then system show error message at the bottom of Login form "error Login"
And then system clear ALL data of email and password form
And then system increase the count of Login_fail by 1.
.....
Hãy lưu ý rằng, bạn chỉ cần ghi những Acceptant case mà bạn cho là quan trọng, nhất định phải có trong User story.
Tuy nhiên, BDD viết theo cách này vẫn chưa phải là rõ ràng nhất cho Developer. Nhưng đây là level mà 1 BA có thể chạm tới. Để biết thêm chi tiết rằng Development team sau khi nhận BDD của BA sẽ chuyển nó thành 1 checklist tốt hơn như thế nào, xin hãy xem topic này .
3/ Use Case
Trước tiên, mình phải nói rằng, Use case ở dây có rất nhiều level. Một bài viết khác sẽ cho giới thiệu bạn Use case ở mức đơn giản nhất. Ở đây, chúng ta sẽ nói về một Use Case diagram chi tiết hơn
Use case, thực chất là 1 document dùng nhiều trong waterfall process. Nó cũng mô tả về feature, nhưng focus chủ yếu vào việc End User sẽ tương tác với system thế nào để đạt được cái benefit mà User Story đã nêu. Hãy nhìn hình dưới đây:
Nó cho ta thấy độ khác nhau về chi tiết của User Story và Use Case. Bạn có thể thấy Use case sẽ có những điểm cần phải được đề cập:
- Preconditions: Điều kiện gì để Use Case có thể thực hiện:
Ví dụ: với use case Login, để có thể xảy ra, điều kiện ban đầu là User chưa Login vào hệ thống.
- Behavior/Events: Step by step, có trình tự mô tả cách User tương tác với hệ thống.
- Alternative paths: tại 1 step nhất định, User có thể có nhiều lựa chọn khác nhau dẫn đến system sẽ có những behavior khác nhau.
- Failure conditions: mô tả những trường hợp nhất định mà User trong trường hợp này sẽ không đạt được cái mà muốn khi được mô tả trong user story
Ví dụ, với User story login, sẽ có những trường hợp User login fail. Và đó là trường hợp mà User 'không mong muốn', vì chẳng ai vào system để login fail cả. Tuy nhiên, nó không phải là edge case, mà nó là 1 case cần thiết và quan trọng của system
- Post condition:
Thể hiện Use Case trong Agile
Việc viết ra document chi tiết trong Agile là điều nên tránh. Agile chú trọng vào communication thay vì document. Đó là lý do vì sao trong Agile người ta khuyến khích bạn dùng User Story ( Đi kèm là BDD check note). Tuy nhiên, nếu team bạn chưa strong về communication, gặp 1 feature khó, và cần có 1 document để track lại requirement, mình xin để nghị bạn sử dụng chart.
- Sử dụng flow chart cho những trường hợp Use case không quá phức tạp. Mình khuyến khích các bạn tạo ra những diagram này đi cùng với User Story
Ví dụ:
Bạn có thể thấy với Diagram này, nó cho ta thấy rõ trình tự hoạt động và logic của feature login
Tuy nhiên, với cách vẽ này bạn không thể hiện được đâu là action của User, đâu là action của System. Đây sẽ là một vấn đề khi bạn có nhiều actor liên quan 1 feature và có nhiều system tương tác với nhau. Với system đơn giản, mình khuyến khích bạn dùng Flow chart ở trên.
- Với 1 feature mà có nhiều User và nhiều phần của system tham gia vào hệ thống, mình khuyên bạn nên dùng Process Flow Diagrams
Ví dụ:
Một ví dụ khác, nói về booking car flow
Bạn có thể thấy, với Diagram như trên:
- Bạn có thể thấy được rất rõ sự tương tác giữa những User và những System khác nhau.
- Failure condition, preconditions, Events, steps, Process được mô tả rất rõ
Chỉ nên spend time để làm ra những document và Diagram này khi feature này thực sự quan trọng và team bạn đang có vấn đề về communication dựa trên User Stories.
Lời kết
Viết document, đặc biệt là cho Agile team làm việc là một công việc đòi hỏi sự linh hoạt rất cao. Quá chi tiết sẽ làm chậm team và quá thiếu sẽ làm team khó tiếp tục công việc Development. Tùy vào feature, vào team, bạn nên có những cách document phù hợp. Chúc các bạn thành công.
Author: Nguyen Duong Hai