Scrum Framework- Scrum event

Các sự kiện được sử dụng trong Scrum là thường xuyên và đã được tối giản, bỏ qua các cuộc họp không cần thiết mà không được định nghĩa trong Scrum. Tất cả các sự kiện đều có time-box, giới hạn trong một khoảng thời gian nhất định. Khi một Sprint bắt đầu, thời gian của nó là cố định và không thể rút ngắn hoặc kéo dài. các sự kiện còn lại có thể kết thúc bất cứ khi nào mục đích của nó được thực hiện, đảm bảo một lượng vừa đủ thời gian và không bị lãng phí.

Sprint

Trái tim của Scrum là một Sprint, sprint có thể kéo dài một tuần đến 1 tháng, các item sau mỗi sprint có thể bàn giao được. Sprint tốt nhất là nên thống nhất trong suốt quá trình phát triển. Một sprint mới được bắt đầu ngay khi kết thúc sprint trước. Sprint bao gồm Sprint Planning, Daily Scrums, the Sprint Review và Sprint Retrospective. Trong một Sprint:

• Không nên có thay đổi vì nó sẽ làm ảnh hưởng tới Sprint Goal
• Mục tiêu chất lượng không giảm
• Phạm vi có thể được làm rõ và tái đàm phán PO và team Mỗi Sprint có thể được coi là một dự án dài quá 1 tháng. Giống như một dự án, mỗi Sprint có một định nghĩa về những gì sẽ được thực hiện, thiết kế, các công việc và sản phẩm tạo thành. Sprint được giới hạn, nếu sprint quá dài thì không kịp thích ứng với thay đổi, rủi ro có thể tăng. Sprint cho phép dự đoán bằng cách đảm bảo sự kiểm tra và tính thích ứng liên tục ít nhất là mỗi tháng, hướng tới Sprint Goal Hủy Sprint Một Sprint có thể bị dừng lại trước thời gian đã định. Chỉ PO mới có quyền hủy bỏ hoặc dừng Sprint, mặc dù việc dừng đó là do ảnh hưởng từ các bên liên quan như nhóm phát triển, hoặc Scrum Master. Một Sprint sẽ bị hủy bỏ nếu Sprint Goal trở nên lỗi thời. Điều này có thể xảy ra nếu các công ty thay đổi mục tiêu hoặc nếu thị trường hay công nghệ thay đổi. Nói chung, một Sprint nên bị hủy bỏ nếu nó không còn có ý nghĩa. Tuy nhiên, do thời gian ngắn Sprints nên việc hủy hiếm khi có giá trị. Khi một Sprint bị hủy, tất cả các item đã hoàn thành trong Product backlog cần được review. Nếu một phần của công việc có khả năng bàn giao thì PO thường chấp nhận. Tất các item chưa hoàn thành cần được estimate lại và đưa về Product Backlog. Việc hủy Sprint có thể gây tốn thời gian và effort vì cần thay đổi kế hoạch của các sprint khác, nó gây ảnh hưởng đến Scrum team và do đó thường hiếm khi xảy ra.

Sprint Planning

Công việc được thực hiện trong Sprint được lên kế hoạch tại buổi họp Sprint Planning. Kế hoạch này được thực hiện bởi PO và Scrum team Thời gian tối đa cho 1 buổi sprint planning meeting là 8h cho 1 sprint 4 tuần. Scrum master cần giữ cho buổi họp này đúng time box đề ra. Kế hoạch Sprint trả lời các câu hỏi sau:

• Những việc nào có thể được hoàn thành trong Sprint này?
• công việc đã chọn sẽ được thực hiện như thế nào? Câu hỏi thứ nhất: Những việc nào có thể được hoàn thành trong Sprint này? Scrum team nghiên cứu để dự báo các chức năng sẽ được phát triển trong Sprint. PO thảo luận về mục đích mà Sprint cần đạt được hướng tới Sprint Goal. Toàn bộ Scrum team tham gia vào việc tìm hiểu công việc của Sprint. Sau khi Scrum team dự định các item sẽ được làm và bàn giao trong Sprint, Scrum team thiết lập Sprint Goal, đó là các mục tiêu cần đạt được trong Sprint thông qua việc thực hiện các iteam trong Product Backlog. Câu hỏi thứ hai: công việc đã chọn sẽ được thực hiện như thế nào? Sau khi thiết lập Sprint Goal và chọn các item trong Product Backlog cho Sprint, Scrum team sẽ quyết định các chức năng sẽ được xây dựng như thế nào để đu. Các mục sản phẩm Backlog được coi là “Done”. Các Product Backlog item được lựa chọn thực hiện trong Sprint cùng với kế hoạch bàn giao được gọi là Sprint Backlog. Scrum team thường bắt đầu bằng cách thiết kế hệ thống và công việc cần thiết để chuyển đổi Product Backlog thành từng phần có thể bàn giao được. PO có thể giúp làm rõ các Product Backlog item đã được chọn. Nếu Scrum team xác định có quá nhiều hoặc quá ít công việc, họ có thể thương lượng lại các item trong Product Backlog đã được chọn với PO. Nhóm phát triển cũng có thể mời những người khác tham dự để cung cấp tư vấn kỹ thuật. Cuối buổi họp Sprint Planning, Nhóm phát triển phải có khả năng giải thích cho PO và Scrum Master về ý định làm việc như một nhóm tự tổ chức để hoàn thành Mục tiêu Sprint và tạo ra Tăng trưởng như dự kiến.

Sprint Goal

Sprint Goal là một mục tiêu đặt ra cho Sprint, có thể đạt được thông qua việc thực hiện Product Backlog. Nó được tạo ra trong cuộc họp Sprint Planning Khi Scrum team làm việc, luôn phải hướng tới Sprint Goal, nếu công việc dần sai lệch với những gì mong đợi thì họ cần làm việc với PO để thương lượng lại phạm vi của Sprint Backlog.

Daily Scrum

Daily Scrum là một cuộc họp kéo dài 15 phút cho Scrum team để đồng bộ các hoạt động và lập một kế hoạch cho 24 giờ tiếp theo. Daily Scrum được tổ chức cùng một thời điểm trong ngày để giảm sự phức tạp. Trong cuộc họp, các thành viên Nhóm phát triển giải thích: Tôi đã làm gì trong ngày hôm qua? Tôi sẽ làm gì hôm nay? Có trở ngại nào không? Scrum team sử dụng Daily Scrum để kiểm tra tiến độ và bám sát Sprint Goal. Scrum team các thành viên trong nhóm thường gặp nhau ngay sau Daily Scrum để thảo luận chi tiết, hoặc để điều chỉnh, hoặc bổ sung lại, công việc còn lại của Sprint. Scrum Master đảm cuộc họp Daily Scrum được duy trì thường xuyên, nhưng Scrum team chịu trách nhiệm về các hoạt động trong cuộc họp. Scrum Master hướng dẫn Scrum team để giữ cho Daily Scrum trong khoảng thời gian 15 phút. Daily Scrums giúp cải thiện giao tiếp, loại bỏ các cuộc họp khác, xác định những trở ngại trong quá trình phát triển để loại bỏ, thúc đẩy quá trình ra quyết định nhanh chóng và nâng cao trình độ của Nhóm phát triển.

Sprint Review

Sprint Review được tổ chức vào cuối Sprint để kiểm tra những phần đã được bàn giao và điều chỉnh Product Backlog. Trong buổi Sprint Review, Scrum team cùng các bên liên quan nhìn lại những gì đã được thực hiện trong Sprint. Dựa vào đó và những thay đổi đối với Product Backlog trong Sprint, người tham dự lên kế hoạch về những việc tiếp theo có thể thực hiện để tối ưu hóa giá trị. Buổi họp có thời gian bốn giờ cho Sprint một tháng. Đối với Sprints ngắn hơn, sự kiện này thường ngắn hơn. Scrum Master đảm bảo rằng sự kiện diễn ra và người tham gia hiểu mục đích của nó. The Scrum Master hướng dẫn để đảm bảo time box của cuộc họp được giữ đúng. Sprint Review bao gồm các yếu tố sau:

• Người tham dự: Scrum team và các bên liên quan chính được PO mời;
• PO giải thích các item của Product Backlog đã được "Done" và những gì chưa được "Done";
• Scrum team thảo luận về những gì đã làm được trong Sprint, những vấn đề gặp phải và những vấn đề đó đã được giải quyết như thế nào
• Scrum team thể hiện công việc đã "Done" và trả lời các câu hỏi về Sự gia tăng
• PO thảo luận về Product Backlog. Người đó dự kiến ngày hoàn thành dựa trên tiến độ của dự án.
• Toàn bộ nhóm sẽ hợp tác để xác định việc phải làm gì tiếp theo, Sprint Review cung cấp đầu vào có giá trị cho Sprint Planning tiếp theo.
• Đánh giá lại nhu cầu thị trường, những gì mang lại giá trị nhất cần làm trong Sprint tiếp theo.
• Đánh giá lại thời gian, ngân sách, khả năng tiềm năng và thị trường cho phiên bản dự kiến tiếp theo của sản phẩm. Kết quả của Sprint Review là một Product Backlog được sửa đổi xác định các sản phẩm Backlog có thể xảy ra cho Sprint tiếp theo. Product Backlog cũng có thể được điều chỉnh tổng thể để đáp ứng các nhu cầu mới.

Sprint Retrospective

Sprint Retrospective là cơ hội để Scrum Team tự nhìn lại cả quá trình của Sprint và tạo kế hoạch để cải tiến trong Sprint tiếp theo Sprint Retrospective được thực hiện sau Sprint Review và trước buổi Sprint Planning tiếp theo. Retrospective meeting kéo dài ba giờ đối với Sprint một tháng. Đối với Sprints ngắn hơn, sự kiện này thường ngắn hơn. Scrum Master đảm bảo rằng sự kiện diễn ra và người tham gia hiểu mục đích của nó. Scrum Master hướng dẫn mọi người để giữ time box của cuộc họp. Scrum Master tham gia như là thành viên trong team, trừ trách nhiệm giải thích Scrum process. Mục đích của Sprint Retrospective:

• Đánh giá lại về con người, các mối quan hệ, quy trình, công cụ trong team
• Xác định và sắp xếp các major item đã rõ ràng và có thể thực hiện được
• Tạo một kế hoạch để thực hiện các cải tiến Scrum Master khuyến khích Scrum team cải tiến. Trong mỗi buổi Sprint Retrospective, Scrum team sẽ lên kế hoạch để tăng chất lượng sản phẩm bằng cách sử dụng định nghĩa "Done" nếu thích hợp. Đến cuối buổi Sprint Retrospective, Scrum team nên xác định những cải tiến sẽ thực hiện trong Sprint tiếp theo. Mặc dù cải tiến có thể được thực hiện bất kỳ lúc nào, Sprint Retrospective cung cấp một cơ hội chính thức để tập trung vào kiểm tra và thích ứng.

Nguồn: http://www.scrumguides.org/