1. User Story
User Story chắc cũng quá quen thuộc với mọi người rồi, nôm na nó có dạng:
Một vài ví dụ cho mọi người dễ hình dung:
- As a rider, I want to choose my favorite driver, so that I feel enjoyable and safe in my ride
- As a system admin, I want to configure recruitment criteria, so that I can control recruitment quality
- As an engineer, I want to scan the Barcode of the laptop, so that I can enter data more accurately and faster
- As a reader, I want to cancel my subscription at any time, so that I do not lose money unintentionally
Căn bản thì User Story không khác gì User Requirement. Nhưng so với User Requirement, thì User Story được gói gọn trong một tính năng rõ ràng mà người dùng cần. Đâu đó nó mang lại cảm giác gọn gàng, có tổ chức và dễ quản lý hơn rất nhiều. Đặc biệt trong những dự án có tính biến động cao.
Tuy nhiên cũng có vài lưu ý cho mọi người khi viết User Story.
1.1. <User> là người
<User> ở đây nên là NGƯỜI thực tế. Khác với Use Case, Actor có thể là Human hoặc System. Nhưng <user> trong User Story phải là người.
Vì sao lại như vậy?
Vì tiếp cận theo hướng User Story, là mọi người đang setup mindset: lấy người dùng ra làm gốc. Các giải pháp đưa ra đều nhằm mục đích giải quyết vấn đề của người dùng, chứ không chỉ đơn thuần là làm tính năng cho system.
Cụm từ “giải quyết gốc rễ vấn đề của user” nó khác hoàn toàn cụm “làm tính năng cho system”.
Làm cho system có tính năng đó, không có nghĩa là đã giải quyết được triệt để vấn đề của user. Mà chỉ khi mình suy nghĩ và phân tích tới tận cùng cái pain-point mà user đang gặp phải, thì khi đó mình mới đủ mường tượng được tính năng này có giải quyết được pain-point đó hay không.
Nó là cách suy nghĩ “user-oriented”. Là cái mà mọi người nên lưu tâm khi phân tích bất cứ tính năng nào.
Nhiều lúc cứ nghĩ: tính năng này đã ổn áp, đã giúp giải quyết vấn đề của user rồi. Nhưng khi deliver ra, tận tay test, tận tay trải nghiệm thì mới thấy có gì đó lấn cấn, cợn cợn mà khó có thể giải thích được.
Nên nếu từ đầu không đặt mình vào tâm thế của User, thì rất khó để hiểu và giải quyết vấn đề một cách hoàn chỉnh được. Nên ngay từ đề bài, User Story cần phải có “yếu tố con người” trong đó. Nếu không thường xuyên đặt mình vào tâm thế của End-User, thì chắc lỗi lầm phải lặp lại cả sớ dài.
Do đó, mục đích của viết User Story là để mọi người hình dung tường tận vấn đề. Và luôn nhắc nhở mình phải “mang đôi giày” của chính end-user.
1.2. Viết dạng chủ động & tránh mang hình ảnh “system” vào
Đây cũng là 1 cái mẹo khá hay khi viết thì phải viết theo hướng chủ động: là user chủ động, user cần cái này, cái kia, là một nhu cầu có thật, khẩn thiết, và cần mình giúp họ giải quyết vấn đề này. Nghe nó thôi thúc và tích cực hơn rất nhiều
Còn tránh mang hình ảnh “system” vào là sao? Là mình chỉ nói theo ngôn ngữ của user: User cần gì mà thôi. Chứ không nói theo ngôn ngữ System có thể offer được gì cho user.
“System offer được gì cho user” là Solution Space.
Còn nói theo “User cần gì” là Problem Space.
Mình viết User Story thì chỉ nói trên Problem Space, đưa ra bài toán cần giải quyết rằng: tui đang bị zầy nè & tui đang muốn cái này. Mình không cần, không cần & không cần đưa ra solution chi tiết ở đây.
Hai lỗi này thường đi chung 1 cặp với nhau:
- US ổn áp: “Là nhà tuyển dụng, tôi muốn nhận thông báo về lịch hẹn phỏng vấn trước 2 ngày, để tôi có thời gian chuẩn bị phỏng vấn”
(thông báo có thể qua email, SMS, zalo, in-app…, khi vào sâu phân tích sẽ biết thông báo qua đâu là tối ưu) - US cần tránh: “Là nhà tuyển dụng, tôi muốn hệ thống bắn noti trên app về lịch phỏng vấn trước 2 ngày, để tôi có thời gian chuẩn bị phỏng vấn”
(Lỗi 1: Chưa gì đã muốn nhận thông báo trên app, trong khi chưa chắc đây đã là phương án tối ưu khi chưa qua phân tích.
Lỗi 2: Nói theo góc nhìn “system offer được gì” – cái cụm “hệ thống thông báo trên app” vô hình dung đã khóa cái đầu mình lại, không nghĩ thoáng ra được. Nếu lỡ system này củ chuối, không thể gửi thông báo trên app thì sao?!?!
Nên mình chỉ cần tập trung vào Problem Space thôi .
1.3. Benefit không nhất thiết chỉ hướng tới User
“As a” <user> thì không nhất thiết “so that” phải là <benefit của user>
Nghĩ thoáng ra một chút thì benefit anh em có thể ghi bất cứ thứ gì, miễn:
- Nó là benefit thật sự (để cung cấp được chính xác context của requirement này)
- Và nó có thể là benefit của end-user hoặc là benefit của customer
Ví dụ: Mình đang làm 1 cái app giúp các kỹ sư tìm đường tới tận nhà của khách hàng để sửa & thay thế linh kiện laptop theo các booking.
Sau khi hoàn tất công việc, anh kỹ sư có thể nhấn 1 nút để gửi thông tin thanh toán qua Momo cho khách hàng. Để khách hàng tiện lợi thanh toán hơn. Tránh phải lui cui lấy đủ tiền mặt ra thanh toán ngay lúc đó, rồi thối tiền tới lui mắc công.
Như vậy thì với Requirement mới này, mình sẽ viết dưới dạng User Story như sau: As an engineer, I want to share payment information via Momo to customers, so that THEY can pay more conveniently.
Benefit ở đây là benefit của khách hàng, chứ không nhất thiết phải là benefit của anh engineer (là user)
1.4. Không phải lúc nào cũng áp dụng format
Một ý nữa là không phải lúc nào mình cũng răm rắp làm theo: As ABC, I want XYZ, so that 123 blah blah…. Với vài thứ đơn giản thì chỉ cần ghi huỵch toẹt nó ra là được.
Ví dụ Apple vừa ra mắt iOS 15, theo đó là app mình cũng cần phải check impact và nâng cấp để có thể work tốt với iOS 15. Đây là một yêu cầu mới toanh. Nếu viết Requirement theo format User Story thì sẽ như sau:
“As a user, I want my app work smoothly on iOS 15, so that I…..không bị bug khi sử dụng hả” ? (thiệt mình cũng không biết ghi chỗ này sao…)
Gác format qua 1 bên. Câu trên được diễn giải gọn gàng – súc tích bằng đúng 1 dòng: “Check impact & upgrade app to iOS 15”. Bùmmmmm, xong, ez game!!!
Vì sao?
- Vì ngữ cảnh này đơn giản, quá dễ hiểu đúng không.
- Requirement này cũng rất hiển nhiên và chẳng có gì lạ lẫm (mình cũng làm i chang như khi upgrade từ iOS 13 lên iOS 14 vậy)
Do đó, sẽ có những requirement tương tự – khá là rõ ràng & hiển nhiên. Thì khi đó mọi người hãy cân nhắc nên viết sao cho tối ưu nhé. Linh hoạt là chia khóa, đừng lúc nào cũng khư khư theo template, theo format. Nếu không thì…
1.5. Ai viết User Story
Nếu dự án chạy theo SCRUM hoặc các framework tương tự thì Product Owner sẽ là người viết. Product Owner có thể đến từ các bộ phận Business hoặc IT.
Còn nếu không có Product Owner, thì BA sẽ là người viết User Story. Và cũng từ User Story đó, BA cùng team sẽ phân tích & thiết kế giải pháp tương ứng về sau.
Nếu phần này trả lời cho các câu hỏi Who, What, Why, thì phần dưới đây sẽ trả lời cho How. Đó là Acceptance Criteria.
2. Acceptance Criteria
Phần Acceptance Criteria này tương đương với Use Case & Business Rules khi anh em viết FS kiểu truyền thống. Nhưng cách thể hiện của nó thì đơn giản hơn.
Đơn thuần mình chỉ cần: 1 cái bảng & liệt kê toàn bộ các Acceptance Criteria thuộc User Story đó là xong
Chắc mọi người sẽ có câu hỏi: Use Case thì có format, Business Rules cũng đơn thuần là note ra các rule của tính năng đó. “Vậy giờ kêu ghi Acceptance Criteria tương đương Use Case với Business Rules là ghi sao?”
Thì câu trả lời sẽ là: cứ liệt kê các Rules của User Story ra là được.
Cách tiếp cận này là mình đang làm theo hướng “rules-oriented”. Vì mình thấy đây là cách viết Acceptance Criteria một cách tự nhiên và dễ kiểm soát nhất.
Rules như thế nào thì cũng tương tự Business Rules mình có note ở 2 bài trước. Nhưng nhìn chung, Acceptance Criteria (AC) của anh em phải đảm bảo được 4 yếu tố sau đây.
2.1. Mỗi AC đều phải test được
Cái tên Acceptance Criteria đọc thôi là hiểu ngay ý nghĩa của nó đúng không anh em. Đây là những tiêu chí cần có để User Story được “accept”.
Mà ai cần “accept” User Story? Như ban đầu mình có nói thì FS dành cho 2 đối tượng đọc: phía Business & phía Tech. Vậy nên Acceptance Criteria mình cần ghi sao để cả 2 đối tượng này đều HIỂU và TEST được.
Phía Business đơn cử là những key-users, hay project cordinator.
Khi sản phẩm được release, họ sẽ dựa trên những gì mình viết ở Acceptance Criteria, để test xem thử hệ thống có chạy đúng như mô tả hông. Dĩ nhiên là trước đó họ cần agree với những gì mình viết. Để đảm bảo AC đã mô tả đúng với kỳ vọng của họ.
Còn phía Tech là những anh em QC, Dev, hay Designer.
- Dev hay Designer cần đọc Acceptance Criteria để break task và dựa vào đó để làm.
- QC thì cần đọc Acceptance Criteria để biết đường viết và chạy Test Case.
Do đó mỗi thứ được ghi ở Acceptance Criteria đều phải được LƯỢNG HÓA rõ ràng. 5 ký tự thì ghi rõ 5 ký tự. Flow đi từ A đến B như nào thì phải mô tả rõ. Hoặc có rule hay công thức tính toán phải viết thật cụ thể nhé anh em.
Tuyệt đối: không cảm thán, không định tính trong Acceptance Criteria. Như kiểu: “Màn hình claim điểm phải được làm tuyệt đẹp và đầy đủ thông tin. User chỉ cần vài ba cú nhấp chuột là đã claim thành công”.
2.2. Phải ghi RÕ RÀNG, chính xác, và dễ hình dung
Mọi người nhớ nằm lòng nguyên tắc vàng này. Viết FS kiểu Agile mà chỉ có cái User Story không thôi thì chưa bao giờ là đủ. Nó như cái mở bài vậy. Mở bài viết có khúc chiết đến cỡ nào. Mà thân bài nó dài lê thê thì cũng không ổn.
Acceptance Criteria chính là thân bài. Nó nó cái ruột, là cái bo đỳ của cả FS. Nên bằng mọi cách, phải giữ cho nó đơn giản và dễ hiểu nhất có thể. Để ai cũng có thể tiếp cận
2.3. Không mô tả chi tiết về technical
Dĩ nhiên rồi, vì FS còn có cả business users đọc nữa, nên “keep it as simple as possible”. Thường mình thấy điểm này hay gặp ở các anh em trước làm Dev xong chuyển qua BA. Nên đôi phần nhìn vấn đề sẽ hơi thiên về lăng kính technical.
Điểm này mình nghĩ cũng không quá to tát. Chỉ cần khách hàng hay mọi người góp ý, rồi thay đổi dần là được.
2.4. Ai là người viết Acceptance Criteria
Câu trả lời là team dự án nhé anh em. Cụ thể hơn là BA, BA sẽ là người “đứng mũi chịu sào” viết Acceptance Criteria.
Có vài anh em hay nhầm lẫn là Product Owner là người viết Acceptance Criteria. Ý này vừa đúng, vừa không.
- Nếu project chạy theo SCRUM (hoặc các framework tương đương) định nghĩa được role Product Owner rõ ràng. Và cái anh PO này work được với Development Team. Thì khi đó Product Owner mới là người viết Acceptance Criteria và chịu trách nhiệm sau cùng.
- Các trường hợp còn lại (prj không hoàn toàn áp dụng SCRUM, hay Waterfall triệt để) mà có role BA, thì anh BA này phải là người làm Acceptance Criteria.
Sau cùng, PO hay BA thì cũng chỉ là title. Câu chốt đơn để mọi người hình dung rõ nhất là: Người làm-công-việc-Business-Analyst sẽ là người chịu trách nhiệm cho Acceptance Criteria.
Nhưng rõ ràng BA không phải là người duy nhất được viết Acceptance Criteria. Mà là cả Development Team phải cùng trao đổi và đưa ra ý kiến để input vào AC.
Bắt đầu 1 quan điểm, BA sẽ trình bày và khơi mào thảo luận cho mọi người.
Dev có thể bàn về cách làm. Các technical spike có thể gặp phải. Nói về system performance, scalable,…. và hàng ti tỉ thứ khác có thể được đem ra mổ xẻ. Còn QC sẽ share góc nhìn về logic hay các góc khuất nhìn từ khía cạnh testing.
Từ đó, gom góp lại toàn bộ, Business Analyst sẽ là người đóng gói cuối cùng và đưa lên FS dạng Acceptance Criteria. Cứ vậy triển cho từng User Story một.
Như vậy mọi người có thể thấy:
- Cả Development Team (bao gồm cả BA) là người RESPONSIBLE cho việt làm Acceptance Criteria
- Nhưng BA lại là người ACCOUNTABLE cho Acceptance Criteria.
Mọi người tham khảo thêm mô hình RACI nhé
Và ý cuối cùng là anh em nên chia Acceptance Criteria theo từng tính năng nhỏ có trong User Story. Rồi viết theo từng mục như đã chia. Làm như vầy, mình sẽ dễ hình dung từng vấn đề một. Đảm bảo các khía cạnh đều được cover, và tránh bị sót.
Dưới đây sẽ show cho mọi người vài ví dụ tham khảo cụ thể nhé.
