Trong các sự kiện của Scrum, chúng ta có 5 hoạt động chính
- Sprint Planning – Lập kế hoạch Sprint: Là sự kiện diễn ra ở đầu mỗi Sprint để chuẩn bị cho toàn bộ Sprint.
- Daily Scrum – Scrum hàng ngày: Là buổi trao đổi ngắn mà Nhóm Phát triển thực hiện đều đặn hằng ngày nhằm cập nhật và đồng bộ công việc giữa các thành viên.
- Sprint Review – Sơ kết Sprint: Là sự kiện diễn ra ở cuối Sprint nhằm thanh tra và thích nghi sản phẩm đang được xây dựng. Sự kiện này bao gồm 2 hoạt động chính đó là dùng thử sản phẩm và thảo luận về tình hình của sản phẩm, hướng đi tiếp theo và những điều chỉnh đối với sản phẩm nếu cần thiết.
- Sprint Retrospective – Cải tiến Sprint: Là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sprint Review nhằm mục đích thanh tra và thích nghi quy trình làm việc. Nói cách khác đây là dịp để Scrum Team nhìn lại quá trình làm việc của một Sprint và xác định những thay đổi cần thiết đối với quy trình để làm việc tốt hơn trong Sprint sau.
- Product Backlog Refinement – Làm mịn Product Backlog: Là hoạt động thêm vào các chi tiết, ước lượng, và trình tự của các hạng mục trong Product Backlog. Đây là quá trình liên tục, theo đó Product Owner và Development Team thảo luận về các chi tiết của từng hạng mục. Trong suốt quá trình làm mịn này, các hạng mục liên tục được xem xét và rà soát cẩn thận.
Sprint Planning
Scrum là 1 framework mà xuyên suốt nó là các sự kiện được đóng khung thời gian: Sprint Planning tối đa 2h với mỗi 1 Sprint 1 tuần, Daily Scrum tối đa 15′, Sprint Retro tối đa 45′ với mỗi Sprint 1 tuần… Về cơ bản, để bắt đầu 1 Sprint ta sẽ lập kế hoạch, để kết thúc Sprint ta sẽ tiến hành sơ kết và họp cải thiện. Nhưng đời đâu như là mơ. Cho dù estimate (ước lượng) kỹ càng cỡ nào thì cũng có lúc có bug, buộc lập trình viên phải overtime. Kế hoạch quảng cáo, marketing, sự kiện đã lên hết cả rồi, không thể nói bỏ là bỏ được. Vậy nên dev nhà ta không có cách nào khác ngoài cắm cúi gõ code và bỏ bớt 1 số cuộc họp.
Câu hỏi: bỏ cuộc họp nào bây giờ?
Sprint Planning thì diễn ra ở đầu Sprint, khi mà team vẫn còn kha khá thời gian. Bản thân nó cũng đóng vai trò rất quan trọng. Daily Scrum thì diễn ra hàng ngày, vào đầu giờ, đóng vai trò quan trọng không kém, và cũng không tốn mấy thời gian. Thế nên 2 sự kiện này đều không nên và không bỏ được rồi.
Bỏ Sprint Review
Có lẽ là cũng là 1 ý kiến chấp nhận được. Lý do: hầu như hàng ngày cả team đã phải coding, test, review, build chương trình và cập nhật tiến độ rồi. Vậy nên cả team đã hình dung mình đạt được điều gì, không đạt được điều gì trong Sprint này rồi. Chỉ còn Product Owner chưa được cập nhật tình hình, nhưng có thể thay vì 1 buổi họp trực tiếp, team có thể gửi link để nhờ Product Owner xác nhận. Sprint Review ở mức độ nào đó đã đạt được mục đích nên có thể cân nhắc tạm không làm.Tuy nhiên điều này cũng không nên kéo dài, vì nó làm mất cảm giác “đạt được 1 cái gì đó” của team.
Ngoài ra trong mô hình outsourcing, Product Owner chính thường là khách hàng, thường không sắp xếp đủ thời gian để tham gia Sprint Review. Để đáp ứng thì team nên gửi link xác nhận sản phẩm liên tục, ngay sau khi hoàn thành chức năng.
Bỏ Product Backlog Refinement
Làm mịn Product Backlog có cần thiết không? Có chứ, nếu không làm mịn thì rất dễ gây kéo dài buổi Sprint Planning do nhiều task chưa được clear rõ ràng. Tuy vậy buổi họp làm mịn Product Backlog hoàn toàn có thể tạm hoãn. Thay vào đó, Product Owner sẽ tự mình làm mịn trước về mặt nội dung của các yêu cầu và phổ biến với team ở buổi Planning.
Bỏ Sprint Retrospective
Thực tế thì mình thấy nhiều team đi tới quyết định này. Phần vì buổi Retro là buổi cuối cùng của Sprint, mà có khi lúc đó anh em lại đang cày cuốc vỡ mặt ra nên tâm trí đâu mà Retro.
Bạn có đang quá bận rộn để cải thiện?
Nhưng thực ra là không nên bỏ Retro đâu nhé
Ý nghĩa của buổi Retro là nhằm để tìm ra điểm chưa tốt và cải thiện quy trình làm việc của team, và nó thường chỉ kéo dài 30′ ~ 45′ là đủ. Thay vì dành 30′ ít ỏi đó để tập trung vào code, team nên sử dụng để tìm cách nâng cao hiệu suất, giải quyết khúc mắc khi làm việc thì sẽ hiệu quả hơn. Cũng giống như chàng tiều phu trong câu chuyện mài chiếc rìu cùn vậy, bạn hãy dành thời gian mài sắc lưỡi rìu của mình để đạt thành công trọn vẹn.
Give me six hours to chop down a tree and I will spend the first four sharpening the ax
Nếu cho tôi 6 giờ để chặt một cái cây, tôi sẽ dành 4 tiếng để mài rìu
- Abraham Lincoln
Tóm lại thì
Không nên bỏ cuộc họp nào đi cả. Cách tốt nhất là ngay từ khi lập kế hoạch, team đưa chi tiết cuộc họp vào trong schedule của mình. Còn nếu bắt buộc, khi yếu tố thời gian không cho phép thì (theo ý kiến cá nhân) có thể tạm hủy theo thứ tự sau
- Product Backlog Refinement – Làm mịn Product Backlog
- Sprint Review – Sơ kết Sprint
Vậy thôi, cố gắng đừng bỏ Sprint Retro nhé.