Iteration Planning
Iteration planning là quá trình được bắt đầu bằng một buổi họp (workshop) có sự tham gia của Delivery team, Product Owner và có thể mời thêm các chuyên gia hoặc nhân sự liên quan khác. Công tác lập kế hoạch trong workshop này cần làm rất chi tiết và căn bản do Delivery team chủ trì và xây dựng kế hoạch. Đại diện khách hàng nếu được mời tham dự thường có nhiệm vụ trả lời các câu hỏi để giúp Delivery team hiểu rõ và hiểu đúng được các yêu cầu. Chẳng hạn khách hàng có thể phát biểu để chỉ ra phải chăng team đang đưa ra giải pháp có quá nhiều yếu tố kỹ thuật vượt ra ngoài nhu cầu thực sự phải đáp ứng hay không.
Một đầu vào cho buổi workshop là Product backlog vừa mới được sắp xếp lại thứ tự ưu tiên bởi Product Owner. Thông tin đầu vào thứ hai phải có là mục tiêu của Iteration (The iteration goal), mà đã được xác định trong quá trình Release planning từ trước đó.
Trình tự Iteration planning như sau:
Thảo luận về các user story của Product backlog
Buổi workshop bắt đầu bằng việc thảo luận các user story có thứ tự ưu tiên cao trong Product backlog để confirm rằng team đã hiểu đúng yêu cầu, nội dung về user story với khách hàng. Team thảo luận về các yếu tố chẳng hạn các mối phụ thuộc (dependencies) mà khiến cho team không thể đơn giản là gói trọn tất cả các user story ở đầu danh sách trong Product backlog vào Iteration.
Lựa chọn các user story cho Iteration
Chúng ta hãy lựa chọn các user story có thứ tự ưu tiên cao nhất trong Product backlog mà có thể cam kết hoàn thành trọn vẹn trong Iteration. Việc này thường phải có sự cân bằng: chúng ta cần bao gồm trong Iteration một số lượng story points đủ để thỏa mãn mục tiêu của Release trong giới hạn số lượng iteration đã lên kế hoạch cho Release đó. Đồng thời chúng ta cần quyết định một cách thực tế về khối lượng công việc team có thể hoàn thành trong iteration, dựa trên thống kê về velocity của team ở những iteration trước đây. Do đó quá trình ra quyết định ở đây sẽ bao gồm cả việc đàm phán và thảo luận.
Xác định các tiêu chí nghiệm thu và viết acceptance tests
Tiếp theo chúng ta làm việc với khách hàng để xây dựng các tiêu chí nghiệm thu cho các user story được lựa chọn. Làm thế nào để chúng ta biết được user story được phát triển đã “Done”? Bằng cách nào chúng ta có thể test để chắc rằng user story đã đáp ứng yêu cầu khách hàng? Về cơ bản chúng ta sẽ cần phải tìm kiếm xác định càng nhiều càng tốt các tiêu chí nghiệm thu để từ đó chúng ta có thể viết các acceptance tests cho phép kiểm thử nghiệm thu công việc của chúng ta.
Phân rã user story thành các task
Bước tiếp theo chúng ta phân chia user story thành các task – là mức phân rã nhỏ nhất từng mẩu lượng công việc phải làm để hoàn thành user story. Bạn có thể ngạc nhiên đặt câu hỏi “Chúng ta đã phân rã và ước lượng user story trong quá trình Release planning rồi cơ mà?”. Quả thực đúng như vậy. Nhưng ở đây bạn cần nhớ khái niệm “progressive elaboration” của Agile. Trong Release planning chúng ta phân rã các user story đến mức độ phù hợp với mục đích lập kế hoạch cho Release mà thôi. Nghĩa là chỉ phân rã ở mức thô (coarse-grained breakdowns), hay mức sơ bộ. Còn ở Iteration planning mức phân rã là nhỏ nhất – đến từng task – và thực hiện ở thời điểm sát với lúc chúng ta bắt tay vào thực hiện công việc phát triển.
Ước lượng tasks
Sau buổi workshop chúng ta có thể ước lượng số giờ hoặc số ngày công thực sự cần để hoàn thành từng task. Nhớ là trước đây ở Release planning chúng ta ước lượng theo story points chứ không phải là theo giờ. Việc ước lượng task theo số h là bước tùy chọn (optional), nhưng nhờ có bước này cho phép chúng ta có niềm tin rằng kế hoạch Iteration của chúng ta là khả thi. Nhớ rằng tổng số h của các task để hoàn thành một user story không nhất thiết phải đúng bằng số h chúng ta ước lượng cho riêng user story đó. Sau khi đã có được tổng số h chúng ta có thể xem xét cân nhắc lại về số lượng user story thực hiện trong Iteration sắp tới. Thậm chí có thể phải cân nhắc lại tổng số user story của toàn bộ Release, nếu thấy cần thiết. Một số agile team bổ sung một buffer thời gian vào kế hoạch khi tính đến các kỳ vọng thực tế về khả năng user story có kích thước lớn hơn ước lượng trong kế hoạch, hoặc tính đến việc phải xử lý các vấn đề phát sinh.
Theo Mike Griffiths
