Hỏi đáp về User story

Em chào mọi người ạ, hiện tại em đang tìm hiểu user story, vậy nên em muốn hỏi về một vấn đề như sau:
Em muốn biết là điểm mạnh giữa user story so với yêu cầu truyền thống (traditonal requirement) là gì?
Nếu được mọi người có thể lấy ví dụ cụ thể về một trường hợp nào đấy để thể hiện được điểm mạnh giữa user story so với yêu cầu truyền thống được không ạ. Em xin chân thành cảm ơn.

“User story” là phiên bản mô tả ngắn gọn của traditional business requirement, được sử dụng rộng rãi trong Agile.
Chắc cậu đã biết, agile được sử dụng tốt nhất cho các phần mềm nhỏ và trung bình, được thiết kế để dễ adapt với các thay đổi. Vậy nên, là một tool sử dụng trong agile, user story có những điểm mạnh:

  • Nhỏ gọn và nhấn mạnh vào cốt lõi của tính năng, hơn là các đặc tả chi tiết như traditional businesses requirement.
    Điều đó dẫn tới việc requirement của cậu dễ hiểu hơn cho tất cả mọi người, từ end user tới lập trình viên, và product owner => mọi thông tin đều rõ ràng với tất cả.
  • Vì nhỏ gọn, nên cậu dễ dàng kết hợp nó với các tool/phương pháp khác của agile, như Kanban, story point estimation… chẳng hạn (cậu không thể dán cả business requirement vào Kanban được :smile:).
    Traditional business requirement đôi khi phải thể hiện sự liên kết giữa các tính năng, còn User story cố gắng chia các vấn đề độc lập nhất có thể.

Tuy nhiên, tớ phải nhấn mạnh một vài điều:

  • User story không sử dụng để thay thế hoàn toàn traditional business requirement.
    User story chỉ tập trung chứa các thông tin high level thôi. Cậu vẫn cần đặc tả chi tiết (đặc biệt là các phần mềm cỡ trung bình) để có thể thiết kế và cài đặt được tính năng, cũng như là tài liệu cần thiết để onboarding các thành viên mới vào dự án.
  • Nếu cậu dựa quá nhiều vào user story trong thời gian dài, dự án của cậu có nguy cơ không được tổ chức tốt.
    Cậu không thể tìm được nhiều thông tin có giá trị lâu dài trong user story, nên nếu chỉ sử dụng nó mà quên đi traditional business requirement, hẳn nhiên trong tương lai cậu sẽ tốn thời gian hơn để hiểu chuyện gì đã xảy ra trong quá khứ.
  • User story không phải silver bullet. Dùng nó không có nghĩa là team cậu sẽ dễ adapt với business requirement changing.
    Cốt lõi của việc hoàn thành công việc không phải nhờ các phương pháp và process, mà là con người. Nếu team nào đó quá cứng nhắc và process-oriented (không phải kiểu team “get things done”), hẳn nhiên không có phương pháp/process nào có thể giúp team đó. Rất nhiều team agile lâm vào cảnh bế tắc do promote các phương pháp trong agile, mà lờ đi khâu quản lý và tổ chức trong thực tế.

Hope it helps!

3 Likes

Câu trả lời rất tuyệt vời. Em cảm ơn ạ.

1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?