Trách nhiệm chồng chéo là một vấn đề cấu trúc trở nên cấp tính hơn khi các tổ chức phát triển và các dự án trở nên đa chức năng hơn. Khi ranh giới giữa các vai trò không rõ ràng, công việc trùng lặp, thất bại phối hợp và xung đột giữa các cá nhân là những kết quả có thể dự đoán được. Thách thứ
Danh sách công việc: quản lý và ưu tiên hiệu quả
Một backlog nhiệm vụ được cấu trúc tốt là nền tảng vận hành của mọi dự án Agile thành công. Đó không phải là danh sách việc cần làm tĩnh mà là một tài liệu liên tục phát triển định nghĩa trọng tâm của nhóm, cho phép thích ứng với các yêu cầu thay đổi và đóng vai trò là nguồn sự thật duy nhất cho tất cả những người tham gia dự án. Sự khác biệt giữa một backlog thúc đẩy việc giao hàng và một backlog tạo ra sự bối rối nằm gần như hoàn toàn ở cách nó được cấu trúc, duy trì và ưu tiên.
Điểm chính
Backlog là một công cụ lập kế hoạch và thích ứng năng động định nghĩa trọng tâm của nhóm
Việc ưu tiên nhiệm vụ hiệu quả giúp tối đa hóa giá trị sản phẩm với nỗ lực tối thiểu
Refinement thường xuyên, sự tham gia của nhóm và việc làm sạch các mục lỗi thời làm cho backlog có năng suất
Giới thiệu
Trong bối cảnh Agile, một backlog nhiệm vụ là một danh sách năng động, liên tục phát triển của mọi thứ mà nhóm cần làm — bao gồm các tính năng, sửa lỗi, cải tiến và bất kỳ công việc nào khác đóng góp vào mục tiêu sản phẩm. Nó đóng vai trò là nguồn sự thật duy nhất cho tất cả những người tham gia dự án, đảm bảo tính minh bạch và hiểu biết chung về các ưu tiên. Mỗi mục trong backlog đại diện cho giá trị tiềm năng được cung cấp cho người dùng, đó là lý do tại sao chất lượng backlog trực tiếp xác định chất lượng giao hàng.
Tại sao điều này quan trọng
Không có backlog nhiệm vụ được cấu trúc rõ ràng, một dự án tích lũy nợ lập kế hoạch tổng hợp thành các thất bại giao hàng. Một backlog được duy trì tốt:
- Định nghĩa hướng: Cho thấy dự án đang đi đâu và những mục tiêu nào nhóm đang hướng tới.
- Đảm bảo tập trung: Nhóm biết phải tập trung vào điều gì bây giờ và mong đợi điều gì trong các chu kỳ tương lai.
- Tăng tính minh bạch: Mọi người đều thấy những gì đang tiến hành, những gì đã hoàn thành và những gì đang xếp hàng. Đây là điều kiện tiên quyết cho việc làm việc nhóm hiệu quả trong phát triển phần mềm.
- Cho phép thích ứng: Cấu trúc backlog cho phép tái ưu tiên nhanh chóng khi thông tin mới đến hoặc các yêu cầu thị trường thay đổi — 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: Nó đóng vai trò là điểm khởi đầu cho việc lập kế hoạch sprint hoặc lặp lại, cung cấp đầu vào làm cho các phiên lập kế hoạch trở nên năng suất hơn là khám phá.
Quản lý backlog
Quản lý backlog hiệu quả là một quá trình liên tục, không phải là hoạt động thiết lập một lần.
- 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 — chịu trách nhiệm về nội dung, ưu tiên và sự rõ ràng của nó. Quyền sở hữu chung tạo ra sự trùng lặp và mâu thuẫn.
- Cập nhật liên tục: Backlog không tĩnh. Nó yêu cầu cập nhật thường xuyên — thêm mục mới, loại bỏ mục lỗi thời và điều chỉnh ưu tiên. Các phiên refinement backlog có cấu trúc làm cho điều này có hệ thống thay vì phản ứng.
- Sự rõ ràng: Mỗi mục backlog nên được trình bày rõ ràng bằng ngôn ngữ đơn giản, không mơ hồ mà toàn nhóm hiểu mà không cần giải thích hoặc giải nghĩa bổ sung.
- Chi tiết từ trên xuống: Các mục gần đầu backlog (ưu tiên cao nhất) nên được chi tiết tối đa và sẵn sàng cho phát triển. Các mục xa hơn yêu cầu ít chi tiết hơn, vì kế hoạch có thể thay đổi trước khi chúng được đạt đến.
Ưu tiên
Việc ưu tiên nhiệm vụ hiệu quả xác định điều gì mang lại giá trị lớn nhất với các ràng buộc hiện tại — không chỉ đơn giản là điều có vẻ quan trọng nhất một cách trừu tượng.
- Giá trị kinh doanh và người dùng: Tiêu chí chính. Mục nào tạo ra lợi ích lớn nhất? Mục nào giải quyết các điểm đau quan trọng nhất của người dùng? Mục nào đóng góp trực tiếp nhất vào các mục tiêu tổ chức chiến lược?
- Khẩn cấp: Có hạn chót hoặc yếu tố bên ngoài nào yêu cầu sự chú ý ngay lập tức không — các lỗi nghiêm trọng, yêu cầu quy định, hoặc các cơ hội thị trường nhạy cảm về thời gian?
- Chi phí thực hiện: Ước tính nỗ lực giúp so sánh chi phí tương đối giữa các mục. Một số mục nhỏ có giá trị có thể mang lại nhiều giá trị tổng hơn một nỗ lực lớn. Story points hoặc kích thước T-shirt là các phương pháp ước tính tiêu chuẩn.
- Rủi ro: Các nhiệm vụ có rủi ro cao có thể đảm bảo ưu tiên sớm hơn để đưa các vấn đề kỹ thuật lên bề mặt trước khi chúng ảnh hưởng đến công việc phụ thuộc.
- Phụ thuộc: Một mục có ưu tiên thấp hơn có thể cần được giải quyết trước khi công việc ưu tiên cao hơn có thể bắt đầu, điều này yêu cầu tầm nhìn rõ ràng vào các phụ thuộc giữa các nhiệm vụ.
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 các yêu cầu theo sự cần thiết của việc giao hàng
- Ma trận giá trị so với nỗ lực: trực quan hóa các nhiệm vụ theo giá trị được giao so với nỗ lực cần thiết, đưa ra các cơ hội giá trị cao, nỗ lực thấp
- Mô hình Kano: tập trung vào sự hài lòng của khách hàng, phân biệt giữa các yêu cầu cơ bản, các tính năng hiệu suất và các yếu tố làm hài lòng
- WSJF (Weighted Shortest Job First): ưu tiên các nhiệm vụ mang lại lợi ích kinh tế lớn nhất trong thời gian ngắn nhất — tiêu chuẩn trong môi trường SAFe
Tối ưu hóa và refinement
Các phiên refinement thường xuyên — nơi nhóm làm việc với Product Owner để xem xét, chi tiết hóa, ước tính và làm sạch backlog — là cơ chế giữ cho backlog hữu ích về mặt vận hành thay vì chính xác về mặt lý thuyết.
- Chi tiết hóa: Các mục ưu tiên cao được làm rõ, chia thành các nhiệm vụ nhỏ hơn khi cần thiết và chuẩn bị cho phát triển.
- Ước tính: Nhóm ước tính nỗ lực của nhiệm vụ, cung cấp cho Product Owner dữ liệu cần thiết cho các quyết định ưu tiên chính xác.
- Loại bỏ các mục lỗi thời: Các nhiệm vụ không còn liên quan được loại bỏ thay vì cho phép tích lũy, ngăn backlog phát triển đến kích thước làm suy yếu tính hữu ích của nó.
- Đánh giá lại ưu tiên: Thảo luận rõ ràng về việc các ưu tiên đã thay đổi kể từ lần refinement trước hay không, kết hợp thông tin mới hoặc điều kiện bên ngoài đã thay đổi.
Các phiên refinement nên thường xuyên và có giới hạn thời gian — đủ để duy trì chất lượng backlog mà không tiêu tốn thời gian của nhóm không tương xứng.
Lỗi phổ biến
Ngay cả với sự hiểu biết về các thực hành tốt nhất, các chế độ thất bại cụ thể lặp lại giữa các nhóm:
- Backlog phình to: Khi backlog phát triển mà không có việc làm sạch thường xuyên, nó mất đi tính hữu ích như một công cụ lập kế hoạch. Các mục sẽ không bao giờ được giải quyết tiêu tốn thời gian xem xét và che khuất các ưu tiên thực sự.
- Sự vắng mặt của ưu tiên có ý nghĩa: Khi tất cả các nhiệm vụ mang ưu tiên ngang nhau, backlog không cung cấp hướng dẫn. Ưu tiên nghiêm ngặt, có sự khác biệt là một yêu cầu chức năng, không phải là một sự ưu tiên.
- Loại trừ nhóm khỏi refinement: Khi nhóm không tham gia vào việc làm rõ và ước tính nhiệm vụ, họ thiếu sự hiểu biết và quyền sở hữu thúc đẩy thực hiện hiệu quả.
- Các mục chất lượng thấp: Các nhiệm vụ không rõ ràng hoặc quá lớn tạo ra sự mơ hồ làm chậm công việc và tạo ra lỗi ước tính.
- Coi backlog như cố định: Một backlog không được cập nhật liên tục cung cấp cấu trúc của Agile mà không có khả năng thích ứng làm cho nó hiệu quả.
Một sự thật thú vị
Việc triển khai Scrum công khai được tài liệu hóa đầu tiên là vào năm 1993 tại Easel Corporation, nơi Jeff Sutherland và nhóm của ông lần đầu áp dụng quản lý nhiệm vụ lặp đi lặp lại với một backlog có cấu trúc, các cuộc họp đứng hàng ngày và các phiên grooming hàng tuần — thiết lập các thực hành trở thành nền tảng cho khuôn khổ Scrum.
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.
Kết luận
Quản lý backlog hiệu quả và ưu tiên nhiệm vụ kỷ luật là các thực hành vận hành, không phải các khái niệm lý thuyết. Một backlog được duy trì tốt giữ cho nhóm tập trung vào công việc mang lại giá trị nhiều nhất, cho phép thích ứng nhanh chóng với thay đổi và cung cấp nền tảng lập kế hoạch làm cho việc thực hiện sprint có thể dự đoán được. Đầu tư cần thiết để xây dựng và duy trì các thực hành này được trả lại trong tính nhất quán giao hàng, giảm chi phí lập kế hoạch và khả năng phản ứng với các điều kiện thay đổi mà không mất phương hướng.
Đọc thêm được đề xuất
"User Story Mapping: Discover the Whole Story, Build the Right Product"
Một hướng dẫn thực tế để tổ chức backlog sản phẩm thông qua việc lập bản đồ trực quan các nhu cầu của người dùng, làm cho các quyết định ưu tiên dựa vào hành trình người dùng thực tế hơn.
"Inspired: How to Create Tech Products Customers Love"
Giải thích cách các nhóm sản phẩm hiệu suất cao quản lý các ưu tiên, xác nhận ý tưởng và xây dựng các cấu trúc cần thiết để liên tục cung cấp giá trị sản phẩm có ý nghĩa.
"Essential Scrum: A Practical Guide to the Most Popular Agile Process"
Một tài liệu tham khảo toàn diện cho việc triển khai Scrum, với phạm vi chi tiết về các thực hành grooming backlog, ước tính và ưu tiên.