팀 내에서 Agile 문화 홍보

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

팀이 성장함에 따라 도구가 함께 성장하기를 원합니다. Agile 방법론을 채택하는 엔터프라이즈인 경우 Agile 도구가 엔터프라이즈의 비즈니스 목표를 지원하려고 합니다.

그러나 Agile의 크기를 성공적으로 조정하려면 조직 내의 문화권과 도구를 모두 해결해야 합니다.

참고 항목

Agile을 새로 사용하시겠습니까? 자세한 내용은 Agile Culture and Scaling Agile to Large Teams를 참조하세요.

자율성 사용

민첩성을 열망하는 조직은 기업 전반에 걸쳐 맞춤을 만들고 팀 자율성을 지원하는 두 가지 의무를 고려해야 합니다. 팀은 효율성을 위해 자율성이 필요합니다. 또한 기업은 효율적으로 팀 및 조직 간에 정렬이 필요합니다.

부족한 팀 자율성 리드와 너무 많은 맞춤은 팀의 혁신이나 민첩성을 지원하지 않습니다. 자체 프로그램을 실행하는 각 팀과 너무 적은 맞춤이 비즈니스 목표를 달성하는 데 필요한 통찰력과 조정을 제공하지 않습니다.

조직 및 팀 자율성 전반에 걸쳐 적절한 수준의 맞춤을 통해 개인은 혁신에 힘을 실어주고 비즈니스 목표를 달성하기 위해 공동 작업하도록 영감을 받습니다.

맞춤 만들기

Agile 도구 집합을 성장시키는 방법을 계획할 때 다음 영역을 고려합니다. 이러한 영역은 팀 자율성을 개발하는 동안 엔터프라이즈 맞춤을 만드는 데 핵심입니다.

영역

맞춤 만들기

자율성 지원

Product Vision

조직은 조직의 목표와 로드맵을 정의합니다. 포트폴리오 백로그에 표시되는 서사시 및 기능으로 목표를 정의할 수 있습니다.

팀은 로드맵을 가장 잘 충족하는 방법을 결정합니다. 팀은 팀 백로그를 사용하여 목표를 사용자 스토리 또는 제품 백로그 항목으로 나눕니다.

팀 구조

비즈니스 목표에 따라 조직은 팀의 수와 크기를 결정합니다. 수직 구조화된 기능 팀은 더 큰 자율성과 효율성으로 이어지고 있습니다.

팀과 함께 제품 소유자 및 개발 리드와 같은 몇 가지 확립된 역할이 있을 뿐만 아니라 역할을 회전할 여지가 있어야 합니다. 예를 들어 팀 구성원은 스크럼 마스터 역할을 수행하거나, 스프린트 데모를 개발하거나, 스프린트 회고를 실행하거나, 스프린트 이메일을 작성할 수 있습니다.

개발 주기

Agile 조직은 정기적으로 제품 및 기능 업데이트를 릴리스해야 합니다. 정규 릴리스 및 스프린트 일정을 설정하면 비즈니스의 리듬이 촉진됩니다.
2~4주 사이의 일정한 지속 시간을 시간 단위로 반복하는 각 스프린트에는 계획, 실행, 가치 제공, 반영 및 지속적인 개선에 참여하는 것이 포함됩니다.

모든 팀은 설정된 스프린트 주기 내에서 작업을 관리합니다. 팀은 가장 적합한 스프린트 길이에 대한 입력을 제공합니다.
팀은 그들을 위해 작동하는 Agile 메서드, 스크럼, Kanban 또는 둘 다의 혼합을 선택합니다. 팀은 또한 자체적인 지속적인 개선 사례 집합에 따라 시작 및 행동에 대한 소유권을 맡습니다.
일부 팀은 짧은 스프린트에서 실행할 수 있습니다. 예를 들어 조직에서 2주 스프린트 주기를 설정하는 경우 일부 팀은 조직 일정에 맞춰 1주 스프린트에서 작동하도록 선택할 수 있습니다.

통신 주기

스프린트가 작업의 흐름에 자연스러운 리듬을 가져다 주는 것처럼 정기적인 통신도 마찬가지입니다. 조직에서는 원하는 커뮤니케이션 유형과 정렬된 상태를 유지하는 빈도에 대한 기대치를 설정하여 팀과 기업 간에 자연스럽게 맞춤을 만듭니다.
팀 스프린트 이메일, 버그 표시줄 상태 및 릴리스 팀 기능 배달 상태 이러한 정기적인 통신의 예입니다.

팀은 통신하는 세부 정보와 통신을 개발하는 사람을 결정합니다. 해당 스프린트 이메일에는 이전 스프린트 성과 및 다음 스프린트 계획에 대한 요약이 포함되거나 최근에 완료된 기능의 데모가 포함될 수 있습니다.

품질

각 조직은 품질을 평가하고 품질 표준에 대한 기대치를 설정하는 기준과 표준을 설정해야 합니다. 기준을 정의하는 몇 가지 방법은 새로운 기능 개발에 대한 종료 기준, 기술 부채를 관리하는 표준 및 팀 또는 개인에 대한 버그 한도를 설정하는 것입니다.
또한 버그 대시보드를 만들어 버그 상태 및 추세를 모니터링할 수 있습니다.

팀은 품질 표준을 충족하는 방법을 선택합니다. 새 기능에 대한 버그 배시를 준비하거나 각 스프린트의 끝에 스테이징할 수 있습니다. 그들은 회전 기준으로 버그 방패로 작동 할 개인을 선택할 수 있습니다.

위험 관리, 작업 추적

조직은 각 기능 단위가 상태 및 위험을 전달하는 방법을 결정합니다. 조직에 필요한 최소 정보로 "통신 계약"을 설정합니다.
또한 조직은 위험을 줄이기 위한 인프라를 제공합니다. 조직은 팀 전체에서 공통적인 위험을 줄이기 위해 수행할 수 있는 모든 작업을 팀에 빚지고 있습니다.

팀에서 설정한 요구 사항을 충족하는 것 외에도 팀은 위험을 줄이기 위해 관리하고 추적하는 데 필요한 다른 세부 정보를 결정합니다. 스티커 메모가 있는 흰색 보드를 사용하든 전체 Gantt 차트를 사용하든 세부 정보를 관리합니다. 예를 들어 팀은 백로그 항목을 추가하여 다른 팀에 대한 종속성을 추적할 수 있습니다. 또는 문제 또는 장애 목록을 통해 위험을 추적할 수 있습니다. 또한 팀은 위험을 관리하고 인사이트를 얻는 조직의 기능을 지원하기 위해 프로세스 및 인프라를 개선하는 데 정기적으로 기여합니다.

팀 구성

규모를 조정할 때 고려해야 할 가장 중요한 작업 중 하나는 팀을 구성하는 방법입니다. 일반적으로 수평 팀 구조는 사용자 인터페이스, 서비스 지향 아키텍처 및 데이터 팀과 같은 소프트웨어 아키텍처에 따라 팀을 나눕니다.

가로 및 세로 팀을 보여 주는 차트입니다.

그러나 Agile 사례를 채택하면 아키텍처에 걸쳐 있는 수직 팀 구조가 더 큰 팀 자율성을 제공합니다. 수직 팀은 소프트웨어 아키텍처 전반에서 작업하여 소유한 기능을 제공할 수 있습니다. 또한 모든 팀 전체의 모든 아키텍처 수준에서 작업하는 데 필요한 지식을 전파합니다.

조직에서 제공하려는 가치 스트림을 따라 팀을 구성합니다. 예를 들어 Fabrikam Fiber는 팀을 다음 7개의 기능 팀으로 구성합니다.

쇼핑 카트, 고객 프로필, 서비스 상태, 전자 메일, 음성, 인터넷, TV 등 7개 기능 팀을 보여 주는 차트

각 팀은 제공할 기능을 계획합니다. 데이터를 구조화하고, 서비스를 설계하고, 웹 및 모바일 사용자 인터페이스를 디자인하는 방법을 결정하는 자율성이 있습니다. 조직에서 설정한 품질 표준과 모든 팀이 기여하는 품질 표준을 준수할 계획입니다.

크기를 조정하도록 Agile 도구 구성

조직이 성장함에 따라 다음과 같은 방법으로 Agile 도구의 크기를 조정할 수 있습니다.

  • 팀 및 필터링된 백로그 보기 추가: 팀 자율성을 지원하는 팀을 추가하고, 팀들이 구성하고 관리할 수 있는 도구를 제공하여 작업 방식을 지원합니다. 이러한 도구에는 제품 백로그, Kanban 보드, 스프린트 백로그, 작업 보드 등이 포함됩니다.

    또한 포트폴리오 관리자가 여러 팀에서 우선 순위 및 진행 상황을 검토할 수 있도록 백로그 및 포트폴리오 백로그 계층 구조를 지원하도록 팀을 구성할 수 있습니다.

  • 스프린트 및 릴리스 설정: 플랫 스프린트 집합 또는 예약된 릴리스에 포함된 스프린트 집합을 지원하도록 반복을 구성할 수 있습니다. 각 팀은 참여해야 하는 스프린트 및 릴리스 집합을 활성화합니다.

  • 포트폴리오 관리: 팀 및 백로그 계층 구조를 설정하고 포트폴리오 백로 그를 활성화합니다. 제품 백로그의 하위 집합에 초점을 맞춘 기능 팀은 다시 사용할 수 기본 백로그에만 집중할 수 있습니다. 진행률 및 종속성을 추적하기 위해 백로그를 보고 구성하려는 포트폴리오 관리자는 기능 및 에픽의 포트폴리오 백로그를 관리할 수 있습니다.

    시나리오 또는 이니셔티브와 같은 다른 포트폴리오 백로그가 필요한 경우 해당 백로그도 추가할 수 있습니다.

  • 대시보드 구성: 팀 대시보드를 사용하여 팀 내 또는 팀 간 진행 상황을 추적하는 차트를 구성할 수 있습니다. 특히 만든 쿼리에 따라 상태 및 추세 차트를 추가할 수 있습니다.

  • 작업 그룹화 또는 분류: 추적하려는 작업을 그룹화하는 여러 가지 방법이 있습니다. 백로그는 팀 영역 할당에 따라 작업 항목을 필터링합니다. 또한 포트폴리오 백로그를 사용하면 기능 및 에픽에서 백로그 항목을 그룹화할 수 있습니다.

    다른 그룹화에 따라 작업 항목을 추적하고 보고하려는 경우 수행할 수 있습니다. 작업 항목에 태그를 추가한 다음 태그를 기반으로 백로그 또는 쿼리를 필터링할 수 있습니다. 또한 하위 영역 경로를 추가하여 보다 세분화된 기능 영역을 나타낼 수 있습니다.

  • 폴더 추가 및 팀 즐겨찾기 사용: 팀이 성장함에 따라 작업 항목 쿼리, 빌드 정의 및 소스 코드 폴더 목록이 늘어나고 있습니다. 폴더, 하위 폴더 및 팀 즐겨찾기를 사용하여 이러한 목록의 대부분을 더 쉽게 관리할 수 있습니다. 공유 쿼리, 소스 코드 및 빌드 정의에 대한 팀 즐겨찾기를 추가할 수 있습니다.

프로젝트가 아닌 팀으로 크기 조정

조직에서는 종종 각 소프트웨어 개발 프로젝트에 대한 프로젝트 추가를 살펴봅합니다.

다음과 같은 이유로 프로젝트를 추가하는 대신 도구를 확장할 팀을 추가하는 것이 좋습니다.

자세한 내용은 프로젝트 및 조직 크기 조정에 대해 참조하세요.

Agile 도구를 만들거나 작업하려면 프로젝트가 필요합니다. 아직 없는 경우 만들 수 있습니다.

한 팀에서 두 팀으로 이동하거나 여러 팀을 구성할 준비가 되면 팀 추가를 참조 하세요. 팀 관리자를 추가하거나 팀 자산을 구성하려면 팀 관리 및 팀 도구 구성을 참조하세요.

자세한 내용은 다음 문서를 참조하세요.

Agile 문화 산업 리소스