Hướng dẫn lập kế hoạch cho Sprint

Khi triển khai dự án áp dụng quy trình Scrum người dùng sẽ phải tham gia rất nhiều sự kiện (cuộc họp) như lập kế hoạch sprint, sơ kết sprint, cải tiến sprint,… Trong bài viết này mình sẽ hướng dẫn mọi người triển khai lập kế hoạch cho sprint.

Thời gian: diễn ra đầu mỗi sprint trong 2h với sprint 1 tuần.

Thành phần tham dự:
– Bắt buộc: nhóm phát triển, ScrumMaster
– Không bắt buộc: Product Owner và trưởng bộ phận

Mục đích: đưa ra mục tiêu của sprint và lên kế hoạch hoàn thành chúng như thế nào.

Nội dung:
Nhóm phát triển sẽ chọn lượng công việc sẽ làm trong sprint dựa vào lượng công việc đã hoàn thành trong các sprint trước đó. Nếu nhóm cảm thấy có thể làm nhiều hơn hoặc ít hơn thì cũng căn cứ vào các sprint trước để quyết định.
Trong trường hợp nếu đây là sprint đầu tiên thì nhóm sẽ vẫn nhận yêu cầu và lên kế hoạch. Sao cho đến khi thời gian hoàn thành công việc đã vượt quá lượng thời gian mà nhóm có trong sprint tới. Việc này có thể điều chỉnh trong sprint tiếp theo.

Các bước thực hiện:

1. Xác định hạng mục phát triển

• Product Owner (PO) đưa ra những User story (US) có độ ưu tiên cao nhất theo đánh giá của PO. Tiếp theo đó PO giải thích chúng cho nhóm phát triển.
• Nhóm phát triển sẽ làm rõ yêu cầu của PO đối với những US, phần này cần hạn chế thời gian để dành thơi gian cho việc lập kế hoạch.
• Nếu mất nhiều thời gian cho phần này thì cần 1 buổi làm mịn Product Backlog.

2. Xác định thời gian nhóm có trong sprint
Một ngày làm việc có 8h nhưng thực chất thời gian tập trung vào công việc mỗi người cao nhất khoảng 6.4h (80%). Vì còn nhiều công việc như họp hành đột xuất, trả lời email, cà phê,…
Mỗi thành viên sẽ đưa ra thời gian mình có thể dành cho công việc phát triển trong sprint tới như sau:

• Thông báo số ngày nghỉ trong sprint tới
• Tính số giờ có trong sprint = số ngày đi làm * 6.4
  Sau khi có thời gian mỗi thành viên thì cộng tất cả lại sẽ được tổng thời gian nhóm có trong sprint tới

3. Phân tách từng yêu cầu thành các công việc đủ nhỏ
Khi phân tách các yêu cầu thành các công việc nhỏ việc này giúp làm rõ yêu cầu được đưa ra từ PO và sản phẩm.
Công việc chia nhỏ làm sao có thể hoàn thành trong 1 ngày làm việc và đó là tất cả công việc cần làm để hoàn thành US.

VD: Với tính năng “Là người dùng tôi cần đăng nhập vào hệ thống để có thể sử dụng tất cả tính năng của sản phẩm”. Thì cần liệt kê những công việc ở cần phải làm để người dùng có thể đăng nhập vào hệ thống.
– FrontEnd: Dựng giao diện “Đăng nhập”
– FrontEnd: Thiết kế các validation cho việc đăng nhập
– FrontEnd: Ghép API “Đăng nhập”
– Back end: Thiết kế CSDL
– Back end: Viết API tính năng Đăng nhập (bao gồm code và self test)
– Back end: Kiểm tra SQL injection.

Trong trường hợp cần thời gian tìm hiểu về tài liệu và kỹ thuật mới thì cũng cần có 1 đầu việc tương ứng.

4. Ước lượng công việc với Planning Poker
Lập kế hoạch cho 1 US (User story) với Planning poker gồm những bước sau

Bước 1: Xác định công việc cần ước lượng (Chi tiết xem phần 3).
Từ những US, nhóm liệt kê tất cả công việc cần làm để hoàn thành được US đó.

Bước 2: Xác định thời gian cần thiết để hoàn thành công việc đã chọn.

Ở mỗi đầu việc, mỗi thành viên xác định thời gian mình có thể hoàn thành đầu việc đó thông qua việc chọn 1 lá bài poker tương ứng. Lá bài đó sẽ úp xuống trước mặt. Việc xác định thời gian này cần dựa trên 1 tính năng cơ bản ( tính năng mà theo nhóm đánh giá là cần ít thời gian nhất để hoàn thành).

Bước 3: Thống nhất thời gian hoàn thành công việc. Tất cả thành viên trong nhóm cùng lật lá bài đã chọn.

• Nếu tất cả thành viên cùng chọn 1 lá bài (cùng số giờ) thì ước lượng thời gian hoàn thành cho công việc đó đã xong.
• Nếu có sự khác biệt thì các thành viên sẽ đưa ra ý kiến của bản thân tại sao lại lựa chọn lá bài đó. Thường chỉ có người đưa ra lá bài giá trị cao nhất và thấp nhất đưa ra ý kiến. Cần giới hạn thời gian cho việc này ( Ví dụ: mỗi người 1 phút). Sau khi đưa ra ý kiến xong thì quay trở lại Bước 2.

Lưu ý: Với mỗi công việc chỉ nên giới hạn ước lượng trong 3 lần. Tới lần thứ 3 mà chưa đạt được sự đồng thuận thì nên lấy theo số đông hoặc chọn cách khác để không tốn quá nhiều thời gian. Mấu chốt ở đây là sự đồng thuận của nhóm trong công việc.

Nhóm tiếp tục việc ước lượng cho đến khi lượng công việc này xấp xỉ với thời gian nhóm có trong kế hoạch cho sprint tới. Kết thúc buổi lập kế hoạch sẽ cho ra Sprint backlog tiếp theo chứa Danh sách những việc cần làm đã có thời gian ước lượng.

Bài viết dựa theo nguồn: https://agilebreakfast.vn/nhom-it-kinh-nghiem-lam-sao-de-lap-ke-hoach-sprint-hieu-qua/

Author: Thái Thị Duyên

Đăng ký nhận bộ tài liệu học Java trên 2 trang giấy tại đây

Xem thêm: Java Coding Bootcamp là gì? Tổng quan về Java Coding Bootcamp