생산적인 팀 구축

엔지니어는 영역에 집중하고 얻을 수 있는 환경에서 번창합니다. 팀은 종종 엔지니어가 컨텍스트를 전환하고 주의를 분산하도록 하는 산만함 및 경쟁 우선 순위에 직면합니다. 그들은 머리 가동 시간과 머리 다운 시간의 균형을 투쟁. 새 기능을 추가하려면 팀 구성원이 고개를 숙이고 집중해야 합니다. 고객 문제에 대응하고 라이브 사이트 문제를 해결하려면 팀이 무슨 일이 일어나고 있는지 알고 있어야 합니다.

산만을 완화하기 위해 팀은 두 명의 승무원으로 나눕니다. 하나는 기능용이고 다른 하나는 라이브 사이트 건강을 위한 것입니다.

2인승 접근 방식은 생산성과 예측 가능성을 높입니다. 성공적인 구현은 다음 주요 요소를 사용합니다.

• 명확하게 정의된 승무원 역할
• 잘 정의된 승무원 회전 프로세스
• 승무원 크기에 대한 빈번한 조정

기능 승무원

기능 승무원, 또는 F-승무원, 미래에 초점을 맞추고. 그들은 명확한 임무와 목표를 가진 효과적인 단위로 작동 : 구축하고 고품질의 기능을 제공합니다.

F-승무원은 라이브 서비스의 일상적인 혼란으로부터 보호되어 작업을 설계, 빌드 및 테스트할 시간이 있는지 확인합니다. 그들은 최소한의 산만에 의존 하 고 무작위로 발생 하는 문제를 해결 하는 데에서 자유에 의존할 수 있습니다. 그들은 거의 자신의 이메일을 검사 그들이 중요하지 않은 한 다른 문제에 당겨하지 않도록하는 것이 좋습니다.

F-승무원 구성원이 대화에 참여하거나 때때로 이메일 스레드에 빨려 들어가면 다른 팀원들은 "당신은 F-승무원에 있어, 뭐하는거야?" 하고 조롱해야 합니다. F-승무원 구성원이 중요한 문제를 해결해야 하는 경우 고객 승무원에게 위임하고 기능 작업으로 돌아가는 것이 좋습니다.

F-승무원은 작은 기능 세트에 무리 꽉 뜨개질 팀으로 작동합니다. WIP(작업 진행 중) 제한은 4~6명에게 제공되는 두 가지 기능입니다. 긴밀하게 협력하여 심층 공유 컨텍스트를 구축하고 커서 코드 검토에서 놓칠 수 있는 중요한 버그 또는 디자인 문제를 찾습니다. 전용 승무원을 사용하면 더 예측 가능한 처리량 속도 및 리드 타임을 사용할 수 있습니다. 팀원들은 종종 F-승무원을 고요하고 집중적인 것으로 지칭합니다. 그들은 평화롭고 젊어지게 기능에 깊이 초점을 맞추고, 그것에 전적으로 주의를 기울입니다. 사람 F 승무원에게 시간을 내어 상쾌하고 성취감을 느낍니다.

고객 승무원

고객 승무원 또는 C-승무원은 현재에 중점을 두고 고객 및 라이브 사이트 문제, 버그, 원격 분석 및 모니터링에 대한 최전방 지원을 제공합니다. C-승무원은 종종 컴퓨터 주위에 모여 중요한 라이브 사이트 문제를 디버깅합니다. 가장 우선 순위는 라이브 사이트 상태입니다. 이 환경에 초점을 맞춘 레이저는 전문가 디버깅 및 분석 기술을 구축합니다. 고객 승무원은 팀의 나머지 부분을 방해로부터 보호하기 때문에 종종 방패 팀이라고합니다. C-crew는 예정된 기능을 작업하는 대신 고객과 현재 제품 간의 다리입니다. 승무원은 이메일, 트위터 및 기타 피드백 채널에서 활성 상태입니다. 고객은 그들이 들었다는 것을 알고 싶어하며, C-승무원의 임무는 그들을 듣는 것입니다. C-승무원은 고객이 보고한 문제를 즉시 심사하고 신속하게 차단된 고객을 참여시키고 지원합니다.

들어오는 작업의 홍수와 함께, 빠르게 진행되는 C-승무원에 작업, 때때로, 흥분 될 수 있습니다. 바쁜 한 주 동안 여러 이메일, 라이브 사이트 조사 및 버그를 처리합니다. 작업이 조용해짐에 따라 원격 분석 및 보고를 개선하고 서비스 유지 관리를 더 쉽게 하기 위해 시간을 투자합니다.

C-승무원은 팀이 다른 우선 순위에서 팀 구성원을 끌어들이지 않고 문제를 해결하고 고객과 파트너가 들을 수 있도록 합니다. 질문과 문제에 대한 응답성은 C-승무원에게 자부심의 포인트가 됩니다. 그러나 이 속도는 배수될 수 있으므로 승무원 간에 자주 회전해야 합니다.

승무원 회전

잘 정의된 회전 프로세스를 통해 2인승 시스템이 작동합니다. 단순히 승무원을 교환 할 수 있지만 (F-승무원은 C 승무원이되고 그 반대의 경우도 마찬가지입니다), 그러나 이것은 승무원 간의 지식 공유를 제한합니다. 대신 주간 회전을 선택합니다.

매주 말에 팀이 승무원 간에 교체할 사람을 결정하는 짧은 스왑 회의를 진행합니다. 화이트보드 차트를 사용하여 각 승무원의 현재 사용자와 교환된 시기를 추적할 수 있습니다. 각 승무원에서 가장 긴 임기의 사람들은 일반적으로 서로 교환해야합니다. 그러나 특정 주에 누군가가 다시 기본 라이브 사이트 조사 또는 기능에 대한 작업을 완료하기를 원할 수 있습니다. 유연성이 있지만, 누군가가 승무원에 오래 있을수록 교체해야 할 가능성이 높습니다.

주간 회전은 팀의 지식 사일로를 방지하고 승무원 간의 정보와 관점의 지속적인 흐름을 보장하는 데 도움이 됩니다. 엔지니어의 빈번한 이동은 팀의 작업에 대한 공유 지식을 만들어 C-승무원이 다른 사람의 도움없이 문제를 해결하는 데 도움이됩니다. 종종 새로운 F-승무원 구성원은 이전에 간과 된 디자인이나 코드 결함을 신속하게 찾을 수 있습니다.

승무원 크기

승무원 크기는 팀의 건강을 기본 따라 다릅니다. 팀이 라이브 사이트 문제의 수신률이 높거나 기술적인 부채가 많은 경우 C-승무원은 더 커지고 그 반대의 경우도 마찬가지입니다. 매주 크기를 조정하면 팀의 결과물 및 종속성에서 예측 가능성이 높아집니다. 몇 주 후에 팀이 모든 사용자를 C-crew로 이동하여 대규모 릴리스의 피드백을 처리할 수 있습니다.

이 전략은 관리와의 통신을 간소화합니다. 2인승 시스템이 없으면 엔지니어는 여러 작업을 동시에 수행하는 경우가 많습니다. 한 주에 몇 가지 방해가 발생하면 진행 중인 기능이 지연되는 경우가 많습니다. 따라서 팀은 향후 기능 작업을 위해 타임라인 자신 있게 제공하지 못할 수 있습니다.

전용 F-승무원은 예측 가능한 처리량 및 리드 타임으로 이어집니다. 승무원 간에 리소스를 분할하면 팀 내의 책임과 팀이 매주 달성할 수 있는 작업과 각 스프린트에 대한 관리가 강화됩니다.

다음 단계

2인승 시스템은 팀이 엔지니어가 시간을 보내야 하는 위치를 이해하고 많은 경쟁 우선 순위에서 진전을 이룰 수 있도록 도와줄 수 있습니다.

2인승 시스템은 생산성과 예측 가능성을 향상시키는 것 외에도 팀 사기를 높일 수 있습니다. 각 팀의 엔지니어는 자신의 역할과 책임을 명확하게 이해하고 더 독립적으로 훨씬 더 큰 책임으로 작동합니다. 이 접근 방식은 개발 및 운영 모두를 담당하는 DevOps 팀에 이상적입니다. 그러나 이 접근 방식은 경쟁 우선 순위를 다루는 거의 모든 Agile 팀에 적용할 수 있습니다.

Microsoft는 세계에서 가장 큰 Agile 회사 중 하나입니다. Microsoft가 DevOps 계획에서 팀을 구성하는 방법을 알아봅니다.