Làm thế nào để xử lý các ước tính cho các lập trình viên tham gia nhóm?


11

Lặp lại đã bắt đầu, lập trình viên mới gia nhập nhóm, nhiệm vụ X đã được ước tính là 30 giờ bởi một nhà phát triển khác.

Thực hành tốt nhất trong tình huống này là gì?

  • nhà phát triển mới chạy với ước tính đã cho (ý tưởng là bất kỳ sự khác biệt nào sẽ được sửa chữa khi vận tốc được tính?)
  • Nhà phát triển mới ước tính lại nhiệm vụ? (nếu vậy, nếu nó cao hơn đáng kể và không còn phù hợp với phép lặp thì sao?)
  • giơ tay lên và quay trở lại thác nước?
  • cái gì khác hoàn toàn?

Câu trả lời:


4

Những gì tôi nói là:

Nhà phát triển mới ước tính lại nhiệm vụ. Nếu nó phải được chuyển ra khỏi vòng lặp thì nó sẽ được chuyển đi.

Bạn không biết liệu nhà phát triển mới sẽ có thể hay không làm điều đó trong thời gian nhà phát triển ban đầu mặc dù sẽ mất. Và với các phương pháp nhanh là nhà phát triển thực hiện công việc đó sẽ cho biết sẽ mất bao lâu.

Hơn nữa, tôi sẽ áp dụng một số nhân (lớn như thế nào tùy thuộc vào nhà phát triển), vì nhà phát triển phải phù hợp với nhóm / dự án / công ty.


15

Tôi sẽ không thêm người này vào nước rút cá nhân này. Thay vào đó, giao cho anh ta một nhiệm vụ khác để làm việc để tăng tốc độ trên cơ sở mã (có lẽ lỗi treo thấp?).

Thêm một người mới vào nhóm có thể sẽ làm chậm tiến độ của bạn vào mục tiêu cụ thể này vì anh ta sẽ phải làm quen với môi trường của bạn và tìm hiểu cách mọi thứ hoạt động ở đó. Kết hợp anh ta vào lần chạy nước rút tiếp theo , với các ước tính phù hợp dựa trên đội mới.


6

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.


Thật không may, tình hình là khá nhiều - ai đó ước tính công việc sau đó chúng tôi đã mất một lượng nhân lực tốt. Bây giờ nhân lực mới có các nhiệm vụ được ước tính bằng nhân lực cũ.

7
Đó là một trường hợp đặc biệt, và trong trường hợp đó tôi sẽ có nhóm mới (không chỉ là người mới) ước tính lại số lượng tồn đọng. Tôi cũng sẽ xem xét hủy bỏ nước rút; nếu một nửa đội của bạn rời giữa nước rút thì đó không còn là cùng một đội, và không nên mong đợi đáp ứng mục tiêu của đội cũ; họ sẽ có vận tốc ổn định mới và cách nhìn khác về mọi thứ.
KeithS
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.