태그 보관물: development-process

development-process

“신화적인 남자-월”의 “외과 팀”패턴은 어떻게 되었습니까? 각 부문이

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

외과 팀

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

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

왜 그런 겁니까?

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


답변

“신화적인 남자-월”은 내가 대학을 시작한 해에 나왔고, 현재의 고유 한 UUUGE를 사용했습니다! 🙂 이해해야 할 것은 소프트웨어가 THEN과 NOW를 어떻게 개발했는지 차이입니다. Back In The Day ™ 거의 모든 코딩 작업이 종이에서 먼저 수행 된 다음, 펀치 된 카드에 키 펀칭 (추측)되어 읽혀지고, 컴파일되고, 연결되고, 실행되고, 결과가 얻어지고 프로세스가 반복되었습니다. 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 ™에는 프로그래밍 콘테스트가 없었고, 스택 오버플로가 없었으며, 마음에들 때마다 코드를 작성할 수있는 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에서 비슷한 내용을 제안한 논문이있었습니다.

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

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

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