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

Công cụ dự án
14 Thời gian đọc
153 lượt xem
0
Alena Shelyakina profile icon
Alena Shelyakina

Lập kế hoạch sprint là nền tảng của việc triển khai phương pháp Agile thành công. Nhiều dự án thất bại chính xác do những thiếu sót trong giai đoạn lập kế hoạch, khi các nhóm không thể xác định rõ ràng phạm vi công việc hoặc ước tính sai yêu cầu về thời gian.

Điểm chính

Biểu tượng điểm chính

Sự chuẩn bị chất lượng giải quyết 80% các vấn đề lập kế hoạch

Mục tiêu sprint nên cụ thểthống nhất

Lập kế hoạch là một cam kết của nhóm, không phải là sự phân công từ trên xuống

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

Lập kế hoạch sprint chất lượng đòi hỏi một cách tiếp cận có cấu trúc bao gồm việc phân tích các sprint trước đó, đánh giá khả năng của nhóm và xác định rõ ràng các mục tiêu.

  1. Việc chuẩn bị cho lập kế hoạch nên bắt đầu từ trước. Product Owner phải chuẩn bị và ưu tiên backlog ít nhất một ngày trước cuộc họp. Nhóm phát triển nên có cơ hội xem xét user story trước và đặt câu hỏi làm rõ.
  2. Quy tắc phân bổ cổ điển: hai giờ lập kế hoạch cho mỗi tuần của sprint. Đối với sprint hai tuần, điều này có nghĩa là bốn giờ — mặc dù thực tế cho thấy thường hiệu quả hơn khi chia thời gian này thành nhiều phiên ngắn hơn thay vì một cuộc họp kéo dài.

Giai đoạn chuẩn bị

Cải thiện lập kế hoạch sprint là không thể nếu không có sự chuẩn bị chất lượng. Giai đoạn này thường bị đánh giá thấp, mặc dù nó quyết định sự thành công của toàn bộ quá trình.

  • Definition of Ready (DoR) thiết lập các tiêu chí cho sự sẵn sàng của user story trước khi đưa vào sprint. Mỗi câu chuyện nên có các tiêu chí chấp nhận rõ ràng, ước tính độ phức tạp và các phụ thuộc được xác định vào các nhiệm vụ khác. Nếu không tuân thủ DoR, việc lập kế hoạch trở nên hỗn loạn, với các nhóm dành thời gian làm rõ thay vì lập kế hoạch thực hiện.
  • Backlog refinement nên diễn ra thường xuyên, không chỉ ngay trước khi lập kế hoạch sprint. Phân bổ 10% thời gian sprint cho quá trình này là thực hành tiêu chuẩn. Các nhóm có thể tổ chức các phiên refinement ngắn nhiều lần mỗi tuần, dần dần làm việc với các câu chuyện cho các sprint trong tương lai.
  • Phân tích Velocity cung cấp cho các nhóm một bức tranh chính xác về khả năng giao hàng thực tế. Điều quan trọng là không chỉ xem xét Velocity trung bình của 3-5 sprint gần nhất mà còn cả những yếu tố có thể ảnh hưởng đến năng suất trong sprint sắp tới: ngày nghỉ theo lịch, ngày lễ, nợ kỹ thuật tích lũy hoặc các phụ thuộc bên ngoài.

Phiên lập kế hoạch

Phiên lập kế hoạch

Lập kế hoạch sprint bao gồm hai giai đoạn có cấu trúc: xác định những gì sẽ được giao trong sprint, và xác định cách công việc đã chọn sẽ được thực hiện. Cả hai giai đoạn đều yêu cầu các loại đầu vào khác nhau và tạo ra các loại đầu ra khác nhau — kết hợp chúng sẽ làm giảm hiệu quả của mỗi giai đoạn.

  1. Nhóm, cùng với Product Owner, xác định mục tiêu sprint thống nhất tất cả các user story đã chọn. Mục tiêu nên cụ thể, có thể đo lường được và có ý nghĩa với tất cả người tham gia. Mục tiêu không hiệu quả: "Cải thiện trải nghiệm người dùng." Mục tiêu hiệu quả: "Người dùng sẽ có thể đăng ký thông qua mạng xã hội với một cú nhấp chuột."
  2. Nhóm phát triển phân tách các câu chuyện đã chọn thành các nhiệm vụ và ước tính chúng theo giờ. Quá trình này làm nổi bật các phức tạp và phụ thuộc ẩn không nhìn thấy được ở cấp độ câu chuyện. Mỗi nhiệm vụ không nên mất hơn 8 giờ — các nhiệm vụ vượt quá ngưỡng này cần được phân tách thêm thành các nhiệm vụ con.

Vai trò và trách nhiệm

Lập kế hoạch sprint hiệu quả phụ thuộc vào việc mỗi người tham gia hiểu và hoạt động trong vai trò được xác định của họ.

  • Scrum Master tạo điều kiện cho quá trình, thực thi timebox và giúp nhóm đạt được các quyết định. Scrum Master không áp đặt các giải pháp mà đặt ra những câu hỏi đúng và giữ cho các cuộc thảo luận hiệu quả.
  • Product Owner chịu trách nhiệm về việc ưu tiên backlog và các quyết định về tính năng nào nên được triển khai trước. Họ phải sẵn sàng giải thích giá trị kinh doanh của mỗi câu chuyện và trả lời câu hỏi của nhóm phát triển với đủ độ cụ thể để cho phép ước tính.
  • Nhóm phát triển cam kết giao kết quả. Cam kết này phải đến từ chính nhóm thay vì được giao từ bên ngoài — cam kết do nhóm tự tạo ra tạo ra các mức độ động lực và trách nhiệm khác biệt về chất so với các mục tiêu áp đặt.

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 liên tục đảm nhận nhiều công việc hơn mức họ có thể hoàn thành, đặc biệt là vào đầu một dự án hoặc sau một sprint thành công. Nguyên tắc hoạt động là: tốt hơn nên cam kết ít hơn và giao nhiều hơn. Các cam kết không được thực hiện làm xói mòn niềm tin của các bên liên quan và giảm động lực của nhóm trong các sprint tiếp theo.
  • 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 bao gồm 10-20% thời gian đệm cho các nhiệm vụ không lường trước, lỗi và yêu cầu hỗ trợ kỹ thuật. Khoản dự trữ này không nên được lấp đầy trước bằng các câu chuyện bổ sung — chức năng của nó là hấp thụ công việc không có kế hoạch hiện diện trong mỗi sprint.
  • Bỏ qua các phụ thuộc tạo ra các trở ngại giữa sprint. Tất cả các phụ thuộc bên ngoài phải được xác định và giải quyết trong quá trình lập kế hoạch. Khi một nhiệm vụ phụ thuộc vào nhóm khác hoặc nhà cung cấp bên ngoài, các thời hạn phải được thỏa thuận trước và xác nhận được lấy trước khi sprint bắt đầu.

Giám sát quy trình

Cải tiến liên tục của chính quy trình lập kế hoạch là một yếu tố tiêu chuẩn của thực tiễn Agile trưởng thành. Trong quá trình retrospective, các nhóm nên phân tích không chỉ kết quả thực hiện sprint mà còn cả chất lượng lập kế hoạch như một biến đầu vào riêng biệt.

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

  • Độ chính xác của ước tính — so sánh thời gian dự kiến so với thời gian thực tế đã chi mỗi câu chuyện và nhiệm vụ
  • Tỷ lệ phần trăm câu chuyện hoàn thành — tỷ lệ các câu chuyện đã cam kết trong sprint được giao vào cuối sprint
  • Số lượng thay đổi trong sprint sau khi lập kế hoạch — một thước đo về sự ổn định của lập kế hoạch và độ rõ ràng của yêu cầu
  • Thời gian dành cho lập kế hoạch — được theo dõi so với việc phân bổ tiêu chuẩn để xác định việc đầu tư quá mức hoặc dưới mức mãn tính

Biểu đồ Burndown theo dõi tiến độ trong suốt sprint và làm nổi bật các vấn đề đủ sớm để có hành động khắc phục. Khi biểu đồ chỉ ra rằng nhóm sẽ không hoàn thành công việc đã lên kế hoạch, các biện pháp khắc phục là cần thiết: ưu tiên lại các nhiệm vụ còn lại hoặc loại bỏ các user story có ưu tiên thấp nhất 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. Các công cụ cộng tác chuyên biệt phải có sẵn, và sự tham gia công bằng cho tất cả người tham gia từ xa phải được quản lý chủ động. Tiến hành lập kế hoạch qua một số phiên ngắn hơn thay vì một cuộc họp kéo dài liên tục tạo ra mức độ tham gia và chất lượng đầu ra tốt hơn trong các bối cảnh phân tá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) cung cấp các cơ chế cấu trúc để đồng bộ hóa việc lập kế hoạch sprint giữa các nhóm có phụ thuộc chung.
  • Các dự án bảo trì — nơi một phần đáng kể thời gian sprint dành cho hỗ trợ và giải quyết lỗi — yêu cầu việc dự trữ năng lực rõ ràng cho công việc không có kế hoạch. Phân bổ tiêu chuẩn 30-50% năng lực sprint cho công việc hỗ trợ, với phần còn lại có sẵn cho việc phát triển tính năng mới, ngăn ngừa những thất bại trong giao hàng do việc coi công việc hỗ trợ như chi phí chung thay vì năng lực có kế hoạch.

Sự thật thú vị Biểu tượng sự thật thú vị

Nghiên cứu của VersionOne cho thấy 76% các tổ chức đã triển khai phương pháp Agile báo cáo về sự cải thiện trong chất lượng lập kế hoạch dự án. Các nhóm đầu tư thời gian thích hợp vào việc lập kế hoạch sprint liên tục thể hiện tốc độ giao hàng cao hơn so với các nhóm đầu tư không đủ vào giai đoạn lập kế hoạch.

Bài viết liên quan:

Đối với các khuôn khổ quản lý dự án và cân bằng các 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í.

Đối với cái nhìn tổng quan thực tế về bảng Kanban và quản lý quy trình làm việc trực quan, 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.

Đối với cách các nhóm Agile sử dụng personas để duy trì sự phù hợp với nhu cầu thực 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.

Kết luận

Lập kế hoạch sprint hiệu quả đòi hỏi một cách tiếp cận có hệ thống và cải tiến liên tục như một thực hành có chủ ý thay vì một hoạt động sau dự án. Các retrospective cung cấp cơ chế có cấu trúc để phân tích không chỉ kết quả thực hiện sprint mà còn cả các đầu vào lập kế hoạch đã định hình chúng — khiến chính quá trình lập kế hoạch phải chịu sự cải tiến lặp lại tương tự như Agile áp dụng cho phát triển sản phẩm.

Đọc đề xuất Biểu tượng đọc đề xuất
Sách về khuôn khổ Scrum

"Scrum: The Art of Doing Twice the Work in Half the Time"

Giải thích cách khuôn khổ Scrum cấu trúc công việc của nhóm để đạt được thông lượng giao hàng cao với các cam kết sprint có thể dự đoán được.

Sách về hiểu mục tiêu sản phẩm

"User Story Mapping: Discover the Whole Story, Build the Right Product"

Lập bản đồ câu chuyện trực quan giúp các nhóm phát triển sự hiểu biết chung về mục tiêu sản phẩm và cấu trúc lập kế hoạch sprint xung quanh các ưu tiên lấy người dùng làm trung tâm.

Sách về hiểu mục tiêu sản phẩm

"Essential Scrum: A Practical Guide to the Most Popular Agile Process"

Một tài liệu tham khảo toàn diện về cấu trúc, vai trò và thực hành Scrum cho các nhóm áp dụng khuôn khổ trong công việc hàng ngày.

0 nhận xét
bình luận của bạn
to
Đặt lại
Để lại bình luận

Để lại một bình luận

Đọc thêm

Xem tất cả các bài viết
scroll to up
Back to menu
Back to menu
Dành cho đội nhóm
Ngành công nghiệp
Loại hình công ty
Xem tất cả giải pháp
Xem tất cả giải pháp