다음을 통해 공유


생산적인 팀 구축

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

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

Illustration of feature crew and customer crew working together.

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 계획에서 팀을 구성하는 방법을 알아봅니다.