Có thực sự có một mối quan hệ giữa số người được giao cho một dự án và số lượng khiếm khuyết?

Dưới đây là trích dẫn từ tài liệu hướng dẫn đào tạo tại nơi làm việc liên quan đến SLIM và ước tính phần mềm:

Cũng lưu ý rằng, có một mối tương quan giữa Nỗ lực và Khiếm khuyết. Điều này có nghĩa là, càng có nhiều người được chỉ định cho một dự án có quy mô nhất định, sẽ càng có nhiều Khiếm khuyết.

Nỗ lực là thời gian cá nhân (người-năm, người-tháng) cho dự án. Khiếm khuyết là số lượng khuyết tật được phát hiện tại bất kỳ điểm nào trong vòng đời. Kích thước được định nghĩa là các trường hợp sử dụng, điểm chức năng hoặc SLOC tạo dự án.

Điều này có vẻ phản trực giác, giả sử một quy trình tốt và các kỹ sư có khả năng. Ví dụ: có nhiều người hơn có nghĩa là nhiều mắt hơn trên tất cả các tạo tác (thông số kỹ thuật yêu cầu, thiết kế, mã, kiểm tra). Bên cạnh việc có nhiều con mắt hơn, trực giác của tôi cho thấy rằng có rất ít mối quan hệ giữa nỗ lực và khiếm khuyết trong một dự án sử dụng các kỹ thuật chất lượng phù hợp.

Tôi chưa thể tìm thấy bất kỳ tài liệu nào, ngoài những tài liệu về Mô hình Putnam (được SLIM sử dụng), đề xuất bất kỳ mối quan hệ đã biết nào giữa khuyết điểm và nỗ lực hoặc khiếm khuyết và số lượng người trong một dự án. Đây có phải là một mối quan hệ đã biết và là lời khẳng định rằng "nhiều người hơn = nhiều khiếm khuyết" hợp lệ?

Trực giác của tôi đi như thế này:

Càng nhiều người được chỉ định cho một dự án có quy mô nhất định, chi phí truyền thông càng lớn
=> khả năng hiểu lầm càng cao và tất cả các loại vấn đề giao tiếp
=> số lượng lỗi dẫn đến càng cao.

Và

Các nhà phát triển giỏi hiếm hơn, do đó khó tìm và thuê hơn so với những người tầm thường / xấu
=> càng nhiều người được giao cho một dự án có quy mô nhất định, mức độ năng lực trung bình của họ càng thấp
=> số lượng khiếm khuyết kết quả càng cao.

Nhưng đây có thể chỉ là lý do của tôi, tôi không có bằng chứng hỗ trợ.

Một lưu ý phụ, các giả định của bạn được nhấn mạnh dưới đây là IMHO (đáng buồn thay) khá mạnh mẽ, có tính đến tình trạng nghề nghiệp của chúng tôi:

Điều này có vẻ phản trực giác, giả sử một quy trình tốt và các kỹ sư có khả năng . [...] Trực giác của tôi cho thấy rằng có rất ít mối quan hệ giữa nỗ lực và khiếm khuyết trong một dự án sử dụng các kỹ thuật chất lượng phù hợp .

Nó chỉ có thể là một mối tương quan. Ban quản lý có xu hướng phân công nhiều người hơn để giúp đỡ cho các dự án mà họ cho là sẽ phức tạp hơn hoặc các dự án bị tụt lại do có nhiều lỗi không liên quan hoặc các dự án đòi hỏi nhiều sự kết hợp giữa các thành phần khác nhau. Nếu bạn có thể đưa các quyết định quản lý ra khỏi hỗn hợp, tôi nghi ngờ rằng mối tương quan ít nhất sẽ giảm đi, nếu không thì ngược lại.

Với các định nghĩa được cập nhật gần đây về quy mô và nỗ lực, tôi sẽ đề xuất rằng có lẽ kết quả là do Effort (tổng số giờ làm việc) thực sự là một công cụ ước tính tốt hơn về quy mô dự án thực sự so với các biện pháp mà nguồn đang sử dụng (Effort sẽ là một thước đo hoàn hảo nếu tất cả các đội và tài nguyên của đội tương đương nhau).

Do đó, những gì đang thực sự xảy ra là các dự án lớn hơn có nhiều khiếm khuyết hơn, điều này không đáng ngạc nhiên chút nào.

Điều này có vẻ phản trực giác, giả sử một quy trình tốt và các kỹ sư có khả năng.

Tôi không nghĩ bạn có thể giả sử một trong hai thứ này trong thế giới thực. Càng nhiều người trong một dự án, bạn càng có nhiều khả năng có những quả táo xấu không thể theo kịp và sẽ làm chậm các nhà phát triển tốt nhất. Ngay cả khi bạn đi với các giả định, có một vài điều khác làm chậm các dự án và gây ra nhiều khiếm khuyết hơn khi bạn tăng số lượng người:

• chi phí liên lạc
• đọc mã trên đầu (điều này có nghĩa là ngay cả những nhà phát triển giỏi nhất cũng mất nhiều thời gian hơn để đọc và sử dụng mã của người khác so với mã của họ)
• kiểm tra phải kỹ lưỡng hơn (Tất cả chúng ta đều đạt được phạm vi kiểm tra 100%, nhưng điều đó hiếm khi xảy ra trong thế giới thực. Càng nhiều người tham gia vào dự án, việc tái cấu trúc càng khan hiếm mà không cần kiểm tra tự động cực kỳ kỹ lưỡng, vì bạn chỉ hy vọng những thay đổi của mình sẽ không có tác dụng phụ. Không phải tất cả các xét nghiệm thậm chí có thể được tự động hóa theo bất kỳ cách hợp lý nào, điều này thậm chí còn mất nhiều thời gian hơn.)

Theo kinh nghiệm của tôi, các tác động tiêu cực của các dự án được tải lên với các nhà phát triển sẽ giảm xuống khi dự án rất mô-đun và bạn chỉ có 1 hoặc 2 người mỗi tầng. Tôi không quan tâm hệ thống kiểm soát phiên bản nào bạn đang sử dụng, có 4 nhà phát triển tất cả các đăng ký hợp nhất tự động vào cùng một tệp có thể sẽ là một ý tưởng tồi.

Có một sự khác biệt giữa tương quan và quan hệ nhân quả; trích dẫn dường như nói rằng tổng số lỗi có xu hướng cao hơn đối với các dự án có số lượng kỹ sư lớn hơn được phân bổ. Điều này có ý nghĩa hoàn hảo với tôi, tôi chắc chắn rằng MS Windows có nhiều khiếm khuyết hơn các ứng dụng mà tôi tạo ra, nhưng điều đó không có nghĩa là các ứng dụng của tôi có chất lượng vượt trội.

Để đưa ra một ví dụ khác, trừu tượng hơn - nếu chúng ta lấy tổng số ca tử vong trên mỗi quốc gia và tương quan với tổng số bác sĩ trong cả nước, tôi chắc chắn rằng chúng ta có thể nói "các quốc gia có nhiều bác sĩ tử vong nhiều hơn". Điều này sẽ không phải là do các bác sĩ gây ra cái chết, mà là số lượng lớn các bác sĩ là biểu hiện của một dân số lớn.

Hãy tạm gác lại sự khẳng định về số lượng người trong một lúc.

Nhìn vào số lượng lỗi được đưa vào như một chức năng của nỗ lực có thể có ý nghĩa miễn là bạn cho rằng nỗ lực tăng lên nhất thiết đòi hỏi phải tăng kích thước, vì có mối tương quan chặt chẽ giữa số lượng lỗi và kích thước phần mềm.

Vì vậy, nếu bạn cho rằng càng nỗ lực nhiều hơn vào một dự án, thì càng có nhiều dòng mã được viết, thì có lẽ bạn có thể sử dụng nỗ lực như một proxy cho kích thước để dự đoán số lượng lỗi. Mối tương quan giữa kích thước (ví dụ LỘC) và số lượng khuyết tật đã được hiển thị hết lần này đến lần khác trong công việc của Watts Humphrey, Capers Jones và những người khác.

Tôi không thấy số lượng người phù hợp như thế nào, ngoài nhiều người ngụ ý nhiều nỗ lực hơn.

Là một lưu ý phụ, đừng nhầm lẫn mối tương quan với quan hệ nhân quả. Mặc dù có mối tương quan giữa kích thước và số lượng khuyết tật được tiêm, kích thước không phải là nguyên nhân. Nguyên nhân thường đến từ, như bạn đã chỉ ra, vấn đề con người và quá trình. Điều đó nói rằng, khiếm khuyết như một chức năng của kích thước là một thước đo tuyệt vời để hiểu nếu có vấn đề và để đánh giá hiệu quả của sự thay đổi.

Tôi cho rằng điều này chỉ giới hạn ở các thành viên của nhóm lập trình cốt lõi và không phải là tình huống có các chuyên gia như: UI, UX, DBA, v.v.

Tôi nghĩ rằng nó cần phải được quản lý tốt, nhưng điều đó không dễ dàng. Các nhóm nhỏ được tạo thành từ các nhà phát triển chất lượng có thể tự quản lý. Có nhiều khả năng tránh các phần lớn mã đã tạo ra một người có ít tài năng hơn.

Có nhiều thành viên trong nhóm có thể giúp phân chia nhiệm vụ dễ dàng hơn. Đặt các nhà phát triển tốt hơn hoặc có kinh nghiệm hơn vào các khu vực khó khăn. Loại bỏ một số nhiệm vụ trần tục hoặc không lập trình khỏi các nhà phát triển tốt hơn của bạn và để các nhà phát triển cơ sở xử lý các cuộc can thiệp. Điều này sẽ mất nhiều kế hoạch và suy nghĩ, nhưng cung cấp một cơ hội để tận dụng tài năng của bạn.

Có một quan niệm rằng tốt hơn là có một nhà phát triển tuyệt vời, người cần tiếp thu một kỹ năng mới hơn là một nhà phát triển dưới mức trung bình đã biết về nó. Điều này là tuyệt vời nếu bạn có thời gian. Có lẽ lý do nhiều người phát ngôn hơn được giao cho một dự án là vì số lượng công việc cần thiết và giới hạn thời gian. Bạn có thể có một người có thể tập trung vào một lĩnh vực cụ thể và trở nên lành nghề hơn. Thật tuyệt khi có kiến ​​thức toàn diện đó, nhưng đôi khi với một chút định hướng, một nhà phát triển nhỏ hơn có thể thực hiện một số hướng dẫn và chạy theo nó.

Thực tế là, không có nhiều người đã từng quản lý một nhóm lớn trong một dự án thành công. Ngay cả khi tất cả họ đều tài năng, thật khó để các đội lớn tự quản lý. Làm bản ngã có cản đường không?