Hiều lầm mà ngày hôm nay chúng ta nghiên cứu sẽ lấy được lấy từ nhóm mà chúng tôi làm việc cùng gần đây. Trong Product Backlog của họ có một hạng mục như sau: “Là một nhà thiết kế, tôi muốn tạo ra một bản hướng dẫn về phong cách (style), để giúp cho tất cả các nhà phát triển có thể tự thực hiện được những thiết kế đơn giản.” Khuôn mẫu phổ biến của một user story như sau: “Là [ai/vai trò gì đó] tôi muốn [hành động/chức năng gì đó] để [lí do/mục đích gì đó]”. Ngoài ra, có các ví dụ tương tự khác: “Là một khách viếng thăm, tôi muốn xem trang web trên điện thoại di động, để tôi có thể xem trên đường về nhà” và “Là một lập trình viên tôi muốn có một API, để tôi có thể truy vấn các lệnh từ backend của ứng dụng.” Tại sao lại không viết ba hạng mục trên ngắn gọn hơn theo cách như sau: “Tạo hướng dẫn phong cách”, “Hỗ trợ các thiết bị điện thoại di động”, và “Cho phép truy vấn các lệnh từ backend (API) ”. Thay vào đó, họ phải tốn công sức để trình bày tất cả mọi thứ trong Product Backlog theo định dạng là các user story.
Khi chúng tôi thử thách họ thực hiện theo cách trên, họ trả lời rằng đó là cách họ hiểu về Scrum. Họ đã được giải thích rằng Product Backlog bao gồm các user story. Ngay cả khi cảm thấy như bị bắt buộc phải thực hiện và khiến nhóm chán nản vì các “nghĩa vụ hành chính” trong việc trình bày các nhiệm vụ hiển nhiên sang thành các user story.
Ngày hôm nay, chúng ta sẽ giải mã hiểu lầm này bằng cách quay trở lại với mục đích của Product Backlog và các user story. Trong quá trình tìm hiểu, chúng ta cũng sẽ giải đáp một hiểu lầm khác có quan hệ mật thiết tới hiểu lầm này; đó là các user story là một phần cần thiết vốn có của Scrum.
Giải mã hiểu lầm
Theo Hướng dẫn Scrum (Scrum Guide), Product Backlog bao gồm tất cả các tính năng, chức năng, yêu cầu, nâng cấp và sửa chữa mà có ta có thể tạo ra các thay đổi đối với sản phẩm trong các bản phát hành tương lai. Nói một cách ngắn gọn, Product Backlog bao gồm các tất cả các công việc cần thiết cho sản phẩm.
Cách mà các Nhóm Scrum quyết định thực hiện công việc này như thế nào sẽ phụ thuộc hoàn toàn vào nhóm. Họ có thể viết các user story, sử dụng một loạt các từ khoá, viết các đối tượng người dùng hay thậm chí vẽ ra hình ảnh. Như tôi đã nhấn mạnh trong các bài viết trước, Khung làm việc Scrum chỉ mô tả những việc cần phải hoàn thành, nhưng lại không nhấn mạnh chúng cần được hoàn thành như thế nào. Trong thực tế việc phát triển sản phẩm quá phức tạp để đưa ra một giải pháp hoàn hảo cho tất cả.
Đôi điều về user story
Theo năm tháng, user story đã trở thành một kĩ thuật “đáng tin cậy” đối với hầu hết các nhóm Scrum. Cách thực hiện của họ hầu như dựa nhiều vào các thực hành được nhắc đến trong sách, các trang blog (bao gồm cả trang của chúng tôi) và từ các huấn luyện viên. Giống như ý nghĩa của chúng, các user story được nhắc đến như những “best practice”.Việc sử dụng các user story trở nên phổ biến trong phương pháp XP (eXtreme Programming) từ năm 1998 bởi Alistair Cockburn. Cùng với sự nổi tiếng của Scrum, không có gì ngạc nhiên khi user story mang tới Scrum những ý tưởng khác từ XP (như Điểm và Stand-up).
Khá dễ để hiểu sự thịnh hành của user story. Chúng khác xa với các đặc tả mở rộng về các cách tiếp cận dựa trên kế hoạch. Thay vì cố nắm bắt mọi chi tiết của một tính năng bằng các yêu cầu/đầu mục dài cả trang, các user story đơn thuần mô tả bản chất của các tính năng dưới góc nhìn của một người dùng: “Là người mua hàng, tôi muốn đặt sản phẩm tôi quan tâm vào giỏ hàng để tôi có thể mua nhiều sản phẩm cùng một lúc”. Sức mạnh của user story nằm ở sự đơn giản. Theo thiết kế, chúng có khả năng cho phép triển khai mọi chi tiết từ những thứ cần dùng. Khi mà một Nhóm Scrum bắt đầu làm việc với Product Backlog, chuyển giao các hạng mục như một phần của các Phần tăng trưởng, họ sẽ cần thảo luận về những việc cần thực thi cho một hạng mục sắp tới mà user story đó mô tả. Nhưng họ sẽ có một cuộc thảo luận như vậy khi họ chuẩn bị thực hiện, chứ không phải ngay tại lúc bắt đầu. Các hạng mục trong một Product Backlog cần có gợi mở để thảo luận trong tương lai, dựa trên các kiến thức, thông tin hữu ích tiếp thu từ lúc đó. Việc này rất tương đồng với lối tiếp cận thực nghiệm của Scrum trong phát triển sản phẩm và với Mô hình hình nón về sự bất định (Cone of Uncertainty).
Download Ebook Scrum Căn bản
Các kĩ thuật để nắm vững công việc trong Product Backlog
Chúng ta có thể kết luận rằng không có vấn đề gì với user story. Đây là môt kĩ thuật tốt để nắm bắt các yêu cầu chức năng, nhưng cần hiểu theo nghĩa “đủ tốt để dùng”, và chúng có chỗ dành cho các thảo luận sâu hơn trong tương lai. Nhưng Scrum không ép buộc/yêu cầu phải thực hiện. Các kỹ thuật khác cũng rất tốt, miễn là chúng giúp thúc đẩy ba thứ:
- Chúng giúp cho Product Backlog có-thể-hiểu được đối với Nhóm Scrum và các bên liên quan. Bên liên quan có thể hiểu được Product Backlog và có cái nhìn tốt về những điều sắp đến và những việc cần đề xuất.
- Mức độ chi tiết mà những kĩ thuật này yêu cầu cần phù hợp với tính bất ổn trong phát triển sản phẩm. Các hạng mục cần hoàn thành muộn hơn nên đòi hỏi ít chi tiết hơn các hạng mục cần phải thực hiện sớm trong một Sprint.
- Chúng nên khuyến khích các giao tiếp, hội thoại liên tục giữa Nhóm Scrum và các bên liên quan (mà bao gồm cả người dùng)
Một vài công việc có thể được giải trình bằng vài từ khoá hay một câu ngắn gọn. Nếu cả Nhóm Scrum và các bên liên quan hiểu ý nghĩa của cụm từ “Responsive Website”, tại sao lại phải bắt buộc phải đưa ra định dạng user story như đã nhắc tới ở phần giới thiệu. Và các công việc kĩ thuật thì sao? Giống như việc xây dựng một API hay là thiết lập hạ tầng? Nếu được sử dụng ở mức trung bình, một mô tả về kĩ thuật của một công việc sẽ tốt nếu như chúng được thực hiện theo cách dễ hiểu nhất, đơn giản nhất. Có rất ít giá trị trong một user story mơ hồ kiểu “Là một công ty, chúng tôi muốn ba thể hiện của một trang web, do vậy việc nếu một thể hiện bị sập sẽ không khiến tất cả mọi thứ phải dừng hoạt động”. Nếu câu này cũng được hiểu như sau “Thiết lập Cân bằng tải cho trang” trên giấy ghi chú. Nhìn tổng thể Product Backlog cần phải dễ hiểu đối với Scrum và đối với các bên liên quan và điều này không có nghĩa là mọi hạng mục cũng phải như vậy. Product Backlog vẫn là câu hỏi mở chưa có đáp án.
Dĩ nhiên Product Backlog cần phải dễ hiểu với nhóm Scrum và các bên liên quan nhưng không cần thiết mọi sản phẩm đơn lẻ đều phải như vậy.
Một Product Backlog tốt cần có sự pha trộn của các hạng mục. Một vài hạng mục là về các nhiệm vụ kĩ thuật (ví dụ như “Cài đặt một server mới” hoặc “Tạo lịch backup cho cơ sở dữ liệu”), trong khi các nhiệm vụ khác có thể thuộc về phần chức năng (ví dụ “Người đăng kí có thể lưu trữ các hạng mục trong danh sách đọc của họ để đọc vào thời điểm khác”). Các user story là một cách tốt để nắm bắt được các yêu cầu về chức năng nếu chúng nảy sinh tự nhiên ngay từ lúc đã được nhận định ở trong các cuộc thảo luận, và phải không tạo cảm giác ép buộc hay đó là “một nhiệm vụ hành chính”. Nếu cảm thấy như bị bắt buộc phải thực hiện theo một khuôn mẫu user story, bạn cũng nên cân nhắc tới các kĩ thuật khác.
Thủ thuật
- Nếu thấy mình áp đặt các yêu cầu vào một mẫu user story có sẵn, cân nhắc lại mục đích của story đó. Đây có phải là cách tốt nhất để khiến Product Backlog có-thể-hiểu-được với cả Nhóm Scrum và các bên liên quan?
- Một mẫu user story chỉ mang tính chất hướng dẫn. Bạn không sai khi viết nhanh gọn như kiểu “Khách viếng thăm có thể đăng kí nhận tin”;
- Khám phá những cách khác để thể hiện các yêu cầu trong Product Backlog.Thay vì sử dụng các user story, chúng tôi thích đặt những câu hỏi này hơn cho mọi hạng mục: “Điều gì biến thành “khả thi” hay “dễ dàng hơn” sau khi thực thi xong hạng mục này?”. Chúng tôi viết câu trả lời và gọi là “Các Thẻ Tính Năng”. Mặt sau của tấm thẻ bao gồm 2 câu hỏi chi tiết hơn, chúng thường được trả lời trong buổi Lập kế hoạch Sprint hay buổi họp Làm mịn Product Backlog: “Tiêu chí gì áp dụng với tính năng này?” (Ví dụ: Tiêu chí chấp nhận) và “Làm thể nào mà chúng ta biết được tính năng này hoạt động như dự kiến?” (Ví dụ:Các trường hợp thử). Một lần nữa, đây cũng chỉ là một kĩ thuật;
- Bản chất của user story được thể hiện khá rõ ràng trong một môi trường none-IT. Chúng được dùng để nắm bắt các yêu cầu thuộc về chức năng, bản mẫu không phải sẽ hữu ích cho tất cả lĩnh vực nào ngoài lĩnh vực IT. Điều này thường đẫn tới các hạng mục thường định hướng nội bộ, không rõ ràng hoặc được thể hiện khá kì quặc. Ví như “Là một Marketer, tôi muốn gửi một email tới nhóm X để họ biết được các Sản phẩm mới” hoặc “Là một thành viên nhóm, tôi muốn viết một bản kế hoạch để thấy cách mà Y có thể được hoàn thành”. Chúng tôi thích yêu cầu các nhóm none-IT nên tập trung vào việc đặt các đầu ra mà họ muốn đạt được trong Product Backlog, chứ không phải việc họ định làm, ví dụ như “Nhắc nhở Nhóm X về các sản phẩm mới” và “Chiến lược để đạt được Y”.
Lời kết
Trong bài này, chúng ta đã giải mã được hiểu lầm về việc phải đưa toàn bộ các hạng mục Product Backlog theo định dạng user story. Bằng cách mô tả mục đích, đặc tính của Product Backlog, chúng ta cũng giải đáp hiểu lầm liên quan – rằng user story là một phần cần thiết, vốn có của Scrum.
Bạn có nhận định gì về hiểu lầm này? Bạn có đồng ý/ không đồng ý với bài viết này? Hãy để lại lời nhận xét bên dưới cho chúng tôi.
Nguồn: medium.com
