Bốn đội chỉ phát hiện phụ thuộc chéo khi đã trễ: lập kế hoạch chung hai ngày với bảng phụ thuộc và phiếu tự tin
Khi nhiều đội cùng làm một sản phẩm, rủi ro lớn nhất thường không nằm trong đội nào mà nằm ở chỗ nối giữa các đội. Một buổi lập kế hoạch chung định kỳ, với bảng phụ thuộc treo tường và một lượt bỏ phiếu mức tự tin, giúp lộ ra xung đột trước khi chúng thành trễ hạn. Bài viết mô tả cách tổ chức và cách đọc bảng.
Tình huống liên quan
Rút ngắn 4 ngày tốn bao nhiêu: nén tiến độ bằng crashing theo chi phí biên và chi phí gián tiếp
Khi khách hàng muốn bàn giao sớm hơn, câu hỏi đúng không phải là "có làm được không" mà là "mỗi ngày rút ngắn tốn thêm bao nhiêu". Bài viết đi qua một ví dụ số đầy đủ: chọn hoạt động nén theo chi phí biên, theo dõi đường găng đổi chỗ và tìm điểm dừng khi tính cả chi phí gián tiếp và tiền phạt.
Sếp hỏi "bao giờ xong 40 hạng mục còn lại?": dự báo bằng mô phỏng Monte Carlo trên throughput thay vì cộng story point
Thay vì ngồi ước lượng lại từng hạng mục rồi chia cho velocity trung bình, đội có thể dùng chính lịch sử throughput của mình để mô phỏng hàng nghìn tương lai và trả lời sếp bằng một xác suất: 85% khả năng xong trong 10 tuần. Bài viết hướng dẫn cách làm, cách đọc kết quả và những giới hạn cần nói rõ.
Cho lập trình bắt đầu khi thiết kế mới xong một nửa: tính lợi và rủi ro làm lại của fast-tracking
Fast-tracking rút ngắn tiến độ bằng cách cho các hoạt động vốn nối tiếp chạy chồng lên nhau. Không tốn thêm tiền ngay, nhưng phải trả bằng rủi ro làm lại. Bài viết lượng hoá đánh đổi đó bằng giá trị kỳ vọng và gợi ý cách chọn mức chồng lấn hợp lý.
Ngày ra mắt đã chốt trước Tết, phạm vi thì chưa: lập kế hoạch phát hành bằng dải velocity "chắc có – có thể có – không kịp"
Khi ngày phát hành không được dời, câu hỏi đúng không còn là "bao giờ xong" mà là "đến ngày đó sẽ có những gì". Dùng velocity thấp và cao của chính đội để vạch hai đường trên backlog đã sắp thứ tự, PM chia phạm vi thành ba vùng và cập nhật sau mỗi sprint. Bài viết hướng dẫn cách tính và cách trình bày với nhà tài trợ.
