엔지니어는 몰입하여 집중할 수 있는 환경에서 번창합니다. 팀은 종종 엔지니어가 컨텍스트를 전환하고 주의를 분산하도록 하는 산만함 및 경쟁 우선 순위에 직면합니다. 그들은 집중 근무 시간과 주의 분산 시간의 균형을 맞추는데 어려움을 겪고 있다. 새 기능을 추가하려면 팀 구성원이 고개를 숙이고 집중해야 합니다. 고객 문제에 대응하고 라이브 사이트 문제를 해결하려면 팀이 무슨 일이 일어나고 있는지 알고 있어야 합니다.
산만함을 줄이기 위해 팀은 두 개의 팀으로 나눌 수 있습니다. 하나는 기능을 위한 것이고 다른 하나는 라이브 사이트 상태 유지를 위한 것입니다.
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팀이 축소됩니다. 매주 크기를 조정하면 팀의 결과물 및 종속성에서 예측 가능성이 높아집니다. 몇 주 후에 팀이 모든 사용자를 C-crew로 이동하여 대규모 릴리스의 피드백을 처리할 수 있습니다.
이 전략은 관리와의 통신을 간소화합니다. 2인승 시스템이 없으면 엔지니어는 여러 작업을 동시에 수행하는 경우가 많습니다. 한 주에 몇 가지 방해가 발생하면 진행 중인 기능이 지연되는 경우가 많습니다. 따라서 팀은 향후 기능 작업에 대한 타임라인을 자신 있게 제공하지 못할 수 있습니다.
전담 F-팀은 예측 가능한 처리량과 리드 타임을 제공합니다. 승무원 간에 리소스를 분할하면 팀 내의 책임과 팀이 매주 달성할 수 있는 작업과 각 스프린트에 대한 관리가 강화됩니다.
다음 단계
2인승 시스템은 팀이 엔지니어가 시간을 보내야 하는 위치를 이해하고 많은 경쟁 우선 순위에서 진전을 이룰 수 있도록 도와줄 수 있습니다.
2인승 시스템은 생산성과 예측 가능성을 향상시키는 것 외에도 팀 사기를 높일 수 있습니다. 각 팀의 엔지니어는 자신의 역할과 책임을 명확하게 이해하고 더 독립적으로 훨씬 더 큰 책임으로 작동합니다. 이 접근 방식은 개발 및 운영 모두를 담당하는 DevOps 팀에 이상적입니다. 그러나 이 접근 방식은 경쟁 우선 순위를 다루는 거의 모든 Agile 팀에 적용할 수 있습니다.
Microsoft는 세계에서 가장 큰 Agile 회사 중 하나입니다. Microsoft가 DevOps 계획에서 팀을 구성하는 방법을 알아봅니다.