Được bỏ lỡ thời hạn phổ biến trong công việc lập trình? [đóng cửa]

Đó là công việc tự do của tôi tại oDesk. Tôi đã thực hiện một số công việc sớm hơn trong thời gian nhất định, nhưng là lần đầu tiên tôi bỏ lỡ thời hạn. Đó là một công việc rất dài và tôi đã cố gắng hết sức nhưng tôi vẫn bỏ lỡ thời hạn. Bây giờ, tôi rất sợ. Bởi vì đó là lỗi của tôi mà tôi đã bỏ lỡ thời hạn.

Câu hỏi của tôi là: Đây có phải là một mối quan tâm lớn hoặc bị bỏ lỡ thời hạn phổ biến trong các công việc lập trình, vì vậy tôi không nên lo lắng quá nhiều về điều này?

Đúng. Thời hạn bỏ lỡ là phổ biến trong phát triển phần mềm.

Nhiều người làm việc tự do đáp ứng thời hạn bằng cách phát sinh nợ kỹ thuật hoặc giấu bụi bẩn dưới tấm thảm.

Diễn giải Tháng của Người đàn ông huyền thoại của Frederick Brooks :

• Thời hạn thường bị bỏ lỡ vì các nhà lãnh đạo dự án tiếp tục ước tính các nhiệm vụ phần mềm giống như cách họ thực hiện các nhiệm vụ kỹ thuật dân dụng, đó là một cách tiếp cận thiếu sót vì phần mềm là một ngành công nghiệp thủ công mới, không có quy tắc rõ ràng. Điều này đúng đến mức bạn không thể thu hồi "giấy phép" của lập trình viên để mã hóa lỗi, cũng như bạn không thể kiện ai đó để lập trình mà không có tiêu đề.

• Phát triển phần mềm có sự phức tạp vốn có mà các ngành khác thiếu. Một chương trình lớn có thể có nhiều thành phần hơn xe hơi và những thành phần này có thể tương tác theo nhiều cách khác nhau.

• Phần mềm khó hình dung, vì vậy các loại sơ đồ khác nhau được sử dụng để xem các khía cạnh khác nhau của dự án và các khía cạnh này có thể không trực giao. Mặt khác, kỹ thuật dân dụng, có các bản thiết kế cho phép bạn nhìn thấy hệ thống ống nước, hệ thống dây điện, vv tất cả trong cùng một biểu đồ (hoặc các lớp) theo cách trực giao.

• Nó không phổ biến, sau khi một cây cầu hoặc tòa nhà được xây dựng một nửa, để khách hàng thay đổi hoàn toàn phạm vi của dự án. Đây thường là trường hợp trong các dự án phần mềm.

• Tình trạng của nghệ thuật phát triển phần mềm chưa đạt đến mức các dự án phần mềm có thể lặp lại và gần như không có rủi ro. Ngay cả các công ty phần mềm lớn nhất như Microsoft cũng có thể bỏ lỡ thời hạn theo tháng hoặc năm.

• Hầu hết các phần mềm hơi không là gì ngoài các dự án phần mềm đã bị cắt vì những vấn đề này.

Tóm lại là:

Ước tính xấu và đánh giá thấp sự phức tạp, do tính chất thủ công của quy trình phát triển phần mềm, có nghĩa là nó vẫn là một môn học chưa trưởng thành.

Hạn chót bỏ lỡ không nên trở thành thông lệ nếu bạn muốn tiếp tục kiếm việc làm.

Như đã nói, bạn thường muốn để lại cho mình một số phòng "ngọ nguậy" trong các ước tính của bạn trong trường hợp có chuyện xảy ra (và nó luôn luôn như vậy). Bạn không cần phải tiết lộ rằng bạn đã thêm thời gian, chỉ cần đừng làm cho nó không hợp lý. Có thể từ 5 - 10% tổng thời gian? Cách duy nhất bạn sẽ tìm ra là làm điều đó một vài lần.

Để có được ước tính thực sự tốt, bạn phải biết mất bao lâu để mã hóa một loại tiện ích nhất định ... ví dụ: giả sử bạn phải tạo tiện ích cuộn vô hạn cho máy khách X. Nếu bạn mất một tuần để triển khai nó vào sản xuất mà không có lỗi, bạn có thể sử dụng nó làm cơ sở cho các ước tính cuộn vô hạn của mình.

Thiếu thời hạn không phải là hiếm trong phát triển phần mềm. Hầu như không thể ước tính chính xác một dự án phần mềm sẽ mất bao lâu.

Sự chuyên nghiệp được thể hiện trong cách bạn đối phó với nó. Khi bạn biết bạn sẽ bỏ lỡ thời hạn, hãy thông báo cho khách hàng của bạn càng sớm càng tốt về nó để họ có thể lên kế hoạch phù hợp.

Nó khá phổ biến, nhưng bạn có thể cải thiện nó tốt hơn. Bạn có thể muốn xem xét việc ước tính bằng cách sử dụng một cái gì đó trừu tượng như các điểm câu chuyện và theo dõi vận tốc của bạn để tính toán các ước tính thực tế của bạn. Những khái niệm này thường được liên kết với scrum, nhưng có thể được sử dụng ngay cả khi bạn không làm scrum.

Điều đáng kinh ngạc về vận tốc là nó bao gồm tất cả những thứ vô hình như sự gián đoạn và sự phức tạp bất ngờ mà các nhà phát triển gặp khó khăn khi tính toán trong các ước tính của họ. Tất cả các xác suất trung bình ra theo thời gian. Tính trung bình trong hơn 10 tuần, ước tính vận tốc của chúng tôi đã chính xác trong khoảng 5%. Tuy nhiên, khi chúng tôi ước tính các nhiệm vụ tương tự trong vài giờ, cùng một nhóm chính xác luôn đánh giá thấp 30-50%.

Lý thuyết của tôi (chưa được chứng minh) là con người đã tiến hóa để đánh giá thấp các công việc phức tạp bằng hai hoặc ba đến một. Bất cứ khi nào Quốc hội yêu cầu NASA một cái gì đó như: chi phí để xây dựng tàu con thoi hoặc du hành lên mặt trăng họ sẽ quay lại trong vòng một tuần với một con số. Sau khi họ hết tất cả các chi phí dự kiến, họ phát hiện ra nó sẽ tốn gấp ba lần.

Chúng tôi đã có một trò đùa vào những năm 1970: lấy bất kỳ ước tính lập trình viên nào, nhân đôi số lượng, sau đó chuyển nó sang đơn vị thời gian tiếp theo. Do đó, nếu một lập trình viên nói rằng nó có thể được thực hiện trong hai tuần, anh ta sẽ hoàn thành nó trong bốn tháng.

Nếu bất cứ ai đã sửa sang lại một nhà bếp, họ thường nghĩ rằng 'Tôi sẽ hoàn thành việc này trong hai tuần'. Họ hoàn thành nó khoảng sáu tuần sau đó.