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. Thông thường thì mỗi sprint kéo dài từ 1-2 tuần. Các phần tăng trưởng của sản phẩm có thể phát hành được sản xuất gói gọn trong khung thời gian này. Trong suốt quá trình phát triển sản phẩm, Sprint được khuyến nghị giữ khung thời gian cố định. Một sprint mới 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 cho phép bất kì sự thay đổi nào ảnh hưởng tới mục tiêu của Sprint
• 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.

Tuy vậy, sprint có thể bị huỷ khi chưa kết thúc khung thời gian khi mục tiêu của sprint không còn phù hợp nữa. Điều này xảy ra khi công ty chuyển hướng kinh doanh hoặc khi tình thế công nghệ có sự thay đổi. Chỉ có PO mới đủ thầm quyền kết thúc Sprint. Khi sprint bị huỷ, các phầm sản phẩm đã hoàn chỉnh được xem xét lại. Các hạng mục trong backlog chưa hoàn tất sẽ được ước lượng lại và trả về product backlog để phát triển tiếp.

Lập kế hoạch sprint (Sprint Planning)

Khi một sprint bắt đầu, thì buổi Planing Meeting sẽ được thực hiện để xác định mục tiêu và chọn ra các task cần làm. Sự kiện này chia làm hai phần, phần một tất nhiên là chọn task và phần 2 là quyết định cách thức hoàn thành các task đó. Trong buổi planing meeting chúng ta sẽ lần lượt trả lời các câu hỏi sau:

• 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 đó?

Toàn bộ nhóm Scrum bắt buộc phải tham gia phần thứ nhất của sự kiện. ở phần thứ 2 PO có thể vắng mặt nhưng phải luôn sẵn sàng hỗ trợ nhóm phát triển làm rõ các hạng mục khi cần thiết. Thời gian tối đa cho 1 buổi sprint planning meeting là 8h cho một sprint 4 tuần. Thời gian dành cho 2 phần này được chia đều cho nhau, mỗi phần chiếm một nửa.

Phần 1: Làm gì trong Sprint này?

Đáp án của câu hỏi này chính là mục tiêu và danh sách các backlog được lựa chọn cho sprint. Phần này bắt đầu bằng việc PO trình bày mục tiêu momg muốn đạt được trong Sprint này. Sau đó PO làm rõ thêm các hạng mục ở phần trên của Product backlog để cả nhóm hiểu kỹ về các mục đó. Trong trường hợp, số lượng backlog ở sprint này so với sprint trước khác nhau, PO phải có trách nhiệm làm rõ. Căn cứ vào mục tiêu sprint và năng lực hiện có, nhóm phát triển sẽ lựa chọn những mục mà họ tin có thể hoàn thành trong Sprint này, bắt đầu từ những hạng mục đứng đầu trong Product Backlog. Đây là cách làm chủ chốt trong Scrum: nhóm phát triển quyết định có bao nhiêu hạng mục sẽ được hoàn thành, thay vì được giao bởi PO. Điều này sẽ giúp nhóm phát triển đưa racacs dự báo tin cậy hơn do họ làm việc đó căn cứ vào những phân tích và lập kế hoạch của chính bản thân họ.

Để quyết định những hạng mục nào của Product Backlog sẽ triển khai trong Sprint này. Nhóm phát triển xem xét tốc độ trung bình của mình trong các sprint trước kết hợp với những yếu tố bất ngờ ở sprint này để tính đưa ra số lượng backlog cho sprint này. Ví dụ: Trong sprint trước, nhóm phát triển 7 người đã hoàn thành 80 point. Mà trong sprint này có người xin nghỉ phép 3 ngày. Vậy khả năng của nhóm không thể đạt được 80 point như trước. Do đó chỉ lựa chọn số lượng hạng mục đủ làm với tổng point là nhỏ hơn 80.

Ở đây phần trên chúng ta có nói đến việc tốc độ của sprint (velocity). Tốc độ đó được tính bằng số lượng đơn vị được hoàn thành trong mỗi Sprint. Nếu bạn dùng đơn vị là point, thì tốc độ chính là số điểm mà nhóm hoàn thành sau mỗi Sprint. Qua thời gian, tốc độ của nhóm có thể tương đối ổn định. Đó là tiền đề quan trọng có thể phỏng đoán được khối lượng công việc của nhóm trong mỗi Sprint.

Nếu nhóm phát triển muốn lựa chọn một vài hạng mục có độ ưu tiên thấp ở phía dưới của Product backlog họ cần thảo luận với PO. Điều này thường xảy ra khi có sự phụ thuộc giữa các hạng mục hoặc nhóm cảm thấy mục đó có độ ưu tiên thấp nhưng phù hợp để phát triển cùng với các mục khác đã lựa chọn. Kết thúc phần 1, nhóm phát triển và PO thống nhất lại mục tiêu và danh sách backlog . Mục tiêu của sprint là một đoạn mô tả ngắn về kết quả kỳ vọng đạt được sau khi sprint kết thúc. Mục tiêu của sprint đóng vai trò định hướng nhóm Phát triển trong suốt quá trình diễn ra Sprint và đồng thời giúp nhóm đưa ra được những quyết định hợp lý nhằm đạt được mục tiêu này. Một ví dụ về Mục tiêu Sprint là :”Xây dựng chức năng mua hàng bao gồm: Xem danh sách sản phẩm, thêm sản phẩm vào giỏ hàng, xem giỏ hàng, loại bỏ sản phẩm khỏi gior hàng, hiển thị thanh toán”.

Phần 2: Làm sao để hoàn thành công việc đã chọn

Phần 2 của buổi lập kế hoạch Sprint với mục đích trả lời cho câu hỏi: Làm sao để hoàn thành công việc đã chọn? Kết quả của phần này đó là Sprint Backlog – tức là bằng công việc được Nhóm phát triển sử dụng trong suốt sprint, bao gồm các task trong Backlog đã lựa chọn và danh sách công việc tương tứng với từng hạng mục đó. Nhóm phát triển bắt đầu thiết kế hệ thống và lên danh sách các công việc cần làm. Đối với mỗi hạng mục trong danh sách đã lựa chọn, nhóm sẽ tách thành các công việc cụ thể. Các công việc này phải đảm bảo đủ nhỏ để hoàn thành trong vài giờ. Mộ số loại công việc thường được thấy là: design mockup, viết test, nghiên cứu kĩ thuật, triển khai tính năng v.v…Tất cả các công việc này đều phải được nhóm ước lược thời gian để hoàn thành. Thường được tính qua đơn vị point và được quyết định qua Planing Poker( một loại bài để quyết định số point cho một task). Những point này sẽ được cập nhập trong Sprint Backlog đồng thời cũng được sử dụng để tạo biểu độ Sprint Burndown nhằm theo dõi tiến độ Sprint. Sau mỗi ngày làm việc, các thành viên sẽ cập nhập đồng thời Sprint Backlog và biểu đồ với các giá trị mới. Nếu nhóm thấy rằng lược công việc quá nhiêu hay quá ít so với khả năng của nhóm họ có thể trao đổi với PO để loại bỏ bới các hạng mục.

Daily Scrum

Khi một sprint bắt đầu thì cũng có một sự kiện bắt đầu theo đó là daily scrum. Đây là sự kiện quan trọng diễn ra hàng ngày trong suốt quá trình phát triển. Thời lượng tối đa là 15p cho mỗi buổi nhằm mục đích trao đổi tiến độ công việc giữa các thành viên trong nhóm, lên kết hoạch cho công việc trong ngày hôm nay. Nó còn có một tên gọi khác quen thuộc hơn đó là daily meeting. Trong buổi này mỗi thành viên sẽ trả lời 3 câu hỏi:

• Tôi đã làm được gì vào hôm qua?
• Tôi sẽ làm gì trong hôm nay?
• Tôi đang gặp những khó khăn gì?

Để đảm bảo không “cháy” time box mỗi thành viên nên chỉ trả lời 3 câu hỏi trên và không lan man thảo luận sâu khi phát hiện ra vấn đề nào đó. Và Daily meeting khuyến nghị người tham gia đứng thay vì ngồi để tăng sự tập trung.

Sơ kết Sprint (Sprint Review)

Buổi sơ kết sprint sẽ được tiến hành khi thời gian triển khai sprint đã hết. Đây là hoạt động thanh tra và thích nghi đối với sản phẩm đang được xây dựng. Kết thúc buổi này, lộ trình sản phẩm và Product Backlog có thể được điều chỉnh để phù hợp với tình hình phát triển. Tham sự buổi này gôm có nhóm phát triển, PO, SM. Ngoài ra PO có thể mời thêm khách hàng để có thể đưa đánh giá. Tất cả những người tham dự đều hoàn toàn tự do trong việc đặt câu hỏi và đong góp. Khung thời gian cho sự kiện này thường là 1 giờ – 2 giờ. Nội dung trong buổi này là nhóm phát triển và PO trao đổi với nhau để tìm hiểu về tình hình và ghi nhận các khuyến nhị của nhau. Đây là cơ hội để PO lắm được sản phẩm. Còn với nhóm phát triển đây là cơ hội để tìm hiểu và nắm tình hình của PO và thị trường. Nội dung củ tổng kết sprint sẽ gồm:

• PO trình bày mục tiêu Sprint.
• Nhóm phát triển trình bày kết quả đã hoàn thành.
• Trực tiếp sử dụng sản phẩm và đưa đóng góp.

Ở trong buổi này, chúng ta chú ý không trình bày những tính năng chưa hoàn thành. Những phản hổi nhận được có thể được đánh giá lại độ ưu tiên cho các backlog. Tổng kết không hoàn toàn chỉ là demo sản phẩm, mà demo sản phẩm chỉ là một nội dung trong buổi này. Nếu tập chung cho việc demo sẽ bỏ qua đi những nội dung quan trọng khác đế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 tiêu thực sự của buổi tổng kết.

Cải tiến Sprint (Sprint Retrospective)

Và sau khi tiến hành tổng kết xong, chúng ta sẽ có buổi cải tiến sprint. Mục đích của sự kiện này là tìm cách để sprint sau tốt hơn. Nhóm phát triển và SM bắt buộc phải tham gia buổi này. PO có thể vắng mặt. Thời gian đối đa cho buổi này là 2 tiếng. Ở buổi này, cần có một người đứng ra làm vai trò hỗ trợ và đó là SM. Hoạt động chính là:

• Đánh giá lại về con người, các mối quan hệ, quy trình, công cụ trong team
• Liệt kê những điểm làm tốt và chưa tốt.
• 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.

Tổng kết

Ở bài viết này, chúng ta đã cùng đi tìm hiểu về các sự kiện trong Scum cũng như có thể áp dụng cho những dự án nhỏ hiện tại. Ở mức beginner thì mình nghĩ 4 bài viết của mình đã là đủ. Tuy rằng nội dung có hơi khô khan, nhưng đưa cho mọi người các nhìn theo mình là chuẩn về Scrum. Và mình sẽ dừng chuỗi bài viết đó tại đây, để chuyển sang những chủ đề khác vào lần sau. Cảm ơn mọi người đã đón nhận 4 bài viết vừa qua.

Nguồn:
https://viblo.asia/p/scrum-cho-nguoi-moi-bat-dau-phan-cuoi-cac-su-kien-trong-scrum-bJzKm0rB59N
https://viblo.asia/p/scrum-framework-scrum-event-aWj53VQGl6m