Sprint Planning Meeting

Trong phương pháp Scrum, sprint planning meeting có sự tham gia của Product owner, Scrum Master và toàn Scrum team. Những người liên quan bên ngoài có thể được mời tham gia, nhưng cũng ít khi xảy ra.

Trong sprint planning meeting, product owner sẽ mô tả cho cả team các tính năng đã được sắp thứ tự ưu tiên cao nhất. Mọi người trong team sẽ đặt câu hỏi để hiểu rõ vấn đề, khi đó họ sẽ chuyển các user story của product backlog thành các task chi tiết hơn trong sprint backlog.

Người product owner không cần phải mô tả từng item trong product backlog. Một mẹo có ích cho người product owner khi đến sprint planning meeting là chỉ cần chuẩn bị số lượng item trong product backlog gấp đôi số lượng item sẽ được chuyển hóa thành sprint là được. Ví dụ dễ hiểu như sau, cứ cho là team luôn luôn hoàn thành 5 item của product backlog trong mỗi sprint. Người product owner khi bước vào cuộc họp chỉ cần chuẩn bị để nói về 10 item có độ ưu tiên cao nhất trong product backlog.

Có 2 điều là kết quả của mỗi sprint planning meeting:

1. Mục tiêu của sprint
2. Sprint backlog

Mục tiêu của sprint được viết bằng 1 đến 2 câu ngắn gọn, mô tả cái mà team đang cố gắng đạt được trong sprint đó. Nó được viết bởi sự hợp tác của cả team và product owner. Đây là các ví dụ về mục tiêu của sprint trong một phần mềm thương mại điện tử:

• Xây dựng một giỏ hàng với các chức năng căn bản như thêm, bớt sản phẩm hoặc cập nhật số lượng sản phẩm.
• Phát triển quy trình thanh toán: trả tiền, chọn phương thức giao hàng, yêu cầu gói quà,…

Mục tiêu của sprint được dùng để báo cáo nhanh cho những ai không tham gia vào sprint. Luôn luôn có những người muốn biết team đang làm gì, nhưng họ không cần phải biết cụ thể về các item của product backlog (các user story). Một sprint được đánh giá hoàn thành tốt hay không sẽ được xác định trong sprint review meeting dựa vào mục tiêu của sprint được nêu ra ban đầu, hơn là dựa vào các item cụ thể trong product backlog.

Sprint backlog là kết quả của việc lên kế hoạch cho sprint. Một sprint backlog là danh sách của các item trong product backlog mà team đã cam kết hoàn thành cộng với danh sách các công việc cần làm để hoàn tất các item đó. Mỗi công việc (task) trong sprint backlog còn được dùng để ước lượng khối lượng công việc.

Một điểm quan trọng cần nhấn mạnh lại là chính team sẽ là người chọn khối lượng công việc mà họ sẽ hoàn thành trong sprint tiếp theo. Người product owner sẽ không nói: “Chúng ta còn 4 sprint để hoàn thành nên team phải làm 1/4 công việc tôi cần trong sprint kế”. Chúng ta đều hy vọng team sẽ làm nhiều nhất có thể, nhưng điều đó hoàn toàn phụ thuộc vào sự ước lượng của team, họ sẽ xác định xem khối lượng công việc mà họ sẽ làm vào sprint tiếp theo là bao nhiêu.

Daily Scrum Meeting

Trong phương pháp Scrum, vào mỗi ngày trong một sprint, team đều họp, gọi là “daily scrum”. Cuộc họp thường tổ chức vào cùng 1 thời gian và địa điểm. Tốt nhất là cuộc họp nên diễn ra vào buổi sáng để định hình các công việc cần làm trong ngày. Mỗi cuộc họp kéo dài tối đa 15 phút, điều này giúp mọi thứ diễn ra nhanh chóng và gọn gàng.

Phương pháp Scrum cấp phát một đặc quyền cho những ai đã hoàn thành công việc đã cam kết, nhiều team thi hành nguyên tắc chỉ cho phép những ai hoàn tất công việc mới được quyền nói trong cuộc họp daily scrum.

Team và Scrum Master được xác nhận có hoàn tất công việc hay không sẽ dựa vào đánh giá của mọi người xung quanh. Có một vài ý kiến khác nhau về việc product owner có phải là một thành viên của team hay không. Quan điểm của tôi là phải xem product owner là một thành viên không tách rời của dự án (và cũng nên cư xử như một thành viên).

Tất cả các thành viên đều bắt buộc tham dự cuộc họp này. Vì Scrum Master và Product owner đều là các thành viên của dự án, họ cũng phải tham gia. Ngoài ra, những người khác (ví dụ như Phó giám đốc — VP, nhân viên kinh doanh hoặc thành viên của các dự án khác) cũng có thể tham dự, nhưng chỉ nghe. Nó làm cho cuộc họp trở thành một phương pháp hoàn hảo cho việc trao đổi thông tin trong team. Nếu bạn quan tâm đến diễn biến công việc thì nên tham gia cuộc họp.

Cuộc họp daily scrum không được dùng để nêu và giải quyết vấn đề hay là một cuộc họp giải quyết một mâu thuẫn nào đó. Các vấn đề đó nên được nêu lên ngoài cuộc họp và thường sẽ được diễn ra ngay sau cuộc họp daily scrum, với chỉ những người có liên quan. Trong daily scrum, mỗi thành viên phải trả lời 3 câu hỏi sau:

1. Đã làm gì vào hôm qua?
2. Sẽ làm gì hôm nay?
3. Cái gì đang cản trở công việc?

Bằng cách tập trung vào những thứ mà mỗi thành viên đã làm hôm qua và sẽ làm hôm nay, team sẽ biết rõ việc gì đã xong, việc gì còn tồn đọng. Cuộc họp daily scrum không phải là một cuộc họp cập nhật tình hình để sếp xem ai đang làm chậm kế hoạch. Mà đó chính là một cuộc họp bình đẳng giữa các thành viên để đánh giá mức độ hoàn thành lẫn nhau.

Nếu một lập trình viên đứng dậy và nói: “Hôm nay tôi sẽ hoàn thành module lưu dữ liệu”, mọi người đều biết ngày mai trong cuộc họp anh ấy sẽ nói anh ấy đã hoàn thành nó hay chưa. Nó tạo nên một tác dụng tuyệt vời giúp team nhận ra ý nghĩa của những lời hứa, và rằng lời hứa của họ là một dạng khác, không phải xa xôi như của khách hàng hay của nhân viên kinh doanh.

Bất kỳ rào cản nào được nêu lên trong cuộc họp cũng đều trở thành trách nhiệm của Scrum Master để giải quyết nó nhanh nhất có thể. Các dạng rào cản thường là:

• Cái ___ của tôi đã bị hư và tôi cần một cái mới hôm nay.
• Tôi vẫn chưa có được phần mềm mà tôi yêu cầu mua cách đây một tháng.
• Tôi cần sự giúp đỡ để giải quyết khó khăn ở vấn đề _____.
• Tôi đang cố gắng học ____ và muốn có bạn học chung.
• Tôi không thể liên lạc được với đội ngũ hỗ trợ của bên bán hàng.
• Đối tác mới của chúng ta không thể bắt đầu vì không có ai ở đây để ký hợp đồng với cô ta.
• Phó giám đốc yêu cầu tôi làm một việc khác trong một hoặc hai ngày.

Nếu Scrum Master không thể loại bỏ các rào cản này bằng chính anh ta (ví dụ thông thường là các vấn đề về kỹ thuật), anh ấy vẫn phải có trách nhiệm đảm bảo rằng ai đó trong team phải giải quyết vấn đề đó thật nhanh.

Phần lớn team thành thời gian trong daily scrum để cho mỗi thành viên trả lời 3 câu hỏi ở trên. Bạn trả lời ba câu đó, đến người tiếp theo, rồi tiếp theo. Một cách làm khác cũng hay được dùng trong một số team là nói về từng item trong product backlog. Bằng cách đó, một cá nhân có thể nói nhiều lần trong cùng một cuộc họp (từ item này sang item khác nếu item đó có liên quan đến họ).

Theo longnguyen.site

Japan IT Works