대규모 팀으로 Agile 스케일링

큰 단어와 Agile은 동일한 문장에서 자주 사용되지 않습니다. 대규모 조직에서는 이동 속도가 느리다는 평판을 얻었습니다. 그러나 이는 변화하고 있습니다. 많은 대규모 소프트웨어 조직이 Agile로 성공적으로 변환하고 있습니다. SAFe, LeSS 또는 Nexus와 같은 인기 있는 프레임워크를 사용하거나 사용하지 않고 Agile 원칙을 확장하는 방법을 배웁니다.

Microsoft에서 이러한 조직 중 하나는 Agile을 사용하여 Azure DevOps 브랜드로 제공되는 제품 및 서비스를 빌드합니다. 이 그룹에는 3주마다 프로덕션으로 릴리스되는 35개의 기능 팀이 있습니다.

Azure DevOps 내의 모든 팀은 처음부터 끝까지 기능을 소유합니다. 고객 관계를 소유하고 있습니다. 자체 제품 백로그를 관리합니다. 코드를 작성하고 생산 분기 검사. 3주마다 생산 분기 배포되고 릴리스가 공개됩니다. 그런 다음, 팀은 시스템 상태를 모니터링하고 라이브 사이트 문제를 해결합니다.

Agile 원칙을 따르는 자율 팀은 생산성이 향상됩니다. Agile 조직은 팀이 일상적인 실행을 제어하기를 원합니다. 그러나 무질서한 자율성은 혼란을 초래할 것입니다. 독립적으로 작업하는 수십 개의 팀은 통합된 고품질 제품을 생산하지 않을 것입니다. 맞춤은 팀에게 목적을 부여하고 조직의 목표를 충족하도록 합니다. 정렬이 없으면 최고의 성적을 거둔 팀조차도 실패할 것입니다.

Agile을 확장하려면 조직과의 연계를 보장하면서 팀에 대한 자율성을 사용하도록 설정해야 합니다.

정렬과 자율성 간의 미묘한 균형을 관리하려면 DevOps 리더가 분류를 정의하고, 계획 프로세스를 정의하고, 기능 채팅을 사용해야 합니다.

분류 정의

Agile 팀과 해당 팀이 속한 더 큰 Agile 조직은 성공하려면 명확하게 정의된 백로그가 필요합니다. 조직의 목표가 불분명하면 팀은 성공하기 위해 고군분투할 것입니다.

명확한 목표를 설정하고 각 팀이 기여하는 방식을 명시하기 위해 조직은 분류를 정의해야 합니다. 명확하게 정의된 분류는 조직에 대한 명명법을 만듭니다.

일반적인 분류는 서사시, 기능, 이야기 및 작업입니다.

에픽

Epics는 조직의 성공에 중요한 이니셔티브를 설명합니다. 에픽은 여러 팀과 여러 스프린트를 수행해야 할 수 있지만 끝이 없는 것은 아닙니다. 에픽은 명확하게 정의된 목표를 가지고 있습니다. 일단 달성되면, 서사시가 닫힙니다. 조직의 집중을 유지하기 위해 진행 중인 서사시 수를 관리할 수 있어야 합니다. 에픽은 기능으로 세분화됩니다.

기능

기능은 에픽의 목표를 실현하는 데 필요한 새로운 기능을 정의합니다. 기능은 릴리스 단위입니다. 고객에게 릴리스된 내용을 나타냅니다. 게시된 릴리스 정보는 최근에 완료된 기능 목록을 기반으로 작성할 수 있습니다. 기능은 여러 스프린트를 완료하는 데 걸릴 수 있지만 고객에게 일관된 가치 흐름을 보장하기 위해 크기를 조정해야 합니다. 기능은 스토리로 구분됩니다.

스토리

스토리는 팀이 기능을 만들기 위해 제공해야 하는 증분 값을 정의합니다. 팀은 이 기능을 증분 조각으로 나눕니다. 완료된 단일 스토리는 고객에게 의미 있는 가치를 제공하지 못할 수 있습니다. 그러나 완성된 스토리는 프로덕션 품질 소프트웨어를 나타냅니다. 스토리는 팀의 작업 단위입니다. 팀은 기능을 완료하는 데 필요한 스토리를 정의합니다. 스토리는 필요에 따라 작업으로 세화됩니다.

작업

작업은 스토리를 완료하는 데 필요한 작업을 정의합니다.

이니셔티브

이 분류는 하나의 크기에 맞는 모든 시스템이 아닙니다. 많은 조직에서 이니셔티브라는 서사시 이상의 수준을 도입합니다.

각 수준의 이름은 조직에 맞게 조정할 수 있습니다. 그러나 위에서 정의한 이름(서사시, 기능, 스토리)은 업계에서 널리 사용됩니다.

자율성의 선

분류가 설정되면 조직은 자율성의 선을 그어야 합니다. 자율성의 선은 수준의 소유권이 관리에서 팀으로 전달되는 지점입니다. 관리는 팀이 소유한 수준을 방해하지 않습니다.

다음 예제에서는 기능 아래에 그려진 자율성의 선을 보여줍니다. 경영진은 정렬을 제공하는 서사시와 기능을 소유합니다. Teams는 스토리와 작업을 소유하고 실행 방법에 대한 자율성을 갖습니다.

이 예제에서는 경영진이 스토리를 분해하거나 스프린트를 계획하거나 작업을 실행하는 방법을 팀에 알리지 않습니다.

그러나 팀은 실행이 경영진의 목표에 부합하는지 확인해야 합니다. 팀이 스토리의 백로그를 소유하는 동안 백로그를 할당된 기능에 맞춰야 합니다.

계획

Agile 계획을 확장하려면 팀은 분류의 각 수준에 대한 계획이 필요합니다. 그러나 계획을 반복하고 업데이트하는 것이 중요합니다. 이 프로세스를 롤링 웨이브 계획이라고 합니다.

이 계획은 일정한 간격으로 예상되는 보정을 사용하여 고정된 기간에 대한 방향을 제공합니다. 예를 들어 18개월 계획은 6개월마다 보정될 수 있습니다.

여기에 분류의 각 수준에 대한 방법을 계획하는 예입니다 : 서사시, 기능, 이야기, 작업.

시각

비전은 서사시를 통해 표현되고 조직의 장기적인 방향을 설정합니다. 에픽은 조직이 향후 18개월 이내에 완료하고자 하는 것을 정의합니다. 경영진은 계획을 소유하고 6개월마다 보정합니다.

비전은 모든 손 회의에서 제시된다. 비전은 야심차고 그 기간 동안 많은 변화가 있을 수 있으므로 비전의 약 60%를 달성할 것으로 기대합니다.

계정

시즌은 기능을 통해 설명하고 향후 6개월 동안의 전략을 설정합니다. 기능은 조직이 고객을 위해 불을 붙이려는 것을 결정합니다. 경영진은 계절 계획을 소유하고 있으며 모든 손 회의에서 비전과 계절 계획을 제시합니다. 모든 팀 계획은 경영진의 계절 계획에 부합해야 합니다. 계절 계획의 약 80%를 달성할 것으로 예상됩니다.

3 스프린트 계획

3 스프린트 계획은 팀이 다음 세 스프린트를 통해 완료할 이야기와 기능을 정의합니다. 팀은 계획을 소유하고 모든 스프린트를 보정합니다. 각 팀은 기능 채팅을 통해 관리 계획을 제시합니다(아래 참조). 이 계획은 팀의 실행이 6개월 계절 계획과 일치하는 방식을 지정합니다. 3 스프린트 계획의 약 90%를 달성할 것으로 예상됩니다.

스프린트 계획

스프린트 계획은 팀이 다음 스프린트에서 완료할 스토리와 기능을 정의합니다. 팀은 스프린트 계획을 소유하고 완전한 투명성을 위해 전체 조직에 이메일을 보냅니다. 이 계획에는 팀이 지난 스프린트에서 달성한 성과와 다음 스프린트에 대한 초점이 포함됩니다. 스프린트 계획의 약 95%를 달성할 것으로 예상됩니다.

자율성의 선

이 예제에서 자율성의 선은 팀이 자율성을 계획하는 위치를 보여주기 위해 그려집니다.

위에서 설명한 것처럼 경영진은 자율성의 선 아래로 소유권을 확장하지 않습니다. 경영진은 비전과 시즌 계획을 사용하여 지침을 제공하고 팀에 3 스프린트 및 스프린트 계획을 만들 수 있는 자율성을 제공합니다.

기능 채팅: 자율성이 맞춤을 충족하는 위치

기능 채팅은 각 팀이 경영진에게 3 스프린트 계획을 제시하는 낮은 의식 모임입니다. 이 모임은 팀 계획이 조직의 목표에 부합하도록 합니다. 또한 경영진이 팀이 수행하는 일에 대한 정보를 유지하는 데 도움이 됩니다. 3 스프린트 계획은 모든 스프린트에서 보정되지만, 기능 채팅은 필요에 따라 개최되며, 일반적으로 1~3개의 스프린트마다 진행됩니다.

기능 채팅 모임은 각 팀에 15분을 할당합니다. 12개 기능 팀을 통해 이러한 모임은 약 3시간 동안 지속될 수 있습니다. 각 팀은 다음 슬라이드를 사용하여 3개의 슬라이드 데크를 준비합니다.

기능

첫 번째 슬라이드는 다음 세 스프린트에서 팀이 조명할 기능을 간략하게 설명합니다.

부채

다음 슬라이드에서는 팀이 기술 부채를 관리하는 방법을 설명합니다. 부채는 경영진의 품질 바를 충족시키지 못하는 것입니다. 엔지니어링 디렉터는 모든 팀(맞춤)에 대해 동일한 품질 막대를 설정합니다. 예제 품질 막대에는 엔지니어당 버그 수, 단위 테스트 통과 비율 및 성능 목표가 포함됩니다.

문제 및 종속성

최종 슬라이드에 나열된 문제 및 종속성에는 팀이 해결할 수 없는 문제 또는 에스컬레이션이 필요한 다른 팀에 대한 종속성과 같이 팀 진행 상황에 영향을 주는 모든 것이 포함됩니다.

각 팀은 슬라이드를 경영진에게 직접 제공합니다. 팀은 3 스프린트 계획이 6개월 계절 계획에 어떻게 부합하는지 제시합니다. 리더십은 질문을 명확히 하고 방향의 변화를 제안합니다. 더 깊은 문제를 해결하기 위해 후속 모임을 요청할 수도 있습니다.

팀의 계획이 경영진의 기대에 부합하지 못하는 경우 경영진은 다시 계획을 요청할 수 있습니다. 이 드문 경우에서 팀은 두 번째 기능 채팅을 다시 계획하고 예약하여 검토합니다.

신뢰: 맞춤과 자율성을 함께 보유하는 접착제

Agile을 대규모로 연습할 때 신뢰는 양방향 거리입니다.

• 경영진은 팀이 옳은 일을 하도록 신뢰해야 합니다. 경영진이 팀을 신뢰하지 않는 경우 팀에 자율성을 부여하지 않습니다.

• 팀은 고품질 코드를 일관되게 제공하여 신뢰를 얻습니다. 팀이 신뢰할 수 없는 경우 경영진은 자율성을 부여하지 않습니다.

경영진은 팀이 팀을 일치시키고 실행할 수 있도록 신뢰할 수 있는 명확한 계획을 제공해야 합니다. 팀은 계획을 조직과 일치시키고 신뢰할 수 있는 방식으로 실행해야 합니다.

조직에서 Agile을 더 큰 시나리오로 확장하려고 할 때 핵심은 조직의 목표에 부합하는 동시에 팀에 자율성을 부여하는 것입니다. 중요한 구성 요소는 명확하게 정의된 소유권과 신뢰 문화권입니다. 조직이 이 기반을 마련하면 Agile이 매우 잘 확장할 수 있음을 알 수 있습니다.

다음 단계

모든 규모의 팀이 오늘 혜택을 보기 시작하는 방법에는 여러 가지가 있습니다. 이러한 사례 중 일부를 확인하여 크기를 조정합니다.

팀 전체의 포트폴리오 관리 및 가시성을 위한 Azure DevOps 기능에 대해 알아봅니다.

Microsoft는 세계에서 가장 큰 Agile 회사 중 하나입니다. Microsoft에서 DevOps 계획을 확장하는 방법에 대해 자세히 알아봅니다.