Lập kế hoạch sprint: thực hành Agile tốt nhất

Các nguyên tắc cơ bản của lập kế hoạch

Muốn lập kế hoạch sprint cho tốt thì phải làm có bài bản: xem lại các sprint đã qua, đánh giá xem nhóm thực sự làm được bao nhiêu và đặt mục tiêu cho thật rõ. Tìm hiểu thêm: Phần mềm quản lý dự án CNTT cho đội ngũ IT.

1. Việc chuẩn bị cho lập kế hoạch nên bắt đầu từ trước. Product Owner cần sắp xếp và xếp thứ tự ưu tiên cho backlog ít nhất một ngày trước buổi họp, còn nhóm phát triển cần có dịp đọc trước các user story và hỏi lại những chỗ chưa rõ.
2. Quy tắc phân bổ cổ điển: mỗi tuần của sprint cần hai giờ lập kế hoạch, nên một sprint hai tuần sẽ cần bốn giờ, dù trên thực tế chia khoảng thời gian này thành vài buổi ngắn thường hiệu quả hơn là ngồi họp một lèo.

Giai đoạn chuẩn bị

Không chuẩn bị kỹ thì không có cách nào lập kế hoạch sprint tốt hơn. Giai đoạn này thường bị xem nhẹ, trong khi thành bại của cả quá trình lại nằm ở đây.

• Definition of Ready (DoR) đặt ra các tiêu chí để biết một user story đã đủ điều kiện đưa vào sprint hay chưa. Mỗi story cần có tiêu chí nghiệm thu rõ ràng, ước lượng độ phức tạp và danh sách những nhiệm vụ khác mà nó phụ thuộc vào. Không bám theo DoR thì buổi lập kế hoạch sẽ rối tung, cả nhóm mất thời gian hỏi cho rõ đầu bài thay vì bàn cách thực hiện.
• Backlog refinement nên làm đều đặn, không đợi đến sát ngày lập kế hoạch sprint mới làm. Dành 10% thời gian của sprint cho việc này là cách làm phổ biến, và nhóm có thể tổ chức vài buổi refinement ngắn mỗi tuần để dần dần làm rõ các story cho những sprint sắp tới.
• Phân tích Velocity cho nhóm thấy chính xác mình thực sự giao được bao nhiêu việc. Ngoài Velocity trung bình của 3-5 sprint gần nhất, nhóm còn phải tính đến những yếu tố có thể ảnh hưởng tới năng suất ở sprint tới như lịch nghỉ phép, ngày lễ, nợ kỹ thuật tồn đọng hay các phụ thuộc vào bên ngoài.

Phiên lập kế hoạch

Buổi lập kế hoạch sprint gồm hai phần rõ ràng: phần đầu chốt xem sprint sẽ giao những gì, phần sau bàn cách thực hiện khối việc đã chọn. Mỗi phần cần những thông tin đầu vào khác nhau và cho ra những kết quả khác nhau, nên nếu gộp làm một thì phần nào cũng kém đi.

1. Nhóm, cùng với Product Owner, đặt ra một mục tiêu sprint gắn kết tất cả các user story đã chọn. Mục tiêu cần cụ thể, đo được và có ý nghĩa với mọi người tham gia. Một mục tiêu kém sẽ trông như "Cải thiện trải nghiệm người dùng", còn một mục tiêu tốt sẽ là "Người dùng có thể đăng ký qua mạng xã hội chỉ với một cú nhấp chuột".
2. Nhóm phát triển chia các story đã chọn thành từng nhiệm vụ và ước lượng mỗi nhiệm vụ theo giờ. Khi chia nhỏ như vậy, những chỗ phức tạp và những phụ thuộc bị khuất ở cấp độ story sẽ lộ ra. Không nhiệm vụ nào nên dài quá 8 giờ, nhiệm vụ nào vượt ngưỡng này thì cần chia tiếp thành các nhiệm vụ con.

Vai trò và trách nhiệm

Buổi lập kế hoạch sprint chỉ chạy tốt khi mỗi người tham gia hiểu rõ vai trò của mình và làm đúng trong phạm vi vai trò ấy.

• Scrum Master dẫn dắt quá trình, giữ đúng khung thời gian và giúp nhóm đi đến quyết định. Scrum Master không áp đặt giải pháp cho nhóm, họ đặt những câu hỏi trúng vấn đề và giữ cho cuộc thảo luận không đi lạc.
• Product Owner chịu trách nhiệm về thứ tự ưu tiên của backlog và quyết định tính năng nào làm trước. Họ phải sẵn sàng giải thích giá trị kinh doanh của từng story và trả lời câu hỏi của nhóm phát triển đủ cụ thể để nhóm ước lượng được.
• Nhóm phát triển cam kết giao kết quả. Cam kết này phải xuất phát từ chính nhóm chứ không do ai bên ngoài giao cho, vì khi tự đưa ra cam kết, người ta có động lực và tinh thần trách nhiệm khác hẳn so với khi phải chạy theo chỉ tiêu bị áp xuống.

Những lỗi phổ biến

• Đánh giá quá cao khả năng là lỗi lập kế hoạch sprint phổ biến nhất. Các nhóm cứ nhận nhiều việc hơn sức mình làm xong, nhất là lúc dự án mới bắt đầu hoặc ngay sau một sprint suôn sẻ. Nguyên tắc nên theo là hứa ít mà làm được nhiều, vì những cam kết không giữ được sẽ làm các bên liên quan mất lòng tin và khiến nhóm nản trong những sprint sau.
• Việc thiếu bộ đệm thời gian là một lỗi cấu trúc nghiêm trọng. Kế hoạch sprint nên chừa ra 10-20% thời gian dự phòng cho những việc phát sinh, lỗi cần sửa và yêu cầu hỗ trợ kỹ thuật. Không nên nhét thêm story vào phần dự phòng này ngay từ đầu, vì nó có mặt là để hứng những việc ngoài kế hoạch mà sprint nào cũng có.
• Bỏ qua các phụ thuộc tạo ra các trở ngại giữa sprint. Mọi phụ thuộc vào bên ngoài đều phải được chỉ ra và xử lý ngay trong buổi lập kế hoạch. Khi một nhiệm vụ phải chờ nhóm khác hoặc nhà cung cấp bên ngoài, hai bên cần thống nhất thời hạn và có xác nhận rõ ràng trước khi sprint bắt đầu.

Giám sát quy trình

Ở những nhóm làm Agile đã chín, chính quy trình lập kế hoạch cũng được cải tiến liên tục như mọi thứ khác. Trong buổi retrospective, nhóm nên xem lại cả kết quả thực hiện sprint lẫn chất lượng của bản kế hoạch, và coi chất lượng kế hoạch là một yếu tố đầu vào cần xét riêng.

Các chỉ số để phân tích:

• Độ chính xác của ước tính: thời gian dự kiến đặt cạnh thời gian thực tế đã bỏ ra cho mỗi story và mỗi nhiệm vụ
• Tỷ lệ phần trăm câu chuyện hoàn thành: trong số các story đã cam kết ở đầu sprint, bao nhiêu story thực sự được giao khi sprint kết thúc
• Số lượng thay đổi trong sprint sau khi lập kế hoạch: thước đo cho thấy bản kế hoạch ổn định đến đâu và yêu cầu rõ ràng đến mức nào
• Thời gian dành cho lập kế hoạch: đem so với mức phân bổ chuẩn để phát hiện nhóm thường xuyên bỏ quá nhiều hay quá ít thời gian cho việc này

Biểu đồ Burndown theo dõi tiến độ suốt sprint và báo hiệu vấn đề đủ sớm để nhóm kịp xoay xở. Khi biểu đồ cho thấy nhóm sẽ không làm xong khối việc đã định, cần hành động ngay: sắp xếp lại thứ tự ưu tiên cho những nhiệm vụ còn lại hoặc bỏ bớt những user story ít ưu tiên nhất ra khỏi phạm vi sprint.

Điều chỉnh lập kế hoạch

• Các nhóm từ xa yêu cầu sự điều chỉnh cụ thể đối với việc lập kế hoạch sprint. Nhóm phải có sẵn công cụ cộng tác chuyên dụng, và người điều phối phải chủ động lo cho mọi thành viên ở xa đều được tham gia ngang nhau. Với nhóm phân tán, chia buổi lập kế hoạch thành vài phiên ngắn thay vì một cuộc họp dài liền một mạch giúp mọi người tham gia tích cực hơn và cho ra kết quả tốt hơn.
• Các chương trình lớn với nhiều nhóm yêu cầu sự phối hợp ở cấp chương trình. Scrum of Scrums hoặc SAFe (Scaled Agile Framework) đưa ra những cơ chế rõ ràng để các nhóm có phụ thuộc chung đồng bộ kế hoạch sprint với nhau.
• Các dự án bảo trì, nơi một phần đáng kể thời gian của sprint dành cho hỗ trợ và sửa lỗi, cần chừa sẵn năng lực rõ ràng cho những việc ngoài kế hoạch. Cách làm thường thấy là dành 30-50% năng lực của sprint cho công việc hỗ trợ và để phần còn lại cho phát triển tính năng mới, nhờ vậy nhóm tránh được những lần trễ hẹn giao hàng chỉ vì coi việc hỗ trợ là chi phí lặt vặt chứ không phải một phần năng lực đã tính trước.

Bài viết liên quan:

Về các khuôn khổ quản lý dự án và cách cân đối những ràng buộc, hãy đọc Tam giác quản lý dự án: Cân bằng phạm vi, thời gian, chi phí.

Nếu cần một cái nhìn thực tế về bảng Kanban và cách quản lý quy trình làm việc bằng hình ảnh, hãy đọc Bảng Kanban là gì? Hướng dẫn quản lý quy trình làm việc trực quan.

Để biết các nhóm Agile dùng personas ra sao nhằm bám sát nhu cầu thật của người dùng, hãy đọc Personas Agile: Tăng cường phát triển lấy người dùng làm trung tâm trong các dự án Agile. Thông tin chi tiết: Bảng Kanban.

Kết luận

Muốn lập kế hoạch sprint tốt, nhóm cần làm có hệ thống và coi việc cải tiến liên tục là một thói quen có chủ đích, đừng đợi dự án xong rồi mới ngồi nhìn lại. Retrospective cho nhóm một cơ chế rõ ràng để xem xét cả kết quả thực hiện sprint lẫn những yếu tố đầu vào của bản kế hoạch đã dẫn tới kết quả ấy, nhờ đó chính quy trình lập kế hoạch cũng được cải tiến qua từng vòng lặp, giống cách Agile vẫn làm với sản phẩm.