User story là gì?

User story mô tả chức năng có giá trị cho người dùng hoặc người mua hệ thống phần mềm. Nội hàm user story bao gồm ba khía cạnh:

• một mô tả bằng văn bản của user story được sử dụng để lập kế hoạch và đóng vai như một lời nhắc nhở (reminder)
• các cuộc hội thoại về user story phục vụ cho các chi tiết của user story
• các tiêu chí nghiệm thu được ghi lại và được sử dụng để xác định khi nào thì user story hoàn thành (definition of done)

Vì các user story theo truyền thống thường được viết bằng tay trên thẻ ghi chú (note card) bằng giấy, Ron Jeffries đã đặt tên cho ba khía cạnh này của user story một cách rất thú vị là “Card, Conversation, Confirmation”. Card là biểu hiện bề nổi rõ ràng nhất của user story, nhưng nó không phải là khía cạnh quan trọng nhất. Những lá bài, tức “Card”, chỉ là hình thức đại diện cho những yêu cầu của khách hàng chứ “Card” không phải giống như lập tài liệu yêu cầu. Mặc dù “Card” có thể chứa văn bản của user story, nhưng các nội dung chi tiết của user story được thể hiện thông qua các “Conversation” (cuộc hội thoại) và được ghi lại trong Confirmation (các tiêu chí nghiệm thu).

Chẳng hạn những user story mẫu cho một trang web giả tưởng, ta cứ tạm gọi tên là BigMoneyJobs website, có thể bao gồm:

• Một người dùng có thể đăng sơ yếu lý lịch của mình lên trang web.
• Một người dùng có thể tìm kiếm việc làm.
• Một công ty có thể đăng tuyển dụng mới.
• Người dùng có thể giới hạn người có thể xem sơ yếu lý lịch của mình.

Vì các user story dùng đại diện cho chức năng sẽ được người dùng thấy có ích lợi, các ví dụ sau không phải là các user story tốt đối với người dùng cho hệ thống này:

• Phần mềm sẽ được viết bằng C ++.
• Chương trình sẽ kết nối với cơ sở dữ liệu thông qua connection pool.

Ví dụ đầu tiên không phải là một user story tốt cho BigMoneyJobs vì người dùng của nó sẽ không quan tâm ngôn ngữ lập trình nào được sử dụng. Tuy nhiên, nếu đây là giao diện lập trình ứng dụng, thì người dùng hệ thống đó (bản thân là lập trình viên) rất có thể là người đã viết rằng “phần mềm sẽ được viết bằng C ++”.

User story thứ hai không phải là một user story tốt trong trường hợp này bởi vì người dùng của hệ thống này không quan tâm đến các chi tiết kỹ thuật về cách ứng dụng kết nối với cơ sở dữ liệu.

Một dự án sử dụng các user story sẽ có nhịp điệu khác với các dự án theo lối truyền thống mà bạn có thể đã quen thuộc. Sử dụng một quy trình waterfall truyền thống dẫn đến một chu trình phát triển bao gồm các chặng như viết tất cả các yêu cầu, phân tích các yêu cầu, thiết kế giải pháp, coding và cuối cùng là thử nghiệm và nghiệm thu sản phẩm trước khi release cho khách hàng. Rất thường xuyên trong quá trình truyền thống như thế này, customer và end user bắt đầu viết yêu cầu và cuối cùng chấp nhận phần mềm, nhưng end user và customer có thể gần như không có mặt trong quãng thời gian nằm giữa chặng làm yêu cầu và chặng nghiệm thu. Đến nay, chúng ta đã biết rằng cách làm này không thực sự hoạt động tốt.

Điều khác biệt đầu tiên bạn nhận thấy trong một dự án agile là customer và end user vẫn tham gia trong suốt thời gian thực hiện dự án. Họ không được chờ đợi ​​(thực ra là không được phép!) vắng mặt trong quãng giữa của dự án. Thực tế này đúng cho dù nhóm dự án sử dụng phương pháp Extreme Programming (XP) hay theo khuôn khổ Scrum, hoặc theo một quy trình agile nào khác mà dựa trên cơ sở các user story. Customer dự định của phần mềm mới phải đóng vai trò rất tích cực trong việc viết các user story, đặc biệt là nếu sử dụng phương pháp XP cho dự án.

Tại sao customer là người viết user story?

Customer team, thay vì các developer, viết các user story vì hai lý do chính. Đầu tiên, mỗi user story phải được viết bằng ngôn ngữ của người làm nghiệp vụ doanh nghiệp chứ không phải bằng thuật ngữ kỹ thuật, để customer team có thể sắp xếp thứ tự ưu tiên các user story và đưa chúng vào các iteration và release thích hợp. Thứ hai, với tư cách là người quyết định về tầm nhìn của sản phẩm, customer team ở vị trí tốt nhất để mô tả hành vi của sản phẩm.

Customer team gồm những ai?

Trong một dự án lý tưởng, chúng ta sẽ có một người duy nhất sắp xếp thứ tự ưu tiên làm việc cho các developer, trả lời một cách khéo léo câu hỏi của họ, người sẽ sử dụng phần mềm khi nó kết thúc và viết tất cả các user story. Điều này hầu như luôn luôn là một hy vọng phi thực tế, vì vậy chúng ta sẽ thành lập một customer team thay vì chỉ dựa vào một người duy nhất. Customer team bao gồm những người đảm bảo rằng phần mềm sẽ đáp ứng nhu cầu của end user thực. Điều này có nghĩa là customer team có thể bao gồm người kiểm thử phần mềm (tester), người quản lý sản  phẩm (product owner/product manager), vài end user thực sự và người thiết kế tương tác (interaction designer/UX-UI designer).

Quá trình viết user story

Quá trình viết user story nên được bắt đầu bằng cách xem xét các loại user, tức là xác định các user roles hay user profiles của hệ thống dự định. Ví dụ: nếu bạn đang xây dựng một trang web đặt phòng du lịch, bạn có thể có các loại end user như người thường xuyên bay, người lập kế hoạch kỳ nghỉ, v.v… Customer team nên bao gồm đại diện của càng nhiều loại end user này càng tốt. Nhưng khi thực tế dự án bạn không thể có một customer team bao gồm đủ các đại diện end user thì phương pháp mô hình hóa user role (user role modeling) nên được áp dụng.

Những user story ban đầu của dự án thường được viết trong một workshop (user-story writing workshop). Nhưng ngoài ra những user story còn có thể được viết bất cứ lúc nào trong suốt quá trình dự án. Trong user-story writing workshop, mọi người brainstorming càng nhiều user story càng tốt. Sau đó với một tập các user story (product backlog) ban đầu đó các developer ước tính kích thước của mỗi user story.

Cùng với nhau customer team và developer chọn độ dài cho iteration, có thể từ một đến bốn tuần. Độ dài iteration đã chọn căn bản sẽ được sử dụng và không đổi trong suốt thời gian của dự án. Vào cuối mỗi iteration, các developer sẽ chịu trách nhiệm cung cấp mã hoàn chỉnh có thể sử dụng để hoàn thành một số user story đã chọn của ứng dụng.

Customer team vẫn thường xuyên tham gia trong quá trình của mỗi iteration, nói chuyện với các developer về những user story được phát triển trong iteration đó. Trong quá trình lập kế hoạch iteration (iteration planning), customer team cũng chỉ định ra các bài thử nghiệm và làm việc với các developer để có thể tự động hóa việc chạy các thử nghiệm. Ngoài ra, customer team đảm bảo cho mục tiêu của dự án phải liên tục bàn giao sản phẩm mong muốn (product increment) cho khách hàng sau mỗi release.

Khi bắt đầu mỗi iteration, customer team có thể thực hiện sửa đổi giữa chừng dự án thông qua việc lập iteration planning. Khi các iteration được hoàn thành, chúng ta đo được velocity thực tế và có thể sử dụng số liệu thực này, thay vì velocity ước tính ban đầu, cho công tác lập kế hoạch tiếp theo.

Ghi nhớ

• Story card chứa một mô tả ngắn về chức năng có giá trị của người dùng hoặc customer.
• Story card là phần hiển thị bề nổi của user story, nhưng phần quan trọng hơn của user story là các cuộc hội thoại giữa customer và developer về user story.
• Customer team bao gồm những người đảm bảo rằng phần mềm sẽ đáp ứng nhu cầu của người dùng dự định, nghĩa là có thể bao gồm người kiểm tra, người quản lý sản phẩm, người dùng thực và nhà thiết kế tương tác.
• Customer team viết các user story vì họ ở vị trí tốt nhất để thể hiện các tính năng mong muốn và vì sau đó họ phải nghĩ ra các chi tiết về user story để giải thích cho các developer và sắp xếp thứ tự ưu tiên các user story đó.
• Kiểm thử nghiệm thu (acceptance tests) xác nhận rằng một user story đã được phát triển với chức năng mà customer team mong muốn khi họ viết ra user story.
• User story có giá trị thiết thực bởi vì chúng nhấn mạnh vào giao tiếp bằng lời nói, customer và developer có thể hiểu về user story như nhau, và user story là công cụ phù hợp để lập kế hoạch iteration, hoạt động tốt trong quy trình phát triển agile và vì chúng khuyến khích trì hoãn việc làm chi tiết cho đến sát thời điểm bắt tay vào coding.
• User story được sắp xếp thứ tự ưu tiên dựa trên giá trị của chúng đối với tổ chức.
• Release và iteration được lên kế hoạch bằng cách đặt user story thuộc product backlog vào các iteration phù hợp với thứ tự ưu tiên.
• Velocity là khối lượng công việc (tính bằng số story point) mà các developer có thể hoàn thành trong một iteration.
• Tổng số story point ước tính của các user story được đặt trong một iteration không thể vượt quá velocity mà các developer dự báo cho iteration đó.
• Nếu một user story có kích thước không phù hợp để đặt trọn vẹn trong một iteration, bạn có thể chia tách user story đó thành hai hoặc nhiều user story nhỏ hơn.