Share via

크기를 조정하는 Agile 사례 구현

  • 아티클

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

엔터프라이즈 조직은 여러 가지 이유로 Agile 사례를 채택합니다. 이러한 이유 중 프라임은 다음과 같습니다.

  • 출시 시간 단축, 제품 출시 가속화
  • 조직의 효율성을 개선하여 변화하는 우선 순위 관리
  • 소프트웨어 품질 및 배달 예측 가능성 향상
  • 프로젝트 가시성 향상 및 프로젝트 위험 감소

조직이 성장함에 따라 사례를 확장하여 민첩하게 기본 변화하는 목표를 충족할 수 있습니다. 이렇게 하려면 다음 두 가지 지침 원칙을 고려합니다.

  • 성공은 사용자, 팀 및 조직에 어떤 모습 일까요? 가장 관심 있는 사항: 정시 배달 제품 품질? 예측? 고객 만족도
  • 첫 번째 원칙으로 돌아가서 스크럼의 창시자 중 한 명인 Ken Schwaber가 지적한 Agile 선언문에 열거된 원칙과 공유 가치로 돌아갑니다.
    • "값과 원칙은 크기가 조정되지만 사례는 상황에 따라 중요합니다."
    • "가치를 유지하고, 원칙을 지키고, 스스로 생각하십시오. Agile의 핵심 전제는 작업을 수행하는 사람들이 이 작업을 수행하는 방법을 가장 잘 파악할 수 있는 사람들이라는 것입니다."

리듬 및 흐름 만들기

공유 주기 및 정기적인 통신 집합을 채택하여 조직 전체에서 일정한 활동 흐름을 만듭니다. 대규모 조직 내에서 리듬과 흐름을 만드는 데 도움이 되는 사례는 다음과 같습니다.

  • 공유 주기: 일반 스프린트 및 릴리스는 비즈니스의 리듬을 설정합니다. 모든 팀이 공유 주기로 작업하도록 하면 모든 조정 및 공동 작업 활동에 도움이 됩니다.
  • 스프린트 이메일: 조직과 모든 팀이 기능 팀의 진행 상황과 계획에 대해 계속 알리기 위해 각 기능 팀은 이전 스프린트 결과 및 현재 스프린트 계획의 요약을 이메일로 보낼 수 있습니다.
  • 스프린트 데모: 팀이 생성한 새로운 기능을 보여 주는 빠른 2~3분 비디오입니다. 이러한 비디오에 대한 링크는 스프린트 전자 메일에 포함될 수 있습니다.
  • 모임 소개: 다른 팀에 알리고 개발 중인 소프트웨어에 대한 피드백을 요청하기 위해 팀은 수행한 작업을 소개합니다. 프로젝트 수명 주기 내내 정기적으로 이러한 모임을 수행하고 모든 이해 관계자에게 엽니다.
  • 버그 요약 이메일: 제품 품질에 대한 인사이트를 지원하고 버그 분야를 기본 권장하려면 정기적으로 품질 메트릭을 조직과 공유합니다. 이러한 메트릭에는 기능 팀당 활성 버그, 버그 추세 및 엔지니어당 버그가 포함될 수 있습니다.
  • 조정 모임: 겹치는 목표, 종속성 및 위험을 해결하기 위해 정기적으로 또는 필요에 따라 팀을 조정하는 모임을 개최합니다.

고객과 상호 작용

제품 수명 주기 전반에 걸쳐 고객을 참여시키는 것이 주요 Agile 원칙입니다. 각 팀이 소유한 기능 집합에서 고객과 직접 상호 작용할 수 있도록 지원합니다.

  • 지속적인 피드백: 고객 피드백 루프에서 빌드합니다. 이러한 루프는 다음과 같은 다양한 형태를 취할 수 있습니다.
    • 고객 의견: 고객이 피드백을 제공하고, 아이디어를 추가하고, 차세대 기능에 투표할 수 있도록 합니다. 피드백 제공은 종종 전용 웹 사이트를 통해 수행됩니다.
    • 제품 피드백: 제품 내 피드백 단추는 제품 환경 또는 특정 기능에 대한 피드백을 요청하는 또 다른 방법입니다.
    • 고객 데모: 고객의 피드백을 요청하는 정기적으로 예약된 데모는 차세대 제품을 만들고 고객이 사용하려는 애플리케이션을 빌드하는 데 도움이 될 수 있습니다.
  • 얼리어답터 프로그램: 이러한 프로그램은 모든 팀이 어느 정도 참여하기를 원할 수 있다는 생각으로 개발되어야 합니다. 얼리어답터는 초기 버전의 작업 소프트웨어에 액세스하여 피드백을 제공할 수 있습니다. 종종 이러한 프로그램은 얼리 어답터 목록에 대한 선택 기능 플래그 를 켜서 작동합니다.
  • 데이터 기반 의사 결정: 유용한 데이터를 얻기 위해 제품을 계측하는 방법을 찾고 다양한 가설을 테스트할 수 있습니다. 학습을 기념하는 실험 친화적 인 문화로 운전하는 데 도움이됩니다.

프로젝트 가시성 향상

사용자와 팀이 수행 중인 작업의 목표, 비전 및 진행 상황에 대한 인사이트가 많을수록 위험을 줄이고 종속성을 관리할 수 있습니다.

  • 팀 구조: 조직의 규모에 관계없이 6~9개의 규모로 구성된 소규모 팀을 중심으로 조직을 구성합니다. 포트폴리오 관리 영역에서 그룹화된 수직 자율 기능 팀을 만듭니다.
  • 작업 분석 구조: 큰 목표, 기능 또는 요구 사항을 더 작은 것으로 세분화하면 프로젝트 관리가 안정적으로 기본. 팀은 작업을 비슷한 크기의 작업으로 분류하여 더 나은 추정치를 만들고 위험 및 종속성을 식별할 수 있습니다.
  • 통합 보기: 온라인 추적 도구를 사용하여 작업을 집계하여 팀 전체에서 지식을 습득합니다. 진행률 및 추세를 표시하는 대시보드를 빌드합니다.
  • 경험 검토: 기능 개발이 시작되기 전에 개최되는 이러한 회의는 시나리오 및 우선 순위에 대한 리더십을 교육하고, 피드백을 수집하고, 기대치를 설정하고, 기능에 대한 팀 간 문제를 노출하는 데 사용됩니다.

생산적인 인력 역량 강화

잘 확장하고 더 행복하고 참여하며 생산적인 직원으로 이어지는 몇 가지 특정 Agile 사례는 다음과 같습니다.

  • 임베디드 리더십: 조직 내의 팀과 리더가 가능한 한 많이 자체 구성하고 자체 관리할 수 있도록 지원합니다. 팀 자율성은 조직의 민첩성 팀 효율성을 높입니다. 팀이 성공하는 데 필요한 기업 후원이 있는지 확인합니다.
  • 일일 스탠드업: 또는 스크럼 모임을 통해 팀은 스프린트 약속을 충족하는 능력을 최대화하기 위해 매일 해야 할 일에 집중할 수 있습니다. 조직이 성장함에 따라 필요에 따라 팀 간 참여가 발생할 수 있도록 이러한 모임을 엄청나게 늘리는 것을 고려해야 합니다.
  • 스크럼 스크럼: 다른 Agile 팀의 구성원이 매일 모여 작업 완료, 다음 단계 및 대표 팀 내에서 발생하는 문제 또는 블록을 보고합니다.
  • 팀 커뮤니케이션: 팀과 다른 팀이 회사 네트워크를 통해 액세스할 수 있는 사례와 지침을 공유하도록 팀을 제공하고 장려합니다. 이 용도로 사용되는 일반적인 도구에는 팀 위키, OneNotes 또는 Markdown 사이트가 포함됩니다.
  • 공동 작업: 팀 내에서 비공식적인 팀 간 커뮤니케이션 및 협업을 장려합니다. 코드 검토, 디자인 검토, 사양 검토와 같은 제도화 관행은 팀 협업을 증가시킬 뿐만 아니라 개인 및 전반적인 회사 역량을 개발하는 데 도움이 됩니다.

조직 문화 개선

구축하려는 문화권에 참석하여 조직의 효율성을 향상시킵니다. 문화권 변화는 개인, 팀 및 조직이 하나 이상의 지속적인 개선 사례를 채택할 때 발생합니다. 몇 가지 확장 가능한 Agile 사례는 다음과 같습니다.

  • 회고: "무엇이 잘 되었습니까?", "어떻게 다르게 해야 하나요?", "무엇을 중단해야 하나요?"와 같은 질문을 하면 팀이 프로세스와 관행을 개선할 수 있는 방법을 숙고할 수 있습니다. 회고전은 팀이 잘 작동하는 것과 개선이 필요한 사항을 파악하는 데 도움이 됩니다. 회고전은 언제 어디서나 수행할 수 있습니다. 그러나 특정 회고를 정기적으로 제도화하면 지속적인 개선 사례를 제도화하는 데 도움이 됩니다. 예시:

    • 스프린트 회고전은 팀이 정기적인 주기로 개선할 영역을 식별하는 데 도움이 될 수 있습니다.

    • 릴리스 회고는 조직이 다음 릴리스에 대한 커뮤니케이션 및 내부 관행 및 연료 개선을 개선하기 위한 영역을 식별하는 데 도움이 될 수 있습니다.

    • 운영 검토: 일반적으로 매월 개최되며 전체 가치 스트림의 담당자를 포함합니다. 프로젝트 및 기타 이니셔티브의 포트폴리오를 포괄하고 객관적이고 양적인 데이터를 사용하여 팀 간의 성과에 영향을 미치는 역학에 대한 논의를 유발하도록 이러한 회고전을 설계합니다.

      회고를 계획하고 수행하기 위한 아이디어, 팁 및 도구는 Agile 회고 리소스 Wiki를 참조하세요. Marketplace 회고전 확장도 참조하세요.

  • 개선 추적 보드: 프로세스를 개선하기 위한 좋은 아이디어는 언제든지 어느 쪽에서나 발생할 수 있습니다. 이러한 아이디어를 캡처하여 신속하게 작업하는 방법을 논의하고 결정하는 것은 프로세스 개선 노력을 지원하는 열쇠입니다.

    화이트 보드는 아이디어를 캡처할 수 있는 쉽고 시각적인 수단을 제공합니다. 또한 개선 추적 팀을 만들고 전자 Kanban 보드에서 추적하는 아이디어를 캡처할 수 있습니다.

  • 공유 제도화: 모범 사례 공유 및 아이디어 전달은 조직 내의 모든 팀이 성장하고 개선하는 데 도움이 됩니다. 학습 문화를 개발하는 것은 이러한 활동 및 기타 지속적인 개선 활동을 지원하는 데 핵심적인 사항입니다. 고려해야 할 몇 가지 아이디어:

    • 사내 위키

    • 사내 메일 그룹

    • 해커톤 주 또는 10% 해킹 시간

    • Agile 사례를 채택하는 팀을 지원하기 위한 내부 Agile 지원 팀

      Culture Game 은 Agile 관리자에게 팀이 Agile을 채택하고 모범 사례를 공유하는 데 도움이 되는 좋은 리소스를 제공합니다.

  • 실습 커뮤니티: 내부 공통 분야 지원(예: DBA, SW 설계자, UX 디자인)

작업 소프트웨어

"몇 주에서 몇 달까지 작업 소프트웨어를 자주 제공하며, 더 짧은 기간을 선호합니다."
"작업 소프트웨어는 진행률의 주요 측정값입니다."
- Agile 선언문

소프트웨어, 기능 및 복잡성이 증가함에 따라 소모성 솔루션을 생성하는 데 도움이 되는 사례를 채택해야 합니다.

  • 기능 플래그: 기능 플래그를 사용하여 다양한 기능에 대한 액세스를 사용하거나 사용하지 않도록 설정합니다. 기능을 얼리어답터에게 설정하여 작업 피드백을 받을 수 있도록 지원합니다.
  • 릴리스 열차: 하나 이상의 기능을 제공하기 위해 다른 유형의 주기를 제공합니다. 기능 팀은 새 기능을 푸시하는 미리 계획된 일정을 이해하고 올바르게 계획합니다. 릴리스 열차는 조직에 대해 설정된 동일한 스프린트 주기에 해당하거나 다른 주기로 발생할 수 있습니다. 스프린트 및 릴리스 열차를 설정하는 방법은 크기 조정된 Agile Framework를 참조하세요.
  • 연속 통합: 수동 작업을 제거하고 대신 테스트, 빌드 및 배포 주기를 통해 소프트웨어 흐름을 자동화하는 프로세스를 채택합니다.
  • 내부 오픈 소스: 오픈 소스 소프트웨어 커뮤니티에서 개발된 가치와 정신을 내부 개발 팀에 가져옵니다.

위의 사례와 함께 다음 문서에서 Agile 도구 크기 조정에 대한 추가 지침을 찾을 수 있습니다.

산업 리소스

크기를 조정하지 않는 사례

  • 대규모 이니셔티브 예측: 폭포 프로젝트 방법의 일부로 자원 및 일정 예측이 포함되었습니다. 이니셔티브가 클수록 이러한 추정치가 가치가 없을 가능성이 적습니다. 프로젝트가 커짐에 따라 위험과 예기치 않은 문제 및 장애물이 발생할 수 있으므로 많은 추정치가 무효화될 수 있습니다.
  • 속도: 팀 속도는 스프린트 주기 동안 각 팀이 완료할 수 있는 작업에 대한 인사이트를 얻기 위한 유용한 메트릭을 제공할 수 있지만 팀 속도를 추가하여 의미 있거나 유용한 메트릭을 얻을 수는 없습니다. 또한 많은 팀에서 얻은 속도를 사용하여 장거리 예측을 안정적으로 완료하는 것은 문제가 됩니다. 팀은 자신의 작업을 예측하는 방식에 따라 다르며 시간이 지남에 따라 이러한 변화가 증가합니다.
  • 하향식 규범적 솔루션: 한 가지 크기가 모두 적합하지는 않으며, 일반적으로 하나의 솔루션이 모든 팀에 맞지는 않습니다. 팀 자율성을 지원한다는 것은 팀이 자체 솔루션을 찾을 수 있도록 하는 것을 의미합니다.