Số lượng công việc thường xuyên trong phát triển phần mềm và ảnh hưởng của nó đến ước tính

Tôi tin chắc rằng khối lượng công việc thường xuyên trong phát triển phần mềm là - và nên - tương đối nhỏ, nếu không nói là không đáng kể và đây là vấn đề cơ bản của ước tính phần mềm.

Hãy để tôi mô tả làm thế nào tôi đi đến kết luận này và cho tôi biết nếu tranh luận có bất kỳ sai sót nghiêm trọng nào:

1. Tất cả những gì có thể được ước tính với độ chính xác cao là công việc thường xuyên, có nghĩa là những việc đã được thực hiện trước đó. Tất cả các loại công việc khác liên quan đến nghiên cứu và sáng tạo thực sự không thể được ước tính, ít nhất là không chính xác, giả sử, +/- 20 phần trăm.

2. Phát triển phần mềm là tất cả về việc tránh các nhiệm vụ lặp đi lặp lại. Một trong những nguyên tắc cơ bản của nó là DRY (đừng lặp lại chính mình). Bất cứ khi nào một lập trình viên thấy mình làm những việc lặp đi lặp lại, đó là lúc tìm thấy một sự trừu tượng để tránh sự lặp lại này. Những tóm tắt này có thể là những điều đơn giản như trích xuất mã lặp lại vào một hàm hoặc đặt nó vào một vòng lặp. Chúng cũng có thể phức tạp hơn như tạo một ngôn ngữ cụ thể cho miền. Trong mọi trường hợp, thực hiện chúng sẽ liên quan đến nghiên cứu (đã có ai làm điều này trước đây chưa?) Hoặc sáng tạo.

Từ hai điểm này tôi rút ra kết luận trên.

Trên thực tế tôi đã tự hỏi khá lâu tại sao mối quan hệ này không được đề cập trong mọi cuộc thảo luận, bài đăng trên blog hoặc bài viết về ước tính phần mềm. Có quá lý thuyết không? Là giả định của tôi sai? Hoặc nó quá tầm thường - nhưng sau đó, tại sao hầu hết các nhà phát triển mà tôi biết tin rằng họ có thể thực hiện ước tính với độ chính xác +/- 20% hoặc tốt hơn?

Trên bất kỳ dự án nào, điều này có thể đúng. Tuy nhiên, nếu bạn làm việc trên nhiều dự án tương tự cho các công ty khác nhau trong nhiều năm, bạn có thể thấy mình 'giải quyết' về cơ bản cùng một vấn đề nhiều lần chỉ với những thay đổi nhỏ.

Ví dụ: tôi đã viết các lớp truy cập dữ liệu rất nhiều lần, bây giờ tôi thích làm điều đó 'dài tay' hơn là sử dụng ORM phổ biến của tháng. Tôi nhanh chóng và dễ dàng hơn để giải quyết 'các vấn đề thường lệ' với các giải pháp đã biết hơn là tìm và giải quyết các vấn đề mới trong các thành phần của bên thứ 3.

Rõ ràng tôi có thể viết ORM của riêng mình để đơn giản hóa mã lặp đi lặp lại mà không cần thêm các quirks chưa biết trong hệ thống của người khác, nhưng mã này sẽ thuộc về công ty mà tôi tình cờ làm việc vào thời điểm đó và các nhà phát triển khác sẽ thấy nó kỳ quặc như bất kỳ ORM của bên thứ 3 nào khác.

Tương tự, theo kinh nghiệm của tôi, hầu hết lập trình là tự động hóa các quy trình kinh doanh và mặc dù mỗi doanh nghiệp thích nghĩ rằng các quy trình của họ là duy nhất đối với họ; Trong thực tế, họ không phải là.

Không phải nói rằng ước tính là dễ dàng! Nó dễ dàng hơn, nhưng tôi thấy rằng những ngày này, vấn đề ước tính là do sự không phù hợp của các yêu cầu hơn là thời gian dành cho mã hóa.

Yêu cầu có xu hướng rơi vào ba loại:

1. Mơ hồ, chi tiết để lại cho nhà phát triển.

"Làm cho tôi một trang web, nó phải được mát mẻ và bán các vật dụng của tôi"

Chúng có xu hướng dễ ước tính nhất, vì khi xảy ra sự cố không mong muốn, bạn có thể chỉ cần thay đổi các yêu cầu thành một chức năng tương đương và tránh sự cố.

2. Vô cùng đặc biệt

"Tạo màu nền tiêu đề # ff1100"

Siêu nhanh để làm và, một lần nữa, dễ ước tính. Nhưng! yêu cầu bắt buộc phải thay đổi. "Hmm không có ý nghĩ thứ hai, hãy thử màu đỏ khác" hoặc "Đợi đã! Tôi chỉ có ý nghĩa trên một trang đó!" vì vậy khoảng thời gian thực của "bao lâu cho đến khi tôi hài lòng với màu tiêu đề" không liên quan gì đến các ước tính mã hóa

3. Mơ hồ, chi tiết giả định

"Làm cho tôi một trang web, (giống như facebook)"

Ở đây vô số các giả định không có căn cứ, "tất nhiên bạn sẽ muốn có một logo khác", "nó phải có cuộn vô hạn", "phải có khả năng mở rộng cho 1 tỷ người dùng!" kiểm soát hiệu quả dự toán. Hoặc nhà phát triển nghĩ về tất cả mọi thứ và đẩy ước tính lên cao hơn mong đợi "1 giờ làm việc của người đàn ông", hoặc họ nghĩ / chỉ giả sử các tính năng cơ bản là bắt buộc và đưa ra ước tính quá thấp. "oh một hoặc hai tuần, tôi giả sử bạn chỉ muốn đưa facebook vào iframe phải không?"

Với kinh nghiệm mã hóa là rất nhanh, nhưng yêu cầu thiết kế là (thường) là phần cứng, và điều này ngày càng bị đẩy lùi trở lại đối với những người không phải là lập trình viên. Với các phương pháp nhanh, tăng tốc độ mã hóa bằng cách chuyển trách nhiệm này sang 'doanh nghiệp' thay vì các nhà phát triển.

tại sao hầu hết các nhà phát triển mà tôi biết tin rằng họ có thể thực hiện ước tính với độ chính xác +/- 20% hoặc tốt hơn?

Bởi vì chúng tôi ước tính sự kiên nhẫn của chúng tôi với vấn đề nhiều hơn so với vấn đề thực tế.

Nếu tôi định làm động một quả bóng nảy, tôi có thể dành một ngày, một tuần, một tháng hoặc một năm cho nó và vẫn chỉ có một hình ảnh động của một quả bóng nảy. Hy vọng rằng nó sẽ trông tốt hơn khi tôi dành nhiều thời gian hơn cho nó nhưng đến một lúc nào đó tôi thật lố bịch.

Bao nhiêu nỗ lực tôi bỏ ra để làm cho quả bóng nảy là một chức năng của thời gian hợp lý để dành cho nó. Nếu cấp độ kỹ năng của tôi không cắt nó, tôi có thể kết thúc với một quả bóng chỉ ngồi đó. Nhưng khi thời hạn đến tôi nên để thời hạn trôi qua hay ít nhất là có được một quả bóng trên màn hình? Thác khăng khăng bóng nảy và vì thế lịch trình trượt. Agile nói chỉ cần lấy bóng ra khỏi đó. Ít nhất chúng ta sẽ tìm hiểu xem mọi người quan tâm đến việc nảy như thế nào. Vì vậy, chất lượng trượt.

Tôi cố gắng chắc chắn rằng những quả bóng của tôi nảy lên nhưng khi thời hạn đến xung quanh thì tốt hơn là tạo ra một quả bóng tĩnh hơn là không có gì cả. Vì vậy, tôi ước tính thời gian dựa trên những gì có vẻ là một khoảng thời gian hợp lý để dành cho một vấn đề trước khi nói về các lựa chọn thay thế. Đôi khi quả bóng sẽ không nảy. Đôi khi điều đó không sao cả. Biến mất trong một tháng là không ổn.