User story là gì?

Trong Agile, user story là một mô tả ngắn gọn, đơn giản về những gì người dùng muốn làm trong một sản phẩm phần mềm để đạt được thứ mà họ thấy có giá trị.

User story thường tuân theo mô hình vai trò-tính năng-lợi ích, hoặc template như dưới đây:

As a [type of user],
I want [an action]
so that [a benefit/value]
Là đơn vị công việc nhỏ nhất trong bối cảnh Agile, user story là một công cụ quan trọng trong quá trình phát triển.

Tại sao nên sử dụng User Stories?

Khi sử dụng user stories, bạn đặt người dùng vào trung tâm, xung quanh đó là những gì cần thêm vào hoặc thay đổi trong một sản phẩm phần mềm.
User stories cung cấp cho nhóm phát triển bối cảnh và lý do cho những gì họ đang tạo ra. Làm như vậy sẽ giúp họ hiểu cách họ đang cung cấp giá trị cho doanh nghiệp và luôn chú ý đến người dùng / khách hàng.
Giúp định hướng sự ưu tiên dựa trên cái nhìn khái quát mà user đem lại.
Bản chất ngắn gọn và sự tập trung vào người dùng của user stories cũng giúp phân biệt ai là người xử lý những gì và ai giải quyết cách bạn tạo ra sản phẩm.
Và cuối cùng, vì user stories là những đơn vị công việc nhỏ tương tự như một target, nên bạn sẽ tận hưởng rất nhiều chiến thắng nhỏ khi hoàn thành lần lượt chúng, nhờ đó tạo động lực nhiều hơn trong công việc.

Thế nào là một User story tốt?

User Story tốt là gì?
Trở lại năm 2003, Bill Wake đã giới thiệu INVEST giúp ghi nhớ các đặc điểm của một user story tốt:

Independent: Độc lập.
User stories cần độc lập với nhau để có thể tự do di chuyển chúng trong Product backlog khi thay đổi ưu tiên thay đổi.
Negotiable: Có thể thương lượng.
Hãy trình bày chi tiết user story với sự cộng tác của khách hàng và nhóm sẽ triển khai user story đó. Sự hợp tác này bao gồm việc thương lượng về phạm vi: những việc sẽ và sẽ không bao gồm khi triển khai.
Valuable: Có giá trị.
User stories tốt sẽ có giá trị đối với khách hàng.
Estimable: Có thể ước tính.
Nếu không thể ước tính một user story, điều đó có nghĩa là bạn chưa hiểu rõ phạm vi hoặc phạm vi quá lớn để có thể dễ dàng ước tính.
Không cần ước tính chính xác, nhưng khi bạn có thể ước tính một user story thì bạn cũng có thể thương lượng được nhiều hơn với khách hàng cũng như nhóm phát triển.
Ngoài ra, bạn sẽ có thể phân biệt giữa một user story cần nỗ lực thấp có giá trị và một user story cần nỗ lực cao nhưng không có giá trị.
Small: Nhỏ.
Hãy cố gắng để user story trở nên nhỏ bé. Nhiều nhất là một vài tuần (bởi một người phát triển) hoặc "một vài ngày". Những user stories
nhỏ hơn sẽ dễ ước tính hơn.
Testable: Có thể kiểm tra được.
User stories cần đủ rõ ràng để cả khách hàng cũng có thể xác minh rằng bạn đã triển khai những gì họ muốn hay chưa.

4 cách đơn giản để viết User stories tốt

Start at the End: bắt đầu từ cuối
Kết thúc quá trình phát triển luôn là để thỏa mãn yêu cầu của khách hàng, vì vậy đó là nơi bạn nên bắt đầu: mục tiêu cuối cùng hoặc giá trị mà người dùng đang tìm kiếm.
Work Backward: Lùi lại
Với đối tượng người dùng và mục tiêu cuối cùng rõ ràng trong tâm trí, bạn sẽ vạch ra các bước mà người dùng cần thực hiện để đạt được mục tiêu của họ.

Giả sử mục tiêu của bạn là thưởng thức sinh tố dâu tây. Vì vậy, bạn bắt đầu ở đó: một ly sinh tố dâu tây đã hoàn thành, sẵn sàng để bạn thưởng thức.
Bạn cần gì cho điều đó? Rõ ràng là một cái ly, một cái ống hút, một ly sinh tố, và đặt mọi thứ lại với nhau.
Lấy một ly → lấy dâu → xay sinh tố → đổ sinh tố vào ly → lấy ống hút vào ly sinh tố
↓
Bạn có một chiếc ly phù hợp, nhưng thiếu ống hút → mua ống hút
↓
Bạn chưa bao giờ làm sinh tố, nhưng bạn biết bạn cần một máy xay sinh tố→ lấy máy xay
↓
Làm theo một công thức → tìm một công thức
↓
Mua các thành phần được chỉ định trong công thức.

Small Is Beautiful: Nhỏ là đẹp
Các Step lớn hoặc task lớn thường che giấu các giả định và chi tiết. Hãy chia Step đó thành những Step nhỏ hơn.
Pen and PaperCards: bút và card

Viết user stories trên thẻ, mỗi thẻ một câu, làm cho câu chuyện trở nên rõ ràng hơn. Bạn có thể thao tác trực tiếp các thẻ: di chuyển chúng trên bàn hoặc bảng. Và đó vẫn là cách sắp xếp thứ tự và sắp xếp thứ tự ưu tiên dễ dàng nhất.

Cách để nhà phát triển bắt đầu với User Stories

User stories là sẽ thiếu các chi tiết cần thiết cho các nhà phát triển và tester.

Vì vậy, khi sắp triển khai một user story, cần thêm các chi tiết để giúp mọi người đi đúng hướng và ngăn chặn công việc không cần thiết.

Ron Jeffries đã đưa ra 3C-3 khía cạnh quan trọng khi làm việc và phát triển phần mềm bắt đầu từ user story.

Card

- Viết user stories của mình lên card và sử dụng những card này để sắp xếp thứ tự ưu tiên, ước tính và lập lịch trình.

- Có thể thêm ghi chú về các ưu tiên và chi phí.

Conversation

- 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

Các cuộc trò chuyện xung quanh user story sẽ tạo ra các giải pháp tốt hơn, đơn giản hơn và có giá trị hơn. Các giải pháp chính xác là những gì người dùng cần.

Không còn phải phỏng đoán và đưa ra các tính năng nghe có vẻ hay nhưng chẳng ai quan tâm đến.

Cảm ơn mọi người đã đọc đến cuối cùng =)))