Hotline

0963 801 047
APEX Global
ACADEMY FOR PROFESSIONAL EXCELLENCE

Viết User Story hiệu quả

2016-06-17  (7395)

User Story là một cách đơn giản để thu thập yêu cầu của người dùng phục vụ cho dự án Agile. User Story xuất phát từ XP (Extreme Programing) và là một lựa chọn để áp dụng cho bất kỳ phương pháp phát triển nào theo hướng Agile.

User Story là một mệnh đề đơn giản về nhu cầu của người dùng đối với chức năng cần có của phần mềm, nó được thể hiện bằng ngôn ngữ kinh doanh (business language) để mọi người có thể hiểu được.

Viet User Story hieu qua

User Story trọng tâm vào WHO, WHAT và WHY của một chức năng mà không chỉ ra là làm như thế nào. Như vậy, nội dung của User Story thể tránh được hiểu lầm hoặc hiểu không đầy đủ, ngoài việc làm rõ yêu cầu thì User Story còn  thển hiện luôn giá trị đối với người dùng.

Ông Ron Jeffries đã đưa ra nguyên tắc 3C để thể hiện cấu trúc của một User Story như sau

Card: Card là phần mô tả các khái niệm quan trọng về ngữ cảnh người dùng. Cấu trúc của phần card thường được thể hiện như sau:

As a [User role], i want to [goal], so i can [reason]

As a [User role]: Sản phẩm này đang viết cho ai và ai dùng nó?

i want to [goal/action]: Sản phẩm sẽ có những chức năng nào và mục tiêu của nó là gì?

so i can [reason/benefit]: Các chức năng đó mang lại giá trị gì cho người dùng và tại sao họ kỳ vọng có?

Conversion:

  • Mô tả nội dung hội thoại giữa Product Owner, khách hàng và nhóm phát triển (Development team)
  • Nội dung thường gắn liền với một vai trò cụ thể
  • Nội dung hội thoại mô tả các giá trị mà người dùng mong đợi, nội dung này có thể thay đổi tuỳ vào mức độ hiểu sâu về nghiệp vụ

Confirmation

  • Các tiêu chí hay điều kiện để Product Owner nghiệm thu User Story trước khi xem xét đến khai niệm Hoàn thành (Definition of Done)
  • Team và Product Owner sẽ dựa vào các điều kiện này để kiểm tra sản phẩm trong quá trình phát triển, và nghiệm thu lúc bàn giao
  • Các tiêu chí này được định nghĩa cho từng User Story

Nhóm làm việc Scrum phải có được những User Story có chất lượng tốt để đảm bảo dự án thành công. Hầu hết các dự án Scrum thất bại vì chất lượng của User story không tốt.

Dưới đây là một số các biểu hiện mà dự án gặp phải khi chất lượng User Story không tốt:

  • Scrum Team rất khó để lựa chọn các User Story để thực hiện trong Sprint và các yếu tốt phụ thuộc
  • Scrum Team không hiểu hết nội dung của các User story khi lên kế hoạch
  • Scrum Team ước lượng không đúng do khi làm thực tế có nhiều phát sinh không mong đợi
  • Khi Sprint kết thúc, không có giá trị nào được chuyển giao cho User
  • Product Owner không nghiệm thu sản phẩm do thiếu các yêu cầu có thể test

Để đảm bảo các User Story có chất lượng thì BillWake đã đưa ra một bộ tiêu chí INVEST để đánh giá chất lượng của một User story

IndependentĐộc lập

Một User Story cần phải độc lập với các User Story khác nhất có thể. Việc một User Story mà bị phụ thuộc vào một User Story khác sẽ khiến cho việc lên kế hoạch, đánh mức độ ưu tiên, ước lượng trở lên khó khăn. Tuy nhiên mức độ độc lập chỉ cần vừa đủ là được. Bạn có thể giảm các phụ thuộc bằng các kết hợp các User Story hoặc chia User Story ra.

Negotiable: thể thương lượng

Một User Story có thể thương lượng được. Nội dung của User Story thường mô tả ở mức độ vừa đủ mà không mô tả chi tiết cụ thể. Các nội dung khác sẽ được làm rõ thông qua các cuộc hội thoại.

Valuable: giá trị với khách hàng

Mỗi User Story bắt buộc phải có giá trị với khách hàng. Cách dễ nhất là bạn sẽ nói chuyện trực tiếp với khách hàng hoặc là yêu cầu khách hàng ghi xuống. Khi khách hàng sẽ dễ dàng viết các User Story khi khách hàng hiểu rằng nó có thể thương lượng được chứ không phải là Hợp đồng.

Estimable: Ướng lượng được

Các User Story phải cho phép các chuyên gia phát triển ước lượng, đánh mức độ ưu tiên (MoSCoW là một kỹ thuật cần ấp dụng để đánh ưu tiên) và lên kế hoạch được. Nếu một User Story quá lớn, nó cần phải được chia nhỏ ra để có thể ước lượng được, tuy nhiên cũng không nên chia quá nhỏ.

Small: Đủ nhỏ

Một User Story phải đủ nhỏ để thực hiện, thường thì nó tối đa là một người làm trong 2-3 tuần. Một User Story có độ lớn hơn khoảng thời gian đó thường có vấn đề về phạm vi và không ước lượng được.

Testable: thể kiểm thử

Chúng ta không thể phát triển thứ gì mà chúng ta không thể kiểm thử được, nếu bạn không kiểm thử được thì bạn sẽ không bao giờ biết nó hoàn thành hay chưa. Một User Story cần phải kiểm thử được để có thể xác nhận và kiểm tra kết quả.

Nói một các tổng quát thì một User Story có chất lượng khi nó độc lập với các User Story khác; chi tiết có thể được làm rõ hơn thông qua các hội thoại với người dùng; có giá trị với khách hàng; có thể ước lượng được với các thông tin vừa đủ và có thể kiểm thử với các kịch bản xác định trước.

Bạch Vân – APEX Global Corporation


APEX Global thường xuyên tổ chức khoá đào tạo về Business Analysis Professional. Bạn có thể tham khảo lịch đào tạo ở link Public Training Schedule. Hoặc đọc thêm các bài viết chuyên đề về kỹ năng nghề, kỹ năng mềm, kỹ năng quản lý, xu thế công nghệ,… liên quan đến CNTT ở link APEX Global News.

Để được tư vấn thêm về các khoá đào tạo của APEX Global, bạn hãy gọi hoặc email đến:  (+84-8) 62 718 187; info@apexglobal.com.vn