Kế hoạch Bàn giao (Delivery Plan)
1. Mục tiêu (Goals)
Mặc dù Scrum truyền thống không bắt buộc (và thậm chí không khuyến khích) việc lên kế hoạch chi tiết cho nhiều sprint cùng lúc, nhưng phần lớn chúng ta làm việc trong các doanh nghiệp nơi sự phụ thuộc vào các đội ngũ bên ngoài (như Marketing, Kinh doanh, Chăm sóc khách hàng) là rất lớn.
Việc đánh giá sơ bộ xem phạm vi dự án có khả thi trong một khung thời gian và nguồn lực hợp lý hay không là cực kỳ cần thiết. Mục tiêu ở đây là có một kế hoạch thô và ước tính ban đầu làm điểm xuất phát, chứ không phải là áp dụng mô hình "Agilefall" (Agile trá hình thác nước).
Lưu ý: Kế hoạch này chỉ là điểm khởi đầu cho các cuộc đối thoại lập kế hoạch. Chúng ta hoàn toàn kỳ vọng lịch trình thực tế sẽ biến chuyển theo thời gian và bạn sẽ liên tục cập nhật phạm vi cũng như tiến độ khi dự án tiến triển.
Kế hoạch bàn giao (Delivery Plans) đảm bảo các nhóm phát triển luôn bám sát các mục tiêu chiến lược của tổ chức.
2. Lợi ích (Benefits)
- Khi hoàn thành đánh giá ban đầu, bạn có cơ sở thực tế để thương lượng lại về phạm vi, giãn thời gian hoặc yêu cầu bổ sung nhân lực.
- Trong quá trình phát triển sản phẩm, bạn có thể sớm phát hiện và gióng lên hồi chuông cảnh báo rủi ro về mặt phạm vi, hạn chót và nguồn lực.
3. Cách tiếp cận (Approach)
Một cách tiếp cận đơn giản và hiệu quả là sử dụng giấy ghi chú (stickies) và bảng tính:
-
Xếp hạng ưu tiên (Stack rank) toàn bộ các tính năng trong Backlog: - Các tính năng chức năng (Functional Features). - Các yêu cầu phi chức năng (Non-functional Features). - Nghiên cứu người dùng và Thiết kế UI/UX. - Chiến lược kiểm thử (Testing). - Viết tài liệu (Documentation). - Quy trình chuyển giao tri thức & Hỗ trợ kỹ thuật.
-
Ước lượng tính năng theo cỡ áo thun (T-shirt) quy đổi tương đối ra số tuần làm việc của một người (working weeks per person). Trong trường hợp bạn chưa hề biết công việc phức tạp ra sao, hãy đề xuất một đợt nghiên cứu ngắn (Spike) có giới hạn thời gian (timeboxed) để nhanh chóng tìm câu trả lời.
-
Tính toán dung lượng khả dụng (Capacity) của toàn đội: Dựa trên số tuần làm việc của từng nhân sự, trừ đi các ngày nghỉ lễ, nghỉ phép, hội thảo, đào tạo, thời gian làm quen ban đầu (onboarding), cũng như thời gian phải trực hỗ trợ kỹ thuật và sửa lỗi nóng.
Dựa trên dung lượng khả dụng tính toán được, bạn có các lựa chọn: - Yêu cầu bổ sung nhân sự: Lưu ý: Đưa người mới vào đội luôn cần thời gian hòa nhập (onboarding) và có thể làm chậm tiến độ ngắn hạn (Định luật Brooks). - Cắt giảm phạm vi về mức MVP tinh gọn nhất: Lưu ý: Cắt giảm quá đà có thể làm mất đi giá trị cốt lõi với khách hàng. Hãy nghĩ về một chiếc bánh cupcake — nó phải có đủ cả phần cốt bánh lẫn lớp kem phủ ngon lành. - Xin lùi thêm thời hạn (Ask for more time): Đây thường là yếu tố linh hoạt nhất, trừ khi dự án gắn liền với một chiến dịch ra mắt thị trường cố định không thể dời ngày.
4. Công cụ hỗ trợ (Tools)
Bạn có thể tạo các Epic và Feature rồi gắn ước lượng số tuần làm việc vào các công cụ quản lý hiện đại:
- Tính năng Delivery Plans trên Azure DevOps: Giúp hiển thị trực quan lịch trình của các Story hoặc Feature theo từng sprint trên giao diện lịch biểu của nhiều nhóm cùng lúc.
- Các công cụ phổ biến khác: Jira, Trello, Rally, Asana, Basecamp và GitHub Issues/Projects.