신화적 인월
The Mythical Man-Month.jpg) 초판 | |
| 작가. | 프레드릭 브룩스 |
|---|---|
| 주제 | 소프트웨어 프로젝트 관리 |
| 출판인 | 애디슨 웨슬리 |
발행일자 | 1975 |
| ISBN | 0-201-00650-2(최종판), 0-201-83595-9(최종판) |
| OCLC | 1201368 |
| 001.6/425 | |
| LC Class | QA76.6.B75 |
| 이어서 | '실버블릿 없음" |
The Mythic Man-Month: Essays on Software Engineering은 Fred Brooks가 1975년에 처음 출판한 소프트웨어 엔지니어링 및 프로젝트 관리에 관한 책으로, 이후 판은 1982년과 1995년에 출판되었습니다.'늦은 소프트웨어 프로젝트에 인력을 더하면 나중에 된다'는 게 핵심이다.이 아이디어는 Brooks의 법칙으로 알려져 있으며, 두 번째 시스템 효과 및 프로토타이핑 옹호와 함께 제시됩니다.
Brooks는 IBM에서 OS/360 개발을 관리하면서 쌓은 경험을 바탕으로 관찰했습니다.그는 예정보다 늦어지는 프로젝트에 프로그래머를 더 많이 추가했는데, 이는 나중에 직감적으로 프로젝트를 더 지연시켰다고 결론지을 수 있었습니다.또, ALGOL 컴파일러의 작성에 관여하는 1개의 프로젝트에는, 관련된 종업원의 수에 관계없이, 6개월의 시간이 필요하다고 단언한 것도 실수입니다(더 오래 걸립니다).매니저들이 프로젝트 개발에서 이러한 오류를 반복하는 경향은 브룩스가 그의 책이 "소프트웨어 공학의 성경"이라고 불릴 정도로 비꼬게 만들었다. 왜냐하면 "모든 사람이 인용하고, 어떤 사람은 그것을 읽고, 어떤 사람은 그것을 [1]지나치기 때문이다.
에디션
이 작품은 1975년(ISBN 0-201-00650-2)에 초판되어 1982년에 수정본으로 전재되어 1995년(ISBN 0-201-83595-9)에 에세이 "No Silver Bullet"을 저자의 해설과 함께 전재한 것을 포함하여 4장의 추가본으로 재출판되었다.
아이디어 제시
신화 속 인간의 달
Brooks에서는 스케줄링 실패의 몇 가지 원인에 대해 설명합니다.가장 영속적인 것은 Brooks의 법칙에 대한 그의 논의입니다. 즉, 최신 소프트웨어 프로젝트에 인력을 더하면 나중에 할 수 있다는 것입니다.인월은 한 달에 한 사람에 의해 이루어진 작업을 나타내는 가상의 단위이다; 브룩스의 법칙은 인월에 유용한 작업을 측정할 수 있는 가능성은 신화이며, 따라서 이 책의 중심축이다.
복잡한 프로그래밍 프로젝트는 작업자 간의 의사소통 없이 그리고 작업자와 작업자를 수행하는 작업자 간의 일련의 복잡한 상호 관계를 확립하지 않고서는 작업될 수 있는 개별 작업으로 완벽하게 분할될 수 없습니다.
따라서 예정보다 늦게 실행되는 프로젝트에 프로그래머를 더 많이 할당하면 더 늦어질 수 있습니다.이는 신규 프로그래머가 프로젝트에 대해 학습하는 데 필요한 시간과 늘어난 통신 오버헤드가 이용 가능한 일정 시간의 양을 점점 더 많이 소비하기 때문입니다.n명이 서로 의사소통을 해야 할 경우 n명이 늘어나면 출력이 감소하고 음이 되면 1명씩 프로젝트가 지연됩니다.
- 그룹 간 통신 공식: n(n - 1)/2.
- 예: 50명의 개발자가 50 × (50 – 1)/2 = 1,420개의 통신 채널을 제공합니다.
실버블렛 없음
Brooks는 The Minside Man-Month 기념판에 "No Silver Bullet-Essence and Accidents in Software Engineering" 장과 이에 대한 추가적인 반성을 추가했습니다.
Brooks는 "기술이나 관리 기술 모두 단일 개발은 없으며, 그 자체만으로도 생산성, 신뢰성, 단순성 면에서 10년 이내에 한 가지 규모의 개선도 기대할 수 있습니다."라고 말합니다.
Amdahl의 법칙이 "병렬화 가능"과 "엄격히 직렬화"의 구별에 의존하는 것과 마찬가지로, 이 주장은 우발적인 복잡성과 본질적인 복잡성의 구별에 의존합니다.
두 번째 시스템 효과
두 번째 시스템 효과는 설계자가 두 번째 시스템을 설계할 때, 설계자가 설계할 시스템 중 가장 위험한 시스템이라고 제안합니다. 왜냐하면 그들은 본래 시간 제약으로 인해 첫 번째 시스템에 추가하지 않았던 모든 추가 사항을 통합하는 경향이 있기 때문입니다.따라서 두 번째 시스템에 착수할 때 엔지니어는 과도한 엔지니어링에 노출될 수 있다는 점에 유의해야 합니다.
줄일 수 없는 오류 수 경향
코드에 99개의 작은 버그가 있습니다.
99마리의 작은 벌레들.
하나를 떼어내서 여기저기 붙이세요.
코드에 127개의 작은 버그가...[2]
저자는 상당히 복잡한 시스템에는 줄일 수 없는 일정한 수의 오류가 있다는 것을 관찰한다.발견된 오류를 수정하려고 하면 다른 오류가 발생하기 쉽습니다.
진행률 추적
브룩스는 "질문:대규모 소프트웨어 프로젝트가 어떻게 1년 늦어질 수 있습니까?답변:하루하루!많은 전선에서의 증분적 편차는 결국 축적되어 큰 전체 지연을 낳는다.각 관리 레벨에서 소규모의 개별 마일스톤을 충족하기 위한 지속적인 주의가 필요합니다.
개념적 무결성
사용자 친화적인 시스템을 만들기 위해서는 시스템이 개념적 무결성을 갖춰야 하며, 이는 아키텍처와 구현을 분리해야만 달성할 수 있습니다.사용자를 대신하여 1명의 최고 설계자(또는 소수의 설계자)가 시스템에 무엇이 포함되고 무엇이 남아 있는지 결정합니다.설계자 또는 설계자 팀은 시스템이 무엇을 해야 하는지에 대한 아이디어를 개발하고 이 비전을 다른 팀원이 이해하도록 해야 합니다.시스템 설계 전체에 심리스하게 들어맞지 않으면 다른 사람의 참신한 아이디어가 포함되지 않을 수 있습니다.실제로 사용자 친화적인 시스템을 확보하기 위해 시스템은 의도적으로 가능한 것보다 적은 수의 기능을 제공할 수 있습니다.요점은 시스템이 너무 복잡해서 사용할 수 없을 경우, 아무도 기능을 배울 시간이 없기 때문에 많은 기능이 사용되지 않는다는 것입니다.
매뉴얼
최고 설계자가 시스템 사양 매뉴얼을 작성합니다.시스템의 외부 사양, 즉 사용자에게 표시되는 모든 사양에 대해 자세히 설명해야 합니다.매뉴얼은 구현 팀과 사용자로부터 피드백이 들어오면 변경해야 합니다.
파일럿 시스템
새로운 종류의 시스템을 설계할 때 팀은 일회용 시스템을 설계합니다(의도 여부에 관계없이).이 시스템은 나중에 시스템의 완전한 재설계를 야기하는 기술을 보여주는 "파일럿 계획" 역할을 합니다.두 번째로 스마트한 시스템은 고객에게 제공되어야 합니다. 파일럿 시스템의 제공은 고객에게 고민만 안겨줄 뿐이며 시스템의 평판은 물론 회사의 평판마저 손상시킬 수 있기 때문입니다.
정식 문서
모든 프로젝트 매니저는 프로젝트의 목표, 달성 방법, 달성 대상자, 달성 시기 및 비용을 정의하는 소규모 핵심 문서 세트를 작성해야 합니다.또, 이러한 문서에서는, 보기 어려운 불일치를 발견할 수도 있습니다.
프로젝트 견적
프로젝트 시간을 추정할 때 프로그래밍 제품(유료 고객에게 판매할 수 있음)과 프로그래밍 시스템은 모두 단순한 독립적 사내 프로그램 [3]작성보다 3배 더 어렵다는 점을 기억해야 합니다.관리 업무나 기타 기술 이외의 업무(회의 등), 특히 '스탠드업' 또는 '올핸드' 회의와는 달리 실제로 기술적인 문제에 주당 근무시간을 얼마나 할애해야 하는지 유념해야 합니다.
의사소통
재난을 피하기 위해 프로젝트에 종사하는 모든 팀은 가능한 한 많은 방법(이메일, 전화, 회의, 메모 등)으로 서로 연락을 유지해야 합니다.구현자는 무언가를 가정하는 것이 아니라 완전히 잘못된 가정을 진행하기 전에 구현 중인 기능에 대한 의도를 명확히 하도록 설계자에게 요청해야 합니다.설계자는 프로젝트의 그룹 그림을 작성하여 다른 사람에게 전달할 책임이 있습니다.
수술팀
수술 중 외과 팀은 가장 중요한 작업을 수행하는 한 명의 외과의가 이끌며, 덜 중요한 부분을 지원하도록 팀을 이끌기 때문에, 나머지 팀이 필요한 것을 적절한 타이밍에 제공하는 동안 "좋은" 프로그래머가 중요한 시스템 컴포넌트를 개발하도록 하는 것이 타당할 것 같습니다.또한 Brooks는 "좋은" 프로그래머가 보통 프로그래머보다 5배에서 10배 더 생산적이라고 생각합니다.
코드 프리즈 및 시스템 버전 관리
소프트웨어는 보이지 않습니다.따라서 많은 것들이 새로운 시스템에서 일정한 양의 작업이 이루어진 후에야 명백해지고 사용자가 그것을 경험할 수 있게 됩니다.이러한 경험은 사용자의 요구나 사용자의 요구에 대한 인식을 바꿀 수 있는 통찰력을 제공합니다.따라서 사용자의 변경된 요건을 충족하기 위해 시스템을 변경해야 합니다.이 문제는 특정 시점까지만 발생할 수 있으며 그렇지 않으면 시스템이 완료되지 않을 수 있습니다.특정 날짜에는 시스템을 더 이상 변경할 수 없으며 코드를 동결해야 합니다.모든 변경 요청은 다음 시스템 버전으로 미뤄야 합니다.
특수 공구
모든 프로그래머가 자신의 특별한 도구 세트를 보유하는 대신, 각 팀에는 지정된 도구 제조사가 있어야 합니다.이 도구 제조사는 팀이 수행하는 작업에 맞게 고도로 맞춤화된 도구(예: 사양에 따라 코드를 작성하는 코드 생성 도구)를 만들 수 있습니다.또한 시스템 전체의 툴은 프로젝트 매니저가 감독하는 공통 툴 팀이 구축해야 합니다.
소프트웨어 개발 비용 절감
Brooks는 소프트웨어 개발 비용을 절감하는 두 가지 기술을 사용합니다.
- 구현자는 시스템 아키텍처가 완료된 후에만 고용할 수 있습니다(몇 개월이 걸릴 수 있으며, 그 동안 섣불리 고용된 구현자는 할 일이 없을 수 있습니다).
- Brooks가 언급하는 또 다른 기술은 소프트웨어를 전혀 개발하지 않고 가능한 한 "즉시" 구입하는 것입니다.
「 」를 참조해 주세요.
참고 문헌
- Brooks, Frederick P. (1975). The Mythical Man-Month. Addison-Wesley. ISBN 0-201-00650-2.
- Brooks, Frederick P. (1983). "The Mythical Man-Month". PC Magazine. 2 (4): 210–240.
- Brooks, Frederick P. (1995). "Chapter 17. 'No Silver Bullet' Refined". The Mythical Man-Month (anniversary ed.). Addison-Wesley. ISBN 0-201-83595-9.
레퍼런스
- ^ Roth, Daniel (2005-12-12). "Quoted Often, Followed Rarely". CNN. Retrieved 2010-10-23.
- ^ 99개의 맥주병에 기초한 이 유머러스한 노래는 적어도 Anonymous (2000). "Computer programming quotes".2000년 이후 게시판에 게시되어 왔다.
- ^ 신화 속 인물-월 그림 1.1, 13페이지
