Danh sách công việc: quản lý và ưu tiên hiệu quả

Giới thiệu

Trong Agile, backlog nhiệm vụ là danh sách mọi việc nhóm cần làm, từ tính năng mới, sửa lỗi, cải tiến cho đến bất kỳ công việc nào khác phục vụ mục tiêu sản phẩm, và danh sách này thay đổi liên tục theo dự án. Mọi người tham gia dự án đều dựa vào nó như nguồn sự thật duy nhất, nhờ vậy các ưu tiên luôn minh bạch và ai cũng hiểu giống nhau. Mỗi mục trong backlog là một phần giá trị có thể đến tay người dùng, vì thế backlog tốt đến đâu thì chất lượng giao hàng tốt đến đó.

Tại sao điều này quan trọng

Khi backlog nhiệm vụ thiếu một cấu trúc rõ ràng, dự án dần tích lũy nợ lập kế hoạch, và món nợ này sớm muộn sẽ biến thành những lần giao hàng thất bại. Một backlog được duy trì tốt sẽ:

• Định nghĩa hướng: Cho thấy dự án đang đi về đâu và nhóm đang làm việc vì những mục tiêu nào.
• Đảm bảo tập trung: Nhóm biết lúc này cần tập trung vào việc gì và những chu kỳ sắp tới sẽ có gì.
• Tăng tính minh bạch: Ai cũng thấy việc nào đang làm, việc nào đã xong và việc nào đang chờ đến lượt. Đó là điều kiện tiên quyết để làm việc nhóm hiệu quả trong phát triển phần mềm.
• Cho phép thích ứng: Với cấu trúc của backlog, nhóm có thể nhanh chóng sắp xếp lại ưu tiên khi có thông tin mới hoặc khi thị trường đòi hỏi điều khác, và đây là một trong những lợi thế vận hành cốt lõi của phương pháp Agile.
• Nền tảng cho lập kế hoạch: Việc lập kế hoạch sprint hay vòng lặp bắt đầu từ đây, vì backlog cung cấp đầu vào để các buổi lập kế hoạch đi đến quyết định cụ thể thay vì chỉ dừng ở mức thăm dò.

Quản lý backlog

Quản lý backlog là việc phải làm liên tục, chẳng phải một bước thiết lập làm một lần rồi thôi.

• Chủ sở hữu đơn lẻ: Backlog nên có một người chịu trách nhiệm, thường là Product Owner, lo về nội dung, thứ tự ưu tiên và độ rõ ràng của nó. Khi nhiều người cùng sở hữu, backlog dễ bị trùng lặp và mâu thuẫn.
• Cập nhật liên tục: Backlog không đứng yên. Nó cần được cập nhật thường xuyên: thêm mục mới, bỏ mục lỗi thời, điều chỉnh ưu tiên, và các phiên refinement có cấu trúc giúp việc này diễn ra có hệ thống thay vì chỉ chạy theo sự vụ.
• Sự rõ ràng: Mỗi mục trong backlog nên được viết bằng ngôn ngữ đơn giản, không gây hiểu lầm, để cả nhóm đọc là hiểu mà không cần ai giải thích thêm.
• Chi tiết từ trên xuống: Những mục ở gần đầu backlog, tức là có ưu tiên cao nhất, cần được mô tả chi tiết hết mức và sẵn sàng để phát triển. Các mục ở xa hơn thì không cần nhiều chi tiết như vậy, vì kế hoạch có thể thay đổi trước khi đến lượt chúng.

Ưu tiên

Mục đích của việc ưu tiên nhiệm vụ là tìm ra việc gì mang lại giá trị lớn nhất trong những giới hạn hiện có, chứ không chỉ là việc nào nghe có vẻ quan trọng nhất trên lý thuyết.

• Giá trị kinh doanh và người dùng: Đây là tiêu chí chính. Mục nào đem lại lợi ích lớn nhất? Mục nào giải quyết những khó khăn lớn nhất của người dùng? Mục nào góp phần trực tiếp nhất vào các mục tiêu chiến lược của tổ chức?
• Khẩn cấp: Có hạn chót hay yếu tố bên ngoài nào buộc phải xử lý ngay không, chẳng hạn lỗi nghiêm trọng, yêu cầu pháp lý hay một cơ hội thị trường sẽ qua đi nếu chậm trễ?
• Chi phí thực hiện: Ước tính công sức giúp so sánh chi phí giữa các mục với nhau. Nhiều mục nhỏ mà hữu ích có thể cộng lại thành giá trị lớn hơn một hạng mục đồ sộ. Story points hoặc ước lượng theo cỡ T-shirt là những cách ước tính thông dụng.
• Rủi ro: Nhiệm vụ có rủi ro cao đôi khi nên được làm sớm hơn, để các vấn đề kỹ thuật lộ ra trước khi ảnh hưởng tới những phần việc phụ thuộc vào nó.
• Phụ thuộc: Có khi một mục ưu tiên thấp hơn phải được giải quyết trước thì việc ưu tiên cao mới bắt đầu được, nên các phụ thuộc giữa các nhiệm vụ cần được thể hiện rõ cho mọi người thấy.

Các khuôn khổ ưu tiên đã được thiết lập cấu trúc quá trình này:

• MoSCoW (Must-have, Should-have, Could-have, Won't-have): phân loại yêu cầu theo mức độ cần thiết đối với việc giao hàng
• Ma trận giá trị so với nỗ lực: biểu diễn các nhiệm vụ theo giá trị mang lại so với công sức bỏ ra, qua đó làm nổi bật những cơ hội giá trị cao mà tốn ít công
• Mô hình Kano: xuất phát từ sự hài lòng của khách hàng, phân biệt yêu cầu cơ bản, tính năng hiệu suất và những yếu tố khiến người dùng thích thú
• WSJF (Weighted Shortest Job First): đưa lên trước những nhiệm vụ mang lại lợi ích kinh tế lớn nhất trong thời gian ngắn nhất, và là cách làm chuẩn trong môi trường SAFe

Tối ưu hóa và refinement

Các phiên refinement đều đặn, khi nhóm cùng Product Owner rà soát, bổ sung chi tiết, ước tính và dọn dẹp backlog, chính là cơ chế giữ cho backlog dùng được trong công việc thật thay vì chỉ đúng trên giấy.

• Chi tiết hóa: Các mục ưu tiên cao được làm rõ, chia nhỏ thành nhiệm vụ nhỏ hơn khi cần và chuẩn bị sẵn cho phát triển.
• Ước tính: Nhóm ước tính công sức cho từng nhiệm vụ, nhờ đó Product Owner có dữ liệu cần thiết để quyết định ưu tiên chính xác.
• Loại bỏ các mục lỗi thời: Những nhiệm vụ không còn phù hợp được xóa đi thay vì để chúng dồn lại, giúp backlog không phình ra đến mức mất hết tác dụng.
• Đánh giá lại ưu tiên: Nhóm thảo luận thẳng thắn xem thứ tự ưu tiên có thay đổi gì từ lần refinement trước hay không, có tính đến thông tin mới và những thay đổi bên ngoài.

Các phiên refinement nên được tổ chức đều đặn và có giới hạn thời gian, đủ để giữ chất lượng backlog nhưng không chiếm quá nhiều thời gian của nhóm.

Lỗi phổ biến

Dù đã biết các thực hành tốt nhất, nhiều nhóm vẫn lặp lại những sai lầm quen thuộc:

• Backlog phình to: Khi backlog cứ lớn dần mà không được dọn dẹp thường xuyên, nó không còn hữu ích cho việc lập kế hoạch. Những mục sẽ chẳng bao giờ được làm tới vẫn ngốn thời gian rà soát và che lấp các ưu tiên thực sự.
• Sự vắng mặt của ưu tiên có ý nghĩa: Khi mọi nhiệm vụ đều có mức ưu tiên như nhau, backlog chẳng còn chỉ dẫn được gì. Việc xếp ưu tiên chặt chẽ, phân biệt rõ từng mục là yêu cầu bắt buộc để công việc vận hành, đâu phải chuyện sở thích.
• Loại trừ nhóm khỏi refinement: Khi các thành viên không được tham gia làm rõ và ước tính nhiệm vụ, họ thiếu sự hiểu biết và cảm giác làm chủ, vốn là thứ giúp việc thực hiện đạt kết quả.
• Các mục chất lượng thấp: Nhiệm vụ mơ hồ hoặc quá lớn khiến mọi người lúng túng, làm chậm công việc và dẫn đến ước tính sai.
• Coi backlog như cố định: Một backlog không được cập nhật liên tục chỉ giữ lại bộ khung của Agile, còn khả năng thích ứng làm nên giá trị của Agile thì mất đi.

Các bài viết liên quan:

Để có các phương pháp tiếp cận lập kế hoạch dự án chiến lược và cấu trúc lộ trình, hãy đọc Lộ trình dự án: Lập kế hoạch và quản lý dự án của bạn.

Để có tổng quan chi tiết về phương pháp quản lý Waterfall, hãy đọc Quản lý dự án Waterfall: Hướng dẫn từng bước.

Để có các giá trị và nguyên tắc nền tảng làm cơ sở cho Agile, hãy đọc Tuyên ngôn Agile: Các giá trị và nguyên tắc cốt lõi được giải thích. Tìm hiểu thêm: Nhiệm vụ.

Kết luận

Quản lý backlog và ưu tiên nhiệm vụ có kỷ luật là những thực hành dùng hằng ngày, chứ không phải khái niệm để bàn trên lý thuyết. Một backlog được chăm chút giúp nhóm tập trung vào phần việc mang lại nhiều giá trị nhất, thích ứng nhanh khi có thay đổi và có nền tảng lập kế hoạch vững để kết quả mỗi sprint trở nên dễ đoán. Công sức bỏ ra để xây dựng và duy trì các thực hành này sẽ được đền đáp bằng việc giao hàng đều đặn, gánh nặng lập kế hoạch nhẹ hơn và khả năng ứng phó với hoàn cảnh thay đổi mà không lạc hướng.