Mythical Man Month의 영향을 완화하는 방법은 무엇입니까?

Brooks의 법칙 : 늦은 소프트웨어 프로젝트에 인력을 추가하면 나중에 만들 수 있습니다.

그의 저서 No Silver Bullet – 소프트웨어 공학의 본질과 사고에서 Frederick Brooks는 Mythical Man Month 의 개념을 정의합니다 .

Brooks의 가정은 복잡한 프로그래밍 프로젝트 를 작업자 간의 의사 소통 없이 수행 할 수있는 개별 작업으로 완벽하게 분할 할 수 없으며 작업과 작업을 수행하는 작업자간에 복잡한 상호 관계를 설정하지 않고서 는 불가능 합니다 .

1982 년 이래로 우리는 확실히이 문제를 해결하고 더 많은 경험을 쌓았습니다. 더 많은 문제를 일으키지 않고 프로젝트에 리소스를 추가하기 위해 직장에서 성공적으로 적용한 몇 가지 솔루션은 무엇입니까?

MMM은 무엇입니까

먼저 Brook의 법칙의 맥락을 설명하고 싶습니다. 그가 1975 년에 다시 만들었다는 가정은 무엇입니까?

한 달은 한 달에 한 사람이 수행 한 작업을 나타내는 가상의 작업 단위입니다. Brooks의 법에 따르면 수개월 동안 유용한 작업을 측정하는 것은 불가능합니다.

^{출처 : https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

과거에는 복잡한 프로그래밍 프로젝트가 큰 모놀리스 시스템을 의미했습니다. 또한 Brooks는 개발자 간의 의사 소통없이 그리고 작업과 작업을 수행하는 사람들 사이에 복잡한 상호 관계를 설정하지 않고 작업 할 수있는 개별 작업으로 완벽하게 분할 할 수 없다고 주장합니다.

이것은 응집력이 높은 소프트웨어 모놀리스에서 매우 사실입니다. 얼마나 많은 디커플링이 수행 되더라도 여전히 큰 모노리스는 새로운 프로그래머가 모노리스에 대해 배우는 데 필요한 시간을 요구합니다. 또한 통신 오버 헤드가 증가하여 사용 가능한 시간이 계속 증가합니다.

그러나 실제로 이런 식이어야합니까? 우리는 모놀리스를 작성하고 개발자 수는 n(n − 1) / 2어디에서 의사 소통 채널을 유지해야 n합니까?

우리는 수천 명의 개발자가 대규모 프로젝트를 수행하고있는 회사가 있다는 것을 알고 있습니다. 따라서 1975 년 이후 변경된 것이 있어야합니다.

MMM 완화 가능성

2015 년 PuppetLabs와 IT Revolution은 2015 년 DevOps 보고서 상태 결과를 발표했습니다 . 이 보고서에서는 성과가 높은 조직과 비 성능의 구별에 중점을 두었습니다.

고성능 조직은 예상치 못한 속성을 보여줍니다. 예를 들어, 개발시 프로젝트 기한이 가장 좋습니다. 최고의 운영 안정성 및 운영 안정성. 최고의 보안 및 규정 준수 추적 기록뿐만 아니라

보고서에서 강조된 놀라운 점 중 하나는 일일 배포 메트릭입니다. 그러나 하루에 한 번의 배포뿐만 아니라 배포 / 일 / 개발자를 측정했으며 고성능 조직과 비 성능 조직에 더 많은 개발자를 추가하는 데 따른 영향을 측정했습니다.

이 보고서의 그래프입니다-

성과가 저조한 조직은 신화 적 인간의 달 가정과 일치합니다. 고성능 조직은 개발자 수에 따라 배포 / 일 / 개발 수를 선형으로 확장 할 수 있습니다.

Gene Kim의 DevOpsDays London 2016 에서 훌륭한 발표 가 이러한 결과에 대해 이야기합니다.

그것을하는 방법

먼저, 고성능 조직이되는 방법은 무엇입니까? 이것에 대해 이야기하는 두 권의 책이 있습니다.이 답변에 충분한 공간이 없으므로 링크로 연결하겠습니다.

• 대기업에게 좋은 점 : 일부 회사는 도약을하는 이유 ... 그리고 다른 회사 는 Jim Collins 가하지 않는 이유
• 최고 속도 : 시장 리더가 운영 우수성을 활용 하여 Steven Spear 의 경쟁 을이기는 방법
• W. Edwards Deming의 산업, 정부, 교육 을 위한 새로운 경제학

소프트웨어 및 IT 조직의 경우 고성능 조직이되기위한 중요한 요소 중 하나는 품질과 속도에 중점을 둡니다 .

예를 들어 Ward Cunningham은 기술 채무에 대해 우리가 고쳐 놓지 않은 모든 것을 설명합니다 . 이것은 시간이있을 때 수정 될 것이라는 약속이 항상 있기 때문에 경영진에 의해 수용됩니다.

시간이 충분하지 않고 기술 부채가 점점 악화되고 있습니다.

기술 부채가 증가하는 원인은 무엇입니까?

• 레거시 코드
• 환경의 수동 구성
• 수동 테스트
• 수동 배포

레거시 코드 Michael Feathers의 레거시 코드 로 효과적으로 작업에 정의 된대로 자동화 된 테스트가없는 코드가 있습니다.

코드를 프로덕션으로 가져 오는 데 언제든지 단축키가 사용됩니다. 운영은이 부채를 영원히 유지해야합니다. 그러면 배포 프로세스가 점점 길어집니다.

Gene은 6 주 동안 배포 한 회사에 대한 프레젠테이션에서 이야기를 전합니다. 400 명을 묶는 수만 건의 극도로 오류가 많은 지루한 단계가 포함되어 있으며 매년 4 번이 작업을 수행합니다.

DevOps의 장점 중 하나는 안정성이 소규모 배포를 더 자주 수행한다는 것입니다.

예

• Velocity 2011의 Jon Jenkins : 아마존은 하루 15k 배포를 수행 합니다.
• AWS Summit 2015의 Ken Exner : Amazon은 하루 136k 배포를 수행 합니다.

이 두 프레젠테이션은 Amazon이 코드를 프로덕션에 배포하는 데 걸리는 시간을 단축하기 위해 수행 한 모든 작업을 보여줍니다.

Gene에 따르면이 고성능 조직에서 시간이 지남에 따라 변경되는 유일한 것은 개발자 수입니다. 따라서 아마존 사례에서 4 년 만에 더 많은 사람을 추가함으로써 배포가 10 배 증가했다고 말할 수 있습니다.

이는 특정 조건 하에서 올바른 아키텍처, 올바른 기술 관행, 올바른 문화적 규범에 따라 개발자 수가 증가함에 따라 개발자 생산성 이 확장 될 수 있음을 의미합니다. 그리고 DevOps는 분명히이 모든 것의 중간에 있습니다.

내가 한 일은 (이것은 주관적입니다) 다음과 같습니다.

마감일을 생각하는 관리자가 필요한 시간을 줄이기 위해 팀에 사람들을 추가하고 MMM 아래에있는 것처럼 보일 때, 나는 왜 이것이 나쁜지에 대해 그와 이야기합니다. 내가 가장 좋아하는 비유는 한 여성이 9 개월 안에 아기를 낳을 수 있다면 9 명의 여성은 한 달에 1 명의 아기를 낳지 않지만 9 개월 동안 9 명의 아기를 낳을 것이라는 점을 상기시키는 것입니다. 시간이 단축되지 않고 병렬 처리가 더 좋습니다.

결정이 우리 팀에 강제 될 때, 우리는 일반적으로 하나 더 나누기에 일부 작업을 시도하고 이것이 가능하지 않을 때 우리는 일반적으로에 의존 페어 프로그래밍 한 프로그래머가 입력에 대한 책임, 그리고 다른 지시 코드 (그리고 주기적으로 전환 ).

코드 작성 자체는 느리지 만, 작성하는 동안 불가피한 검토로 인해 테스트 할 때 오타 / 린트 및 버그가 줄어 듭니다. 전반적인 코드 품질도 조금 더 좋다고 생각하지만 그 주장을 뒷받침 할 지표는 없습니다.

CI 관점에서 독점적으로 말하면, 프로젝트에서 작업하는 개발자의 수가 증가하면 일반적으로 같은 지점에서 일하는 사람들이 더 많아집니다.

기존 CI 시스템은 이와 관련하여 확장 성 문제가 있습니다. 대규모 프로젝트 / 팀의 지속적인 통합 확장 방법을 참조하십시오 . . 이것은 신화적인 남자 달 개념을 따라 진행됩니다.

이 질문에 대한 대답에서 제안하는 솔루션은 확장 성이 뛰어난 CI 시스템을 사용하여 규모가 큰 전체 팀을위한 단일 지점 / 트렁크 기반 통합의 진정한 CI로 마이그레이션 할 수 있습니다.

동일한 페이지의 모든 사람이 동일한 자동화 된 도구 / 프로세스와 CI 시스템 자체 내에서 자동화 된 대부분의 QA 검증을 사용하면 역할을 전환하고 팀 구성원간에 집중하는 것이 훨씬 쉬워집니다. 전체 개발 과정이 더 매끄럽고 예측 가능하며 완화되었습니다.

이러한 환경에서 새로운 사람들을 끌어 들이고,보다 숙련 된 팀 구성원들로부터 덜 어려운 작업을 덜어내어 더 어려운 작업을 수행 할 수있게하면 생산성을 높일 수 있습니다.

나는이 모든 것을 신화적인 달의 개념 효과를 진정시키는 것으로 볼 수 있다고 생각합니다.