1-3 명의 개발자로 구성된 팀이 10 명 이상으로 성장하면 어떤 관리 / 개발 관행을 변경합니까?


14

우리 팀은 몇 년 전에 고객을 위해 웹 사이트를 구축했습니다. 사이트 taffic은 매우 빠르게 성장하고 있으며 고객은 유지 관리 및 기능 요청 요구를 충족시키기 위해 팀을 키울 것을 요청했습니다.

우리는 소수의 개발자로 시작했으며 팀이 성장했습니다. 이제 우리는 두 자리 수입니다.

팀이 소규모 "차고 규모"팀에서 10 명 이상의 개발자로 성장할 때 가장 유용한 관리 / 개발 변경 사항은 무엇입니까?


1
질문의 관리 부분을 분리하여 pm.stackexchange.com
blueberryfields

2
팀은 이전에 어떤 관리 관행을 사용 했습니까?
chrisaycock 2018

원래는 2 명의 시니어 레벨 개발자가 있었기 때문에 대개 이야기 만합니다. 팀과 프로젝트가 성장함에 따라 주니어 개발자가 있었기 때문에 WIKI, 버그 추적 시스템, 소스 제어 등을 도입했습니다. 이제 팀이 너무 커서 한 명의 수석 개발자가 관리 할 수없는 것 같습니다. 작은 팀으로 나누었습니다.
Mag20

커피를 더 사십시오.
haylem

1
좋은 "문제"가 있습니다. 성장하는 팀을 축하합니다!
애자일 스카우트

답변:


8

나는 두 가지 주요 도로가 있다고 말합니다.

  • 팀을 두 개 또는 세 개의 그룹으로 나눕니다. 각 그룹은 특정 필드 / 관점을 담당합니다. 이는 소규모 그룹 내에서 익숙한 방식으로 작업 할 수 있다는 이점이 있습니다.
  • "The Surgical Team"은 신화-남자-월 에서 읽을 수 있습니다 . 또한 이 링크 에는 멋진 그림이 있습니다.

행운을 빕니다!


4

우리는 지난 7 년 동안 약 10에서 거의 200으로 성장했습니다. 가장 먼저 변경해야 할 것은 더 나은 문서화와 표준 프로세스가 필요하다는 것입니다. 요구 사항도 더 공식화되어야 할 수도 있습니다.

또한 성장할 때 전문가를 고용하는 것도 고려해야합니다. 데이터베이스 백엔드가있는 경우 하나 이상의 전용 데이터베이스 전문가가 있어야합니다. 테스터를 위해 돈을 써야 할 것입니다.

더 많은 프로젝트가 진행되고 tham을 관리해야 할 필요성이 커지므로 지금 사용하지 않는 경우 프로젝트 관리 시스템과 버그 추적기가 필요합니다. 배포 작업을 생성하고 배포를 수행 할 사람에게만 프로덕션 권한을 제한해야하며 더 이상 제품을 직접 변경하지 않아도됩니다. 개발자는 제품에 대한 권한 만 선택하도록 제한해야합니다.

팀 규모가 클수록 더 많은 사람들이 문제를 겪고 숙련도가 낮은 사람들을 고용 할 가능성이 높아질 것입니다. 최고의 인재를 얻으려고 노력할수록, 더 많이 고용할수록 더 멍청해질 수 있으므로 사람들도 갈 수 있도록 준비하십시오.

사람들 간의 조정이 핵심입니다. 제품을 상호 배타적으로 변경하는 두 팀은 나쁜 일입니다.

2 ~ 3 명의 개발자 만 있으면 후배를 가질 여유가 없습니다. 모두가 상급 수준에서 일해야합니다. 개발자가 많으면 후배를 가질 여유가 없습니다. 중학교를 고용하고 원하는 방식으로 훈련 시키십시오. 일반적으로 같은 수준에서 경력을 쌓지 못한 곳에서 일하는 것이 좋습니다.

팀이 성장함에 따라 많은 현재 개발자가 새로운 관리 직원이 될 것입니다. 어떤 사람들은 그것을 싫어하고, 경영진보다는 선임 개발자에게 승진 기회를 주어야합니다. 경영진에 대한 모든 기술 전문 지식을 잃지 마십시오. 새로운 사람들을 최신 상태로 끌어 올리려면 현재 시스템에 대한 자세한 지식이 필요하기 때문에 관리에 참여하지 않는 사람들에게 보상하십시오.


4

프로젝트가 10 명 이상의 개발자에게 충분히 큰 경우 더 작은 영역으로 쉽게 분류 할 수 있어야합니다. 팀을 각각 3-5 명으로 구성된 소규모 팀으로 나누고 해당 지역에 대한 자율권을 부여하십시오. API는 팀간에 개발되어야합니다. 각 팀이 요구 사항을 파악하도록하고 각 팀의 한 두 사람이 API를 논의하도록 만날 것을 권장합니다. 더 적은 수의 사람들이 참여할 때 더 쉽게 토론하고 결정을 내릴 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.