User Story: Giải Pháp Linh Hoạt Cho Phát Triển Phần Mềm

Cập nhật lần cuối vào 13/09/2023 bởi Nguyễn Quang Hoàng

Trong thế giới phát triển phần mềm đang ngày càng thúc đẩy sự linh hoạt và tập trung vào khách hàng, “user story” đã trở thành một khái niệm không thể thiếu. Đây là một cách tiếp cận độc đáo giúp định rõ nhu cầu của người dùng và giúp đội phát triển hiểu rõ hơn về giá trị thực sự mà họ đang tạo ra. Bài viết này sẽ khám phá chi tiết về user story, từ cơ bản đến ứng dụng thực tế, để giúp bạn hiểu rõ hơn về tại sao nó trở thành một công cụ quan trọng trong phát triển phần mềm theo phong cách Agile.

Giới thiệu về User Story

Một user story là đơn vị công việc nhỏ nhất trong mô hình agile. Đó là một mục tiêu cuối cùng, không phải là một tính năng, được diễn đạt từ góc độ của người dùng hoặc khách hàng sử dụng phần mềm.

User story là một lời giải thích không chính thức và tổng quan về một tính năng phần mềm, được viết từ góc độ của người dùng cuối cùng hoặc khách hàng.

Mục đích của user story là diễn tả cách một công việc cụ thể sẽ mang lại giá trị cho khách hàng. Lưu ý rằng “khách hàng” không nhất thiết phải là người dùng cuối cùng, họ cũng có thể là những khách hàng hoặc đồng nghiệp nội bộ trong tổ chức của bạn, phụ thuộc vào nhóm của bạn.

User stories chỉ là một vài câu đơn giản mô tả kết quả mong muốn. Chúng không đi vào chi tiết. Yêu cầu sẽ được thêm vào sau, khi được đồng ý bởi nhóm.

User stories phù hợp với các khung làm việc linh hoạt như scrum và kanban. Trong scrum, user stories được thêm vào các sprint và được hoàn thành trong suốt thời gian của sprint. Các nhóm kanban kéo các user story vào backlog và xử lý chúng qua quy trình làm việc của họ.

Xem thêm: Scrum Sprint và những điều cần biết

Chính việc làm việc trên user stories giúp các nhóm scrum trở nên giỏi hơn trong việc ước tính và lập kế hoạch sprint, dẫn đến dự báo chính xác hơn và tính linh hoạt cao hơn. Nhờ những câu chuyện này, các nhóm kanban học cách quản lý công việc đang thực hiện (WIP) và có thể tinh chỉnh quy trình làm việc của họ thêm nữa.

Ý Nghĩa của User Story

Yêu cầu sẽ luôn thay đổi khi các nhóm phát triển và khách hàng tìm hiểu thêm về hệ thống khi dự án tiến triển. Việc mong đợi các nhóm dự án làm việc dựa trên một danh sách yêu cầu cố định và sau đó giao phần mềm hoàn chỉnh sau một khoảng thời gian là không thực tế.

Với phương pháp User Stories, chúng ta có thể thay thế việc thiết kế lớn ban đầu bằng một cách tiếp cận “vừa đủ”. User Stories giảm thời gian sử dụng vào việc viết tài liệu chi tiết và thay vào đó là việc tập trung vào cuộc trò chuyện hướng đến khách hàng. Do đó, User Stories cho phép nhóm phát triển giao phần mềm chất lượng và nhanh chóng hơn, điều mà khách hàng ưu tiên.

Có nhiều lợi ích khi áp dụng phương pháp User Stories trong phát triển Agile như sau:

• Việc sử dụng định dạng đơn giản và nhất quán cho user stories giúp tiết kiệm thời gian khi thu thập và ưu tiên yêu cầu của dự án.
• User stories giúp tập trung vào việc cung cấp giá trị cho khách hàng thay vì chú trọng vào các chi tiết kỹ thuật, giúp đảm bảo rằng sản phẩm cuối cùng sẽ đáp ứng đúng nhu cầu của khách hàng.
• Tránh đưa ra chi tiết quá sớm để tránh việc hạn chế sự sáng tạo và lựa chọn thiết kế của nhóm phát triển
• Tránh sự xuất hiện của tính hoàn thiện và sự chi tiết ở giai đoạn ban đầu.
• Được phân chia thành các thành phần nhỏ có khả năng thực hiện trong một khoảng thời gian ngắn (thường từ 3 đến 4 ngày) giúp tạo điều kiện cho sự thương lượng và di chuyển linh hoạt trong danh sách công việc chờ xử lý, giúp quản lý dự án hiệu quả hơn.
• Được viết và trình bày một cách rõ ràng, dễ hiểu để các chức năng kỹ thuật, như kiến trúc sư, nhà phát triển, và kiểm thử viên có thể hiểu và triển khai chúng dễ dàng. 

Viết Một User Story Như Thế Nào?

User Story chỉ ghi nhận những phần thiết yếu của một yêu cầu:

Người sử dụng

Người sử dụng nên là một người thực sự tương tác với hệ thống.

• Hãy cụ thể hóa càng nhiều càng tốt.
• Đội phát triển KHÔNG phải là người sử dụng.

Hành động 

Hành vi của hệ thống cần được miêu tả dưới dạng một hành động.

• Thường là duy nhất cho mỗi User Story.
• “Hệ thống” được ngụ ý và không cần được đề cập trong câu chuyện.
• Sử dụng ngôn từ chủ động, không phải bị động (“Tôi có thể nhận thông báo”).

Lợi ích 

Lợi ích nên là kết quả thực sự trong thực tế, không liên quan đến hệ thống hoặc tính năng.

• Nhiều User Story có thể chia sẻ cùng một câu lợi ích.
• Lợi ích có thể là cho người sử dụng hoặc khách hàng khác, không chỉ dành cho người sử dụng trong câu chuyện.

Lưu ý:

User Story được viết bằng ngôn ngữ hàng ngày và mô tả một mục tiêu cụ thể (làm gì) từ góc độ của một cá nhân (người nào) cùng với lý do (tại sao) mà người đó muốn nó.

Trong phát triển phần mềm, mục tiêu thường là một tính năng mới của sản phẩm, cá nhân là một người dùng cuối và lý do là lợi ích mà người dùng thấy trong tính năng của sản phẩm mục tiêu.

Ví Dụ về User Story

As a [customer], I want [shopping cart feature] so that [I can easily purchase items online].

As an [manager], I want to [generate a report] so that [I can understand which departments need more resources].

As a [customer], I want to [receive an SMS when the item is arrived] so that [I can go pick it up right away]

Trong các ví dụ trên:

Người sử dụng đại diện cho người, hệ thống, phần hệ thống hoặc bất kỳ thực thể nào khác sẽ tương tác với hệ thống cần triển khai để đạt được một mục tiêu. Người đó sẽ thu được giá trị thông qua việc tương tác với hệ thống.

Hành động đại diện cho mong đợi của người sử dụng mà có thể thực hiện thông qua việc tương tác với hệ thống.

Lợi ích đại diện cho giá trị đằng sau việc tương tác với hệ thống.

Đây không phải là một quy tắc mà là một hướng dẫn giúp bạn suy nghĩ về một User Story bằng cách xem xét các điểm sau:

• User Story sẽ mang lại giá trị cho một người nào đó hoặc một bên cụ thể (ví dụ: khách hàng).
• User Story đang thực hiện nhu cầu của một người dùng (ví dụ: nhận SMS khi sản phẩm đã có sẵn).
• Có một lý do để hỗ trợ việc triển khai User Story này (ví dụ: khách hàng có thể đến lấy sản phẩm mà cô ấy đã mua).

Các giai đoạn của một User story

User Story là một phương pháp đơn giản, nhanh chóng ghi lại “ai”, “cái gì” và “tại sao” của một yêu cầu sản phẩm. Một cách dễ hiểu, user stories là những ý tưởng về yêu cầu mà người dùng cần. User stories ngắn gọn, với mỗi phần thường chứa ít hơn 10 hoặc 15 từ.

User stories là danh sách “cần làm” giúp bạn xác định các bước trên con đường của dự án. Chúng giúp đảm bảo rằng quy trình của bạn, cũng như sản phẩm kết quả, sẽ đáp ứng yêu cầu của bạn.

User story được định nghĩa theo từng giai đoạn:

• Mô tả ngắn gọn về nhu cầu.
• Cuộc trò chuyện diễn ra trong quá trình duyệt danh sách công việc và lập kế hoạch vòng lặp để cụ thể hóa chi tiết.
• Các bài kiểm tra xác nhận rằng user story đã được hoàn thành đầy đủ và đạt yêu cầu.

Và những yếu tố này được biết đến với tên gọi “3C” – Card (Thẻ), Conversation (Cuộc trò chuyện), và Confirmation (Xác nhận)

User Story và 3C’s (Card, Conversation, Confirmation)

Ron Jeffries, một trong những người đóng góp quan trọng cho Extreme Programming (XP), đã mô tả về user story và nó vẫn được chúng ta hiểu và sử dụng ngày nay. Một User Story có ba thành phần chính, mỗi thành phần bắt đầu bằng chữ cái ‘C’: Thẻ (Card), Cuộc Trò Chuyện (Conversation) và Xác Nhận (Confirmation) để mô tả ba yếu tố của một User Story. Ở đó:

Thẻ (Card)

Thẻ đại diện cho 2-3 câu được sử dụng để mô tả ý định của câu chuyện và có thể coi là một “lời mời” để thảo luận. Thẻ này tóm tắt ý định và đại diện cho những yêu cầu chi tiết hơn, những chi tiết này sẽ được xác định sau.

Bạn không cần phải hoàn tất tất cả các mục “Product Backlog” từ đầu, trước khi đưa chúng đến cho nhóm. Nó cho phép khách hàng và nhóm sẽ đưa ra yêu cầu về sản phẩm/ hệ thống cơ bản khi họ làm việc trên nó. Các yêu cầu này sẽ được gợi mở thông qua cuộc trò chuyện và cộng tác xung quanh các user stories.

Thẻ thường theo định dạng tương tự như sau:

Với vai trò là (vai trò) của sản phẩm, tôi có thể (thực hiện hành động) để tôi có thể đạt được (một số lợi ích / giá trị)

Lưu ý: Thẻ phải đề cập đến “ai (vai trò)”, “làm gì (hành động)” và “tại sao (lợi ích)” của câu chuyện.

Cuộc Trò Chuyện (Conversation)

Cuộc trò chuyện đại diện cho cuộc thảo luận giữa người dùng mục tiêu, nhóm phát triển, Product Owner và các bên liên quan khác để xác định hành vi chi tiết hơn được yêu cầu cho việc thực hiện ý định.

Cuộc trò chuyện sẽ do Product Owner hướng dẫn và quản lý và bao gồm tất cả các bên liên quan và nhóm.

Cuộc trò chuyện là nơi đem lại giá trị thực sự của user story và Thẻ (Card) sẽ được điều chỉnh và cập nhật dựa trên sự hiểu biết chung từ cuộc trò chuyện này.

Cuộc trò chuyện này thường là trò chuyện sử dụng lời nói nhưng cũng được hỗ trợ bằng tài liệu và lý tưởng hơn là các kiểm tra tự động (ví dụ: acceptance test).

Xác Nhận (Confirmation)

Xác nhận là cách mà khách hàng hoặc Product Owner sẽ xác nhận rằng user story đã được triển khai và họ hài lòng với điều đó.

Product owner phải xác nhận rằng user story đã hoàn thành trước khi nó có thể được coi là “done”.

Nhóm và Product Owner kiểm tra sự “done” của mỗi user story dựa trên definition of done của nhóm.

Xem thêm: Definition of Done và Bí quyết Áp Dụng Hiệu Quả Trong Dự Án Agile

Các acceptance criteria cụ thể có thể được xác định cho từng câu chuyện cụ thể, nhưng tiêu chí hiện tại phải được hiểu rõ và được đồng thuận bởi Nhóm. Tất cả các kiểm tra acceptance test liên quan phải ở trạng thái “đạt” (passing).

User Story – INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)

INVEST là một bộ tiêu chí hoặc danh sách chấm điểm phổ biến để đánh giá chất lượng của một user story. Nếu user story không đáp ứng được một trong những tiêu chí này, nhóm có thể sẽ phải viết lại nó hoặc thậm chí xem xét việc viết một cái mới. 

Một user story tốt phải tuân theo tiêu chí INVEST:

Independent (Độc Lập): User story cần phải đầy đủ để có thể được phát hành mà không phụ thuộc vào những user story khác.

Negotiable (Có Thể Đàm Phán): Chỉ cần đưa bản chất về nhu cầu của người dùng, để lại những thông tin khác dành cho cuộc trò chuyện. User story không nên được viết như một hợp đồng cứng nhắc.

Valuable (Có Giá Trị): Mang lại giá trị cho người dùng cuối cùng.

Estimable (Có Thể Đánh Giá): User story phải có khả năng ước tính  được để có thể sắp xếp vào các sprint và đặt mức độ ưu tiên.

Small (Nhỏ): Một user story là một phần nhỏ của công việc, cho phép hoàn thành trong khoảng 3 đến 4 ngày.

Testable (Có Thể Kiểm Tra): User story phải được xác nhận thông qua các tiêu chí chấp nhận (acceptance criteria) được viết trước.

Khi Nào Thì User Story Được Viết?

User stories được viết xuyên suốt trong thời gian dự án agile diễn ra. Thông thường, một buổi họp viết user stories (story-writing workshop) được tổ chức gần ngay trước khi bắt đầu dự án agile.

Tất cả mọi người trong nhóm tham gia, với mục tiêu tạo ra một product backlog mô tả đầy đủ các chức năng cần được thêm vào trong suốt dự án hoặc trong một chu kỳ phát hành kéo dài từ ba đến sáu tháng trong dự án đó.

Một số user stories này sẽ không thể tránh khỏi việc được gọi là epics (câu chuyện chính). Epics sau đó sẽ được phân chia thành các user stories nhỏ hơn, dễ dàng hơn để phù hợp vào một chu kỳ phát triển (iteration) duy nhất. Ngoài ra, các user stories mới có thể được viết và thêm vào product backlog bất cứ lúc nào và bởi bất kỳ ai trong nhóm.

Vòng Đời của Một User Story

Trong một khía cạnh rộng lớn, có sáu trạng thái chính cho mỗi user story trong suốt một dự án phần mềm:

Pending (Đang Chờ) 

Trong giai đoạn này, thông qua việc giao tiếp giữa người dùng và nhóm dự án, các user story sẽ được đưa ra. Ở trạng thái này, các user story chỉ có một mô tả ngắn gọn về nhu cầu của người dùng. Chưa có cuộc thảo luận chi tiết về yêu cầu, chưa có logic hệ thống và chưa có thiết kế giao diện.

Thực tế, mục đích duy nhất của user story ở thời điểm này là để nhắc nhở tất cả các bên về cuộc thảo luận trong tương lai về yêu cầu của người dùng được viết trong user story này. Có thể xảy ra trường hợp user story này sẽ bị hủy bỏ trong tương lai.

To-do (Chưa Làm) 

Thông qua cuộc thảo luận giữa các bên liên quan khác nhau, các user story sẽ được quyết định sẽ được thực hiện trong vài tuần tới và sẽ được đặt vào một khoảng thời gian cụ thể gọi là sprint. Các user story như vậy được coi là đang ở trạng thái To-do. Ở trạng thái này, chưa có cuộc thảo luận chi tiết nào.

Discussing (Đang Thảo Luận)

Khi một user story ở trạng thái Discussing, người dùng cuối sẽ trò chuyện với nhóm phát triển để xác nhận yêu cầu cũng như xác định các tiêu chí chấp nhận. Nhóm phát triển sẽ ghi lại các yêu cầu hoặc quyết định trong cuộc thảo luận. Chuyên gia về trải nghiệm người dùng (UX specialist) có thể tạo ra bản thiết kế giao diện hoặc storyboard để cho người dùng xem trước các tính năng đề xuất trong bản mô phỏng trực quan và để họ cảm nhận. Quá trình này được gọi là thiết kế trải nghiệm người dùng (UX design).

Developing (Đang Phát Triển)

Sau khi yêu cầu được làm rõ, nhóm phát triển sẽ thiết kế và triển khai các tính năng để đáp ứng yêu cầu của người dùng.

Confirming (Đang Xác Nhận)

Khi nhóm phát triển đã triển khai xong một user story, user story sẽ được người dùng cuối xác nhận. Người dùng sẽ được cung cấp quyền truy cập vào môi trường kiểm thử hoặc một phiên bản phần mềm gần như hoàn chỉnh (thường được gọi là phiên bản alpha) để xác nhận tính năng. Xác nhận sẽ được thực hiện dựa trên các mục xác nhận được viết khi chi tiết hóa user story. Cho đến khi xác nhận hoàn thành, user story sẽ ở trạng thái Confirming.

Finished (Hoàn Thành)

Cuối cùng, khi tính năng được xác nhận là hoàn thành, user story được coi là ở trạng thái Finished. Thông thường, đây là điểm kết thúc của user story. Nếu người dùng có yêu cầu mới, có thể là về một tính năng mới hoặc là một cải tiến của user story đã hoàn thành, nhóm sẽ tạo một user story mới cho vòng lặp tiếp theo.

Cách Sử Dụng User Story Hiệu Quả

Giống như nhiều phương pháp phát triển phần mềm khác, nếu bạn áp dụng user story một cách đúng đắn trong dự án phần mềm của bạn, bạn sẽ có khả năng sản xuất một hệ thống phần mềm chất lượng và giành được sự tin tưởng và sự hài lòng từ khách hàng. Dưới đây là một số điểm bạn cần ghi nhớ khi sử dụng user story:

• Giữ mô tả của user story ngắn gọn: User story nên được viết một cách ngắn gọn và súc tích.
• Suy nghĩ từ góc độ của người dùng cuối khi viết user story: Hãy tập trung vào cách mà người dùng cuối sẽ sử dụng sản phẩm của bạn và những giá trị họ mong muốn đạt được.
• Xác định các mục xác nhận trước khi bắt đầu phát triển: Đảm bảo rằng các tiêu chí xác nhận đã được xác định trước khi bạn bắt đầu phát triển để đảm bảo rằng tính năng sẽ được thực hiện đúng cách.
• Ước tính user story trước khi thực hiện để đảm bảo khối lượng công việc của nhóm của bạn được kiểm soát: Điều này giúp bạn đảm bảo rằng bạn có thể thực hiện user story trong thời gian ấn định.
• Yêu cầu (requirements) cho dự án phần mềm không nên được xác định chỉ bởi một người dùng cuối cụ thể hoặc chỉ bởi nhóm phát triển: Thay vào đó, yêu cầu nên được tìm hiểu và xác định thông qua sự tương tác và hợp tác giữa các người dùng cuối và nhóm phát triển.
• Giao tiếp luôn quan trọng trong việc hiểu những gì người dùng cuối muốn: Đảm bảo rằng có cuộc trò chuyện và giao tiếp đầy đủ để hiểu rõ những gì người dùng cuối mong muốn.

Kết luận

Tóm lại, User story là một trong những thành phần cốt lõi của một chương trình agile. Chúng giúp tạo ra một khuôn khổ tập trung vào người dùng cho công việc hàng ngày — điều thúc đẩy sự hợp tác, sáng tạo và nhìn chung, tạo ra một sản phẩm tốt hơn cho người dùng.