Ngày hôm nay chúng ta cùng khám phá hiểu lầm về việc Product Backlog được “ưu tiên”, “sắp xếp theo thứ tự ưu tiên” hay “sắp xếp theo tầm quan trọng”.
Giải mã hiểu lầm
Hướng dẫn Scrum (Scrum Guide) đã nói ra rằng “Product Backlog là một danh sách có thứ tự” của tất cả mọi việc cần được đưa vào trong sản phẩm. Đó không phải là một danh sách được ưu tiên hóa. Sự khác biệt giữa hai cách hiểu dù nhỏ, nhưng hậu quả để lại có thể rất lớn. Trong thực tế, sau khi đọc bài này bạn sẽ thấy việc sắp xếp thứ tự các hạng mục đơn lẻ dựa theo sự ưu tiên thường không phải là các tốt nhất để tối đa hoá giá trị.
Để công bằng hơn, hiểu lầm này mô tả cách Scrum không ngừng cải tiến và thay đổi (như được nêu ra trong Hướng dẫn Scrum). Trước năm 2011, Khung làm việc Scrum đã xác định Product Backlog như là một “danh sách ưu tiên”. Điều này đã thay đổi sau năm 2011, trong đó phản ánh rõ ràng hơn cách mà việc sắp xếp thứ tự các hạng mục của Product Backlog được tính toán
Ưu tiên hay thứ tự
James Coplien có một cách nhằm phân biệt rõ ràng hai định nghĩa tưởng chừng như giống nhau này trở nên rõ ràng hơn, ông lấy ví dụ của việc xây dựng một ngôi nhà ở các vùng nhiệt đới. Tại đây thường hay xảy ra mưa lớn vào các buổi chiều, do vậy xây một mái che là vô cùng quan trọng và cần thực hiện càng sớm càng tốt. Product Backlog cho ngôi nhà của bạn sẽ bao gồm tất cả các hạng mục để tạo thành một ngôi nhà, ví dụ – cửa ra vào, cửa sổ, tường, và hiển nhiên có mái nhà. Nếu bạn được lệnh sắp xếp Product Backlog đơn lẻ theo sự ưu tiên, mái ngói chắc chắn sẽ nằm trên đầu danh sách. Chúng nhằm giúp bạn tránh mưa. Nhưng việc sắp đặt này không phải cách bạn thực sự định xây nhà như thế nào. Bạn không thể xây một mái nhà bền vững mà không có các bức tường, càng không thể xây tường nếu chưa làm nền móng. Thứ tự của Product Backlog sẽ bị ảnh hưởng bởi các yếu tố như sự phụ thuộc lẫn nhau, sử dụng hiệu quả nguyên vật liệu, sự sẵn có của các bên thứ ba và các yếu tố xây dựng. Nếu chỉ sắp đặt dựa trên mức độ ưu tiên sẽ không giúp bạn có được một ngôi nhà an toàn, ổn định và vững chắc để vượt qua những buổi chiều mưa to gió lớn.
Tập trung vào Thứ tự (hơn là Ưu tiên) cũng nhấm mạnh vai trò thường trực của một Product Owner trong việc sắp xếp thứ tự và tái-sắp-xếp thứ tự của công việc khi muốn tối đa hoá giá trị. Nếu một Product Backlog đơn giản chỉ là một danh sách ưu tiên, rất dễ để đưa đến một kết luận kiểu “15 tính năng này cần được đặt Ưu tiên cao, 23 tính năng kia thì ở ưu tiên ở mức độ trung bình, 10 tính năng khác thì ưu tiên thấp hơn”. Đồng thời dễ dẫn đến việc một Product Owner tự cho rằng, tính năng có ưu tiên cao được chuyển giao ở kì Sprint nào cũng được (không phải là vấn đề), miễn là chúng được “ưu tiên” chuyển giao trước những hạng mục khác. Việc này nghiễm nhiên đã đóng lại những cơ hội cho việc tối đa hoá giá trị, giống như ở ví dụ trên về mái nhà. Chúng ta đã tạo sai lầm ngay từ lúc đặt câu hỏi cho Product Owner về những Hạng mục mà anh ấy cảm thấy quan trọng nhất, bởi vì chúng sẽ quyết định thứ tự trong Product Backlog – “Tất cả đều quan trọng đối với tôi. Tôi không muốn phải đưa ra lựa chọn.” là một câu trả lời tệ hại. Bằng cách đóng khung Product Backlog như một danh sách ưu tiên, chúng ta đã đơn giản hoá vai trò của một Product Owner. Thay vào đó, chúng ta hay hỏi “Việc sắp xếp thứ tự các hạng mục sẽ giúp bạn đạt được lợi nhuận nhanh chứ?”
Bằng cách đóng khung Product Backlog như một danh sách ưu tiên, chúng ta đã đơn giản hoá vai trò của một Product Owner.
Cuối cùng, tập trung vào thứ tự (hơn là ưu tiên) nhấn mạnh rằng khi sắp xếp thứ tự của các hạng mục cần thực hiện, Product Backlog cần được xem xét một cách toàn diện. Product Backlog thể hiện thứ tự của việc chuyển giao các hạng mục, do vậy cũng thể hiện cách giá trị được tạo ra theo thời gian. Mọi thay đổi về thứ tự, tạo ra các thay đổi về giá trị. Nếu chúng ta chỉ đơn giản tập trung vào ưu tiên, ta sẽ bị “chìm” trong các nỗ lực tối đa hoá giá trị nhỏ, ví dụ như hai hạng mục được ưu tiên có liên quan tới nhau, “Hạng mục này quan trọng hơn hạng mục kia?”.
Các nhân tố ảnh hưởng tới thứ tự
Có vô số những nhân tố ảnh hưởng tới thứ tự tiềm năng của một Product Backlog, bao gồm:
- Sự phụ thuộc lẫn nhau giữa các hạng mục Product Backlog, sự phụ thuộc giữa các bộ phận nội bộ với Nhóm Phát triển cũng có thể ảnh hưởng tới thứ tự. Một số hạng mục nhất định có thể thực thi dễ dàng hơn nếu các hạng mục khác được thực hiện trước. Hoặc bên cung cấp cần thực hiện một công việc trước khi các hạng mục được hoàn thành;
- Những rủi ro liên quan tới việc thực thi hoặc không thực thi một hạng mục cụ thể. Có lẽ việc triển khai một hạng mục sẽ giúp chúng ta học hỏi thêm về sản phẩm mà chúng ta đang phát triển. Một công nghệ cụ thể có đưa ra nền tảng tốt cho sự phát triển trong tương lai không? Người dùng có phản hồi tốt với mẫu thử của tính năng mới trước khi đưa vào công việc thực tế hay không?
- Kiến thức của một Nhóm Phát triển cũng cần tính đến. Việc triển khai một hạng mục có thể giúp cho nhóm học thêm điều mới cần thiết cho sự phát triển xa hơn. Hoặc một số hạng mục chỉ có thể thực thi khi Nhóm Phát triển đạt được kiến thức cần thiết;
- Các nhu cầu của khách hàng ảnh hưởng tới thứ tự, bởi vì các hạng mục chỉ ra được nhu cầu khách hàng sẽ tạo ra các giá trị cho công việc kinh doanh của chúng ta ( ví dụ: gia tăng doanh số, lợi nhuận, thu hút một nhóm khách hàng mới …);
- Chi phí của việc thực thi cũng ảnh hưởng tới thứ tự. Có lẽ, những việc trong Product Backlog một khi thực hiện được sẽ đơn giản các công việc của các hạng mục tương lai. Giống như việc thiết lập các luồng triển khai liên tục, tái cấu trúc các thành thần của sản phẩm hoặc thực thi các script nhập tự động. Chi phí cũng cần phải cân nhắc tùy theo các hạng mục cá nhân, bởi vì có thể chi phí phát triển lớn hơn nếu so sánh với độ ưu tiên/ giá trị/ rủi ro;
- Các điều kiện kinh doanh có thể thay đổi, yêu cầu một vài hạng mục phải thay đổi thứ tự lên hoặc xuống trong Product Backlog;
- Chi phí trì hoãn cũng ảnh hưởng tới thứ tự. Donald Reinertsen coi đây là chi phí trì hoãn việc thực thi một tính năng nào đó.
Sameer Patil đã viết một bài sâu hơn về những điều cần cân nhắc khi sắp xếp thứ tự trong Product Backlog. Thông điệp chính ở đây là chúng ta cần liên tục sắp xếp thứ tự và tái-sắp-xếp thứ tự nhằm tối đa hoá giá trị được chuyển giao sau mỗi Sprint. Nhưng điều gì được coi là giá trị sẽ phụ thuộc vào các nhân tố nêu trên. Scrum không và không thể đưa ra một kĩ thuật có thể giải quyết tất cả các trường hợp nhằm tạo ra được một thứ tự “tốt nhất”.
Thủ thuật
- Là một ScrumMaster, bạn có thể giúp Product Owner đưa ra một thứ tự tối ưu nhất bằng cách đặt các câu hỏi đúng: “Hạng mục nào đi đúng các mong đợi lớn nhất mà chúng ta đang thực hiện? ”, “Nếu anh dừng ba Sprint từ bây giờ, hạng mục nào chắc chắn cần có?”, “Nếu anh chỉ có thể giữ 20% trong Product Backlog, những hạng mục nào anh sẽ giữ?” Hoặc “Làm thế nào chúng ta tối ưu thứ tự để xác định được các phụ thuộc?”
- Liberating Structure ‘Min Spec’ có thể được dùng để giúp nhận ra những hạng mục chắc chắn cần hay không cần thiết cho việc thành công.
- Là một Scrum Master, giúp Product Owner tìm ra các chiến lược khác để sắp xếp thứ tự các hạng mục Product Backlog, huấn luyện Product Owner giám sát thứ tự thường xuyên, dựa trên các thông tin hữu ích có phát sinh trong được trong quá trình phát triển.
- Sơ kết Sprint là một cơ hội tuyệt vời để thanh tra và thay đổi thứ tự Product Backlog cùng với Nhóm Phát triển và các bên liên quan;
Lời kết
Trong bài này, chúng ta đã giải mã hiểm lầm rằng Product Backlog được ”ưu tiên hóa”. Dù với sự thay đổi nho nhỏ về từ ngữ, nhưng Product Backlog được hiểu là “một danh sách được sắp xếp theo thứ tự”. Bằng cách mặc định Product Backlog là “danh sách ưu tiên”, chúng ta đã rút gọn vai trò quan trọng của Product Owner cần thể hiện. Anh ấy/cô ấy cần có trách nhiệm liên tục trong việc tạo ra thứ tự/ tái-sắp-xếp thứ tự của Product Backlog nhằm tối đa hoá giá trị chuyển giao trong mỗi Sprint khi triển khai công việc, hay khi có những thông tin hữu ích tìm thấy. Kết luận, chúng tôi đã đưa ra một vào thủ thuật giúp bạn hiểu được Product Backlog ở một bức tranh rộng hơn.
Bạn nghĩ gì về hiểu lầm này? Bạn có đồng ý với những nhận định trên? Và bạn đã học được những gì?
Nguồn: medium.com
