기술 수준이 다른 팀을 어떻게 관리해야합니까?

나는 내 친구들과 소프트웨어 프로젝트를 진행할 것이며 기술 책임자로 임명되었습니다. 이 사람들 중 어느 것도 나쁜 프로그래머는 아니지만 나는 그들보다 훨씬 더 많은 경험을 가지고 있습니다. 팀원 모두에게 작업을 배포 할 수 있어야하며, 우리가 서로의 발가락을 밟지 않도록해야합니다. 그들이 약속 한 모든 것을 검토 할 필요없이이 프로젝트를 성공적으로 수행하는 데 필요한 상대적으로 높은 품질 및 확장 성 표준을 충족 시킨다는 것입니다.

소규모 관리를 피하면서 어떻게 표준을 유지해야합니까? 다이어그램을 만들고, 코드 검토 일정을 잡고, 그들이 깨뜨릴 수있는 것을 고칠 수 있을지, 또는 TDD 경로로 가서 팀이 만족할 수 있도록 명시적인 테스트를 작성해야한다고 신뢰하는 것으로 충분합니까?

코드 중 일부를 검토하고 서로를 검토하도록해야합니다. 체크인 경찰이 되려는 것이 아니라 가능한 한 자주 피드백을 제공하고자합니다. 검토자가되면 이해를 강화할 수 있습니다. 그들이 당신의 코드를 검토하게하십시오. 모델이 되십시오.

참고 : 연간 검토 중에는 놀라움이 없어야합니다.

무엇보다도 : 가능한 한 다양한 방식으로 기대와 디자인을 전달하십시오. 다이어그램은 일부에게는 좋습니다. 정의 된 인터페이스는 다른 사람들을 위해 작동합니다. 페어 프로그래밍도 가능합니다. 공식적인 코드 검토도 일부 사람들에게 도움이 될 수 있습니다.

나는 또한 가능한 한 많이 자동화를 사용하는 것이 좋습니다 :

• .Net 영역에있는 경우 팀에 NDepend 또는 Resharper 와 같은 도구를 사용하도록 하십시오. 표준 규칙이 마음에 들지 않으면 조정하십시오.
• 실용적으로 테스트를 자동화하십시오.

테스트 케이스 또는 자동화 된 검사 도구가 제대로 설정되어 있지 않다면 논쟁하기가 어렵습니다.

동일한 프로젝트에서 다양한 기술 수준으로 작업하는 경우 몇 가지 문제가 발생합니다. 문제는 언제 처리합니까? 그들은 당신이 그들의 도움을받지 않는 것이 더 나을 수있는 나쁜 코드를 작성하려고합니까? 이것이 개인적인 긴장을 유발할까요? 우정을 끝내시겠습니까? 이 질문은 아무도 당신에게 대답 할 수 없습니다.

모든 사람이 팀에 머물러 있다고 가정하면 과제를 작은 덩어리로 나누고 (더 큰 것은 숙련 된 전문가에게 간다) 가장 숙련 된 개발자는 리팩토링을 완료 할 수 있습니다. QA를 정기적으로 단단하게 실행하십시오. 이것은 어쨌든 현실에서 일어나는 것과 매우 가깝습니다.

가능한 한 잡초를 피하십시오. 어느 팀에서든 리더라면 위기와 큰 그림을 위해 특정 대역폭 덩어리를 저장해야합니다. 다이어그램은 훌륭하고 코딩 표준은 항상 제정이지만 사람들이 서로의 작업을 확인하는 프로세스를 설정하는 것이 더 좋습니다 (교차 테스트, 동료 검토, 페어 프로그래밍). 팀의 모든 사람이 별이 될 필요는 없습니다. 팀은 일반적으로 개인의 약점을 극복 할 수 있습니다.

내가 권장하는 것은 가능한 한 많은 사람들에게 코딩에서 어떤 오류가 발생했는지 알려 주려는 충동에 저항하는 것입니다. 대신 그 자체로 보도록 유도하십시오. 개발 작업에 대한 공동 검토의 일부로 남아 있지만 다른 구성원보다 더 많은 기여를하지 않아야합니다. 대신 사람들이 당신이 보는 것을 보도록 격려하고 당신이 보는 것이 왜 중요한지에 대한 충분한 설명을하도록 추가적인 노력을 기울이십시오.

합리적 업무 중단을 넘어서 중복에 대해 너무 걱정하지 마십시오. 팀원에게 직접 체크인하도록 요청한 다음 의사 소통이 발생했는지 확인할 수 있습니다. 팀은 합의를 달성하기위한 방법으로 서로를 신속하게 조사하기 시작하여 약 20 배 더 쉽게 작업을 수행 할 수 있습니다. 그러면 주요 지역에 동의하지 않을 때 동점자 만 있으면됩니다.

그런 다음 팀을 총괄적으로 보려고 노력하십시오. 각 사람에게는 놀라운 강점과 매혹적인 약점이 있습니다. 이상적으로는 팀의 생산성을 방해하지 않는 방식으로 약점을 극복 할 수있는 기회를 제공하면서 자신의 강점에 맞는 사람들을 대상으로 작업을 시작합니다.

팀 리더십의 궁극적 인 골드 스타는 사람들이 자신의 약점을 인식하여 동기를 부여하고이를 고치기 시작하기에 충분한 정보를 얻도록하는 것입니다.

팀의 모든 사람들이 동의하는 기술 및 도구 세트에 대해 논의하십시오. 어떤 사람들은 팀의 다른 사람들보다 합의 된 도구에 대해 더 많은 경험이있을 수 있으므로 더 많은 경험이있는 사람들은 경험과 지식을 다른 사람들과 기꺼이 공유 할 의지가 있어야합니다.

표준 (예 : 명명 규칙, 코딩 모범 사례 및 폴더 구조)에 대해 토론, 동의, 작성, 모델링 및 전달합니다.

지속적이고 정기적 인 테스트 및 QA 검사를 수행하십시오. 불일치가 발견되면 최대한 빨리 담당자에게 알리십시오.

나는 '팀에서 가장 경험이 많은 사람이 조직하도록하자'라고 말하려고했지만 그 사람인 것처럼 들립니다.

가능하면 프로젝트를 두 수준으로 나눕니다. 응용 계층 / 드라이버 계층은 좋은 분할입니다. 팀 내에서 두 개의 하위 그룹을 구성하고 각 레벨에서 한 사람 씩 해당 레벨을 담당하십시오. 그것은 매우 잘 작동 할 수 있습니다.

그것에 사임하십시오. 그들이 저지른 모든 것을, 특히 일찍 검토해야합니다. 모든 것이 수영으로 가고 있다면 코드를 눈으로 볼 수 있습니다. 검토하는 데는 시간이 많이 걸리지 않으며 일이 잘 진행되고 있다고 확신 할 수 있습니다. 누군가가 세마포어를 잘못 사용하고 있거나 자신의 버전의 라이브러리 함수 또는 일부 광기를 작성하고있을 가능성이 큽니다. 내 경험은 새싹의 코드 문제를 해결하기 위해 코드를 작성하면서 코드를보고 있어야한다는 것입니다.

일반적으로 회사의 기술 책임자는 무엇입니까? 저는 관리자이고 이번 주부터 몇 번이고이 직책을 다시 시작하려고합니다 (초보자 및 다른 사람들이 20 년 및 4 년 ​​경험이있는 팀에 합류하도록 고용).

저는 관리자이며 기술 책임자가 될 수 있습니다 (지난 몇 년 동안 팀 내에서 리더십을 키우기 위해 후자의 역할을 수행했습니다.

• 팀 전체의 기술과 약점을 평가하십시오.
• 성장 계획 수립-초점이 가장 약한 회원을 늘리는 동안 개인과 팀으로서 모두를 성장시키는 데 집중해야합니다.
• 이 계획을 알리고 모든 사람의 기대치를 설정하십시오.
• 팀 전체에 학습 및 검증을 배포하십시오. 당신은 리드로서 저 자신의 작품의 가장 큰 비중을 차지하고 있지만, 그 작품을 배포하면 더 많은 선임 팀원들이 리더로 도움이 될 것입니다.
• 정기적 인 피드백 루프를 만듭니다. 팀 구성원과 만나 진행 상황을 평가하고 피드백을 제공하십시오.
• 성공을 보장하기 위해 필요에 따라 계획을 조정하십시오.
• 누군가가 운동을하지 않고 합당한 도움을 얻지 못하더라도 그들을 밀어 낼 준비를하십시오. 이 과정은 복잡하지만 계획을 세우고 기대치를 설정하고 피드백 루프를 제공하면 훨씬 더 나은 위치에있게됩니다.
• 팀의 사기를 주시하십시오. 이러한 유형의 상황은 팀을 키우거나 찢어 버릴 수있는 좋은 일을 할 수 있습니다. 당신의 리더십 기술과 팀에 대한 투자는 결과를 설정하는 데 먼 길을 갈 것입니다.

"소프트웨어 아키텍처"를 정의 할 때 고려해야 할 사항이 있습니다. 별도로 개발 가능한 모듈을 만드는 것이 선행 설계 및 분석을 수행하는 주요 이유 중 하나입니다. 이러한 유형의 작업을 수행하는 것은 스타일이 좋지 않지만 새로운 개발 방법이 배우는 경우와는 달리 모든 경우에서 작동합니다.

팀에서 가장 경험이 풍부한 개발자 인 저는 여러분의 무거운 코칭을 기대합니다 .

팀이 kanban을 사용하여 작업을 할당 한 다음 하루 종일 각자와 함께 페어 프로그래밍 을합니다.

나쁜 습관이나 그들이 알고 있어야 할 것을 볼 때, 모든 것을 멈추고 화이트 보드에 그립니다.

몇 주가 지나면 팀의 전반적인 기술이 당신에게 다가 갈 것이므로 무거운 코칭을 늦출 수 있습니다.

당신의 입장에서 검토하고 싶은 두 가지 다른 목록이 있습니다.

1. 이 팀을 얼마나 잘 알고 있습니까? 팀원 모두의 강점과 약점을 알고 있습니까? 각 사람을 최대한 활용하는 방법을 알고 있습니까? 모든 사람에게 작품을 비교적 공정하게 나누는 방법을 알고 있습니까? 이러한 종류의 질문은 시간이 지남에 따라이 목록에 변화가있을 수 있다는 점을 이해하고 이해하는 것입니다. 일부 사람들은 자신이 보는 방식을 바꿀 수있는 기술을 개발할 수도 있습니다. 당신이 임명되었을 때 팀의 일부 사람들이 당신에 대해 기대했던 것이 있습니까? 마지막 질문은 사람들이 정직하게 답변하기가 어려울 수 있지만, 그것이 논의되고있는 내용이 일부 개인에게는 매우 쉬운 공격이나 분개를 유발하지 않고 의미있는 방식으로 공개되고 논의 될 수 있다면 많은 도움이 될 수 있습니다 사람들. 그룹 회의에서 개인적인 의견을 구하려고하지 마십시오.

2. 내가 얼마나 잘 알고 있는지 백그라운드에서 어떤 기술 권한을 주장하기 위해 어떤 요소를 사용하고 있습니까? 팀에 어떤 장단점이 있습니까? 정기적으로 참호에 들어갈 것으로 예상됩니까? 팀을 이끄는 데 도움을주기 위해이 팀을 소개하고자하는 관행이 있습니까? 과거 경험에서 기억하고있는 경고 표시가 팀의 작업에 나타나기 시작하는 경우 유용 할 수 있습니다.

어떤면에서 이것은 모두 의사 소통으로 귀결됩니다. 행운을 빕니다!

일부 기술 주제를 정기적으로 (매주) 발표하고 그룹을 중심으로 회전 시키십시오. 그렇게하면 모든 사람이 무언가를 배우게됩니다. 그리고 젊은 회원들도 함께 발표 할 수 있도록 가르치는 것보다 실제로 무언가를 이해하는 더 좋은 방법은 없습니다. 그들이 주제를 선택하도록 도와야 할 수도 있습니다.

대화하는 방법에 대한 코칭은 모두에게 도움이 될 수 있습니다. 나는 대학에서 교수님이 나를 위해 그것을했고 매우 도움이되었습니다.