Fred Brooks의 "외과 팀"은 버스 요소를 효과적으로 처리합니까?

4 명의 숙련 된 개발자로 구성된 팀은 대형 모듈 식 Windows 응용 프로그램 (약 200KLoC)에서 작업합니다. 프로젝트를 시작한 이래 (3 년 전) 핵심 코드베이스에 중점을 두 었으며 팀 관리자는 아니지만 점차 반납 개발자 위치로 전환했습니다.

현재 반복은 상위 코드 관리에 의해 요청 된 우선 순위가 높은 UI 새로 고침이며 핵심 코드베이스에 대한 약 15 개의 변경이 포함됩니다. 관리자의 요청에 따라 15 개의 변경 사항 을 완료 하는 데 4 시간 미만 , 총 7 일 미만 이 소요될 것으로 예상했습니다 . 나는 그 일을 수행하기 위해 자원했다. 대신, 관리자는 15 개의 작업을 4 명의 개발자 모두에게 고르게 분배하기로 결정했습니다.

일을 시작한 지 3 일 만에 두 가지를 관찰했습니다.

1. 경험이없는 다른 팀원은 각각 약 1 개 이하의 작업을 완료했습니다.

2. Brook의 법칙 : 저는 약 절반의 시간을 지원을 제공하는 데 보냈습니다 (구성 요소 사용에 대한 코치를 시도 함). 결과적으로 5 또는 6이 아닌 2 개의 작업 만 완료했습니다.

나는 우리가 늦게 달리고 있다는 우려로 관리자에게 접근하여 나머지 작업을 완료 할 것을 다시 제안했습니다. 나의 요청은 친절하게 거절되었고, 부하를 고르게 나누는 이유는 두 가지였다.

1. 트럭 / 버스 요소를 제한하십시오. 이제 다른 개발자가 이러한 기술을 익히도록해서 앞으로 모든 작업을 나뿐만 아니라 다른 사람에게도 줄 수 있습니다.
2. "병목 현상"(me)을 제거하고 작업을 더 빠르게 수행합니다.

분명히, 나는 a) 시간 교육에 투자, b) 내 코드를 만지는 사람들, 또는 c) 직업 보안에 문제가 없습니다. 실제로, 나는 정기적으로 팀 리더에게 위험을 줄이기 위해 핵심 코드베이스의 특정 측면에 대해 다른 개발자를 훈련시킬 것을 제안합니다.

이 반복에서는 우선 순위가 높은 버그 수정 모음도 다수 있으므로 워크로드가 재분배되면 더 많은 진전이있을 수 있습니다.

Mythical-Man-Month에서 Brooks '는 모든 팀이 리드 + 하위 리더 (관리자 및 저)와 몇 가지 사소한 역할로 구성된 " 수술 팀 "을 제안 합니다. 마치 우리가이 조직에 자연스럽게 빠져있는 것처럼 느껴지지만 관리자가 반대하고 있습니다. 나는 버스 요소가 이미 처리되어 있고 (관리자는 핵심 코드에 정통하고) 병목 현상이 실제로 존재하지 않는다고 생각합니다 (더 많은 개발자가 참여해도 작업 속도가 빨라지지는 않습니다). 이와 관련하여 외과 팀은 좋은 일이라고 생각합니다.

이것들은 내 감정이지만, 숙련 된 관리자는 아니며, 버스 요소 (나무를 두드리는 소리)를 다루지 않아도됩니다. 브룩스가 맞았 어? 버스 팩터가 작동하는 "외과 팀"에서 일했습니까? 분산 전문 지식을 관리하는 더 나은 기술이 있습니까?

유제:

• 버스 팩터를 늘리고 동시에 전문화하는 방법은 무엇입니까?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

사실, 나는 당신이 "외과 팀"모델을 따르고 있다고 주장합니다. 럭키!

상기 모델의 요점 중 일부는 하위 팀 구성원이 보조 역할을한다는 것입니다. 팀이 심장 수술을하지 않을 때는 느리게 움직여 기술을 연습하거나 책임을지는 훈련을하는 것이 좋습니다.

팀의 약점을 찾아 해결하고 최고의 개발자가되어 팀을 검사하고 관리하는 것은 외과의의 임무입니다. 비 외과 의사 (비즈니스 관리자)는이를 수행 할 수 없습니다. 마스터 장인의 견습생과 같은 필요한 기술을 이해하지 못하기 때문입니다.

따라서 관리자는이 기회를 활용하여 다른 목표 중 하나를 수행합니다. 그 과정에서 팀에 결함이 드러나면 문제가 발생하기 전에 처리 할 수 ​​있습니다. 다른 개발자를 고용하여 말하십시오.

또는 주니어가 실수를 할 수도 있습니다. 그들은 누군가가 그들의 어깨 너머로보고 있기 때문에 그렇게하기에 완벽한 시간입니다. 오스카 와일드는 말했다

경험은 단순히 우리가 실수하는 이름입니다.

이 후배들 에게 실수 할 기회가 없다면 , 그들은 결코 향상되지 않을 것입니다. 숙련 된 미래의 개발자로 구성된 팀을 강탈 할뿐만 아니라 어떤 식 으로든 그들이 가질 기회를 빼앗습니다.

우리 회사는 당신이 제안한 것처럼 일했었습니다. 코드의 중요한 부분을 이해 한 사람은 두 명뿐이었습니다. 다른 사람의 속도를 높이는 데 몇 주가 걸리지 않고 코드의 해당 부분에서 작업이 시작될 때마다 작업이 며칠 내에 완료 될 수 있기 때문에 작업이 할당됩니다. 이것은 실제로 한동안 꽤 잘 작동했습니다.

결국 2 일 안에 작업을 완료 할 수 있었지만 목록의 맨 위로 이동하는 데 몇 주가 걸렸습니다. 관리자들은 그 과제가 더 시급한 언어 싸움을했을 것입니다. 긴급한 작업은 취소 될 수 있습니다.

결국 관리자들은 기다리다가 자신의 팀을 훈련시키기 시작했습니다. 예, 그것은이었다 많은 느린 잠시 동안,하지만 지금 우리의 처리량이 훨씬 낫다.

작업을 처리 할 수있는 첫 번째 단계에있을 수 있지만 두 번째 단계로 이동할시기를 예측할 방법이 없습니다. 힌트는 다음과 같습니다. 항상 가장 불편한 시간에 발생합니다. 호흡 실이 남아있을 때 관리자가 적중 할 권리가 있습니다.

그렇습니다. 누군가 자신이 훨씬 더 쉽고 빠르게 할 수있는 일로 어려움을 겪는 것을 보는 것은 실망 스럽습니다. 언젠가는 두 살짜리 육아를 시도하십시오. 팀 전체를 향상시키는 데 도움이되기 때문에 그렇게합니다. 일정에 대해 걱정하는 것은 관리자의 임무입니다. 실행 취소 된 우선 순위가 높은 버그에 대해 걱정이되는 경우 얼마나 빨리 버그를 해결할 수 있는지 확인하십시오.

당신은 지금 병목이되지는 않을지 모르지만, 결국 모든 일을 스스로 계속한다면 당신은 결국 당신이 될 것입니다. 관리자는 프로젝트가 늦을 위험을 감수하기 위해 위임하는 것을 배우는 것이 중요하다는 것을 알고 있습니다. 놓아주는 법을 배우면 후배들은지도하에 배우고 훨씬 더 많이 생산하기 시작할 것입니다.

존재하지 않거나 생각한 정도만큼 중요하지 않은 구속 조건을 적용하고 있습니다. 특히, 완료까지의 시간이 걱정됩니다. 반면에 관리자는 인식 된 시간 제약 조건과 관련하여 나타나지 않습니다.

배송 시간을 질문에서 제외하면 처음에 왜 질문을하는지 궁금해지기 시작합니다.

그것은 시간이 항상 가능하다는 것을 말하는 것이 아니며, 이것이 고위 경영진의 우선 순위가 높은 요청이라고 말한 것입니다. 그러나 당신은 당신의 상사가 그들과 맺은 모든 대화에 대해 특권이 아닙니다. 그는 당신이 그 팀의 다른 멤버들을 훈련시키는 데 그 시간을 보내기 위해 더 많은 시간을 협상했을 수도 있습니다.

그리고 버스 요인이 이미 해결되었다고 생각하는 동안, 상사는 스타 개발자 중 한 사람이 7 일 동안 쉽게 처리 할 수없는 다음 요청을 찾고있을 수 있습니다 . 객관적인 위험 규모가 훨씬 작은 소규모 반복에 대해 팀을 교육하는 것이 훨씬 안전합니다.

나는 전에 병목 현상이 있었다; 솔직히 말해서 즐거운 곳이 아닙니다. 필자의 경우 IT 부사장과 이야기를 나 and으며 문제를 영구적으로 해결할 계획을 세웠습니다. 그것은 아 but지만 내가 트럭을 than 때보 다 훨씬 덜 아 hurt습니다.

가능한 한 빨리 기절해야하는 모든 것의 사고 방식에 쉽게 도달 할 수 있습니다. 훌륭한 관리자는 약간의 지연 (교차 훈련 / 교육)이 나중에 상당한 배당금을 지불 할 수있는 드문 기회를 발견합니다.