Các sự kiện trong scrum

Các sự kiện trong scrum Scrum được định nghĩa bởi 4 sự kiện: Lập kế hoạch Sprint (Sprint Planning), Scrum hàng ngày (Daily Scrum), Sơ kết Sprint (Sprint Review) và Cải tiến Sprint (Sprint Retrospective). Mỗi sự kiện sẽ đảm nhận một vai trò khác nhau, kết hợp với nhau để tạo ra những Sprint

Các sự kiện trong scrum

Scrum được định nghĩa bởi 4 sự kiện: Lập kế hoạch Sprint (Sprint Planning), Scrum hàng ngày (Daily Scrum), Sơ kết Sprint (Sprint Review) và Cải tiến Sprint (Sprint Retrospective). Mỗi sự kiện sẽ đảm nhận một vai trò khác nhau, kết hợp với nhau để tạo ra những Sprint thành công và đạt được mục tiêu mà cả nhóm đề ra.

1. Sprint

Trước khi tìm hiểu về các sự kiện trong Scrum, chúng ta cần hiểu rõ về một Sprint là gì, bởi cả 4 sự kiện trong Scrum đều sẽ được thực hiện trong một Sprint.
Định nghĩa
Sprint trong Scrum là khoảng thời gian mà Nhóm Scrum tiến hành tất cả các hoạt động cần thiết để sản xuất được một phần tăng trưởng có khả năng chuyển giao được.

Sprint được đóng khung thời gian, có độ dài không quá một tháng và nhất quán trong suốt quá trình phát triển. Sprint ngắn gia tăng tính thích ứng với thay đổi và giảm thiểu rủi ro nhưng tăng chi phí quản lý (thời gian cho các cuộc họp tăng lên). Các Sprint diễn ra liên tiếp nhau mà không bị gián đoạn.
Những lưu ý trong Sprint

  • Không cho phép bất kỳ sự thay đổi nào ảnh hưởng đến Mục tiêu Sprint (Sprint Goal)
  • Thành phần Nhóm Phát triển được giữ nguyên
  • Mục tiêu chất lượng không được cắt giảm
  • Phạm vi có thể được làm rõ và tái thương lượng giữa Product Owner và Nhóm Phát triển

2. Lập kế hoạch Sprint

Định nghĩa
Một Sprint bắt đầu bằng buổi Lập kế hoạch Sprint để xác định Mục tiêu Sprint và lên kế hoạch các công việc cần thực hiện. Sự kiện này được chia làm 2 phần: Phần thứ nhất để lựa chọn các công việc cần làm trong Sprint và Phần thứ 2 để quyết định cách thức hoàn thành các công việc đã lựa chọn trước đó.

Toàn bộ buổi Lập kế hoạch Sprint sẽ lần lượt trả lời các câu hỏi: “Mục tiêu của Sprint này là gì?”, “Sprint này phải chuyển giao cái gì?”, “Làm sao để đạt được điều đó?”

3. Scrum hàng ngày

Định nghĩa
Scrum hằng ngày là một sự kiện quan trọng diễn ra đều đặn hằng ngày. Đây là một buổi trao đổi ngắn không kéo dài quá 15 phút với mục đích giúp các Nhà Phát triển đồng bộ công việc và lập kế hoạch cho ngày làm việc tiếp theo.

Lưu ý: Scrum Master thường tham dự nhưng chỉ để đảm bảo các Nhà Phát triển thực hiện đúng công việc chứ không trực tiếp tham gia điều hành hay phát biểu đóng góp vào nội dung của sự kiện. Product Owner và một số người khác có thể tham dự nhưng chỉ được lắng nghe và không đóng góp bất cứ vai trò nào trong sự kiện.

Buổi Scrum Hằng ngày nên được diễn ra tại một địa điểm và khung thời gian cố định để giảm thiểu sự phức tạp. Việc lựa chọn thời điểm tùy thuộc vào nhóm, điều quan trọng là đảm bảo sự kiện này luôn luôn diễn ra đúng thời điểm đã lựa chọn nhằm tạo ra thói quen và không biến nó thành một sự kiện phức tạp.

Những lỗi nên tránh khi Scrum hàng ngày

  • Scrum hàng ngày trở thành một buổi báo cáo công việc cho ScrumMaster.
  • Scrum hàng ngày biến thành nơi dành cho ScrumMaster cập nhật tiến độ công việc.
  • Scrum hàng ngày biến thành một phiên thảo luận để giải quyết vấn đề.
  • Scrum hàng ngày diễn ra quá xa nơi làm việc.
  • Nhà Phát triển không thấy giá trị của buổi Scrum hàng ngày.
  • Các thành viên thường báo cáo là không gặp vấn đề gì.
  • Scrum hàng ngày không diễn ra như là một thói quen, hôm làm hôm bỏ.
  • Scrum Master giao việc cho thành viên trong Scrum hàng ngày.
  • Mỗi người nói xong là xong việc, không nghe người khác nói tiếp.

4. Sơ kết Sprint (Sprint Review)

Định nghĩa
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.

Những lưu ý để buổi Sơ kết Sprint diễn ra hiệu quả

  • Không trình bày những tính năng chưa “hoàn thành”
  • Các phản hồi được đưa ra – Product Backlog có thể được đánh giá lại độ ưu tiên
  • Product Owner nên sử dụng kỹ thuật kiểm thử chấp nhận để đánh giá các tính năng.
  • Đây không là buổi demo sản phẩm. Trong thực tế, việc demo sản phẩm chỉ là một nội dung của buổi Sprint Backlog. Nếu chỉ tập trung vào demo sản phẩm thì sẽ bỏ qua một nội dung quan trọng khác liên quan đến việc thảo luận và cộng tác giữa các thành viên tham gia. Từ đó gây hiểu nhầm và thực hiện sai mục đích thực sự của buổi Sơ kết Sprint đó là thanh tra và thích nghi sản phẩm đang được xây dựng.

5. Cải tiến Sprint (Sprint Retrospective)

Định nghĩa
Cải tiến Sprint là một sự kiện quan trọng trong Scrum, nó diễn ra ngay sau buổi Sơ kết Sprint và trước phiên Lập kế hoạch Sprint tiếp theo. Mục đích của sự kiện này là để cải thiện cách làm việc cho hiệu quả hơn sau mỗi Sprint. Nói cách khác đây là dịp để Nhóm Scrum 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.

Những lưu ý khi thực hiện Sprint Retrospective

  • Nhiều nhóm thực hiện việc cải tiến liên tục rất tùy hứng, không kiểm soát, không theo dõi nên kết quả cải tiến thường không rõ ràng và ít giá trị. Hoạt động cải tiến liên tục cần phải trở thành thói quen của từng cá nhân và nhóm, và lâu dần thành văn hóa của tổ chức thì sẽ đạt hiệu quả cao nhất.
  • Có một lỗi mà các nhóm thường gặp phải đó là buổi cải tiến chỉ tập trung vào những vấn đề làm chưa tốt để cải tiến. Điều này thường dẫn đến tình trạng các thành viên có cảm giác không thích thú với sự kiện này và xem nó như một cuộc họp mang tính tiêu cực. Hãy cố gắng tạo ra sự hứng thú và tinh thần tích cực trong các thành viên bằng cách động viên thông qua những công việc đã làm tốt.
  • Mặc dù việc cải tiến có thể diễn ra bất cứ lúc nào, nhưng sự kiện Sprint Retrospective (Cải tiến Sprint) vẫn là thời điểm chính thức được quy định để làm việc này. Tuân thủ và thực hiện tốt sự kiện này là cách để tạo một thói quen thanh tra và thích nghi quy trình làm việc trong nhóm.

Nguồn: Học viện Agile

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,