프로젝트에 배정 된 인원 수와 결함 수 사이에는 실제로 관계가 있습니까?

12

다음은 SLIM 및 소프트웨어 추정과 관련하여 직장에서 교육 매뉴얼을 인용 한 것입니다.

노력과 결함 사이에는 상관 관계가 있습니다. 즉, 지정된 규모의 프로젝트에 더 많은 사람이 할당 될수록 더 많은 결함이 발생합니다.

노력은 프로젝트의 사람-시간 (사람-년, 사람-월)입니다. 결함은 수명주기의 어느 시점에서나 감지 된 결함의 수입니다. 크기는 프로젝트를 구성하는 사용 사례, 기능 포인트 또는 SLOC로 정의됩니다.

좋은 프로세스와 유능한 엔지니어를 가정하면 이는 직관적이지 않은 것처럼 보입니다. 예를 들어 사람이 많을수록 모든 아티팩트 (요구 사항 스펙, 디자인, 코드, 테스트)에 대해 더 많은 시선이 필요합니다. 더 많은 눈을 갖는 것 외에도, 직관은 적절한 품질 기술을 사용하는 프로젝트에서 노력과 결함 사이에는 관계가 거의 없음을 시사합니다.

SLIM에서 사용하는 Putnam Model 관련 문서 외에 결함과 노력 또는 결함 사이의 알려진 관계와 프로젝트의 인원 수를 나타내는 문서를 찾을 수 없었습니다. 이것은 알려진 관계이며 "더 많은 사람 = 더 많은 결함"이 유효하다는 주장입니까?

— 토마스 오웬스
소스

10

"늦은 소프트웨어 프로젝트에 인력을 추가하면 나중에 만들 수 있습니다"

— -Fred

2

@Oded 늦게 사람들을 추가하는 것은 전혀 언급되지 않았습니다. 또한 Brooks의 법은 결함에 대해서는 아무 것도 말하지 않고 의사 결정을 내리고 사람들에게 정보를 제공하기위한 의사 소통 채널을 늘립니다. 칼 빌레펠트 (Karl Bielefeldt)가 제안한 것처럼 의사 소통의 어려움으로 인해 결함이 발생할 수 있다고 생각합니다.

— 토마스 오웬스

@ThomasOwens-그렇습니다. 실제로 통신 채널의 증가 (따라서 어려움)에 대한 인용은 이것이 결함을 초래할 것이라는 가정하에 이루어집니다.

— Oded

나는 여전히 많은 개발자들이 프로젝트에 던져 질 때 종종 죽음의 행진을 나타내는 것이라고 말합니다.

— Morgan Herlocker

@ironcode 프로젝트의 개발자 수는 프로젝트의 규모와 범위, 구성 방법에 따라 결정되어야합니다. 너무 많은 개발자가 있거나 나중에 너무 많은 개발자를 추가하는 것은 경영진의 징후, 아마도 죽음의 행진 일 것입니다.

— Thomas Owens

14

내 직감은 다음과 같습니다.

주어진 규모의 프로젝트에 더 많은 사람들이 배정 될수록 의사 소통 오버 헤드가 커질
수록 오해의 가능성이 높아지고 모든 종류의 의사 소통 문제가 발생할
수 있습니다.

과

좋은 개발자는 평범한 / 나쁜 것보다 찾기가 어렵고 찾기가 어렵습니다.
=> 주어진 크기의 프로젝트에 더 많은 사람들이 할당 될수록 평균 역량 수준이 낮을
수록 => 결과적인 결함의 수가 높아집니다.

그러나 이것들은 단지 내 추리 일 수 있습니다. 근거가 없습니다.

참고로, 아래 강조된 가정은 우리 직업의 상태를 고려하여 IMHO (슬프게도) 상당히 강력합니다.

이것은 좋은 프로세스와 유능한 엔지니어를 가정 할 때 직관적이지 않은 것처럼 보입니다 . [...] 내 직감 은 적절한 품질 기법을 사용 하는 프로젝트에서 노력과 결함 사이에는 관계가 거의 없음을 시사합니다 .

— 페테르 토 ö
소스

나는 McConnell의 Thrashing / Process / Productivity 그래프가 그 문제를 해결했다고 생각했습니다. 새로운 사람들을 소개하지 않으면 프로젝트와 관련된 커뮤니케이션 오버 헤드에 익숙해지고 적절한 커뮤니케이션을 유지하는 것이 더 쉽고 자연스러워집니다. 이는 늦게 프로젝트에 사람들을 추가 할 때 Brooks 'Law에 따라 분류되는데, 이는 프로세스를 프로젝트에 늦게 도입하는 것과 동일합니다. 통신 채널의 증가는 스 래싱의 증가와 결함으로 이어지는 통신의 붕괴를 의미합니다. 그래도 나는 그것을 기반으로하지 않을 수 있습니다. 당신의 추론이 유효 할 수 있습니다.

— 토마스 오웬스

그러나 사람이 적 으면 자신의 강점을 고수 할 가능성이 줄어 듭니다. 모든 것을 할 수있는 단 한 명의 전문가 대신 한 분야에 집중할 수 있다면 실제로 더 나은 소수의 훌륭한 개발자를 고용하는 것이 더 쉬운가?

— JeffO

@ Jeff O, 당신은 요점이 있습니다. OTOH 각 개발자가 자신의 강력한 영역에만 초점을 맞추면 개발자 간의 의사 소통이 더욱 어려워 질 수 있습니다.

— Péter Török

1

의사 소통이 더 번거 롭거나 필요한가요?

— JeffO

@Jeff O, IMO는 서로의 영역에 대한 이해가 적을수록 의사 소통이 더 필요하며 오해 및 잘못된 가정의 가능성이 높아집니다.

— Péter Török

5

그것은 단지 상관 일 수 있습니다. 경영진은 더 복잡 할 것으로 생각되는 프로젝트 또는 많은 비 일시적 버그로 인해 뒤쳐지는 프로젝트 또는 다양한 구성 요소 사이에 많은 연결이 필요한 프로젝트를 돕기 위해 더 많은 사람들을 할당하는 경향이 있습니다. 믹스에서 경영진 결정을 내릴 수 있다면, 역전이 아니라면 상관 관계가 적어도 감소 할 것으로 생각됩니다.

— 칼 빌레펠트
소스

이것에 대한 유일한 문제는 시간이 지남에 따라 직원의 변화 (특히 증가)가 언급되지 않는다는 것입니다. 그것은 단지 n 명의 사람들과 함께 프로젝트를한다면 m 개의 결함이있을 것이라고 말합니다. 사람들을 추가하면 의사 소통 오버 헤드와 문제가 발생하지만 (내가 알 수있는 것)은 사람들 결함 간의 단순한 관계 범위를 벗어납니다. 나는 사람들을 늦게 추가하는 부작용은 의사 소통 채널이 증가하고 사람들을 훈련시키고 속도를 낼 필요성 (브룩스의 법칙)뿐만 아니라 결함의 잠재적 인 증가라는 데 동의합니다. 그러나 그것은 범위를 벗어났습니다.

— 토마스 오웬스

사람들을 늦게 추가하는 것은 내가 언급 한 한 가지 요소 일뿐입니다. 관리는 여전히 더 많은 사람들을 할당하는 경향이 눈 앞에 그들이 더 위험하거나 복잡한 것으로 예상 프로젝트를.

— Karl Bielefeldt

SLIM (및 올바르게 사용될 경우 다른 추정 도구)의 요점은 필요한 인원 수, 프로젝트 비용, 소요 시간 등을 추정하는 데 도움이됩니다. 그러나 도구를 이해하고 올바르게 사용해야합니다.

— 토마스 오웬스

3

최근에 업데이트 된 크기와 노력의 정의를 감안할 때, 아마도 노력 (총 인력)이 소스가 사용하고있는 측정치보다 실제 프로젝트 크기를 더 잘 추정 할 수 있기 때문일 수 있습니다. 모든 팀과 팀의 리소스가 동일한 경우 완벽한 척도).

따라서 실제로 일어나고있는 일은 더 큰 프로젝트가 더 많은 결함을 가지고 있다는 것입니다.

— psr
소스

2

좋은 프로세스와 유능한 엔지니어를 가정하면 이는 직관적이지 않은 것처럼 보입니다.

나는 당신이 현실 세계에서 이들 중 하나를 가정 할 수 있다고 생각하지 않습니다. 프로젝트에 더 많은 사람들이있을수록, 유지할 수없고 최고의 개발자를 늦출 수있는 나쁜 사과를 가질 가능성이 높습니다. 가정을하더라도 프로젝트 수를 늦추고 사람들의 수를 늘리면 더 많은 결함을 유발하는 몇 가지 사항이 있습니다.

통신 오버 헤드
코드 읽기 오버 헤드 (이것은 최고의 개발자조차도 자신의 코드보다 다른 사람들의 코드를 읽고 소비하는 데 더 많은 시간이 걸린다는 것을 의미합니다)
테스트는 더욱 철저해야합니다 (우리 모두는 100 % 테스트 범위로 촬영하지만 실제로는 거의 발생하지 않습니다. 프로젝트에 더 많은 사람들이 참여할수록 변경 사항을 바라고 있기 때문에 철저한 자동 테스트없이 더 리팩터링 할 수 있습니다. 모든 테스트를 합리적인 방식으로 자동화 할 수있는 것은 아니며 시간이 더 오래 걸립니다.)

내 경험상 프로젝트가 매우 모듈화되어 있고 계층 당 1 ~ 2 명만 있으면 개발자와 함께로드 된 프로젝트의 부정적인 영향이 줄어 듭니다. 어떤 버전 제어 시스템을 사용하고 있는지 상관하지 않습니다 .4 명의 개발자가 동일한 파일에 한 번에 자동 병합 체크인을하는 것은 나쁜 생각 일 것입니다.

— 모건 허 로커
소스

동일한 파일에서 4 명의 개발자가 작업하지 못하게하는 유일한 방법은 팀 크기를 3으로 제한하는 것보다 큰 문제가 있습니다.

— JeffO

2

상관 관계와 인과 관계에는 차이가 있습니다. 이 말은 더 많은 수의 엔지니어가 할당 된 프로젝트의 경우 총 결함 수는 더 높은 경향이 있다고 말합니다. 이것은 나에게 완벽하게 이해됩니다. MS Windows에는 내가 만든 응용 프로그램보다 많은 결함이 있다고 확신하지만 이것이 내 응용 프로그램의 품질이 우수하다는 것을 의미하지는 않습니다.

보다 추상적 인 또 다른 예를 들자면, 만약 우리가 국가 당 총 사망자 수를 가져 와서 그 국가의 총 의사 수와 상관 관계가 있다면, "많은 의사를 가진 국가가 더 많은 사망자를 가졌다"고 말할 수있을 것입니다. 의사가 사망을 초래했기 때문이 아니라 많은 수의 의사가 많은 인구를 나타냅니다.

— 다니엘 B
소스

Windows의 예를 들어, Windows는 단순히 더 큰 결함으로 인해 더 많은 결함이 발생할 가능성이 있다고 확신합니다. 한 개발자가 10 SLOC 시스템과 10000 SLOC 시스템을 작성한 경우 10000 SLOC 시스템은 결함을 가질 가능성이 더 높습니다 (컴파일을 방지하는 오타, 세미콜론 누락, 논리 오류 등). . 일반적으로 규모가 큰 프로젝트에는 엔지니어가 더 많지만 사람과 결함의 수는 아니지만 크기와 결함 사이의 관계입니다.

— Thomas Owens

@ThomasOwens-그래, 그건 내 요점이었다.

— Daniel B

왜 프로젝트의 규모와 복잡성과 관련하여 오류가 비교되지 않습니까?

— JeffO

@JeffO-상대적인 방법으로 측정하는 것은 결코 쉽지 않습니다 (얼마나 정확하게합니까?). 아마도 원래의 진술은 문맥에서 벗어난 것일 수도 있지만 저자는 복잡한 계산 결과를 단순히 "결함"이라고 언급하는 경우가 거의 없습니다. 이 경우 "품질"(일부 계산이 수행됨을 의미 함)과 같은 다른 단어 나 "지정된 엔지니어 당 결함"과 같은 더 긴 어구가 필요합니다. 아마도 나는 여기 작가들에게 약간 냉소적이다. :)

— Daniel B

@Jeff 그들은 것입니다. 그러나 결함 수를 사람들의 수가 아니라 크기와 복잡성과 비교할 수 있습니다. 크기와 복잡성이 증가함에 따라 결함이 증가 하고 인원이 증가합니다. 그렇습니다. 사람의 수가 증가하더라도 사람들의 증가는 결함의 수를 증가시키지 않습니다.

— Thomas Owens

1

잠시 동안 사람들의 수에 대한 주장을 제쳐 보자.

노력의 함수로 주입 된 결함 수를 살펴보면 결함 수와 소프트웨어 크기 사이에 강한 상관 관계가 있기 때문에 노력이 증가하면 크기를 늘려야한다는 가정하에 의미가있을 수 있습니다.

따라서 프로젝트에 더 많은 노력을 기울일수록 더 많은 코드 줄을 작성한다고 가정하면 결함 수를 예측하기 위해 크기에 대한 프록시로 노력을 사용할 수 있습니다. Watts Humphrey, Capers Jones 등이 작업에서 크기 (예 : LOC)와 결함 수의 상관 관계가 계속해서 나타났습니다.

더 많은 사람들이 아닌 다른 사람들의 수가 얼마나 많은 노력을 필요로하는지 알 수 없습니다.

참고로, 인과 관계를 혼동하지 마십시오. 크기와 주입 된 결함 수 사이에는 상관 관계가 있지만 크기는 원인이 아닙니다. 원인은 일반적으로 사람과 프로세스 문제에서 지적했듯이 발생합니다. 즉, 크기의 함수로서의 결함은 문제가 있는지 이해하고 변화의 효과를 측정하기위한 훌륭한 척도입니다.

— 남자 이름
소스

0

나는 이것이 UI, UX, DBA 등과 같은 전문가가있는 상황이 아니라 핵심 프로그래밍 팀의 멤버로 제한된다고 가정합니다.

잘 관리해야한다고 생각하지만 쉽지는 않습니다. 양질의 개발자들로 구성된 소규모 팀은 스스로 관리 할 수 있습니다. 재능이 적은 사람을 만든 큰 코드 섹션을 피하는 것이 좋습니다.

팀원이 많을수록 업무를 더 쉽게 나눌 수 있습니다. 어려운 지역에 더 좋고 경험이 많은 개발자를 배치하십시오. 평범하거나 프로그래밍이 아닌 작업 중 일부를 더 나은 개발자로부터 멀리하고 주니어 개발자가 중재를 처리하게하십시오. 더 많은 계획과 생각이 필요하지만 재능을 활용할 수있는 기회를 제공합니다.

이미 잘 알고있는 평균 이하의 개발자보다 새로운 기술을 익힐 필요가있는 훌륭한 개발자를 보유하는 것이 낫다는 생각이 있습니다. 시간이 있으면 좋습니다. 더 많은 개발자들이 프로젝트에 배정 된 이유는 필요한 작업량과 시간이 부족하기 때문일 것입니다. 특정 분야에 집중하고 더 숙련 된 사람이있을 수 있습니다. 다재다능한 지식을 갖는 것이 좋지만 때로는 약간의 지시만으로도 적은 개발자가 약간의 지시를 받아 실행할 수 있습니다.

실제로 성공적인 프로젝트에서 대규모 팀을 관리 한 사람은 많지 않습니다. 그들이 모두 재능이 있더라도 큰 팀이 자기 관리하기가 어렵습니다. 자아가 방해가 되나요?

— 제프
소스