Trước hết, tôi nghe "Nhiệm vụ nhanh nhẹn" và tôi nghĩ rằng một đến hai ngày làm việc, không phải một tuần. Nhiệm vụ là những gì bạn chia nhỏ câu chuyện khi câu chuyện khớp với vòng lặp và thật hiếm khi có một câu chuyện không thể chia thành các phần nhỏ hơn.
Thứ hai, về cơ bản, bạn đang yêu cầu nhà phát triển mới này bắt đầu chạy. Nếu anh ta có thể được dự kiến hợp lý để nhảy ngay vào và theo kịp tốc độ của phần còn lại của đội, thì ước tính ban đầu nên giữ. Nếu anh ta không thể, có lẽ anh ta không nên giữ ước tính này, ít nhất là không phải một mình.
Thứ ba, tình hình là gì? Tôi khá chắc chắn rằng tình hình không phải là nhóm ước tính công việc của họ, sau đó ai đó đã bước ra ngoài và bạn thay thế anh ta vào ngày hôm sau. Vì vậy, tôi nghĩ rằng những người X trong nhóm đã ước tính công việc chạy nước rút này và tiếp nhận những gì họ nghĩ họ có thể xử lý, sau đó bạn giới thiệu anh chàng mới và bây giờ có những anh chàng X + 1 thực hiện công việc ban đầu được cam kết bởi các chàng trai X . Trừ khi nhóm không chọn khối lượng công việc của họ, và thay vào đó có sự tồn đọng bị quản lý nhồi nhét, tôi sẽ không cho anh chàng mới làm nhiều việc trong tuần này. Nếu lịch trình được đặt bởi quản lý, đó không phải là Agile.
Cá nhân, tôi sẽ đặt anh chàng này kết hợp với một lập trình viên giàu kinh nghiệm hơn cho lần chạy nước rút đầu tiên của anh ta (nếu các lập trình viên của bạn không ghép đôi mọi lúc, điều mà tôi cho rằng họ không xem xét việc họ đang đưa ra một nhiệm vụ cho một chàng trai). Bằng cách nhìn qua vai và đặt câu hỏi, anh ta sẽ bắt đầu tìm hiểu cơ sở mã hóa, và nếu kỹ năng lập trình chung của anh ta bị nghẹt, anh ta sẽ trở thành một người đánh giá mã hiệu quả gần như ngay lập tức, phát hiện ra lỗi, mã không hiệu quả, v.v.