Giao hàng Agile hiệu quả phụ thuộc rất nhiều vào công tác chuẩn bị. Khi các đội bắt đầu ngay lập tức vào lập kế hoạch Sprint mà không có sự chuẩn bị đầy đủ, kết quả thường là sự mơ hồ, động lực bị đình trệ và thiếu cam kết. Quy trình rà soát các mục trong danh sách công việc trước khi bắt đầu lập kế hoạch Sprintlà nền tảng cốt lõi của một đội Scrum có thể dự đoán được và hoạt động hiệu quả. Hướng dẫn này khám phá các cơ chế, triết lý và các bước thực tế cần thiết để đảm bảo danh sách công việc sản phẩm của bạn luôn sẵn sàng.
🤔 Tại sao việc rà soát danh sách công việc lại quan trọng
Nhiều tổ chức coi danh sách công việc sản phẩm như một danh sách tĩnh, phát triển không giới hạn. Trên thực tế, đó là một tài sản động, đòi hỏi bảo trì liên tục. Việc rà soát không phải là một sự kiện duy nhất; đó là một hoạt động diễn ra liên tục. Nếu không có nó, chi phí thay đổi sẽ tăng lên, và khả năng dự báo giao hàng của đội sẽ giảm đi.
Hãy cân nhắc phương án thay thế: tham gia buổi lập kế hoạch Sprint với các yêu cầu mơ hồ. Đội phải dành nửa đầu buổi họp để đặt câu hỏi thay vì cam kết làm việc. Điều này dẫn đến:
- Tốc độ giảm sút:Thời gian dành để làm rõ yêu cầu trong quá trình lập kế hoạch là thời gian không được dùng để phát triển.
- Chất lượng thấp hơn:Tiêu chí chấp nhận không rõ ràng thường dẫn đến công việc phải làm lại sau khi Sprint kết thúc.
- Sự thất vọng của đội:Các nhà phát triển cảm thấy không được chuẩn bị và buộc phải đoán mò các yêu cầu.
- Mở rộng phạm vi:Không có ranh giới rõ ràng, các ý tưởng mới sẽ được thêm vào giữa Sprint.
Việc rà soát giúp giảm thiểu những rủi ro này. Nó chuyển tải gánh nặng nhận thức khỏi buổi họp lập kế hoạch Sprint, giúp đội có thể tập trung vào làm thế nàođể xây dựng giải pháp thay vì cái gìcần phải được xây dựng.
🛠 Việc rà soát danh sách công việc là gì?
Việc rà soát danh sách công việc, đôi khi được gọi là làm sạch danh sách công việc, là quá trình xem xét, cập nhật và sắp xếp các mục trong danh sách công việc sản phẩm. Nó bao gồm việc chia nhỏ các bản ghi lớn thành các câu chuyện nhỏ hơn, làm rõ yêu cầu và ước lượng nỗ lực.
Hoạt động này khác biệt với lập kế hoạch Sprint. Lập kế hoạch là sự kiện ra quyết định nơi đội cam kết thực hiện một tập hợp cụ thể các mục cho Sprint sắp tới. Việc rà soát là công việc chuẩn bị giúp các quyết định đó trở nên khả thi.
Đặc điểm chính của việc rà soát
- Hợp tác:Nó đòi hỏi sự tham gia của Chủ sở hữu sản phẩm, Đội phát triển và đôi khi là các bên liên quan.
- Liên tục:Nó diễn ra liên tục, không chỉ diễn ra ngay trước khi lập kế hoạch.
- Giới hạn thời gian:Nó không nên chiếm toàn bộ Sprint. Một quy tắc phổ biến là dành 5-10% năng lực của đội.
- Lặp lại:Các mục có thể được tinh chỉnh nhiều lần trước khi được chọn cho một sprint.
👥 Ai nên tham gia?
Việc tinh chỉnh là một hoạt động của cả đội. Trong khi Product Owner chịu trách nhiệm về danh sách công việc, đội phát triển chịu trách nhiệm về việc triển khai. Cả hai góc nhìn này đều cần thiết.
- Product Owner:Cung cấp bối cảnh, làm rõ lý do “tại sao” và nội dung “cái gì”, đồng thời ưu tiên các mục dựa trên giá trị kinh doanh.
- Nhà phát triển:Xác định các rủi ro kỹ thuật, làm rõ chi tiết triển khai và đưa ra ước tính.
- Scrum Master:Hỗ trợ buổi họp, đảm bảo đội tập trung và loại bỏ các trở ngại đối với quy trình.
- QA/Kiểm thử viên:Xác định các tiêu chí chấp nhận và phát hiện các trường hợp biên sớm.
Loại bỏ các bên liên quan quá sớm có thể dẫn đến bỏ sót yêu cầu. Bao gồm quá nhiều người có thể làm chậm cuộc thảo luận. Đội cốt lõi nên dẫn dắt cuộc thảo luận, với các bên liên quan sẵn sàng tham gia khi cần thiết để đi sâu vào từng vấn đề cụ thể.
📝 Tiêu chuẩn Sẵn sàng
Trước khi một mục được đưa vào buổi lập kế hoạch Sprint, nó phải đạt đến một ngưỡng cụ thể về độ rõ ràng. Điều này thường được quy định thành mộtTiêu chuẩn Sẵn sàng (DoR). Một mục không đáp ứng DoR thì không nên được thảo luận để chọn trong sprint sắp tới.
Các yếu tố cốt lõi của một mục đã sẵn sàng
- Giá trị rõ ràng:Câu chuyện người dùng nêu rõ ai cần tính năng này và tại sao điều đó quan trọng.
- Tiêu chí chấp nhận:Các điều kiện cụ thể phải được đáp ứng để coi câu chuyện là hoàn thành.
- Kích thước có thể ước tính:Câu chuyện đủ nhỏ để có thể ước lượng kích thước (ví dụ: điểm câu chuyện) và phù hợp trong một sprint.
- Các phụ thuộc đã được giải quyết:Các phụ thuộc kỹ thuật hoặc bên ngoài đã được xác định và quản lý.
- Thiết kế sẵn sàng:Thiết kế UI/UX hoặc tài liệu kỹ thuật sẵn sàng nếu cần thiết.
🔍 Đi sâu: Bản đồ Câu chuyện Người dùng
Một trong những kỹ thuật hiệu quả nhất cho việc tinh chỉnh là Bản đồ Câu chuyện Người dùng. Phương pháp trực quan này giúp đội hiểu được luồng trải nghiệm người dùng và phát hiện các khoảng trống trong chức năng.
Thay vì một danh sách phẳng, các câu chuyện được sắp xếp theo chiều ngang để đại diện cho hành trình người dùng. Điều này giúp đội hình nhìn thấy bức tranh toàn cảnh và quyết định những gì tạo thành Sản phẩm Tối thiểu Khả thi (MVP) cho vòng lặp tiếp theo.
Các bước thực hiện Bản đồ Câu chuyện:
- Xác định các Hoạt động:Những bước chính mà người dùng thực hiện để đạt được mục tiêu của họ là gì?
- Chia thành Các Nhiệm vụ:Những hành động cụ thể nào cần thực hiện trong từng hoạt động?
- Xác định Các Câu chuyện:Chuyển đổi các nhiệm vụ thành các câu chuyện người dùng có thể thực hiện.
- Thứ tự sắp xếp:Sắp xếp các câu chuyện theo thứ tự ưu tiên để tạo thành một hành trình có thể đi được.
🧮 Ước lượng trong quá trình tinh chỉnh
Việc ước lượng là một phần quan trọng trong công tác chuẩn bị. Nó không dự đoán chính xác thời gian cần thiết, mà thay vào đó là mức độ phức tạp tương đối và nỗ lực liên quan. Các đội thường sử dụngĐiểm Câu chuyện hoặc Phân loại theo kích cỡ áo thun.
Các yếu tố ảnh hưởng đến việc ước lượng
- Độ phức tạp:Việc triển khai kỹ thuật khó đến mức nào?
- Độ bất định:Chúng ta biết bao nhiêu về các yêu cầu?
- Nỗ lực:Dự kiến sẽ mất bao nhiêu giờ làm việc?
- Rủi ro:Có những điểm nguy hiểm tiềm tàng nào có thể làm chậm tiến độ không?
Trong quá trình tinh chỉnh, đội hình thảo luận các yếu tố này. Nếu một mục quá lớn, nó sẽ được chia thành các câu chuyện nhỏ hơn. Nếu quá mơ hồ, nó sẽ được gửi lại cho Người sở hữu Sản phẩm để làm rõ. Điều này đảm bảo rằng các mục được chọn trong quá trình lập kế hoạch Sprint là thực tế.
⚠️ Những sai lầm phổ biến trong quá trình tinh chỉnh
Ngay cả các đội có kinh nghiệm cũng có thể rơi vào bẫy trong quá trình tinh chỉnh. Nhận thức về những sai lầm này giúp duy trì tính toàn vẹn của quy trình làm việc.
| Sai lầm | Tác động | Chiến lược giảm thiểu |
|---|---|---|
| Làm chi tiết quá mức | Lãng phí thời gian vào các công việc chưa được chọn cho sprint. | Tập trung chỉ vào 20% đầu tiên của danh sách công việc. |
| Làm chi tiết chưa đủ | Các mục đến giai đoạn lập kế hoạch với quá nhiều điều chưa rõ. | Thực thi nghiêm ngặt Định nghĩa về Sẵn sàng. |
| Bỏ qua nợ kỹ thuật | Tốc độ tương lai giảm dần do tích tụ các vấn đề. | Phân bổ dung lượng cụ thể cho việc tái cấu trúc. |
| Bỏ qua ý kiến của các bên liên quan | Thiếu bối cảnh kinh doanh dẫn đến các giải pháp sai. | Mời các bên liên quan tham gia các cuộc thảo luận ưu tiên cao. |
| Ước lượng như cam kết | Áp lực đạt số liệu thay vì mang lại giá trị. | Xem ước lượng như dự báo, chứ không phải cam kết. |
🛡 Quản lý các phụ thuộc
Các phụ thuộc có thể làm hỏng một sprint ngay từ đầu. Trong quá trình làm chi tiết, đội cần xác định xem một câu chuyện có phụ thuộc vào câu chuyện khác, một API bên ngoài hay một dịch vụ bên thứ ba hay không.
Các loại phụ thuộc:
- Bên trong:Câu chuyện A phải hoàn thành trước khi câu chuyện B có thể bắt đầu.
- Bên ngoài:Phụ thuộc vào nhà cung cấp hoặc một nhóm khác.
- Nguồn lực:Cần một kỹ năng cụ thể mà hiện tại chưa có sẵn.
Khi phát hiện các phụ thuộc, đội cần lên kế hoạch phù hợp. Điều này có thể có nghĩa là lên lịch các câu chuyện phụ thuộc trong cùng một sprint hoặc phối hợp với các nhóm khác từ trước.
📏 Phân tích sâu về Tiêu chí chấp nhận
Tiêu chí chấp nhận là những điều kiện mà một sản phẩm phần mềm phải đáp ứng để được người dùng, khách hàng hoặc bên liên quan khác chấp nhận. Chúng được viết từ góc nhìn của người dùng.
Viết các tiêu chí hiệu quả
- Cụ thể rõ ràng: Tránh các thuật ngữ mơ hồ như “nhanh” hoặc “dễ”. Sử dụng các thuật ngữ có thể đo lường được như “tải trang trong dưới 2 giây.”
- Có thể kiểm thử:QA nên có thể viết một trường hợp kiểm thử dựa trên các tiêu chí.
- Phủ các trường hợp biên: Điều gì xảy ra nếu người dùng nhập dữ liệu không hợp lệ? Điều gì xảy ra nếu mạng bị lỗi?
- Sử dụng cú pháp Gherkin: Một số đội ưu tiên định dạng “Given/When/Then” để rõ ràng hơn.
Ví dụ:
- Xấu: “Người dùng có thể đăng nhập.”
- Tốt: “Cho một tên người dùng và mật khẩu hợp lệ, khi người dùng nhấp vào đăng nhập, thì hệ thống sẽ chuyển hướng đến bảng điều khiển.”
🔄 Cải tiến liên tục
Việc tinh chỉnh không phải là cố định. Khi đội tích lũy thêm kinh nghiệm với lĩnh vực, cách thức tinh chỉnh các mục sẽ thay đổi. Các buổi tổng kết nên bao gồm thảo luận về chính quá trình tinh chỉnh.
Những câu hỏi cần đặt ra trong buổi tổng kết:
- Chúng ta có đủ các mục đã sẵn sàng cho sprint tiếp theo không?
- Có bất kỳ điều bất ngờ nào xảy ra trong sprint mà có thể đã được phát hiện sớm hơn không?
- Đội có cảm thấy tự tin về các ước lượng của mình không?
- Tiêu chuẩn “Sẵn sàng” có được đáp ứng cho tất cả các mục đã chọn không?
📅 Thời gian và nhịp độ
Không có quy tắc duy nhất về việc khi nào nên thực hiện tinh chỉnh, nhưng tính nhất quán là điều then chốt. Một số đội tổ chức buổi tinh chỉnh riêng trong giữa sprint. Những đội khác tích hợp nó vào các buổi họp hàng ngày hoặc lập trình cặp.
Nhịp độ được khuyến nghị:
- Buổi hàng tuần: Một buổi họp 1 giờ mỗi tuần dành cho toàn bộ đội.
- Theo nhu cầu: Người chủ sản phẩm và trưởng nhóm phát triển thảo luận các mục mỗi ngày.
- Ngay trước khi cần: Tinh chỉnh các mục từ 1 đến 2 sprint trước khi chúng cần thiết.
Mục tiêu là đảm bảo phần đầu danh sách công việc luôn được hoàn thiện. Nếu bạn chờ đến phút cuối cùng, bạn có nguy cơ vội vàng quá trình và làm giảm chất lượng.
🧩 Mô hình INVEST
Khi phân tích các mục, mô hình INVEST là một khung chuẩn để đảm bảo chất lượng.
- I – Độc lập:Các câu chuyện cần có thể được phát triển độc lập so với những câu chuyện khác.
- N – Có thể thương lượng:Chi tiết là mở cho thảo luận, không phải là hợp đồng cố định.
- V – Có giá trị:Mỗi câu chuyện phải mang lại giá trị cho người dùng.
- E – Có thể ước lượng:Đội ngũ phải có khả năng ước lượng khối lượng công việc.
- S – Nhỏ:Các câu chuyện cần phải phù hợp trong một sprint.
- T – Có thể kiểm thử:Phải có cách để xác minh câu chuyện đã hoàn thành.
🌱 Xây dựng văn hóa tinh chỉnh
Quy trình quan trọng, nhưng văn hóa thì thiết yếu. Một văn hóa tinh chỉnh coi trọng sự chuẩn bị hơn tốc độ. Nó khuyến khích đặt câu hỏi sớm. Nó tạo ra môi trường an toàn để nói rằng “Tôi không hiểu yêu cầu này” mà không sợ bị phán xét.
Lãnh đạo cần hỗ trợ điều này. Nếu quản lý thúc đẩy tốc độ hơn mà không cho thời gian chuẩn bị, quá trình tinh chỉnh sẽ bị ảnh hưởng. Ngược lại, nếu lãnh đạo coi trọng tính dự đoán và chất lượng, họ sẽ dành thời gian cho hoạt động then chốt này.
📊 Đo lường thành công
Làm sao bạn biết quá trình tinh chỉnh của bạn có hiệu quả không? Hãy theo dõi các chỉ số này theo thời gian.
- Tỷ lệ thành công mục tiêu Sprint:Bạn có hoàn thành những gì đã lên kế hoạch không?
- Tỷ lệ chuyển sang sprint tiếp theo:Có bao nhiêu câu chuyện bị chuyển sang sprint tiếp theo do thiếu sự rõ ràng?
- Độ ổn định tốc độ:Xuất phát của đội bạn có nhất quán không?
- Số lượng lỗi:Bạn có đang phát hiện ít lỗi hơn trong môi trường sản xuất không?
🏁 Tóm tắt các thực hành tốt nhất
Tóm lại, tinh chỉnh các mục trong danh sách công việc trước khi bắt đầu lập kế hoạch Sprint là điều bắt buộc; nó là thiết yếu cho sự trưởng thành của Agile. Bằng cách tuân thủ các thực hành tốt nhất sau đây, các đội có thể đảm bảo một buổi lập kế hoạch trơn tru và một sprint hiệu quả.
- Xác định mức độ sẵn sàng:Thiết lập các tiêu chí rõ ràng về những gì một câu chuyện cần để sẵn sàng.
- Tham gia đội ngũ: Đảm bảo các nhà phát triển và kiểm thử tham gia vào cuộc trò chuyện.
- Tập trung vào giá trị:Ưu tiên các mục mang lại giá trị kinh doanh cao nhất.
- Ước lượng sớm:Ước lượng quy mô các câu chuyện trước khi sprint bắt đầu để đặt kỳ vọng.
- Quản lý phụ thuộc: Nhận diện rủi ro và các trở ngại bên ngoài từ sớm.
- Giữ nó trong khung thời gian giới hạn: Tôn trọng năng lực của đội và tránh làm chi tiết hóa quá mức.
Bằng cách đầu tư thời gian vào giai đoạn chuẩn bị này, bạn xây dựng nền tảng cho sự phát triển bền vững. Kết quả là một đội ngũ luôn cung cấp giá trị một cách nhất quán, với sự tự tin cao và căng thẳng thấp.