Product Backlog là gì? Có quan hệ như thế nào với WBS?
Người ta tin rằng cấu trúc phân chia công việc (WBS) đã xuất hiện kể từ khi các kim tự tháp được xây dựng ở Ai Cập, và product backlog là phát minh mới của những người trẻ tuổi để có thể lên kế hoạch một cách vội vàng nhưng vẫn chính xác. Tuy nhiên, như mọi sự việc khác, sự thật luôn phức tạp hơn bạn tưởng.
Năm 1957, Kỹ thuật Ước lượng và Đánh giá Chương trình (Program Evaluation and Review Technique – PERT) được Bộ Quốc phòng Mỹ (DoD) tạo ra và mô tả các nhiệm vụ tạo thành các danh mục định hướng sản phẩm. Tuy nhiên, họ không sử dụng thuật ngữ “cấu trúc phân chia công việc” hay WBS cho đến năm 1962 khi DoD, NASA và ngành hàng không vũ trụ xuất bản một tài liệu về PERT trong đó có mô tả về phương pháp WBS.
Trong khi đó, vào năm 1960, Tom Gilb đã mô tả phương pháp phân phối giá trị tiến hóa của mình (Evolutionary Value Delivery approach, hay gọi tắt là Evo) được chấp nhận rộng rãi để trở thành tiền thân của các phương pháp agile. Evo bao gồm các nguyên tắc như:
– Nguyên tắc 1: Phân tách theo kết quả thực hiện và các bên liên quan – Chia nhỏ công việc thành các bước phân phối giá trị nhỏ (hàng tuần).
– Nguyên tắc 2: Thực hiện những bước có tính rủi ro cao trước tiên – Ưu tiên công việc dựa trên rủi ro.
– Nguyên tắc 3: Tập trung vào việc cải thiện các mục tiêu có giá trị nhất của bạn trước tiên – Đồng thời cũng ưu tiên công việc dựa trên giá trị doanh nghiệp.
Những ý tưởng này đã trở thành những khái niệm về backlog trong các cách tiếp cận và khuôn khổ agile ngày nay.
Vì vậy, chúng ta có thể theo dõi các phương pháp cùng một lúc và cũng tự tin rằng những ý tưởng này đã được thiết lập vững chắc từ lâu trước đó. Việc xây dựng các kim tự tháp và các thành phố La Mã đòi hỏi nhiều cấp độ lập kế hoạch, phân rã công việc và phối hợp nhiệm vụ. Có rất ít tranh cãi về việc liệu WBS hay backlog xuất hiện trước vì nó rõ ràng còn nhiều yếu tố khác.
Ngày nay, tiêu chuẩn thực hành PMI cho các cấu trúc phân chia công việc (PMI Practice Standard for Work Breakdown Structures) định nghĩa WBS là một phân rã phân cấp (hierarchical decomposition) của toàn bộ phạm vi công việc sẽ được nhóm dự án thực hiện để hoàn thành các mục tiêu của dự án và tạo ra các giao phẩm được yêu cầu. Hướng dẫn Scrum định nghĩa product backlog là một danh sách theo thứ tự của tất cả mọi tính năng cần thiết về sản phẩm.
Chúng có thực sự khác nhau không? Cả hai đều giúp hình thành một khuôn khổ về phạm vi. Tuy nhiên, do cách mà chúng được sử dụng, nhiều người cho rằng chúng khá khác nhau… đó là quan điểm mà tôi muốn thay đổi.
Những điểm giống và khác nhau giữa WBS và Backlog.
Cấu trúc phân chia công việc WBS thường được xác định trước và đi kèm với từ điển WBS (WBS dictionary). Chúng có thể được sử dụng để hình thành báo cáo công việc và hợp đồng. Nếu những giao phẩm này hữu ích cho các dự án của bạn, hãy tạo chúng. Tuy nhiên, chúng ta cũng có thể tạo các giao phẩm tương tự từ một product backlog.
Tuy nhiên, đối với các dự án agile, chúng ta thường không làm như thế vì các môi trường này có xu hướng năng động hơn nên các sản phẩm này sẽ sớm bị lỗi thời hơn. Thay vào đó, chúng ta tạo các kế hoạch lặp lại xoắn ốc (iteration plan), lộ trình phát hành (release roadmap) và làm việc từ tốp đầu của backlog trong khi product owner quản lý backlog với độ ưu tiên và yêu cầu thay đổi luôn cập nhật. Những giao phẩm này dễ cập nhật hơn khi những thay đổi xuất hiện. Sự khác biệt trong hành động mà chúng ta nhận thấy xuất phát nhiều từ các đặc điểm của môi trường làm việc hơn là so với việc sử dụng công cụ WBS hoặc backlog. Cả hai công cụ đều giúp chúng ta xác định và phân tích phạm vi.
Lợi ích trực quan.
Cả hai đều trực quan và cho phép chúng ta tập trung vào các hạng mục khi nói về chúng. Điều này là rất quan trọng. Mô tả trực quan về công việc cho phép chúng ta làm việc cộng tác hiệu quả hơn. Khi hai người đối mặt với bảng công việc (task board) hoặc sơ đồ WBS, họ có thể hợp tác làm việc cùng nhau, ít xảy ra tranh chấp hơn. Trực quan hóa giúp chúng ta chia sẻ những hiểu biết và tránh những nhầm lẫn chẳng hạn như có hai hạng mục tương tự được coi là cùng một thứ hoặc giả sử một giải pháp phù hợp với hai kịch bản nhưng lại không phải.
Mô tả phạm vi trực quan cũng cho phép chúng ta tô bóng và tô màu các hạng mục để chỉ ra loại, quyền sở hữu, rủi ro và trạng thái hoàn thành. Hình dung công việc là một thành phần chính của tư duy tinh gọn. Khi chúng ta hình dung ra một cái gì đó, não chúng ta cũng xử lý thông tin nhanh hơn nhiều so với việc đọc và giải thích thông tin bằng văn bản. Đây là lý do mà chúng ta có biển báo bằng hình ảnh thay vì mô tả để đọc. Đó là sự khác biệt giữa giải mã và hiểu ý nghĩa trong 150 micro giây (khi nhìn biển báo trên đường) so với 6.000 micro giây để đọc:
Product Backlogs như một dạng của WBS.
Quyển Tiêu chuẩn thực hành cho các cấu trúc phân chia công việc tái bản lần thứ 3 cho rằng backlog giống như một dạng của WBS. Nhiều người nghĩ rằng chỉ có cấu trúc cây (tree structures) dạng hộp (boxes) và đường (lines) là cấu trúc phân chia công việc, nhưng thực tế chúng có thể có nhiều dạng bao gồm cả backlog dạng bảng hoặc sơ đồ tư duy.
Tôi có thể tưởng tượng một số người nguyên tắc sẽ hét lên “Không, đó không phải là WBS!” khi tôi đang gõ cái này, nhưng nếu bạn không tin hãy tự mình kiểm chứng. Tiêu chuẩn thực hành cho các cấu trúc phân chia công việc WBS là bản tải xuống miễn phí cho các thành viên PMI.
Tôi tham gia với tư cách là người đánh giá cho tiêu chuẩn và rất hài lòng khi biết nó bao gồm cả phân rã agile scope sử dụng chuỗi sự kiện, tính năng, câu chuyện của người dùng và tác vụ như các yếu tố WBS. Một điều khiến tôi bối rối mà tôi hy vọng rằng người đọc bài viết này có thể rút ra được đó là các yếu tố WBS tiềm năng bao gồm sprint (khoảng thời gian tiến hành tất cả các hoạt động cần thiết để sản xuất được một phần tăng trưởng có khả năng chuyển giao được) hay iteration.
Sự nhầm lẫn của tôi bắt nguồn từ định nghĩa của công việc trong phần 2.1 rằng “…công việc đề cập đến kết quả đầu ra, sản phẩm hoặc giao phẩm là thành quả của sự nỗ lực, nhưng cũng không phải chỉ dựa vào mỗi sự nỗ lực”. Tiếp theo đó, trong phần 2.3.1.1 về các quy tắc của WBS, viết rằng “các yếu tố WBS không bao gồm thời gian hoặc chuỗi các hành động”. Một lần nữa, điều này có vẻ hợp lý.
Tuy nhiên, các ví dụ cho các dự án agile bao gồm WBS với các hạng mục cấp 2 hiển thị “iteration 1”, “iteration 2”, v.v có chứa công việc. Điều này dường như vi phạm các giao phẩm so với sự nỗ lực của công việc và quy tắc “work and no-time”. Chúng ta không có yếu tố WBS nào gọi là “Tháng Chín” (September), vì vậy tại sao lại phải đưa ra một mốc thời gian tùy ý? Iteration chỉ là cấu trúc thời gian và bạn có thể chọn sử dụng chúng hoặc làm việc mà không có chúng như là một tính năng liên tục từ backlog.
Có vẻ như tôi đang diễn giải công việc, các giao phẩm và quy tắc no-time theo đúng nghĩa đen, giống như tranh luận về phương pháp nào có trước, nhưng đó có lẽ không quan trọng. Nếu có iteration rõ ràng có thể giúp bạn chia sẻ kế hoạch của mình và có các cuộc đàm luận có ý nghĩa về phạm vi, thì hãy thực hiện nó. Tôi cho rằng nó sẽ dẫn đến việc tái cấu trúc (refactor) lại WBS thường xuyên khi các tình huống được chuyển đổi giữa các iteration khi độ ưu tiên thay đổi và thông lượng thay đổi, nhưng cũng có thể là không.
Quan trọng hơn đó là chúng ta phải hình dung và thảo luận về phạm vi dự án với nhiều bên liên quan khác nhau để hiểu và sửa chữa những hiểu lầm. Tin tốt là product backlog là một hình thức hợp pháp của WBS và chúng giống như anh em ruột hơn là họ hàng xa. Một vài trích dẫn tuyệt vời từ quyển Tiêu chuẩn thực hành WBS nhắc lại giá trị và áp dụng tốt như nhau cho các backlog và lộ trình phát hành:
“WBS cung cấp nền tảng cho sự thể hiện trực quan về phạm vi công việc… Nghiên cứu chứng minh rằng truyền thông giao tiếp là một trong những lĩnh vực quản lý dự án có tác động cao nhất đến thành công của dự án. WBS phục vụ như một cơ chế truyền thông dự án quan trọng giúp truyền đạt phạm vi của dự án thông qua mô tả đồ họa của nó.”
Vì vậy, hãy tiếp tục sử dụng đồ họa và tiếp tục truyền thông giao tiếp.
Product Backlog là gì? Có quan hệ như thế nào với WBS
Bản tuyên ngôn Agile – lịch sử hình thành Agile
12 nguyên tắc của Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
Quản lý dự án với Scrum
Scrum of Scrums
User stories – Công cụ lên kế hoạch của Agile
Story points – Công cụ ước lượng của Agile
Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile
Story Map – Lập kế hoạch tổng quát trong Agile
Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án
Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án
PDCA – Chu trình cải tiến liên tục
Personas – Công cụ xây dựng hình tượng khách hàng trong Agile
Lean – Tinh gọn hóa quy trình một cách hiệu quả
Hướng Dẫn Scrum – The Scrum Guide
Bóng đá có 3-5-2, Scrum có 3-5-3
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu quả
