소개

지난 10년동안 Agile 방법론의 채택은 증대되었다. 많은 조직들은 Agile과 함께 성장하였고 팀의 계획, 배포, 진행을 추적하는데 도움이되는 확장된 방법론을 사용하고 있다. 많은 확장된 방법론들이 이용가능하지만, Scaled Agile Framework(SAFe)는 대규모 조직에서 가장 널리 채택된 방법론이다. Atlassian은 수년간 Agile 방법론을 채택하면서 대기업을 지원해왔으며 JIRA Software와 Portfolio for JIRA를 사용하여 Agile을 확장하기 위한 강력한 방법을 제공한다. 이 문서는 JIRA Software와 Portfolio for JIRA가 어떻게 SAFe 방법론을 지원하고 조직의 모든 요구사항을 어떻게 지원하는지에 대해 설명한다. 

Agile 확장의 필요성

Agile 방법론들(Scrum, Kanban, XP 등)은 개별 팀 계획 및 배포 활동에 초점을 둔다. 각 방법론은 점진적으로 가치있는 제품의 배포를 지속적으로 확인하고 돕는 특정 역할, 활동, 보고서를 가진다. 개별 팀의 경우 이러한 접근은 성공하지만, 최근 이러한 방법은 여러 팀을 거쳐 확장되고 높은 수준의 업무를 계획하는데 어려움을 준다. 

Agile 팀은 성숙하고 성장함에따라 다음 방법에 대해 어려움을 겪고 있다. 

• 컨셉으로부터 배포까지 여러 다른 팀의 다양한 기능을 병합하기 위한 대규모 이니셔티브의 추적
• 객관적인 의사 결정을 만들기 위한 팀의 배포 업무에 비즈니스 가치를 계획하고 조정
• 고품질 릴리즈 배포를 위해 조직에서 팀과 전문가와 함께 다양한 스킬 셋의 이점을 가지는 것
• 여러 팀들 간의 스프린트 목표를 조정하는 것
• 릴리즈 계획에 시스템 아키텍처와 인프라 필요를 빌드
• 여러팀의 진행상황을 추적하고 팀들간의 문제를 식별하고, 조직에따른 솔루션 방향을 드라이브하는 데이터 사용

초기에는 Agile 리더들이 이러한 문제를 해결하기 위한 반복가능한 방법을 생성하는 것이 어려웠다. 2011년에 Scaled Agile Inc.는 크고 작은 조직에 성공적인 패턴을 제공하는 이러한 문제를 해결하는데 도움이 되는 Scaled Agile Framework for the Enterprise 1.0를 발표했다. SAFe는 지금 4.5가 출시되었고 고객의 피드팩과 실제 사용 패턴에 따라 업데이트 되고 있다. 이는 Agile 확장 방법으로 널리 채용되고 있다. 

Team level agility

조직 레벨에서 Agile을 확장하는 것은 개별 팀과 동일하게 전체 조직에 많은 동일한 혜택을 제공한다. 이러한 이점은 Time to market 단축, 개발 프로세스 간소화, 조직 전반의 투명성 향상을 포함한다. 애자일 확장에 두 가지 가장 큰 문제점은 종종 스펙트럼의 반대편에서 발생한다. 이러한 문제는 기본 Waterfall 컨셉에서 발생한다.

1. Encourage organizational rigidity
   조직의 엄격성을 장려하는 것.
2. Don't embrace the culture of agility throughout the development process
   개발 프로세스 전역에서 agility 문화를 포용하지 못하게 하는것

애자일을 확장하기 위해 이러한 고전점을 벗어나고 건전한 기반을 조성하는 프렉티스를 살펴보자.

Team agile 101

우리는 애자일 채용은 프로세스가 아닌 문화의 변화로 본다.

많은 팀들은 종종 스탠드업을 하고 있기 때문에 애자일을 하고 있다고 생각한다. 불행히도 애자일은 워터풀 개발 + 스탠드업이 아니다. 스탠드업이 애자일의 중요하지만 조직이 가져가야할 많은 변화 중 하나에 불과하다. 애자일은 고객의 새로운 기능에 우선순위를 정하고 추정하고 배포하고 고객으로부터 정기적으로 피드백을 얻어 통합하는 반복적인 방법론이다. 우리는 프로세스가 아닌 문화의 변경을 애자일 도입으로 본다. 애자일은 무엇보다도 문화적 변화이며, 프로세스와 도구에 영향을 준다. 팀은 조직을 더 신뢰해야하고 고객, 개발 현실, 제품에 관하여 더 배우는 프로세스 변경을 만드는 용기를 가져야한다.

Team ceremonies

첫째, 개별팀이 스프린트 계획, 스프린트 리뷰, 스프린트 회고, 스탠드업 미팅의 스크럼 활동을 하고 있는지  보아라. 둘째, 학습과 성장없이 고립된 프로세스를 따르면 팀이 Agile을 하는데 도움이 되지 않는다. 팀의 성장 여부를 확인하는 방법은 다음과 같다.

• 스크럼마스터에게 마지막 회고가 다음 스프린트 플랜 미팅에 어떠한 영향을 주었는지 묻는다
• 제품 소유자에게 마지막 스프린트 리뷰가 제품에 관해 무엇을 배우게 해주었는지 묻는다. 
• 팀에게 스프린트 리뷰와 회고가 팀의 백로그에 어떤 영향을 주었는지 물어본다. 
• 몇몇 엔지니어에게 팀이 목표를 달성하는데 스탠드 업 미팅이 어떠한 도움이 되었는지 물어본다. 

각 활동를 하는 것으로 충분하지 않다. 팀은 각 활동의 가치를 볼 필요가 있으며, 각 활동은 팀의 접근 방식과 방향에 정기적으로 영향을 미쳐야 한다. 

Team metrics

팀의 애자일 건강을 평가하는 다음 스탭은 개발 프로세스의 가치를 알 수 있게 해주는 매트릭을 보는 것이다. 팀은 JIRA Software의 몇몇 리포트를 사용하여 개발 사이드를 정량화할 수 있다. 

Sprint Report

• 팀은 예측할 수 있나요?
• 팀은 지난 몇 차례의 스프린트 무결성을 존중 했나요? 얼마나 많은 예상밖의 범위 변경이 있었나요?
• 팀은 자연스러운 번다운을 하나요? 혹은 스프린트가 끝날 때 모든 것이 0으로 충돌하나요?

Velocity Chart

Control Chart

• 개발의 마지막 3개월 동안 각 스토리 포인트 값의 사이클 시간이 일관되나요?
  예를 들어 5의 스토리포인트 값이 일괄된 사이클 시간을 가졌나요?
• 장기간에 해결되지 않은 스토리가 있나요?

Cumulative flow diagram

Organizational Culture

애자일에서 프로세스와 매트릭이 중요하지만, 개별팀의 문화가 조직을 지배하는 경향이 있다. 문화는 

SAFe overview

SAFe는 엔터프라이즈 규모에서 Lean-Agile 소프트웨어와 시스템 개발을 구현을 위해 입증된 성공 패턴의 지식 기반이다. 

SAFe는 엔터프라이즈 규모에서 Lean과 Agile을 활용하기 위해 조직에게 행위, 역할, 측정, 관계를 제공한다. 

우리는 기본적인 SAFe의 사상과 개념을 리뷰할 것이다. 

SAFe에 대한 간단한 개용을 보려면 다음 비디오를 시청해라.

비디오는 이 문서의 개념과 용어를 이해하는데 도움이 되는 기초를 설명한다. 

이 문서는 http://www.scaledagileframework.com/ 에 있는 SAFe 4.0 다이어그램과 밀접한 관련이 있다. 

• Portfolio level - SAFe의 최상위 레벨로 엔터프라이즈의 요구사항에 만족되는 시스템과 솔루션을 제공한다. 이는 전략 목적 가치 스트림; 거대하고 복잡한 솔루션을 위한 선택적 레벨, 배포를 위해 요구되는 다중 그룹
• Program level - 개발로 향하는 치명적으로 적용되는 팀 리소스
• Team level - 백로그로부터 정의, 빌드, 그리고 테스트 스토리에 공통 반복 케이던스로 일하는 팀

활동들과 리소스를 정렬하기 위해 SAFe는 두 핵심 구조를 정의하고 사용한다. 

• Agile Release Train ("ART") - 5~12 팀의 그룹(50 ~125명)으로 표현된다. 프로그램 레벨에서 계획, Committing, 비즈니스 값을 배포. ART는 중요 비즈니스 가치를 배포하기위해 충분하다. 
• Program Increment ("PI") - ART 내에서 계획, 배포, 리뷰를 동기화하는 타임박스

SAFe는 WSJF를 추천한다. 

• Cost of Delay(CoD) = Business Value(BV) + Risk Reduction(RR) + Time Criticality(TC) / Opportunity Enablement(OE)
• Job Size는 백로그에서 jobs/epics의 여분에 대행하는 상대적인 Job Size이다. 
• 매트릭을 위한 값들은 Fibonacci 스케일을 사용하여 설정한다. 

Portfolio level

Program portfolio management - strategy, investment, governance, program management를 위한 책임. 

• Epic owner - 비전과 전략 테마에 의한 조정되는 에픽의 식별과 생성을 위한 책임이 있다.
• Enterprise architect - 엔터프라이즈 와이드 아키텍처 시스템, 플랫폼, 인프라스트럭쳐 의존 업무를 위한 책임이 있다.

Value stream level

• Value stream engineer
• Solution management
• Solution architect/engineer
• Customer

Program level

• Release train engineer
• System architect/engineer
• Project management
• Business owner

Team level

• Product owner
• Scrum master
• Scrum team

Portfolio and value stream level

• Create strategic themes
• Define value streams
• Define portfolio backlog

Program level

• Form and launch ARTs
• PI planning
• ART sync
• Solution demo

Team level

• Iteration planning
• Iteration execution
• System demo
• Iteration retrospective

Scaling from concept through delivery

Tool requirements to support SAFe

확장 방법론은 팀이 요구하는 프로세스와 관행을 채택함에 따라 많은 조직의 도구를 한계까지 확장함. 

SAFe와 같은 확장 방법론과 함께 성공하는 도구는 모든 레벨에서 유연한 구성 및 사용법을 제공한다. 우리는 SAFe를 지원하는 도구에서 다음 요소가 중요함

• Support for SAFe ceremonies and activities
  다중 포트폴리오와 프로그램 칸반 보드, 오브젝티브 평가  수행, 모든 플래님, 실행, 데모 활동을 용의하게 지원하는 능력
• Flexible requirement hierarchy
  네스티드 요구사항의 다중 레벨을 허락하는 능력
• Traceability of requirements
  핵심 비즈니스 목적과 테마를 위한 모든 요구사항을 추적하는 능력
• Enable communication
  매크로에서 커뮤니케이션을 위한 능력과 도구내에서 마이크로 레벨
• Support collaboration
  변경과 업데이트의 트래킹 내에 크로스 팀과 크로스 ART 협업할 수 있는 능력
• Tracking and reporting
  프로그레스 리포트 능력과 포트폴리오, 프로그램, 팀레벨 고전; 흥미로운 파티를 위한 실시간 가시화 제공

Atlassian and SAFe

Atlassian JIRA Software, Portfolio for JIRA, Confluence, HipChat은 SAFe 솔루션을 지원하기 위해 요구되는 기본 제품이다.

• JIRA Software 
• Portfolio for JIRA
• Confluence
• HipChat

Solution overview

SAFe 방법론을 해석하고 채택하는 방법에는 여러가지가 있으며, 각 조직은 자신에게 중요한 요소와 제공된 입증된 패턴을 활용하는 방법을 선택해야한다.

아래에 설명된 솔루션은 Atlassian 제품을 사용하여 SAFe를 지원하는 한가지 방법을 보여준다.

Scaling agile Atlassian solution -organization

Scaling agile Atlassian solution - hierarchy

Portfolio level 

Portfolio 레벨에서 메인 목표는 모든 중요한 이니셔티브 intake, evaluate, prioritize, track하는 것이다. 여기에 Portfolio 레벨에서 수행되어야하는 주요 활동이 있다.

Portfolio Epic Owners

Epic Owners

Solution Management Team (Evaluation)

Solution  Management Team (Execution)

Assumptions

Program level

프로그램 수준에서 주요 목표는 작업의 우선순위를 정하고 자원 및 시간을 사용하여 처적의 처리향을 위해 필요한 기술과 역량을 기반으로 팀 간 작업 할당, 활동 조정, 종속성 관리 및 what-if 분석 수행한다.

다음은 프로그램 수준에서 수행되는 주요 활동입니다.

Program and Portfolio Management Team

Product Managers

Product Owner

PI Planning Team

Activities

Tools used

Configuration

Release Train Engineer

Activities

Tools used

Configuration

Team level

 Scrum Masters

Product Owner

Product Owner, Scrum Master, AND the Agile Team

Agile Team Iteration Execution

Scrum Masters, Product Owners, And Agile Team

Scrum Master