User stories – Công cụ lên kế hoạch của Agile

Giá trị cốt lõi đầu tiên trong Agile Manifesto đó là “Individuals and interactions over processes and tools” – “Cá nhân và tương tác hơn là quy trình và công cụ”, chính vì vậy các nhóm Agile đề cao việc sử dụng những công cụ đơn giản để lập kế hoạch, ước lượng, quản lý các dự án của họ. Đơn cử là các nhóm Scrum sẽ cùng nhau lập kế hoạch cho dự án, để các thành viên trong nhóm thể hiện sự cam kết thực hiện theo đúng từng Sprint goal ban đầu đề ra. Nhằm duy trì cam kết tập thể đó thì những công cụ cho việc lập kế hoạch, ước lượng và quản lý cần phải đạt được sự đơn giản, từ đó toàn team sẽ dễ dàng thực hiện cùng với nhau.

Các nhóm Scrum sử dụng một số công cụ trong việc thiết lập mục tiêu và theo dõi quá trình thực hiện mục tiêu đó. Mặc dù các công cụ này không phải là một phần trong các quy tắc cốt lõi của Scrum, nhưng chúng đã được nhóm Scrum sử dụng để lập kế hoạch làm việc và thể hiện các hạng mục cần thực hiện một cách hiệu quả. Scrum gọi chung các công cụ này là GASPs – Generally Accepted Scrum Practices, có thể kể tên đến như User stories, Story point, Story map, Task boards, Planning Poker, Burndown chart và Personas. Chúng ta sẽ cùng tìm hiểu cặn kẽ các công cụ này, công cụ đầu tiên đề cập trong bài viết này chính là User stories.

User storier là công cụ lập kế hoạch tối ưu trong các dự án Agile

Trong phát triển phần mềm/sản phẩm, user story được thể hiện bằng ngôn ngữ tự nhiên, là một mô tả ngắn gọn, súc tích về một hoặc nhiều tính năng bất kỳ của phần mềm, sản phẩm. Và phần mô tả về tính năng này được thể hiện từ góc độ của người dùng cuối.

Mike Cohn – người đóng góp chính cho việc phát minh ra phương pháp phát triển phần mềm Scrum, chia sẻ: “Sử dụng công cụ lập kế hoạch Agile: User story là một phần của cách tiếp cận nhanh chóng, giúp chuyển trọng tâm từ việc ghi chép chi tiết về các yêu cầu sản phẩm sang việc nói về chúng. Tất cả user stories có thể là một hoặc hai câu viết và quan trọng hơn là một loạt các cuộc trao đổi về chức năng mong muốn của người dùng/khách hàng”.

là một mô tả rất ngắn về một điều cụ thể mà người dùng cần, thường chứa ít hơn 10 hoặc 15 từ mỗi câu. Rất nhiều nhóm ghi nhớ yêu cầu của người dùng chỉ bằng cách viết trên sticky notes, rất đơn giản. Khi tổ chức tất cả các công việc xung quanh user stories, Scrum đảm bảo rằng nhóm luôn đáp ứng nhu cầu của người dùng, từ việc lập kế hoạch, sắp xếp độ ưu tiên cho các tính năng, tập trung vào việc xây dựng những gì người dùng cần cho tới khi demo sản phẩm ở cuối Sprint – tại Sprint Review.

Trong quá trình tiến triển của dự án Agile, yêu cầu luôn thay đổi khi các nhóm và khách hàng có nhiều thông tin hơn về hệ thống, sản phẩm. User stories cho phép các nhóm cung cấp phần mềm chất lượng và nhanh hơn vì giảm thiểu được nỗ lực phải xây dựng những tài liệu hoàn chỉnh ngay từ đầu dự án, đó chính là những gì khách hàng mong đợi. Có rất nhiều lợi ích cho việc áp dụng user stories trong phát triển tính năng sản phẩm/phần mềm như:

• Định dạng đơn giản và nhất quán giúp tiết kiệm thời gian khi nắm bắt và sắp xếp mức độ ưu tiên cho các yêu cầu, trong khi vẫn có thể linh hoạt sử dụng cho các tính năng lớn và nhỏ như nhau.
• Giúp gia tăng giá trị thu được cho khách hàng bằng cách cung cấp một sản phẩm/phần mềm mà khách hàng thực sự cần.
• Tránh việc đi sâu vào chi tiết quá sớm sẽ làm cho Development teams bị hạn chế trong việc đưa ra giải pháp, và trong quá trình triển khai.
• Vì đơn giản và là từng mục nhỏ nên sẽ hỗ trợ dễ dàng việc điều chỉnh kế hoạch, sắp xếp độ ưu tiên trong product backlog.
• Tránh đi sâu vào các vấn đề sâu về kỹ thuật, vì chúng sẽ được các chuyên gia, developer hay tester bàn bạc về sau. 

User stories sẽ giúp nhóm hiểu những gì người dùng cần. Khi người dùng yêu cầu nhóm xây dựng một tính năng cho sản phẩm/phần mềm có nghĩa là họ cần thực hiện một điều gì đó trong tương lai từ việc phát triển tính năng này. User stories sẽ là công cụ hiệu quả nhất giúp cho team có thể ghi nhớ những nhu cầu của người dùng trong suốt quá trình phát triển tính năng/phần mềm.

User story nên được xây dựng cùng với các bên liên quan, tốt nhất là thông qua một cuộc gặp mặt trực tiếp. User story là một quá trình khám phá yêu cầu thay vì quá trình phân tích yêu cầu đã được đề cập trước.

Trong các cách tiếp cận truyền thống, người phân tích hệ thống (Business Analytics) cố gắng tìm hiểu nhu cầu của người dùng/khách hàng, sau đó chuẩn bị một đặc tả yêu cầu cho hệ thống một cách chi tiết. Đây không phải là cách tiếp cận user story đang nhắm đến. Việc xác định user story giống như một quá trình ghi chú hơn là ghi chép chi tiết. Các bước chính để xác định user stories như sau:

• Thông qua các cuộc thảo luận với người dùng/khách hàng, nhóm sẽ lắng nghe, hiểu vấn đề và nhu cầu của người dùng/khách hàng.
• Sau đó, viết ra nhu cầu của người dùng/khách hàng dưới dạng user story, mô tả ngắn gọn.
• Tất cả các user stories sẽ được tổng hợp lại và trở thành bộ nguồn các yêu cầu.
• Các mô tả chi tiết có thể được điền sau đó, cung cấp cho nhóm các tài liệu tham khảo về yêu cầu của người dùng/khách hàng ở mức độ “vừa đủ” trong suốt quá trình phát triển dự án. 

User stories mô tả cách người dùng sẽ sử dụng phần mềm chỉ trong một vài câu. User story được viết dựa trên việc trả lời ba câu hỏi sau:

• Tính năng đó dành cho ai?
• Họ mong đợi gì từ hệ thống?
• Tại sao tính năng đó quan trọng?

Nhiều nhóm viết user stories trên sticky notes theo định dạng điền vào chỗ trống:

• .

→ Với tư cách là <>, tôi muốn <hành động cụ thể mà tôi đang thực hiện> để <điều tôi muốn xảy ra / kết quả>.

Ví dụ:

Là một [khách hàng], tôi muốn [tính năng giỏ hàng] để [tôi có thể dễ dàng mua các mặt hàng trực tuyến].

Là một [khách hàng], tôi muốn [tính năng nhận SMS khi có hàng] để [tôi có thể đến lấy ngay].

Làm sao để viết user stories

Vì stories được xây dựng với nội dung ngắn gọn và rõ ràng, nên chúng như lời nhắc nhở giúp nhóm liên tục xây dựng các tính năng một cách phù hợp. Mỗi story card có thể được xem là một biểu tượng cho một story giữa nhóm với người dùng/khách hàng để đảm bảo rằng họ xây dựng đúng các tính năng theo yêu cầu.

User stories lập kế hoạch dự án Agilegiúp việc cung cấp, bàn giao phần mềm/sản phẩm có thể kiểm thử một cách dễ dàng, hay nói cách khác user stories cho chúng ta biết rõ ràng rằng một tính năng, hay một phần mềm, một sản phẩm sẽ được vận hành như thế nào.

Trong quá trình lập kế hoạch cho một dự án, Product Owner sẽ làm việc với người dùng/khách hàng cuối để xác định stories. Stories xác định nhu cầu của người dùng/khách hàng và lý do họ yêu cầu tính năng này trong phần mềm/sản phẩm của họ. Chỉ cần viết ra user story là nhóm sẽ hiểu về nhu cầu của người dùng/khách hàng. Khi viết user story thì nhóm có thể chưa biết gì về các chi tiết, họ sẽ sử dụng card như một lời nhắc nhở họ cần tìm ra các chi tiết và lên kế hoạch cho công việc để phát triển nó.

User stories hướng đến cùng một mục đích là giúp nhóm linh hoạt hơn trong việc lên kế hoạch, đưa giao phẩm của dự án tới tay khách hàng càng sớm càng tốt. Và đây là cách họ làm điều đó:

• Card (Thẻ): Đầu tiên, Product Owner viết ra user story (thường sử dụng “As a… I want to… So that…” – như mẫu đã đề cập ở phần trên) và card nhắc nhở họ phải tìm hiểu các chi tiết / tính năng cần được xây dựng.
• Conversation (Trao đổi): Khi ước lượng cho các story, nhóm sẽ có một cuộc trao đổi với Product Owner và đôi khi sẽ là người dùng/khách hàng nhằm tìm ra các chi tiết mà nhóm cần biết. Đôi khi, Product Owner sẽ làm việc với đội ngũ thiết kế và người dùng/khách hàng để tạo ra các bản vẽ mock-ups, hoặc nhóm sẽ tạo ra các bản thiết kế kỹ thuật giúp nhóm đưa ra phương pháp tiếp cận trong việc triển khai cho một story.
• Confirmation (Xác nhận): Tiếp theo, nhóm chuyển sang các bài kiểm tra (tests) mà họ sẽ viết để đảm bảo user story đã được triển khai một cách đúng đắn. Confirmation này là những phản hồi quan trọng được lặp đi lặp lại và thực tế là khi các user stories nhỏ và rõ ràng sẽ giúp cả nhóm và người dùng/khách hàng gia tăng sự đồng ý, thống nhất về các bài kiểm tra/thử nghiệm sẽ được tiến hành. 

Mô hình 3C của User stories

Một số nhóm sẽ viết các tiêu chí chấp thuận của từng user story ở mặt sau user story card. Điều đó giúp nhóm ghi nhớ story sẽ hoạt động như thế nào khi nhóm thực hiện. Nó cũng giúp người dùng/khách hàng và nhóm đi đến thỏa thuận về cách story sẽ hoạt động khi phần mềm/sản phẩm đã sẵn sàng. Những bài kiểm tra này có thể được gọi với cái tên khác là điều kiện để thỏa mãn hoặc tiêu chí để chấp thuận.

Các hướng dẫn để viết user story tốt có thể được tóm tắt bằng các ký tự trong từ INVEST:

• I – Independent (Độc lập): user stories có thể được mô tả tách biệt với nhau.
• N – Negotiable (Thương lượng được): tất cả các tính năng trong một phần mềm/sản phẩm được xem là sản phẩm của quá trình đàm phán.
• V – Valuable (Có giá trị): không có lý do gì để dành thời gian viết user story mà không có giá trị đối với người dùng/khách hàng của bạn.
• E – Estimable (Ước lượng được): mỗi user story cần truyền tải một tính năng mà nhóm có thể ước lượng được, hoặc biết được nỗ lực cần thiết để thực hiện.
• S – Small (Kích thước): user stories nên mô tả các tương tác độc lập, không phải là một tập khổng lồ của các chức năng.
• T- Testable (Kiểm thử được): việc có thể kiểm tra/thử nghiệm từng user story giúp nhóm Scrum lấy được phản hồi một cách hiệu quả.

Hướng dẫn để viết user story

Có 6 trạng thái chính cho mỗi user story trong suốt dự án phần mềm:

• Pending – Đang chờ xử lý: Ở trạng thái này, user stories không có gì khác ngoài một mô tả ngắn về nhu cầu của người dùng. Không có thảo luận chi tiết về các yêu cầu, không có logic hệ thống và chưa có các thiết kế. Trên thực tế, mục đích duy nhất của user story hiện tại chỉ là để nhắc nhở tất cả các bên về cuộc thảo luận trong tương lai trình bày về yêu cầu của người dùng được viết trong user story này và thậm chí có thể user story này sẽ bị loại bỏ trong tương lai.
• To-do – Cần Làm: Thông qua một cuộc thảo luận giữa các bên liên quan, user stories sẽ được giải quyết trong vài tuần tới, được quyết định đưa vào một Sprint. User stories trong giai đoạn này được cho là ở trạng thái việc cần làm. Không có thảo luận chi tiết nào được thực hiện trong trạng thái này.
• Khi user story ở trạng thái này, người dùng/khách hàng sẽ làm việc với Development team để xác nhận các yêu cầu cũng như để xác định các tiêu chí chấp thuận cho một story. Development team sẽ viết ra các yêu cầu hoặc bất kỳ quyết định nào dưới dạng ghi chú. Chuyên gia UX (user experience) có thể tạo wireframes (bản vẽ phác thảo) hoặc storyboards (bảng phân cảnh) để cho phép người dùng/khách hàng xem trước các tính năng được đề xuất thông qua mô phỏng trực quan và để khách hàng cảm nhận nó. Quá trình này được gọi là thiết kế trải nghiệm người dùng (thiết kế UX).
• Sau khi các yêu cầu được làm rõ, Development team sẽ thiết kế và triển khai các tính năng để đáp ứng các yêu cầu của người dùng/khách hàng.
• Khi Development team đã triển khai xong user story, user story sẽ được xác nhận bởi người dùng cuối. Người dùng cuối sẽ được cấp quyền truy cập vào môi trường thử nghiệm hoặc một sản phẩm phần mềm bán hoàn chỉnh (đôi khi đượ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 tiêu chí chấp thuận được viết chi tiết trong user story. Cho đến khi việc xác nhận được thực hiện, user story được cho là ở trạng thái Confirming.
• Cuối cùng, tính năng được xác nhận đã xong, user story được xem xét ở trạng thái Hoàn thành – . Thông thường, đây là kết thúc của user story. Nếu người dùng/khách hàng có một yêu cầu mới, về một tính năng mới, hoặc một cải tiến của user story đã hoàn thành, nhóm sẽ tạo user story mới cho lần lặp tiếp theo.

Tổng kết

Cũng giống như nhiều công cụ hỗ trợ việc phát triển phần mềm/sản phẩm khác, nếu bạn áp dụng đúng user story trong dự án của mình, bạn sẽ có thể tạo ra một phần mềm/sản phẩm chất lượng cộng với việc gia tăng sự tin tưởng và hài lòng từ phía khách hàng. Dưới đây là một số điểm bạn cần lưu ý khi sử dụng user story:

• Giữ mô tả về user story ngắn gọn.
• Suy nghĩ dựa trên quan điểm của người dùng cuối khi viết một user story.
• Các tiêu chí chấp thuận (hoặc DoD – Definition of Done) phải được xác định trước khi bạn bắt đầu triển khai.
• Ước lượng 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 kiểm soát.
• Giữ mối quan hệ tốt với người dùng cuối sẽ có lợi cho cả hai bên.
• Quá trình trao đổi rất quan trọng giúp nhóm có thể hiểu những gì người dùng cuối yêu cầu.

Chúng tôi sẽ tiếp tục chia sẻ về các công cụ còn lại một cách cụ thể (đã được nhắc đến ở đầu bài) trong các bài viết tiếp theo, bạn đọc đừng bỏ lỡ!

Kiến thức tổng hợp bởi Masterskills (PMP, PMI-ATP Instructor)

References: PMI-ACP Exam Prep, Head First Agile, Visual-Paradigm