다음을 통해 공유

Microsoft에서 DevOps를 사용하여 계획하는 방법

  • 아티클

Microsoft는 Agile 방법론을 사용하는 세계에서 가장 큰 회사 중 하나입니다. 수년간의 경험을 통해 Microsoft는 Windows와 같은 대규모 노력을 통해 가장 작은 프로젝트에서 확장되는 DevOps 계획 프로세스를 개발했습니다. 이 문서에서는 Microsoft가 회사 전체에서 소프트웨어 프로젝트를 계획할 때 구현하는 많은 교훈과 사례를 설명합니다.

도구 변경

다음 주요 변경 사항은 개발 및 배송 주기를 더 건강하고 효율적으로 만드는 데 도움이 됩니다.

  • 문화적 맞춤과 자율성을 촉진합니다.
  • 개인에서 팀으로 포커스를 변경합니다.
  • 새로운 계획 및 학습 전략을 만듭니다.
  • 다중 승무원 모델을 구현합니다.
  • 코드 상태 사례를 개선합니다.
  • 투명성과 책임을 촉진합니다.

문화적 맞춤 및 자율성 촉진

피터 드루커는 "문화는 아침 식사를 위한 전략을 먹는다"고 말했다. 자율성, 숙달 및 목적은 인간의 주요 동기입니다. Microsoft는 성공적인 제품을 빌드할 수 있는 권한이 있다고 느낄 수 있도록 이러한 동기를 PM, 개발자 및 디자이너에게 제공하려고 합니다.

이 접근 방식의 두 가지 중요한 기여자 맞춤과 자율성입니다.

  • 맞춤은 개인과 팀이 자신의 책임이 더 넓은 비즈니스 목표에 어떻게 부합하는지 이해할 수 있도록 위에서 아래로 정렬됩니다.
  • 자율성은 개인과 팀이 일상적인 활동 및 의사 결정에 영향을 미칠 수 있도록 처음부터 발생합니다.

맞춤과 자율성 사이에는 섬세한 균형이 있습니다. 맞춤이 너무 많으면 사람들이 말하는 대로만 수행하는 부정적인 문화를 만들 수 있습니다. 자율성이 너무 많으면 구조나 방향이 부족하고, 의사 결정이 비효율적이며, 계획이 잘못될 수 있습니다.

개인에서 팀으로 포커스 변경

Microsoft는 사용자와 팀을 PM, 디자인 및 엔지니어링의 세 그룹으로 구성합니다.

  • PM은 Microsoft가 빌드하는 내용과 그 이유를 정의합니다.
  • 디자인은 Microsoft에서 빌드하는 것을 디자인하는 일을 담당합니다.
  • 엔지니어링은 제품을 빌드하고 품질을 보장합니다.

Microsoft 팀에는 다음과 같은 주요 특징이 있습니다.

  • 교차 징계
  • 10~12명
  • 자체 관리
  • 12-18 개월 동안 헌장 및 목표 지우기
  • 실제 팀 룸
  • 자체 기능 배포
  • 프로덕션에서 고유한 기능

수직 팀을 위해 노력

Microsoft 팀은 모든 UI, 모든 데이터 또는 모든 API를 포함하는 가로로 사용되었습니다. 이제 Microsoft는 수직 팀을 위해 노력하고 있습니다. Teams는 제품 엔드 투 엔드의 영역을 소유합니다. 특정 계층의 엄격한 지침은 제품 전체의 팀 간에 균일성을 보장합니다.

다음 다이어그램은 수평 팀과 수직 팀의 차이를 개념화합니다.

Diagram showing horizontal and vertical team structures.

자체 선택 팀 허용

약 18개월마다 Microsoft는 개발자가 다음 몇 가지 계획 기간 동안 작업하려는 제품의 영역을 선택할 수 있는 "노란색 고정 연습"을 실행합니다. 이 연습에서는 팀이 작업할 작업을 선택할 수 있고 조직 조정이 팀 간의 균형을 촉진하므로 자율성을 제공합니다. 이 연습에 참가한 사람들의 약 80%가 현재 팀에 기본 있지만, 선택의 여지가 있었기 때문에 힘을 얻었다고 느낍니다.

새 계획 및 학습 전략 만들기

드와이트 아이젠하워는 "계획은 쓸모가 없지만 계획은 전부입니다." Microsoft 계획은 다음 구조로 나뉩니다.

  • 스프린트(3주)
  • 계획(3 스프린트)
  • 시즌(6개월)
  • 전략(12개월)

엔지니어와 팀은 주로 스프린트와 계획을 담당합니다. 리더십은 주로 계절과 전략을 담당합니다.

다음 다이어그램에서는 Microsoft 계획 전략을 보여 줍니다.

Diagram showing Microsoft planning strategy.

이 계획 구조는 계획을 수행하는 동안 학습을 최대화하는 데도 도움이 됩니다. Teams는 피드백을 받고, 고객이 원하는 것을 파악하고, 고객 요청을 신속하고 효율적으로 구현할 수 있습니다.

다중 승무원 모델 구현

이전 방법은 버그 및 라이브 사이트 인시던트에 대한 "인터럽트 문화"를 조성했습니다. Microsoft 팀은 포커스를 제공하고 방해를 피할 수 있는 고유한 방법을 마련했습니다. 팀은 각 스프린트에 대해 기능(F-승무원)과 고객(C-승무원)이라는 두 명의 고유한 승무원으로 자체 구성합니다.

F-승무원은 헌신적 인 기능을 작동하고, C-승무원은 라이브 사이트 문제와 중단을 다룹니다. 팀은 구성원이 활동을 보다 쉽게 계획할 수 있는 회전 주기를 설정합니다. 다중 승무원 모델에 대한 자세한 내용은 고객 중심의 생산적인 팀 빌드를 참조 하세요.

코드 상태 연습 개선

Agile 방법론으로 전환하기 전에 팀은 개발 단계가 끝날 때 코드가 완료될 때까지 코드 버그를 빌드하도록 하는 데 사용했습니다. 그런 다음 팀은 버그를 발견하고 수정하는 작업을 수행했습니다. 이 연습은 버그의 롤러 코스터를 만들어 팀이 새로운 기능을 구현하는 대신 버그 수정 작업을 해야 할 때 팀의 사기와 생산성에 영향을 줍니다.

이제 Teams는 수식# of engineers x 5 = bug cap으로 계산된 버그 한도를 구현합니다. 팀의 버그 수가 스프린트 종료 시 버그 한도를 초과하는 경우 새로운 기능에 대한 작업을 중지하고 한도에 있을 때까지 버그를 수정해야 합니다. 이제 팀은 버그 부채를 갚습니다.

투명성 및 책임 강화

각 스프린트가 끝나면 모든 팀은 이전 스프린트에서 수행한 작업과 다음 스프린트에서 수행할 계획을 보고하는 메일을 보냅니다.

목표 및 주요 결과(OKR)

팀은 조직이 달성하려는 목표를 명확히 할 때 가장 효과적입니다. Microsoft는 목표 및 주요 결과(OKR)를 통해 팀에 명확성을 제공합니다.

  • 목표는 달성할 목표를 정의합니다. 목표는 중요하고 구체적이며 행동 지향적이며 이상적으로 영감을 주는 의도 진술입니다. 목표는 실제 숫자가 아니라 큰 아이디어를 나타냅니다.
  • 주요 결과는 목표를 달성하는 단계를 정의합니다. 주요 결과는 진행률을 평가하고 특정 기간의 목표에 대한 성공을 나타내는 정량화 가능한 결과입니다.

OKR은 가장 가능성이 큰 결과뿐만 아니라 최상의 결과를 반영합니다. 지도자들은 야심차고 신중하지 않으려고 노력합니다. 팀이 도전적인 핵심 결과를 추구하도록 밀어붙이면 목표에 대한 가속이 가속화되고 더 큰 목표를 향해 나아가는 작업의 우선 순위가 지정됩니다.

OKR 프레임워크를 채택하면 팀이 다음과 같은 이유로 더 나은 성능을 발휘할 수 있습니다.

  • 모든 팀이 계획에 맞춰집니다 .
  • Teams는 활동을 완료하는 대신 결과를 달성하는 데 집중 합니다 .
  • 모든 팀은 정기적으로 노력에 대한 책임이 있습니다.

OKR은 제품의 다른 수준에 있을 수 있습니다. 예를 들어 최상위 제품 OKR, 구성 요소 수준 OKR 및 팀 수준 OKR이 있을 수 있습니다. 특히 목표가 하향식으로 설정된 경우 OKR을 정렬된 상태로 유지하는 것이 비교적 쉽습니다. 발생하는 모든 충돌은 조직의 잘못된 정렬에 대한 중요한 초기 지표입니다.

OKR 예시

목표: 강력하고 행복한 고객 기반을 성장합니다.

주요 결과:

  • 외부 NPS(순 프로모터 점수)를 21에서 35로 늘입니다.
  • 문서 만족도를 55에서 65로 늘립니다.
  • 새 파이프라인 흐름의 Apdex 점수는 0.9입니다.
  • 작업에 대한 큐 시간은 5초 이하입니다.

OKR에 대한 자세한 내용은 목표 및 주요 결과를 사용하여 비즈니스 결과 측정을 참조하세요.

올바른 메트릭 선택

키 결과는 기반으로 하는 메트릭만큼만 유용합니다. Microsoft는 변화에 초점을 맞춘 선행 지표를 사용합니다. 시간이 지남에 따라 이러한 메트릭은 제품 가속 또는 감속의 작업 그림을 작성합니다. Microsoft는 종종 다음 메트릭을 사용합니다.

  • 채택의 월별 증가율 변경
  • 성능 변경
  • 학습 시간 변경
  • 인시던트 빈도 변경

Teams는 목표에 대한 값이 누적되지 않는 메트릭을 방지합니다. 특정 용도가 있을 수 있지만 다음 메트릭은 목표에 대한 진행 상황을 추적하는 데 도움이 되지 않습니다.

  • 원래 예상치의 정확도
  • 완료된 시간
  • 코드 줄
  • 팀 수용작업량
  • 팀 번다운(burndown)
  • 팀 개발속도
  • 발견된 버그 수
  • 코드 검사

Agile 이전 및 Agile 이후

다음 표에서는 Agile 사례를 채택할 때 Microsoft 개발 팀이 변경한 내용을 요약하여 설명합니다.

이전 이후
4-6개월 마일스톤 3주 스프린트
수평 팀 수직 팀
개인 사무실 팀 룸 및 원격 작업
긴 계획 주기 지속적인 계획 및 학습
PM, 개발 및 테스트 PM, 디자인 및 엔지니어링
연간 고객 참여 지속적인 고객 참여
기능 분기 모든 사용자가 기본 분기에서 작동합니다.
20명 이상의 개인 팀 8-12인 팀
비밀 로드맵 공개적으로 공유된 로드맵
버그 부채 부채 0개
100페이지 분량의 사양 문서 PowerPoint 사양
프라이빗 리포지토리 오픈 소스 또는 InnerSource
심층 조직 계층 구조 평면화된 조직 계층 구조
설치 번호는 성공을 정의합니다. 사용자 만족도는 성공을 정의합니다.
1년 1회 기능 제공 기능은 모든 스프린트를 제공합니다.

핵심 내용

  • 민첩한 과학을 진지하게 받아들이지만 지나치게 규범적이지는 않습니다. Agile은 너무 엄격해질 수 있습니다. 민첩한 사고방식과 문화가 성장하도록 합시다.
  • 활동이 아닌 결과를 축하합니다. 기능 배포는 코드 줄보다 큽니다.
  • 리듬과 주기를 설정하고 수행해야 할 모든 작업을 찾기 위해 모든 스프린트에서 배송.
  • 원하는 동작을 가져올 문화권을 구축합니다.