Bài viết

Cải tiến Sprint

Cải tiến Sprint là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sơ kết Sprint 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 để 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.

Thành phần tham dự: Nhóm Phát triểnScrumMaster bắt buộc phải tham dự. Product Owner có thể tham dự hoặc không. Ngoài ra Nhóm Phát triển còn có thể mời thêm những người khác cùng tham dự nếu cần thiết.

Thời gian: Sự kiện này được đóng khung trong 3 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thời gian có thể ngắn hơn, vào khoảng 45 phút tương ứng với 1 tuần làm việc của Sprint.

Mục đích của buổi Cải tiến Sprint bao gồm:

  • Thanh tra lại Sprint trước, về các yếu tố liên quan đến con người, giao tiếp, quy trình và công cụ.
  • Liệt kê những hạng mục đã làm tốt và những hạng mục có thể cải tiến được.
  • Lên kế hoạch triển khai các cải tiến về cách làm việc của Nhóm Scrum.

Có rất nhiều kỹ thuật để tiến hành một buổi Cải tiến Sprint, chẳng hạn như Glad-Sad-Mad, SpeedBoat, SailBoat,… Trang RetrospectiveWiki có liệt kê một số kỹ thuật thường được dùng.

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 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.

Đọc thêm:

Cải tiến Sprint với Speedboat

Cải tiến Sprint với Sailboat

Cải tiến Sprint với Glad, Sad, Mad.

Sơ kết Sprint

Sơ kết Sprint là sự kiện diễn ra ở cuối Sprint nhằm thanh trathí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.

Thành phần tham dự: Nhóm Phát triển, ScrumMasterProduct Owner bắt buộc phải tham dự. Ngoài ra, Product Owner có thể mời những người khác như người dùng, khách hàng và các bên liên quan khác.

Thời gian: Sự kiện này đóng khung tối đa trong 4 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thường cần ít thời gian hơn.

Bắt đầu sự kiện, Product Owner sẽ trình bày về những hạng mục đã được lựa chọn cho Sprint, liệu chúng đã được hoàn thành hay chưa. Nhóm Phát triển có thể trình bày về những khó khăn mà mình gặp phải trong suốt Sprint và các giải pháp mà mình đã đưa ra.

Tiếp theo là buổi dùng thử sản phẩm. Thay vì để Nhóm Phát triển trình diễn về những tính năng mới làm được trong Sprint thì nên sắp xếp để những người tham gia có thể trực tiếp dùng thử sản phẩm, đặc biệt là những người dùng thực sự.

Sau đó, tất cả mọi người tham gia sẽ thảo luận và đóng góp ý kiến cho sản phẩm. Product OwnerNhóm Phát triển ghi nhận những ý kiến này. Product BacklogKế hoạch Phát hành có thể được thay đổi nếu cần thiết để phù hợp hơn với tình hình mới.

Sự kiện này cũng được coi là cơ hội để Product OwnerNhóm Phát triển tìm hiểu lẫn nhau. Product Owner tìm hiểu về sản phẩm và tình hình của Nhóm Phát triển. Nhóm Phát triển tìm hiểu về tình hình của Product Owner và thị trường.

Scrum Hằng ngày

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. Sự kiện này cũng được coi là buổi tái-lập kế hoạch của Nhóm Phát triển.

Thành phần tham dự: Tất cả các thành viên của Nhóm Phát triển bắt buộc phải tham gia sự kiện Scrum Hằng ngày. ScrumMaster không bắt buộc phải tham dự nhưng phải đảm bảo Nhóm Phát triển thực hiện tốt sự kiện này.

Thời gian: Khung thời gian tối đa cho sự kiện Scrum Hằng ngày là 15 phút, bất kể số lượng thành viên của Nhóm Phát triển là bao nhiêu.

Mục đích của buổi Scrum Hằng ngày không phải là để giải quyết vấn đề mà là để thông báo và cập nhật tình hình. Do vậy, không cho phép bất cứ cuộc thảo luận chi tiết nào ở đây. Để đảm bảo tính ngắn gọn, lần lượt các thành viên của Nhóm Phát triển trình bày câu trả lời cho 3 câu hỏi: Tôi đã làm gì từ buổi Scrum Hằng ngày trước cho đến bây giờ? Tôi sẽ làm gì từ bây giờ cho tới buổi Scrum Hằng ngày hôm sau? Tôi đang gặp phải những khó khăn gì?. Nếu có các vấn đề đỏi hỏi phải thảo luận sâu giữa các thành viên thì Nhóm Phát triển sẽ tổ chức các buổi thảo luận ngay sau khi sự kiện Scrum Hằng ngày kết thúc.

Một thành viên của Nhóm Phát triển sẽ ghi lại các trở ngại để ScrumMaster hỗ trợ giải quyết sau khi buổi trao đổi kết thúc.

Scrum Hằng ngày là một thủ tục đơn giản, dễ thực hiện nhưng cũng vì thế mà nó dễ bị làm sai và không phát huy được tính hiệu quả. Hãy thực hiện Scrum Hằng ngày vào cùng một địa điểm và khung thời gian để tạo thói quen cho nhóm và tìm cách để cho sự kiện này diễn ra vui vẻ, đều đặn và hiệu quả.


Xem thêm:

Họp stand-up, hãy làm cho đúng

Video: Làm sao để cải thiện Scrum Hằng ngày

Agipedia

Cải tiến Sprint

Cải tiến Sprint là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sơ kết Sprint 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 để 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.

Thành phần tham dự: Nhóm Phát triểnScrumMaster bắt buộc phải tham dự. Product Owner có thể tham dự hoặc không. Ngoài ra Nhóm Phát triển còn có thể mời thêm những người khác cùng tham dự nếu cần thiết.

Thời gian: Sự kiện này được đóng khung trong 3 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thời gian có thể ngắn hơn, vào khoảng 45 phút tương ứng với 1 tuần làm việc của Sprint.

Mục đích của buổi Cải tiến Sprint bao gồm:

  • Thanh tra lại Sprint trước, về các yếu tố liên quan đến con người, giao tiếp, quy trình và công cụ.
  • Liệt kê những hạng mục đã làm tốt và những hạng mục có thể cải tiến được.
  • Lên kế hoạch triển khai các cải tiến về cách làm việc của Nhóm Scrum.

Có rất nhiều kỹ thuật để tiến hành một buổi Cải tiến Sprint, chẳng hạn như Glad-Sad-Mad, SpeedBoat, SailBoat,… Trang RetrospectiveWiki có liệt kê một số kỹ thuật thường được dùng.

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 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.

Scrum Hằng ngày

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. Sự kiện này cũng được coi là buổi tái-lập kế hoạch của Nhóm Phát triển.

Thành phần tham dự: Tất cả các thành viên của Nhóm Phát triển bắt buộc phải tham gia sự kiện Scrum Hằng ngày. ScrumMaster không bắt buộc phải tham dự nhưng phải đảm bảo Nhóm Phát triển thực hiện tốt sự kiện này.

Thời gian: Khung thời gian tối đa cho sự kiện Scrum Hằng ngày là 15 phút, bất kể số lượng thành viên của Nhóm Phát triển là bao nhiêu.

Mục đích của buổi Scrum Hằng ngày không phải là để giải quyết vấn đề mà là để thông báo và cập nhật tình hình. Do vậy, không cho phép bất cứ cuộc thảo luận chi tiết nào ở đây. Để đảm bảo tính ngắn gọn, lần lượt các thành viên của Nhóm Phát triển trình bày câu trả lời cho 3 câu hỏi: Tôi đã làm gì từ buổi Scrum Hằng ngày trước cho đến bây giờ? Tôi sẽ làm gì từ bây giờ cho tới buổi Scrum Hằng ngày hôm sau? Tôi đang gặp phải những khó khăn gì?. Nếu có các vấn đề đỏi hỏi phải thảo luận sâu giữa các thành viên thì Nhóm Phát triển sẽ tổ chức các buổi thảo luận ngay sau khi sự kiện Scrum Hằng ngày kết thúc.

Một thành viên của Nhóm Phát triển sẽ ghi lại các trở ngại để ScrumMaster hỗ trợ giải quyết sau khi buổi trao đổi kết thúc.

Scrum Hằng ngày là một thủ tục đơn giản, dễ thực hiện nhưng cũng vì thế mà nó dễ bị làm sai và không phát huy được tính hiệu quả. Hãy thực hiện Scrum Hằng ngày vào cùng một địa điểm và khung thời gian để tạo thói quen cho nhóm và tìm cách để cho sự kiện này diễn ra vui vẻ, đều đặn và hiệu quả.


Đọc thêm: Họp stand-up, hãy làm cho đúng

Video: Làm sao để cải thiện Scrum Hằng ngày

Sơ kết Sprint

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.

Thành phần tham dự: Nhóm Phát triển, ScrumMasterProduct Owner bắt buộc phải tham dự. Ngoài ra, Product Owner có thể mời những người khác như người dùng, khách hàng và các bên liên quan khác.

Thời gian: Sự kiện này đóng khung tối đa trong 4 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thường cần ít thời gian hơn.

Bắt đầu sự kiện, Product Owner sẽ trình bày về những hạng mục đã được lựa chọn cho Sprint, liệu chúng đã được hoàn thành hay chưa. Nhóm Phát triển có thể trình bày về những khó khăn mà mình gặp phải trong suốt Sprint và các giải pháp mà mình đã đưa ra.

Tiếp theo là buổi dùng thử sản phẩm. Thay vì để Nhóm Phát triển trình diễn về những tính năng mới làm được trong Sprint thì nên sắp xếp để những người tham gia có thể trực tiếp dùng thử sản phẩm, đặc biệt là những người dùng thực sự.

Sau đó, tất cả mọi người tham gia sẽ thảo luận và đóng góp ý kiến cho sản phẩm. Product OwnerNhóm Phát triển ghi nhận những ý kiến này. Product BacklogKế hoạch Phát hành có thể được thay đổi nếu cần thiết để phù hợp hơn với tình hình mới.

Sự kiện này cũng được coi là cơ hội để Product OwnerNhóm Phát triển tìm hiểu lẫn nhau. Product Owner tìm hiểu về sản phẩm và tình hình của Nhóm Phát triển. Nhóm Phát triển tìm hiểu về tình hình của Product Owner và thị trường.