9 Tips để tạo một Sprint Backlog tốt
Bài đăng này đã không được cập nhật trong 3 năm
The sprint backlog là một danh sách đơn giản bao gồm các task, các task này phải được thực hiện bởi team để bàn giao các chức năng trong phần tăng trưởng vào cuối sprint đó. Sprint backlogđược thực hiện trong phần thứ hai buổi họp Sprint planning với sự tham gia của tất cả các thành viên trong nhóm. Quá trình thực hiện sprint planning này cần được thực sự lưu ý bởi nó sẽ giúp team hiểu rõ hơn về các công việc cần được hoàn thành và lên một kế hoạch tốt hơn cho sprint. Mặc dù vậy, nhiều team vẫn gặp rất nhiều khó khăn và đang phải vật lộn với việc này. Dưới đây là một vài gợi ý để tạo ra một Sprint backlog tốt.
1. Tất cả các thành viên trong team đều cần tham gia vào quá trình tạo sprint backlog
Sự tham gia của tất cả các thành viên trong team vào quá trình tạo Sprint backlog là cần thiết. Trong một team đa nhiệm, tất cả mọi người có thể đóng góp vào việc tạo ra task, cho phép team phân tích Story trên nhiều quan điểm khác nhau. Điều này tạo ra Sprint Backlog phong phú hơn nếu là nếu chỉ có coder hoặc một technical member tham gia.
2. Thảo luận về cách thức thực hiện từng item.
Trước khi bất kỳ task nào được viết ra, cả team dành thời gian thảo luận về các Story được đưa vào Sprint backlog là rất cần thiết. Trên thực tế, phần lớn cuộc họp cần được dành để hiểu team sẽ giải quyết những Story này như thế nào. Cuộc thảo luận này sẽ bao gồm việc tạo ra các thiết kế cơ bản, kiểm tra code hiện có, thảo luận các kiến trúc hệ thống, v.v ... Có hiểu biết chung về Story và các giải pháp có thể sẽ cho phép nhóm tạo danh sách công việc phải làm.
3. Có một định nghĩa về việc hoàn thành (DoD- Defination of Done).
Có một định nghĩa chung về DoD được team thống nhất tại chỗ, các yêu cầu về sự hoàn thành này cần đươc định nghĩa và hiển thị cho mọi người cùng biết. Định nghĩa này như là một hướng dẫn cho những gì nên được thực hiện và sẽ nhắc nhở nhóm rằng tiêu chí chấp nhận chung cho mỗi task trong backlog.
4. Xác định tất cả các loại task.
Quá nhiều team chỉ tập trung vào việc coding. Sự thật là, chỉ coding không thì không đủ để cung cấp phần mềm có thể làm việc thực sự. Sprint backlog cần bao gồm mọi loại task: object modeling, coding, learning new technology, database activities, tests, v.v ... Có một định nghĩa về DoD sẽ giúp nhắc nhở các team về những nhiệm vụ mà họ quên. Bằng cách liệt kê ra tất cả các yêu cầu, mong đợi trong một sản phẩm phần mềm được bàn giao và lần lượt thực hiện những việc đó thì nhóm sẽ có được một sự hiểu biết mới về effort thực sự cần có đối với các sprint tiếp theo.
5. Không estimate task.
Estimate cho task bằng số giờ là phổ biến và cần thiết cho team nếu đó là những sprint đầu, và nếu là lần đầu các thành viên làm việc với nhau. Các thành viên trong team cam kết hoàn thành các task trong sprint trong ý thức, tư tưởng của họ chứ không ép buộc rằng đó là một công việc phải hoàn thành. Nếu chúng ta estimate rằng một task sẽ mất 4 giờ để hoàn thành nhưng thực tế nó mất 12 giờ thì cũng vẫn được, miễn là team đạt được mục tiêu của sprint (sprint goal), nó sẽ tạo ra sự khác biệt nào ? Xác định càng nhiều nhiệm vụ càng tốt và tạo ra một cảm giác tiến bộ liên tục trong quá trình thực hiện Sprint là đủ.
6. Không giao task trước.
Chống lại sự cám dỗ về việc chỉ đạo trong công việc. Nhóm nên quyết định ai sẽ làm gì theo hoàn cảnh. Nếu bạn bắt đầu phân công nhiệm vụ cho thành viên nhóm "phù hợp nhất", nó sẽ ngăn không cho các thành viên còn lại học hỏi những điều mới, ngăn cản sự giao tiếp và giảm sự cộng tác giữa các thành viên trong team. Trao quyền và tin tưởng vào nhóm để tự quản lý.
7. Xem lại Sprint commitment (cam kết trong Sprint).
Sau khi xác định nhiệm vụ, khi team rõ hơn về nỗ lực thực sự cần thiết, cần phải phân tích lại các commitment. Liệu Sprint backlog đã chọn có thực sự phù hợp đặt trong sprint hay không? Nếu không, có một số lựa chọn khác. Bỏ một vài task có mức độ ưu tiên thấp nhất ra hoặc chia nhỏ các task thành từng phần nhỏ. Điều quan trọng cuối cùng là nhóm có thể cam kết một cái gì đó mà họ có một sự hiểu biết tốt về nó.
8. Không sử dụng quá nhiều thời gian.
Tôn trọng timebox. Xác định thời gian cho mỗi cuộc họp và tuân thủ theo. Timebox buộc team phải tập trung và thảo luận kỹ lưỡng các item, khiến cho các task sẽ được phân tích rõ hơn. Nhóm không phải lúc nào cũng có thể xác định được mọi thứ cần làm trong suốt Sprint, nhưng đó không phải là vấn đề. Điều quan trọng hơn là họ có một sự hiểu biết thấu đáo về các Story họ đưa và Sprint.
9. Phát triển Sprint Backlog trong quá trình thực hiện Sprint.
Nhóm sẽ hiểu thêm về những Story khi họ làm việc với chúng. Những ý tưởng mới có thể nảy sinh và những ý tưởng cũ có thể bị bỏ đi. Sprint backlog nên phản ánh được những thay đổi này. Daily Scrum là một khoảng thời gian tuyệt vời nhìn nhận, đánh giá để có sự thay đổi kịp thời và ngay lập tức, thêm mới task hoặc bỏ đi những task không cần thiết.
Nếu nhóm đầu tư thời gian và nỗ lực để xây dựng một Sprint backlog tốt nó sẽ mang đến sự hiểu biết tổng thể tốt hơn rất nhiều về mức độ hoàn thành công việc, một cảm giác tiến bộ mỗi ngày, và cam kết rõ ràng về những gì sẽ được bàn giao. Nó có thể không dễ dàng, nhưng nó sẽ mang lại giá trị thực sự.
All rights reserved
