지난 10년동안 Agile 방법론의 채택은 증대되었다. 많은 조직들은 Agile과 함께 성장하였고 팀의 계획, 배포, 진행을 추적하는데 도움이되는 확장된 방법론을 사용하고 있다. 많은 확장된 방법론들이 이용가능하지만, Scaled Agile Framework(SAFe)는 대규모 조직에서 가장 널리 채택된 방법론이다. Atlassian은 수년간 Agile 방법론을 채택하면서 대기업을 지원해왔으며 JIRA Software와 Portfolio for JIRA를 사용하여 Agile을 확장하기 위한 강력한 방법을 제공한다. 이 문서는 JIRA Software와 Portfolio for JIRA가 어떻게 SAFe 방법론을 지원하고 조직의 모든 요구사항을 어떻게 지원하는지에 대해 설명한다.
Agile 방법론들(Scrum, Kanban, XP 등)은 개별 팀 계획 및 배포 활동에 초점을 둔다. 각 방법론은 점진적으로 가치있는 제품의 배포를 지속적으로 확인하고 돕는 특정 역할, 활동, 보고서를 가진다. 개별 팀의 경우 이러한 접근은 성공하지만, 최근 이러한 방법은 여러 팀을 거쳐 확장되고 높은 수준의 업무를 계획하는데 어려움을 준다.
Agile 팀은 성숙하고 성장함에따라 다음 방법에 대해 어려움을 겪고 있다.
초기에는 Agile 리더들이 이러한 문제를 해결하기 위한 반복가능한 방법을 생성하는 것이 어려웠다. 2011년에 Scaled Agile Inc.는 크고 작은 조직에 성공적인 패턴을 제공하는 이러한 문제를 해결하는데 도움이 되는 Scaled Agile Framework for the Enterprise 1.0를 발표했다. SAFe는 지금 4.5가 출시되었고 고객의 피드팩과 실제 사용 패턴에 따라 업데이트 되고 있다. 이는 Agile 확장 방법으로 널리 채용되고 있다.
조직 레벨에서 Agile을 확장하는 것은 개별 팀과 동일하게 전체 조직에 많은 동일한 혜택을 제공한다. 이러한 이점은 Time to market 단축, 개발 프로세스 간소화, 조직 전반의 투명성 향상을 포함한다. 애자일 확장에 두 가지 가장 큰 문제점은 종종 스펙트럼의 반대편에서 발생한다. 이러한 문제는 기본 Waterfall 컨셉에서 발생한다.
애자일을 확장하기 위해 이러한 고전점을 벗어나고 건전한 기반을 조성하는 프렉티스를 살펴보자.
우리는 애자일 채용은 프로세스가 아닌 문화의 변화로 본다.
많은 팀들은 종종 스탠드업을 하고 있기 때문에 애자일을 하고 있다고 생각한다. 불행히도 애자일은 워터풀 개발 + 스탠드업이 아니다. 스탠드업이 애자일의 중요하지만 조직이 가져가야할 많은 변화 중 하나에 불과하다. 애자일은 고객의 새로운 기능에 우선순위를 정하고 추정하고 배포하고 고객으로부터 정기적으로 피드백을 얻어 통합하는 반복적인 방법론이다. 우리는 프로세스가 아닌 문화의 변경을 애자일 도입으로 본다. 애자일은 무엇보다도 문화적 변화이며, 프로세스와 도구에 영향을 준다. 팀은 조직을 더 신뢰해야하고 고객, 개발 현실, 제품에 관하여 더 배우는 프로세스 변경을 만드는 용기를 가져야한다.
첫째, 개별팀이 스프린트 계획, 스프린트 리뷰, 스프린트 회고, 스탠드업 미팅의 스크럼 활동을 하고 있는지 보아라. 둘째, 학습과 성장없이 고립된 프로세스를 따르면 팀이 Agile을 하는데 도움이 되지 않는다. 팀의 성장 여부를 확인하는 방법은 다음과 같다.
각 활동를 하는 것으로 충분하지 않다. 팀은 각 활동의 가치를 볼 필요가 있으며, 각 활동은 팀의 접근 방식과 방향에 정기적으로 영향을 미쳐야 한다.
팀의 애자일 건강을 평가하는 다음 스탭은 개발 프로세스의 가치를 알 수 있게 해주는 매트릭을 보는 것이다. 팀은 JIRA Software의 몇몇 리포트를 사용하여 개발 사이드를 정량화할 수 있다.
애자일에서 프로세스와 매트릭이 중요하지만, 개별팀의 문화가 조직을 지배하는 경향이 있다. 문화는
SAFe는 엔터프라이즈 규모에서 Lean-Agile 소프트웨어와 시스템 개발을 구현을 위해 입증된 성공 패턴의 지식 기반이다.
SAFe는 엔터프라이즈 규모에서 Lean과 Agile을 활용하기 위해 조직에게 행위, 역할, 측정, 관계를 제공한다.
우리는 기본적인 SAFe의 사상과 개념을 리뷰할 것이다.
SAFe에 대한 간단한 개용을 보려면 다음 비디오를 시청해라.
비디오는 이 문서의 개념과 용어를 이해하는데 도움이 되는 기초를 설명한다.
이 문서는 http://www.scaledagileframework.com/ 에 있는 SAFe 4.0 다이어그램과 밀접한 관련이 있다.
활동들과 리소스를 정렬하기 위해 SAFe는 두 핵심 구조를 정의하고 사용한다.
SAFe는 WSJF를 추천한다.
Program portfolio management - strategy, investment, governance, program management를 위한 책임.
Value stream level
Program level
Team level
Portfolio and value stream level
Program level
Team level
Scaling from concept through delivery
확장 방법론은 팀이 요구하는 프로세스와 관행을 채택함에 따라 많은 조직의 도구를 한계까지 확장함.
SAFe와 같은 확장 방법론과 함께 성공하는 도구는 모든 레벨에서 유연한 구성 및 사용법을 제공한다. 우리는 SAFe를 지원하는 도구에서 다음 요소가 중요함
Atlassian JIRA Software, Portfolio for JIRA, Confluence, HipChat은 SAFe 솔루션을 지원하기 위해 요구되는 기본 제품이다.
SAFe 방법론을 해석하고 채택하는 방법에는 여러가지가 있으며, 각 조직은 자신에게 중요한 요소와 제공된 입증된 패턴을 활용하는 방법을 선택해야한다.
아래에 설명된 솔루션은 Atlassian 제품을 사용하여 SAFe를 지원하는 한가지 방법을 보여준다.
Portfolio 레벨에서 메인 목표는 모든 중요한 이니셔티브 intake, evaluate, prioritize, track하는 것이다. 여기에 Portfolio 레벨에서 수행되어야하는 주요 활동이 있다.
Activities | Portfolio Epic Owners는 요청을 퍼널(funnel)에 제출한다. 추가적으로 Program Epic Owners는 포트폴리오 레벨 에픽과 관련된 요청을 생성할 수 있다. |
---|---|
Tools used | 도입(intake)과 흐름(flow) 관리를 위해 JIRA Software Kanban Board |
Configuration |
|
Activities | Epic Owners는 Value 문장들과 경량 비즈니스 케이스를 제출 |
---|---|
Tools used | 문서 기반의 템플릿을 위한 Confluence |
Configuration | 비즈니스 케이스, Value 문장들, Value 스트림 템플릿 |
Activities | Solution Management Team은 이니셔티브에 대한 전략적인 테마, 비전, 승인, 거절을 가지고 에픽의 정렬을 평가한다. 그리고 최종적으로 WSJF 측정을 사용한 실행을 위해 우선순위를 정한다. |
---|---|
Tools used | JIRA Software는 WSJF 계산을 위해 계산된 필드를 커스텀한다. |
Configuration |
|
Activities | 우선순위를 정하고 실행에 옮기며, Solution Management Team은 수용가능성을 정의하고 기능을 분해한다. 다음 활동을 포함한다.
|
---|---|
Tools used | Feature Breakdown을 위해 Portfolio for JIRA |
Configuration |
|
Assumptions
프로그램 수준에서 주요 목표는 작업의 우선순위를 정하고 자원 및 시간을 사용하여 처적의 처리향을 위해 필요한 기술과 역량을 기반으로 팀 간 작업 할당, 활동 조정, 종속성 관리 및 what-if 분석 수행한다.
다음은 프로그램 수준에서 수행되는 주요 활동입니다.
Activities | Program and Portfolio Management Team은 프로그램 보드를 사용하여 수요와 지속적인 가치 흐름을 관리한다. |
---|---|
Tools used |
|
Configuration |
|
Activities | Product Managers는 PI 계획을 위해 승인된 이니셔티브와 에픽을 각각 보유한다. |
---|---|
Tools used | PI 계획과 Story Breakdown을 위한 Portfolio for JIRA |
Configuration | 다음을 기반으로 프로그램 레벨 계획 생성
|
Activities | Product Owner는 Epic을 스토리로 분해한다. 스토리의 가치를 추정하고 백로그에 우선순위를 준다.
|
---|---|
Tool used | PI 계획과 Story Breakdown을 위한 Portfolio for JIRA |
Configuration | 추가적인 구성 없음
|
Activities
Tools used
Configuration
Activities
Tools used
Configuration
Scrum Masters
Activities | 팀 특정 애자일 보드를 만들기 위해 Scrum Master |
---|---|
Tools used | 팀을 위한 JIRA Software scrum board |
Configuration |
|
Activities | Product Owner는 PI 계획 세션의 결과물을 기반으로 팀 백로그를 관리한다. 이 백로그는 새로운 스토리, Defect, 리팩토링, 디자인, 기술 업데이트를 포함한다. Product Owner에의해 다음 활동들이 수행된다.
|
---|---|
Tool used | JIRA Software scrum board per team |
Configuration | 우리의 솔루션에는 스프린트 작업 계획, 관리 및 제공을 위한 3개의 팀 스크럼 보드가 있다.
|
Activities | Product Owner, Scrum Master, Agile Team은 각 스프린트의 시작에서 iteration planning 미팅을 개최한다. 다음 활동들이 수행된다.
|
---|---|
Tools used | JIRA Software scrum board per team - backlog |
Configuration | 다음 구성을 제안한다.
|
Activities | Agile 팀이 iteration을 실행하면, 그들은 |
---|---|
Tools used | JIRA Software scrum board - active sprint and report view |
Configuration | 우리 솔루션에서, 다음 구성을 제안한다.
|
Activities | |
---|---|
Tools used | HipChat |
Configuration | 각 팀과 cross team PI planning을 위한 HipChat room |
Activities | Scrum Master는 interation의 끝에서 스프린트를 닫는다. 다음 활동들이 수행된다.
|
---|---|
Tools used |
|
Configuration | 요구되는 추가적인 구성 없다.
|