Cách ước tính thời gian lập trình

Kỹ thuật ước tính thời gian để tạo phần mềm

Tôi thực sự muốn nói với mọi người rằng tôi ước tính thời gian cần thiết để xây dựng các dự án phần mềm như thế nào.

Trong 10 năm qua, tôi đã được hỏi điều này hàng trăm lần.

  • “Chúng tôi cần triển khai tính năng này. Bạn sẽ mất bao lâu? ”
  • “Hãy cho tôi một cái nhìn tổng quan chi tiết về thời gian của dự án này về mặt thời gian. 1 tháng? 2 tháng?"
  • “Tôi muốn bạn gửi cái này. 50 giờ thời gian lập hóa đơn là đủ? "

Câu trả lời cho những câu hỏi đó là mộtcá cược, trong trường hợp lạc quan nhất. Hoặc mộtbước nhảy vọt của niềm tin, biết rằng nếu tôi đã hứa một con số, đó có thể sẽ là tiền lương của tôi bất kể thời gian thực tế đã mất.

Đôi khi với những khách hàng dài hạn, tôi có thể phân bổ cho những dự án vượt quá dự toán của tôi với những dự án mà tôi đã hoàn thành công việc sớm hơn dự kiến, cho khách hàng biết.

Cuối cùng thì tôi đã kết thúc rằng “Tôi không thể ước tính”.

Vì vậy, câu trả lời cho “Tôi thực sự muốn cho mọi người biết cách tôi ước tính thời gian cần thiết để xây dựng các dự án phần mềm” là:Tôi không.

Nhưng tôi có thể ước tính rằngkhông ai thực sự có thể ước tínhkhi nói đến việc xây dựng phần mềm, vì sự phức tạp bên trong mà lĩnh vực này có thể gây ra đối với bạn.

“Kỹ sư thực thụ” sẽ khó thừa nhận điều này, nhưng tôi chưa bao giờ là kiểu kỹ sư thực thụ điển hình của bạn.

Ước tính có lẽ là điều khó nhất khi làm việc với tư cách là một nhà phát triển.

Đây là một bảng tham chiếu thú vị mà bạn có thể sử dụng khi cần ước tính một nhiệm vụ

Bài tập Bạn ước tính Bạn quên Thời gian thực tế cần thiết
Một bản sửa lỗi nhỏ 2 phút Chúng tôi cần tìm chức năng có lỗi trong mã nguồn, git pull, kiểm tra xem chúng tôi không phá vỡ bất kỳ chức năng nào khác, chúng tôi cần thêm một số kiểm tra, chạy kiểm tra, sửa các kiểm tra chúng tôi đã phá vỡ, triển khai, cập nhật theo dõi lỗi 2 giờ
Một tính năng nhỏ 2 giờ Bạn cần sửa việc CẦN LÀM còn lại trong mã trong hàm bạn sẽ chỉnh sửa và xem tại sao có//don't touch thisbình luận. Bạn cần cẩn thận thực hiện kiểm tra thủ công, cộng với kiểm tra trình duyệt và kiểm tra lý do tại sao trên Edge không hoạt động như mong đợi. Ồ, chúng tôi cần cập nhật tất cả các ảnh chụp màn hình trong tài liệu 10 giờ
Cải thiện hiệu suất của một điểm cuối 10 giờ Bạn cần các điểm chuẩn chính xác mà bạn có thể sử dụng để chứng minh triển khai mới của mình đang hoạt động chính xác và thêm 10 thử nghiệm khác mà trước đây chưa có, nếu không bạn có nguy cơ phá vỡ mã sản xuất được sử dụng bởi 10000 khách hàng 5 ngày
Viết lại toàn bộ mã giao diện người dùng 3 tuần Bạn chỉ bắt đầu với cái mớicó thể mở rộng hơnkhung mà bạn đang thử nghiệm, không chạm vào giao diện người dùng, nhưng bạn gặp phải một loạt vấn đề hoàn toàn mới nhưng lần này không có StackOverflow hoặc Google để trợ giúp, vì khung này quá mới. Bạn đang gặp phải những vấn đề riêng và bạn cần thuê người bảo trì thư viện để làm việc với bạn, nhưng anh ta đã chuyển sang điều tuyệt vời tiếp theo. Trong khi bạn đang ở đó, nhóm giao diện người dùng quyết định làm việc để viết lại giao diện hoàn chỉnh, 2 lần. Những người quản lý sản phẩm ở thời điểm giữa muốn chuyển sang một sản phẩm hơi khác một chút 12 tháng

Đây có thể là một ước tính tốt về việc chúng tôi thiếu ước tính, nhưng tất nhiên mọi thứ cũng có thể hoạt động ngược lại: một thứ bạn ước tính có thể mất 5 ngày có thể chỉ mất 1 ngày vì bạn thấy mọi thứ đã sẵn sàng để thêm nó và nó mất ít hơn nhiều so với dự đoán.

Một số có thể đánh giá quá cao, dự đoán họ có thể gặp khó khăn, thêm 30% những gì họ nghĩ.

Ước tính dự án nhóm thậm chí còn khó hơn, tôi thậm chí sẽ không thử.

Làm gì sau đó?

Thay vì ước tính chi tiết, tôi đề xuất liên lạc liên tục với khách hàng hoặc sếp hoặc bất kỳ ai đã ủy thác công việc của bạn và thực hiện kiểm tra hàng tuần về tiến độ dự án. Mà không cần xác định trước khi nào quá trình kết thúc.

Bởi vì sau tất cả quá trình sẽ không bao giờ kết thúc.


Các hướng dẫn phòng thí nghiệm khác:


Công nghệ Wiki trực tuyến!