Product Backlog là nơi lưu trữ danh sách các tính năng mong muốn của sản phẩm. Danh sách này được sắp xếp dựa trên độ ưu tiên của từng hạng mục. Các hạng mục có độ ưu tiên cao hơn nằm ở phía trên của danh sách và sẽ được Nhóm Phát triển lựa chọn để đưa vào sản xuất sớm, các hạng mục có độ ưu tiên thấp hơn sẽ nằm ở phía cuối của danh sách và được phát triển muộn hơn.
Product Backlog và User Story là 2 trạng thái quan trọng được áp dụng triệt để khi làm việc. Ở mỗi bước sẽ có cách thực hiện khác nhau, dưới đây là quy trình dành cho bạn.
Nội dung bài viết
Product Backlog là gì?
Product backlog là một danh sách các yêu cầu, tính năng và công việc cần thực hiện để phát triển hoặc nâng cấp sản phẩm. Nó được quản lý và sắp xếp thứ tự bởi Product Owner.
Product backlog là một phần quan trọng của Scrum, một framework phát triển phần mềm linh hoạt. Scrum sử dụng product backlog để xác định tầm nhìn cho sản phẩm, ưu tiên các tính năng và công việc, và theo dõi tiến độ phát triển.
Thu thập yêu cầu tạo Product Backlog
Trong giai đoạn bắt đầu dự án, Product Owner gặp những người đại diện cho các bên liên quan, cố gắng hiểu những gì họ cần và chuyển chúng thành các yêu cầu cho sản phẩm phần mềm mới. Có hai phương án tiếp cận thực hiện:
- Top-down: bắt đầu từ mức Rừng (SP tổng thể) => SP mới sẽ bao gồm những gì (có những cây nào trong rừng của bạn) => Xác định các cành của mỗi cây => Xác định lá trên mỗi cành…
- Bottom-up: hỏi người dùng liệt kê tất cả những user story (hoặc lá) mà họ nghĩ đến trước tiên, nhóm chúng lại với nhau, sử dụng phép loại suy “rừng và cây” để lấy từ lá cho đến cành, rồi từ cành cho đến cây, và sau cùng từ cây cho đến rừng.
Các yêu cầu thu thập được viết ra dưới dạng các User story (bản tóm tắt nhu cầu người dùng). Người ta thường dùng một khuôn mẫu nhất định để viết User story cho phép ta biết được yêu cầu của khách hàng là gì, ai sẽ là người sử dụng chức năng đó, nhằm mục đích gì. Một trong các mẫu ấy là:
Là <người dùng cụ thể \ vai trò> , tôi muốn <làm gì đó> để <phục vụ mục đích nào đó>.
Ví dụ: Là quản trị của diễn đàn, tôi muốn xóa một người dùng phạm quy nghiêm trọng để tránh gây gại cho diễn đàn.
Tiêu chí của một User story hoàn chỉnh (nhóm hoàn thành công việc viết các User story để lập KH):
- Liên quan đến tất cả các tầng của ứng dụng và nó không thể chia thành những Story nhỏ nữa.
- Có thể chuyển thành các công việc (4-8h) từ Story đó để bắt đầu việc phát triển.
- Nhóm có thể bắt đầu ước tính điểm của Story đó.
Đọc thêm:
Khách hàng (hoặc Product Owner) có thể viết user story, nhưng sẽ tốt hơn là nhóm phát triển cộng tác với khách hàng trong buổi làm việc User Story Writing Workshop tập trung. Khi đó, bên cạnh việc viết ra các User Story, cả nhóm có điều kiện trao đổi, tìm hiểu sâu về các yêu cầu của hệ thống, giúp cho quá trình phát triển sau này.
Quy tắc CUTFIT là một trong những cách để đảm bảo các yêu cầu được viết đúng
- Nhất quán (Consistent): không mâu thuẫn với các yêu cầu khác
- Không mơ hồ (Unambiguous): có thể diễn giải nó theo một cách duy nhất trong mọi trường hợp
- Kiểm thử được (Testable): phải có khả năng tạo ra các test case cho một yêu cầu
- Khả thi (Feasible): phải triển khai được từng yêu cầu trong những khả năng và hạn chế đã biết
- Độc lập (Independent): không có chuyện User story này phụ thuộc vào User story kia
- Theo dõi được (Traceable): bạn phải có khả năng liên kết từng yêu cầu đến với người dùng và mục đích của họ.
Không chỉ phục vụ cho việc thể hiện chính xác nhu cầu của người dùng, User Story còn là công cụ để triển khai việc kiểm thử chấp nhận (acceptance test). Khi đó, User Story có thể thêm điều kiện kiểm thử chấp nhận Ví dụ: Là quản trị của diễn đàn, tôi muốn xóa một người dùng phạm quy để tránh di hại về sau cho diễn đàn. Sau khi xóa xong, người dùng không thể truy xuất hệ thống sử dụng tài khoản đã xóa, các bài viết của người này trên diễn đàn cũng bị hủy khỏi diễn đàn.
Từ đây có thể dễ dàng trả lời câu hỏi User Story là gì?
User Story là một bản tóm tắt nhu cầu người dùng. Đây là công cụ được sử dụng phổ biến trong Extreme Programming, Scrum và các phương pháp Agile khác để thể hiện nhu cầu người dùng. Thông thường, user story do khách hàng, hoặc đại diện của khách hàng, người thực sự hiểu nghiệp vụ và nắm bắt được chính xác yêu cầu của mình đối với nhóm phát triển.
Thường thì, các User Story rất đơn giản, viết trên các thẻ index loại nhỏ hoặc các miếng giấy dán sticky note. Có nhóm dán các User Story này lên bảng, chính là các task board hay các Product Backlog; có nhóm kẹp lại và cất giữ ở nơi phù hợp để nhóm có thể đem ra đọc và thảo luận dễ dàng.
Ước lượng điểm User Story
Xác định UP (Unadjusted Point): Là tổng điểm của các tiêu chí đánh giá Loại tương tác, Qui tắc nghiệp vụ, Số lượng thực thể và Hệ số thao tác dữ liệu.
1. Loại tương tác
Đơn giản (1): giao diện được định nghĩa rõ ràng (tương tác với ứng dụng khác)
Trung bình (2): Giao diện động
Phực tạp (3): tương tác với con người
2. Quy tắc nghiệp vụ
Một qui tắc nghiệp vụ là một chỉ thị cho bạn biết khi nào bạn có thể hoặc không thể làm gì
Đơn giản (1): 1 qui tắc
Trung bình (2): 1-3 qui tắc
Phức tạp (3): >3 qui tắc
3. Số lượng thực thể
Số lượng thực thể cần thiết để thực thi User story
Đơn giản (1): 1 thực thể
Trung bình (2): 1-3 thực thể
Phức tạp (3): >3 thực thể
4. Hệ số thao tác dữ liệu (CRUD)
Đơn giản (1): đọc, xóa
Trung bình (2): tạo
Phức tạp (3): cập nhật
Xác định ED (Environment Dimension)
Tính điểm ED dựa trên các yếu tố như sau (cho điểm 0-2 cho mỗi yếu tố):
- Khía cạnh tổ chức
- Đã có những phòng ban khác nhau cùng làm việc thành công trong 1 dự án Scrum?
- Có sự chống đối mạnh mẽ với Scrum trong tổ chức?
- Có tồn tại sự hỗ trợ lớn về Scrum giữa những phòng ban khác nhau trong công ty?
- Khía cạnh hạ tầng phát triển
- Kiểm thử tự động đã được áp dụng và trở thành một kỹ thuật phổ biến hay chưa?
- Kiểm thử tích hợp liên tục đã được áp dụng và trở thành một kỹ thuật phổ biến chưa?
- Môi trường build hàng ngày đã được áp dụng và trở thành một kỹ thuật phổ biến chưa?
- Khía cạnh nhóm
- Scrum là hoàn toàn mới đối với nhóm?
- Có phải trước đó cá thành viên trong nhóm đã từng làm việc thành công với nhau?
- Cách thành viên trong nhóm hiểu và tôn trọng lẫn nhau?
- Khía cạnh công nghệ:
- Nhóm phát triển có nhiều kinh nghiệm với ngôn ngữ lập trình?
- Các thành viên trong nhóm phát triên có nhiều kinh nghiệm với công nghệ được dùng?
- Môi trường chạy ứng dụng thực tế với scrum đã sẵn sàng?
- Khía cạnh qui trình:
- Scrum có phải là qui trình được chấp thuận trong công ty hay không?
- Trong công ty có sự hỗ trợ tốt cho Scrum hay không?
- Trong công ty có sự phản đối đáng kể nào đối với Scrum hay không?
- Khía cạnh nghiệp vụ:
- Có một Product Owner nào hoàn toàn sẵn sàng và gắn bó với nhóm hay không?
- Có một Product Owner đã quen thuộc với Scrum nhưng vẫn thiếu kinh nghiệm thực tế?
- Product Owner đã từng thành công với Scrum trước đây hay chưa?
Tính điểm cho mỗi Story
1. Tính hệ số nhân (C)
Nếu ED nằm giữa 0 và 11 thì C=2
Nếu ED nằm giữa 12 và 23 thì C=1
Nếu ED nằm giữa 24 và 36 thì C=1/2 (môi trường giúp nhóm chuyển giao được nhiều story hơn trong một Sprint)
2. Tính điểm đã hiệu chỉnh (AP)
AP = UP * C
3. Điểm cho mỗi Story:
PPS = AB * ED / 36
