본문으로 이동
주 메뉴
주 메뉴
사이드바로 이동
숨기기
둘러보기
대문
최근 바뀜
요즘 화제
임의의 문서로
sitesupport
사용자 모임
사랑방
사용자 모임
관리 요청
편집 안내
소개
도움말
정책과 지침
질문방
한울위키
검색
검색
보이기
로그인
개인 도구
로그인
브룩스의 법칙 문서 원본 보기
문서
토론
한국어
읽기
원본 보기
역사 보기
도구
도구
사이드바로 이동
숨기기
동작
읽기
원본 보기
역사 보기
일반
여기를 가리키는 문서
가리키는 글의 최근 바뀜
문서 정보
보이기
사이드바로 이동
숨기기
←
브룩스의 법칙
문서 편집 권한이 없습니다. 다음 이유를 확인해주세요:
요청한 명령은 다음 권한을 가진 사용자에게 제한됩니다:
일반 사용자
.
문서의 원본을 보거나 복사할 수 있습니다.
'''브룩스의 법칙'''(Brooks' law)은 [[프레더릭 브룩스]]가 자신의 [[1975년]] 저서 《[[맨먼스 미신]]》 (The Mythical Man-Month)에서 "지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다"라고 주장한 법칙이다. 브룩스는 "임산부가 아무리 많아도, 아이를 낳는 데에는 9개월이 걸린다"라고 자신의 주장을 비유적으로 표현했다. 이 브룩스의 법칙은 자주 인용되지만, 《맨먼스 미신》에 이 주장 바로 위에 써 있던 "극도로 단순화해서 말하면"이란 구문이 생략되어 본뜻이 왜곡되어 전해지기도 한다. == 오해 == 브룩스 법칙에 대한 가장 흔한 오해는 뛰어난 프로그래머와 일반적인 프로그래머 개인의 능력이 차이가 많이 나기 때문에, 고액의 임금을 받는 매우 뛰어난 소수의 프로그래머를 이용하는 것이 평범한 능력을 가진 다수의 프로그래머를 고용하는 것보다 생산성이 높다는 것이다. 그러나 브룩스 법칙이 적정선 이하의 극소수의 프로그래머만을 프로젝트에 투입하더라도 개발을 빨리 끝낼 수 있다고 말하는 것은 아니다. == 해결책 == 브룩스 법칙에서 언급된 문제를 피해가기 위해서는 문제 전체를 소규모의 그룹이 맡을 수 있는 조각으로 나누고, 상급 팀이 시스템 통합을 맡는 것이다. 그렇지만 이 또한 문제를 나누는 과정이 정확하지 않으면 팀 간의 의사소통 비용이 늘어나게 되어 문제를 더 크게 만들 수 있다는 단점이 있다. <!--- ==오픈소스 소프트웨어 개발== Some would claim the programming practices associated with [[open source software development]] allow open source projects to defy the predictions of Brooks' law, but this is not true. A late [[Open-source software|OSS]] project will become even later if additional developers are added for the reasons addressed above. Also, most OSS projects (e.g., [[리눅스]]) have no schedule, so "late" and "later" have no meaning. --> == 여타 분야에의 적용 == 브룩스의 법칙은 달성하고자 하는 일의 속성에 따라 그 적용 가능성이 극명하게 달라진다. 예를 들어 늦어진 건설 계획에서 덤프트럭을 더 투입한다고 해서 부가적으로 계획이 지체되거나 하지 않는다. 이는 일의 속성상 누구나 최소한의 기술과 트럭만 갖고 있다면 업무를 바로 처리할 수 있고, 트럭 운전사들끼리 의논을 해 가며 일을 할 필요 또한 적기 때문이다. 반면 소프트웨어 개발과 같은 디자인 작업에서는 새로 투입된 인력은 프로젝트에 대해 기본적인 방향이나 방법, 이미 진행된 작업에 대한 교육이 선행되어야만 프로젝트에 도움이 될 수 있다. == 같이 보기 == * [[안티패턴]] * [[리누스의 법칙]] {{위키데이터 속성 추적}} [[분류:사람 이름을 딴 낱말]] [[분류:소프트웨어 공학]] [[분류:소프트웨어 프로젝트 관리]] [[분류:1975년 신조어]]
브룩스의 법칙
문서로 돌아갑니다.
검색
검색
브룩스의 법칙 문서 원본 보기
새 주제