"신화적인 남자-월"의 "외과 팀"패턴은 어떻게 되었습니까?

몇 년 전, The Mythical Man-Month를 읽을 때 다른 출처에서 이미 알고있는 많은 것들을 발견했습니다. 그러나 1975 년 이후의 책에도 불구하고 거기에도 새로운 것들이있었습니다.

외과 팀

Mills는 대규모 직종의 각 부문이 한 팀을 이룰 것을 제안하지만이 팀은 돼지를 도살하는 팀이 아닌 외과 팀처럼 조직되도록 제안합니다. 즉, 각 구성원이 문제를 해결하는 대신 절단을 수행하고 다른 구성원은 자신의 효율성과 생산성을 향상시킬 수있는 모든 지원을 제공합니다.

이것은 소프트웨어 개발 팀을 조직하는 데 매우 흥미로운 패턴이지만 다른 소프트웨어 엔지니어링 책에서는 설명하지 않았으며 어디에서도 언급되지 않았습니다.

왜 그런 겁니까?

• 당시 "수술팀"은 이례적인가?
• 아니면 시도하고 실패 했습니까?
  • 그렇다면 어떻게 실패 했습니까?
  • 그렇지 않다면 오늘날의 소프트웨어 프로젝트에서 해당 패턴이 구현되지 않는 이유는 무엇입니까?

"신화적인 남자-월"은 내가 대학을 시작한 해에 나왔고, 현재의 고유 한 UUUGE를 사용했습니다! :-) 이해해야 할 것은 소프트웨어가 THEN과 NOW를 어떻게 개발했는지 차이입니다. Back In The Day (tm) 거의 모든 코딩 작업이 종이에서 먼저 수행 된 다음, 펀치 된 카드에 키 펀칭 (추측)되어 읽혀지고, 컴파일되고, 연결되고, 실행되고, 결과가 얻어지고 프로세스가 반복되었습니다. CPU 시간은 비쌌습니다자원이 제한되어 있고 낭비하고 싶지 않았습니다. 디스크 공간, 테이프 드라이브 시간 등도 마찬가지입니다. 컴파일시 CPU 시간을 완전히 낭비하면 (충격과 공포!) 오류가 발생했습니다 ... 완전히 좋은 CPU 시간을 낭비했습니다. 그리고 이것은 중후반 1960의 CPU 시간조차이었다 프레드 브룩스가 자신의 아이디어를 개발되었을 때, 1975 년이었다 더비싸고, 메모리 / 디스크 / 무엇이 더 제한되어 있는가 등. 외과 팀의 아이디어는 One Super Great Rockstar Developer가 책상 점검 코드, 키 펀칭, 일반 작업과 같은 일상적인 작업에 HIS 시간을 낭비하지 않도록하는 것입니다. 작업 제출, 결과 대기 (때로는 몇 시간). Rockstar Dude Developer Man은 코드를 작성해야했습니다. 그의 그룹 / 서기 / 주니어 개발자 군단은 평범한 일을하기로되어있었습니다.

문제는 브룩스의 책이 출판 된 지 2 년 만에 외과 팀의 기본 아이디어가 무너 졌다는 것입니다.

1. CRT 터미널 및 디스크 파일이 키펀치 및 카드 데크를 대체하기 시작했습니다. 컴퓨터 시간이 저렴 해지고 여러 컴퓨터를 사용할 수있게되었으며 작업 처리 시간이 크게 단축되었습니다. 내가 대학에 도착 (요청 마이애미 대학, 옥스포드, 오하이오, '79 클래스, 덕분에) 좋은작업 처리 시간은 약 1 시간이었습니다. 결승 주간에는 4 시간, 때로는 6 시간이 소요됩니다. (우리는 많은 상용 회사 및 대학과 CPU 시간을 놓고 경쟁했으며, 상용 사용자가 최우선 순위였습니다.) 마이애미가 자신의 "공유 컴퓨터"배열에서 벗어나고, 캠퍼스에 자체 IBM 370/145가 설치되어 있고, RJE 스테이션 역할을하는 멋진 HP 미니를 가지고 메인 프레임을 돌릴 수 있었던 시니어 년 5 분 이내에 작업을 처리합니다. 코드를 HP에서 가져와 HP에서 메인 프레임으로 보내고, 엄지 손가락으로 담배를 피우고 담배를 피우고, 책상 점검을 마치기 전에 출력물을 다시 가져 오는 것이 좋습니다.

2. 외과 팀은 기본적으로 전제로 귀하 (또는 "관리", 신이 우리 모두를 도와줍니다)가 Rockstar Surgical Developer Dude를 식별 할 수 있다는 아이디어를 전제로합니다. 사실, 나는 그것이 가능한지 의심합니다. 가 있습니다 록 스타 개발자, 모두가 그것을 알고있다 - 연구만큼 2000 %의 최고와 최악 개발자 간의 생산성의 차이를 보여 -하지만 그 사람을 식별 그들이 오랜 기간 동안 코드를 작성하지 않고아마도 불가능할 것입니다. 누군가 Rockstar 개발자인지 알 수있는 유일한 방법은 실제로 코드를 개발하는 것입니다. 그러나 Rockstar Surgical Developer Dude가 아닌 경우 코드 확인, 카드 키 입력, 구멍을 뚫은 카드 상자를 Job Entry 부서로 옮긴 다음 결과를 기다리는 동안 코드를 작성하고 코드를 디버깅하여 실제로 작동하는 유일한 방법을 코딩하는 대신 Rockstar Surgical Developer Dude에게 다시 보내 줄 수 있습니다. Back the The Day (tm)에는 프로그래밍 콘테스트가 없었고, 스택 오버플로가 없었으며, 마음에들 때마다 코드를 작성할 수있는 PC가 없었습니다. 바보 책에 대한 알고리즘은 없었습니다. 프로그래밍을 배우는 유일한 방법은 학교에 가서 약간의 프로그래밍을해야하는 것을 전공하는 것이 었습니다. 그러나 프로그래밍그 자체 는 진지하게 받아 들여지지 않았으며 사람들이 원하지 않는 것으로 가정되었습니다 . 첫 번째 대학 과정 (SAN151-시스템 분석 소개, Tom Schaber 박사-Tom :-감사)은 강사로부터 다음과 같이 말했습니다. "... 시스템 분석가가되기 전에 프로그래머로 2 년이 걸렸습니다. " "2 년?" "2 년 동안 만이 작업을 수행 할 수 있습니까?!?". 나는 심하게 불쑥했다. 고맙게도 그는 틀렸고 그 이후로 거의 코딩을 해왔습니다. :-)

3. 외과 팀은 프로그래머가 비교적 드문 자원이라고 가정합니다. 실제로 몇 년이 더 걸렸지 만 80 년대 초반에 PC가 등장하면서 모든 괴짜가 참여할 수있게되었습니다. 컴퓨터 가격이 떨어지기 시작했고 개발 도구 가격이 떨어지기 시작했습니다. 우박 터보 파스칼 (Ultra Turbo Pascal) – 오늘날의 표준으로는 그다지 많지 않았지만 당시에는 약 40 달러의 완전한 파스칼 IDE였습니다. 이제 ANYBODY는 프로그래밍에 들어갈 수 있습니다-컴퓨터를 구입할 수 있고 IBM이 PCjr (예, 첫 번째 PC는 IBM의 가장 큰 실수 중 하나였습니다. 어디에나 갇힌 괴짜들은 한 달 동안 임대료 지불을 건너 뛰었습니다 ( "예, 알아요,하지만 ... 어. .uh ... 예, 다음 주에 아무 문제 없습니다. 고마워요 .....) 그런 다음 컴퓨터를 사용하기 위해 컴퓨터에 지불 한 것보다 더 많은 비용을 썼습니다. ( "그렇습니다, 다음 주, 아마도 ...":-).

내가 정말로 슬프게하는 것은 오늘날에도 사람들이 "신화적인 남자-월"을 읽었는지 또는 주된 교훈 ( "늦은 프로젝트에 리소스를 추가하면 나중에 만들어집니다")을 이해했는지 묻는다면 응시 한 다음 OS / 360을 개발하는 동안 All Thats Years Ago와 똑같은 오류를 만들었습니다. 오래된 모든 것이 다시 새롭다 ... :-}

그 개념의 몇 가지 측면이 있습니다 있습니다 때로는 오늘 구현은, 다른 측면이있다 피할 수는 .

팀을 작게 유지하는 것은 애자일 방법의 기본 기능 중 하나이지만 애자일 외부에서도 실행됩니다.

부서 간 팀도 애자일의 필수 요소이지만 애자일 외부에서도 일반적입니다.

프로그램 서기의 역할은 버전 제어 시스템, 소프트웨어 구성 관리 시스템, 변경 관리 시스템, 문서 관리 시스템, 위키, 아티팩트 리포지토리가있는 연속 빌드 시스템 등과 같은 컴퓨터 시스템에 의해 대체됩니다. 내 말은, 소스 코드를 인쇄하고 수동으로 색인을 생성하고 제출하기 위해 정규 직원에게 돈을 지불하는 것을 상상할 수 있습니까?

마찬가지로 시스템 관리자 (Mills 's Surgical Team의 일부는 아니지만 지난 몇 년간의 전형적인 교차 기능 팀의 일부)의 역할은 DevOps와 같은 개념에서 더 이상 사용되지 않습니다 (Sysadmin의 역할을 소프트웨어 엔지니어의 역할로 흡수 함). , Platform-as-a-Service, IaaS (Infrastructure-as-a-Service) 및 유틸리티 컴퓨팅 (Sysadmin의 역할이 "다른 사람의 문제"임) 또는 IaaS (Systems-as-Code) (시스템 관리를 소프트웨어 엔지니어링으로 전환).

오늘날 우리가 피하려고하는 측면 중 하나는 최대 두 사람 이 시스템을 이해한다는 것입니다. 의사 만이 시스템을 완전히 이해할 수 있으며, 부조종사가있을 수도 있고 그렇지 않을 수도 있습니다. 이것은 1과 2 사이 의 버스 팩터 를 제공합니다 . 외과의가 아프면 프로젝트는 죽었습니다. 기간. 그에 대한 민첩한 대답은이다 집단 코드 소유권이다 정반대 그 모델의 : 아무도 대한 단독 책임이없는 일부 시스템. 대신, 모든 사람 은 그룹으로서 모든 것을 책임집니다 .

마지막으로, 그 개념에는 구식 인 몇 가지 가정이 있습니다. 예를 들어, 명시 적으로 명시되어 있지 않더라도 팀의 한 사람 (외과 의사) 만 실제로 컴퓨터를 보유하는 방식으로 팀이 설정됩니다. 물론, 기사가 쓰여질 당시 팀 전체의 한 사람은 물론 전체 팀이 자신을 위해 한 대의 컴퓨터를 가질 것이라는 생각조차도 확장 되었기 때문입니다. (Smalltalk가 출시 된 1980 년에도 실패에 기여한 것 중 하나는 시스템이 모든 개발자와 모든 사용자가 자신의 컴퓨터를 갖도록 설정되었다는 사실이었습니다. 당시에는 전혀 생각할 수 없었습니다.)

그래서, 짧은 : 설명 된 바와 같이 나는 생각하지 않는다 개념이 정확하게 구현되었지만, 그것의 일부 측면이 분명히 있다 구현, 일부 측면은 바람직하지 않은으로 간주하고 적극적으로 피할 수있다, 일부는 사용되지 않습니다, 일부는 ™ 아마도 좋은 아이디어입니다, 그러나 아무도하지 않습니다.

예전에는 대학 교육이 독창적이었고 엔지니어는 선택된 소수였습니다. 컴퓨터는 비쌌으며, 팀은 정의 된 비즈니스 RoI로 프로젝트를 진행했습니다. 이것들은 흔하지 않았습니다.

일어난 일은 마이크로 컴퓨터, 유비쿼터스 학부 교육 및 진학을 위해 대학 학위가 필요없는 컴퓨터 시스템이었습니다. 또한 경제 변화와 노동 비용 상승이 일어났습니다.

8 : 2 지원 : 엔지니어 비율의 경제성은 더 이상 의미가 없습니다. 엔지니어는 자신의 지원이어야합니다. 개발 팀에 효과적으로 연결될 수있는 충분한 교육과 기술을 갖춘 현대인은 너무 비싸서 자체 개발을하지 못합니다.

(관련 경제학 용어는 "서비스 부문의 비용 질병"입니다.)

이 패턴은 Mob 프로그래밍처럼 나에게 많이 들립니다.

전체 그룹 (QA, 개발자 및 필요한 경우 제품 소유자)도 같은 문제에서 동시에 작업하고 있습니다. 일어 서고, 의사 소통 할 필요가 없으며, 라이브에 직접 배포됩니다.

에서 http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

mob 프로그래밍의 기본 개념은 간단합니다. 팀 전체가 한 번에 하나의 작업을 수행하는 팀으로 작동합니다. 즉 : 하나의 팀 – 하나의 (활성) 키보드 – 하나의 화면 (물론 프로젝터). 전체 팀 페어 프로그래밍을하는 것과 같습니다.

https://www.youtube.com/watch?v=dVqUcNKVbYg 에서 실제로 확인하십시오.

이 팀 모델은 305 페이지의 Steve McConnell의 Rapid Development-Taming Wild Software Schedules에서 다시 언급됩니다.이를 수석 프로그래머 팀이라고합니다.

이 모델은 팀에 천재가 있었고 컴퓨팅 리소스가 제한되어 있었기 때문에 일어났습니다. 천재가 드물기 때문에 호의를 얻지 못했으며 유비쿼터스 컴퓨터와 분산 버전 제어를 통해 운영 테이블에 많은 손을 넣을 수있는 공간이 있습니다.

다른 참고 문헌 :

베이커, F. 테리 "생산 프로그래밍의 수석 프로그래머 팀 관리", IBM Systems Journal, vol. 11 호 1, 1972, 56-73 쪽.

Baker, F. Terry 및 Harlan D. Mills. "최고 프로그래머 팀." 자료 화, 19 권, 12 호 (1973 년 12 월), 58-61 쪽.

내 생각에 대부분의 소규모 자체 조직 팀은 사실상의 외과 팀 모델에 정착하는 경향이 있습니다.

내가 최근에했던 두 팀은 보통 3 명 또는 4 명으로 구성되는데, 보통 1 명의 선임 (외과 의사), 중급 (공동 조종사) 및 2 명의 후배 / 전문가로 구성됩니다. 오늘날 Brooks가 언급 한 수술 팀의 일부 역할은 Scrum 마스터 및 sysadmins 또는 클라우드 제공 업체가 작성합니다. 소스 제어는 git만큼 강력한 것은 물론 당시에는 거의 존재하지 않았 음을 기억하십시오.

베조스의 2 피자 규칙을 생각해보십시오. 그것은 바로 당신의 자기 조직적인 외과 팀입니다.

HP에서 비슷한 내용을 제안한 논문이있었습니다.

• 각 소프트웨어 엔지니어는 여러 관리자와 여러 지원 담당자가 필요합니다.
• 각 엔지니어마다 기술 작가, 테스터, 빌드 관리자 및 툴 메이커가 있어야합니다.

이 신문은 웹 이전 시대에 있었고 때때로 재미있었습니다. 해마다 그 논평은 "너무 웃기다"에서 "어쩌면 우리가 그렇게해야 할 것"으로 조금씩 움직였다.

실제 테스트는 설계하기 어려운 것으로 악명 높으므로 아마도 의견이 남아있을 것입니다. 프로젝트 및 완료율에 대한 일부 설문 조사가있을 수 있습니다.

인터넷, 통합 개발 환경 및 소프트웨어 개발 키트 의 증가로 인해 외과 팀의 필요성이 어느 정도 중복되어 왔는지 궁금합니다.이 도구는 다음과 같은 외과 팀 의 많은 기능을 수행 할 수 있습니다.

• 외과 의사 : 프로그래머
• 공동 조종사 : 프로그래머 , 동료, StackExchange 또는 IRC와 같은 온라인 커뮤니티 쌍
• 관리자 : 소프트웨어 프로젝트 관리자가 일반적으로 수행하는 역할
• 편집기 : Javadoc 또는 Doxygen과 같은 문서 생성기를 통합하는 IDE; 소프트웨어 개발 키트의 설명서
• 비서 : 이메일 클라이언트, 이슈 트래커 및 풀 요청과 같은 프로젝트 관리 도구, 회사 대화방 및 메일 목록
• 프로그램 담당자 : 코드를 리팩토링하는 기능이 추가 된 프로젝트 디자인에 대한 정보를 저장하는 IDE; 소프트웨어 개발 키트의 문서 및 예제
• 툴 스미스 : 전체 오픈 소스 커뮤니티
• 테스터 : 즉시 테스트 스위트 및 테스트 라이브러리. 물론 생산 코드에는 별도의 QA 프로세스가 필요합니다.
• 언어 변호사 : 온라인 문서, StackExchange

신화의 달의 전제를 살펴 봐야한다고 생각합니다. 더 많은 프로그래머를 고용하면 문제가 있거나 기한이 지난 소프트웨어 프로젝트 만 악화됩니다. 문제는 의사 소통에 있으며 새로 추가 된 프로그래머가 프로젝트 (기존 개발에서 시간이 걸리는 시간), 기술 및 때로는 도메인 자체의 속도를 높이는 데 있습니다.

하나의 잘 지원되는 프로그래머는 많은 통신 시간과 조정을 제거합니다. Technology X의 컨설턴트를 고용한다고 가정 해 봅시다.이 컨설턴트가 해당 개인이 해당 영역에서 모든 코딩을 수행 할 수있을 정도로 프로젝트 속도를 높이는 대신 기존 개발자에게 무언가를 만들 수있는 지점까지 코치합니다. 약간의 감독과 함께.

당신이 이것을 많이 보지 못하는 한 가지 이유는 대부분의 소프트웨어가 한 사람에 의해 작성되기 때문입니다. 팀은 작업을 나누고 모두가 가고 일을합니다. 페어 프로그래밍, 리뷰 및 미시적 관리 냄새가 난다. 많은 사람들이 프로그래밍을 팀 스포츠로 보지 않습니다. 한 사람이 전체 제약 조건을 고려하여 주어진 문제를 해결합니다.

디자인, 구현, 테스트, 문서화, 빌드, 배포, 운영 등을 전문가가 수행하는 고유 한 역할로 분리할수록 "수술 팀"철학을 더 많이 따르게 될 것입니다. ).

내 경험상 모든 사람이 모든 작업을 수행 할 수 있어야한다는 devOps 철학은 돼지를 도살하는 모델로 돌아온다는 것입니다.

나는 종종 DevOps와 Build Master의 역할을 맡은 프로그래머로서 나는 종종 외과 팀의 위치에 있다고 느꼈습니다. 빌드 마스터로서 전체 코드에 대한 개요를 보았으며 실패했을 때 첫 번째 줄이었습니다. 종종 나는 그것을 스스로 고칠 것입니다.
나는 종종 이러한 통계 시스템을 작성하고 코드에서 핫 포인트를 측정하고, 더 자주 실패하는 부분, 가장 많은 버그 보고서를 끌어 들인 부분 등을 측정했습니다. 나는 결과를 팀에 공개하지 않았습니다. 이 문제를 해결하기 위해 문제와 제안 된 솔루션 및 아키텍처 변경을 일으킨 꼬임.

DevOps로서 나는 프로세스와 오버 헤드의 엄청난 혼란을 자동화 할 것입니다. 팀, 팀 전체, 개발자, QA 테스터 IT 운영에 이르기까지 모든 작업을보다 쉽게 ​​관리 할 수있는 기술과 도구를 연구했습니다. 내 역할은 프로세스를 이해하는 것이 었습니다. 그러나 그 과정을 사용하여 (고통) 팀 (실제 인간)에 시선을 고정함으로써 나는 그것을 객관적으로 볼 수있는 유용한 데이터를 얻는 동안 그것을 완전히 투명하게 만드는 시점까지 흘릴 수있었습니다. 아주 어려운 "큰 그림".

그것은 왜 그렇게 끔찍한 입장이며 왜 그렇게 많이 기피했는지에 대한 것입니다. 아무도 그 과정을 눈치 채지 못했을 때, 아무도 빌드 파이프 라인에 대해 생각하지 않았을 때, 내가 잘한 일을 알고 있습니다. 따라서 기름칠이 잘 된 기계는 당연히 당연한 것으로 여겨집니다. 그러나 실제로 측정 한 결과이 작업이 팀의 생산성에 미치는 영향은 투자 가치가 있다는 것을 알았습니다.

그렇습니다. 저는 그 역할이 오늘날에도 여전히 살아 있다고 생각합니다.