Dự án của bạn được đề nghị triển khai theo phương pháp Agile và hiển nhiên bạn phải xây dựng một Backlog với chứa các công việc còn tồn đọng cần thực hiện (Product Backlog Items – PBI). Bạn đã sẵn sàng đưa ra cách tiếp cận để quản lý Backlog?

Bài viết này tôi xin giúp bạn trả lời ba câu hỏi chính: Thế nào là một Backlog trong dự án Agile? Làm sao để quản lý Backlog hiệu quả? Các điểm mạnh và giới hạn của việc quản lý Backlog là gì?

1) Mục đích của Product Backlog

Mục đích của Product Backlog là dùng để ghi lại, theo dõi, và sắp xếp những công việc đang tồn đọng trong dự án.

Quản lý Backlog liên quan đến kế hoạch tiếp cận để xác định thông tin:

• Những công việc nào cần chính thức đưa vào danh sách công việc còn tồn đọng (Backlog)?
• Làm thế nào để mô tả những PBI?
• Làm thế nào để các PBI được theo dõi?
• Làm thế nào để các PBI cần được xem xét định kỳ, được sắp xếp ưu tiên hợp lý thoả mãn sự phụ thuộc với tất cả các PBI liên quan có trong Backlog?
• Làm thế nào để các PBI được chọn để triển khai?
• Và làm thế nào để các PBI dần bị loại bỏ ra khoải Backlog?

Với một Backlog được quản lý tốt thì nhưng PBI có giá trị cao cho khách hàng (Business Value) được sắp xếp độ ưu tiên cao nhất, và được chọn để thực hiện trước.

Các hạng mục còn tồn đọng cần được xem xét và đánh giá định kỳ, vì trong quá trình thực hiện dự án có nhiều thay đổi đến từ: Kế hoạch tung sản phẩm ra thị trường thay đổi; Nhu cầu từ những bên liên quan (stakeholders) trong dự án thay đổi; Công nghệ, kỹ thuật áp dụng cho sản phẩm có thay đổi;… Với dự án triển khai theo Scrum thì công việc này được thực hiện ở Backlog Grooming và Release Planning.

Những thay đổi liên quan đến số lượng PBI cần được theo dõi thường xuyên. Các nguyên nhân gốc rễ của thay đổi cần được điều tra bởi vì: Số lượng PBI ngày càng tăng có thể chỉ ra rằng như cầu đang tăng lên hoặc năng suất lao động của Development team đang giảm đi; Số lượng PBI ngày càng giảm có thể chỉ ra rằng nhu cầu đang giảm đi hoặc những cải tiến trong chu trình phát triển có dấu hiệu tích cực.

2) PBI trong Product Backlog

PBI là những công việc cần thực hiện theo yêu cầu của khách hàng và có thể là những công việc liên quan đến yêu cầu đó. Một Backlog có thể chứa những loại công việc sau:

• Use Cases
• User Stories
• Các yêu cầu chức năng – functional requirements
• Các yêu cầu phi chức năng – non-functional requirements
• Thiết kế – Design
• Các đơn đặt hàng của khách hàng – customer orders
• Các rủi ro – risk items
• Các yêu cầu thay đổi – change requests
• Lỗi – defects
• Chuẩn bị nội dung thuyết trình sản phẩm
• Hoàn thành một tài liệu hoá

Một PBI được thêm vào Backlog nếu chúng mang lại giá trị cho các đối tượng liên quan trong dự án. Chỉ có một người duy nhất có quyền quyết định những PBI cần được thêm vào Product Backlog. Với dự án triển khai theo Scrum thì đây là công việc của Product Owner.

3) Sắp xếp độ ưu tiên cho PBI trong Product Backlog

Các PBI trong Backlog được sắp xếp độ ưu tiên tương đối với nhau. Theo thời gian, độ ưu tiên sẽ bị thay đổi theo như cầu thay đổi ưu tiên của các bên liên quan, hoặc sự phụ thuộc (dependencies) giữa các BPI được hiện ra hoặc quy tắc quản lý Backlog có thể gây ảnh hưởng điến độ ưu tiên.

Khi những PBI đầu tiên được thêm vào Backlog, độ ưu tiên có thể rất rộng, bạn có thể sử dụng kỹ thuật MoSCoW để phân loại độ ưu tiên theo 2 mức: Cao – (high); Trung bình (medium); hoặc Thấp (low).

Các PBI có độ ưu tiên cần phải được xem xét, đánh giá thường xuyên. Thông thường Product Owner cần làm rõ yêu cầu cho các PBI cho ít nhất hai hoặc bai Sprint kế tiếp.

4) Ước lượng PBI trong Product Backlog

Mức độ chi tiết để mô tả cho mỗi PBI có thể thay đổi đáng kể. Những PBI có độ ưu tiên cao nhất trong Backlog cần được mô tả chi tiết để Development team có thể ước lượng kích thước (size) và độ phức tạp (complexity) để xác định những nỗ lực cần thực hiện và chi phí cần tính cho khách hàng. Khi một PBI được thêm vào Backlog thì thường không được mô tả chi tiết, đặc biệt với những PBI không có khả triển khai trong tương lai gần.

Với dự án Agile thì kỹ thuật Planning Poker luôn được khuyến khích để xác định kích thước. Sự phản hồi từ quá trình phát triển sản phẩm liên quan đến chi phí và nỗ lực để hoàn thành các PBI trước đó có thể dùng tham khảo để điều chỉnh các ước lượng cho PBI đang tồn đọng trong Backlog.

5) Quản lý thay đổi trong Backlog

Các PBI cần phát triển nằm ở bênh trên của Backlog phụ thuộc vào cách mà đội dự án phối hợp với nhau để sắp xếp độ ưu tiên. Khi có những yêu cầu mới hoặc thay đổi đã được xác định, đội dự án sẽ thêm vào Backlog và sắp xếp độ ưu tiên tương đối với các PBI đang có trong Backlog (nếu chúng phụ thuộc vào nhau).

Bất cứ khi nào Development team chọn lựa PBI vào Sprint Board để thực hiện cần xem xét các yếu tố: năng lực sẵn có, sự phụ thuộc giữa các hạn mục, sự hiểu biết hiện tại của đội phát triển về kích thước và độ phức tạp của mỗi PBI. PBI sẽ được loại bỏ khỏi Product Backlog khi chúng đã hoàn thành, hoặc một quyết định được đưa ra để loại bỏ chúng.

Tuy nhiên, những PBI đã bị loại bỏ có thể thêm trở lại Backlog với những lý do sau:

• Như cầu của các đối tượng liên quan có thể thay đổi đáng kể
• Nó có thể mất nhiều thời gian hơn dự tính
• Các hạn mục có độ ưu tiên cao có thể mất nhiều thời gian để hoàn thành hơn dự kiến
• Hoặc sản phẩm chuyển giao có lỗi

6) Điểm mạnh và giới hạn trong cách quản lý

a) Điểm Mạnh:

• Đáp ứng như cầu thay đổi nhanh cho các đối tượng liên quan. Bởi vì những hạn mục còn tồn đọng có độ ưu tiên cao tương ứng với độ ưu tiên của chính họ.
• Chỉ những hạn mục có độ ưu tiên cao trong Backlog mới được mô tả chỉ tiết và được ước lượng, những hạn mục liệt kê ở cuối Backlog phản ánh độ ưu tiên thấp và nhận được sự quan tâm ít hơn. Đội dự án sẽ chỉ tập trung nhiều cho hạn mục có độ ưu tiên cao.
• Đây là phương tiện truyền thông hiệu quả bởi vì các đối tượng liên quan có thể hiểu được những hạn mục chức năng nào đã được phát triển và đã chuyển giao, những hạn mục tồn đọng nào đang được ưu tiên cao, những hạn mục nào có thể không cần phát triển.

b) Giới hạn:

• Hạn mục tồn đọng lớn trên Backlog sẽ trở nên công kềnh và khó quản lý.
• Cần Product Owner có nhiều kinh nghiệm có khả năng chia nhỏ những công việc cần hoàn thành, mô tả yêu cầu đủ chi tiết để việc ước lượng được chuẩn sát.
• Thiếu thông tin chi tiết trong mỗi PBI của Backlog có thể dẫn đến mất mát thông tin theo thời gian.

Việc quản lý Product Backlog là một công việc khá thách thức, đặc biệt trong các dự án lớn. Bạn áp dụng kỹ thuật để đưa ra cách tiếp cận phù hợp là một sự khởi đầu tốt. Cách tiếp cận phù hợp sẽ giúp Product Ownertối đa hoá giá trị cho khách hàng và nâng cao hiệu suất của đội dự án.

>> Nguồn: APEX Global

Trân trọng,

Nguyễn Đức Giang