Contents
-
Part 1. What We Found
- 1. Accelerate
- 2. Measuring Performance
- 3. Measuring and Changing Culture
- 4. Technical Practice
- 5. Architecture
- 6. Integrating Infosec into the Delivery Lifecycle
- 7. Management Practices for Software
- 8. Product Development
- 9. Making Work Sustainable
- 10. Employee Satisfaction, Identity, and Engagement
- 11. Leaders and Managers
- Part 2. The Research
- Part 3. Transformation
Quick Reference: Capabilities to Drive Improvement
Our research has uncovered 24 key capabilities that drive improvements in software delivery performance. This reference will point you to them in the book. A detailed guide is found in Appendix A. They are presented in no particular order.
The capabilities are classified into five categories:
- Continuous delivery
- Architecture
- Product and process
- Lean management and monitoring
- Cultural
CONTINUOUS DELIVERY CAPABILITIES
- Version control: Chapter 4
- Deployment automation: Chapter 4
- Continuous integration: Chapter 4
- Trunk-based development: Chapter 4
- Test automation: Chapter 4
- Test data management: Chapter 4
- Shift left on security: Chapter 6
- Continuous delivery (CD): Chapter 4
ARCHITECTURE CAPABILITIES
- Loosely coupled architecture: Chapter 5
- Empowered teams: Chapter 5
PRODUCT AND PROCESS CAPABILITIES
- Customer feedback: Chapter 8
- Value stream: Chapter 8
- Working in small batches: Chapter 8
- Team experimentation: Chapter 8
LEAN MANAGEMENT AND MONITORING CAPABILITIES
- Change approval processes: Chapter 7
- Monitoring: Chapter 7
- Proactive notification: Chapter 13
- WIP limits: Chapter 7
- Visualizing work: Chapter 7
CULTURAL CAPABILITIES
- Westrum organizational culture: Chapter 3
- Supporting learning: Chapter 10
- Collaboration among teams: Chapters 3 and 5
- Job satisfaction: Chapter 10
- Transformational leadership: Chapter 11
Preface
Part 1. What We Found
1. Accelerate
To remain competitive and excel in the market, organizations must accelerate:
- delivery of goods and services to delight their customers;
- engagement with the market to detect and understand customer demand;
- anticipation of compliance and regulatory changes that impact their systems; and
- response to potential risks such as security threats or changes in the economy.
이 가속(acceleration)의 핵심에는 소프트웨어가 있다. 은행도 더 이상 골드바를 금고에 넣는 방식으로 가치를 전달하지 않고, 거래를 더 빠르고 안전하게, 또 고객과 대면할 새로운 채널과 제품을 발견하는 방식으로 가치를 전달한다 (소프트웨어를 사용한다는 얘기.)
소프트웨어와 기술이 차별점이다.
데브옵스 성숙도에 대한 경영진과 실무자의 추정치 사이의 불일치에 대한 이러한 조사 결과는 리더가 종종 놓치는 두 가지 고려 사항을 강조합니다.
- 첫째, 실무자의 데브옵스 성숙도 또는 역량에 대한 추정치가 더 정확하다고 가정하면(실무자가 업무에 더 가깝기 때문에) 조직 내에서 가치 제공 및 성장의 잠재력은 경영진이 현재 인식하는 것보다 훨씬 더 클 수 있습니다.
- 둘째, 이러한 단절은 데브옵스 역량을 정확하게 측정하고 이러한 측정 결과를 리더에게 전달하여 조직의 기술 태세에 대한 의사 결정과 전략 수립에 활용할 수 있도록 해야 할 필요성을 명확하게 해줍니다.
FOCUS ON CAPABILITIES, NOT MATURITY
성숙도 모델은 업계에서 매우 인기가 있지만, 성숙도 모델은 사용하기에 적절한 도구나 마음가짐이 아니라는 점은 아무리 강조해도 지나치지 않습니다. 대신, 소프트웨어 배포를 가속화하려는 조직은 역량 측정 모델로 전환하는 것이 필수적입니다. 이는 네 가지 요인 때문입니다.
첫째, 성숙도 모델은 조직이 성숙한 상태에 '도달'한 후 여정이 끝났다고 선언하는 데 중점을 두는 반면, 기술 혁신은 지속적인 개선 패러다임을 따라야 합니다. 또는 역량 모델은 기술 및 비즈니스 환경이 끊임없이 변화하고 있음을 인식하고 조직이 지속적으로 개선하고 발전하도록 돕는 데 중점을 둡니다. 가장 혁신적인 기업과 최고의 성과를 내는 조직은 항상 더 나은 기업이 되기 위해 노력하며, 개선 또는 혁신 여정을 '성숙'하거나 '완료'했다고 생각하지 않으며, 이러한 사실은 연구에서도 확인할 수 있습니다.
둘째, 성숙도 모델은 모든 팀과 조직이 거쳐야 할 유사한 기술, 도구 또는 역량 세트를 규정하는 '잠금 단계' 또는 선형 공식인 경우가 많습니다. 성숙도 모델은 '레벨 1'과 '레벨 2'가 모든 팀과 조직에서 동일하게 보인다고 가정하지만, 기술 분야에서 일하는 사람들은 그렇지 않다는 것을 알고 있습니다. 반면 역량 모델은 다차원적이고 역동적이기 때문에 조직의 여러 부분이 개선에 대한 맞춤형 접근 방식을 취하고 현재 상황과 장단기 목표에 따라 가장 큰 이점을 얻을 수 있는 역량에 집중할 수 있습니다. 팀마다 고유한 상황, 고유한 시스템, 고유한 목표, 고유한 제약 조건이 있으며, 혁신을 가속화하기 위해 다음에 집중해야 할 것은 이러한 요소에 따라 달라집니다.
셋째, 역량 모델은 주요 결과와 역량 또는 레버리지가 이러한 결과의 개선을 주도하는 방법, 즉 결과 기반에 중점을 둡니다. 이를 통해 기술 리더십은 주요 결과를 개선하기 위한 역량에 초점을 맞춘 높은 수준의 목표에 대한 명확한 방향과 전략을 제시할 수 있습니다. 또한 팀 리더와 개별 기여자가 현재 팀이 집중하고 있는 역량과 관련된 개선 목표를 설정할 수 있습니다. 대부분의 성숙도 모델은 조직의 기술 숙련도 또는 도구 설치 기반을 성과와 연결하지 않고 단순히 측정합니다. 이러한 지표는 비교적 쉽게 측정할 수 있지만, 비즈니스에 미치는 영향에 대해서는 아무 것도 알려주지 않기 때문에 결국 허영 지표가 됩니다.
넷째, 성숙도 모델은 달성해야 할 기술, 프로세스 및 조직 능력의 정적인 수준을 정의합니다. 끊임없이 변화하는 기술 및 비즈니스 환경의 특성을 고려하지 않습니다. 자체 연구와 데이터에 따르면 업계는 변화하고 있으며, 현재 충분히 우수하고 심지어 '높은 성과'를 내는 것이 내년에는 더 이상 충분하지 않을 수 있습니다. 반면 역량 모델은 역동적으로 변화하는 환경에 대응하고 팀과 조직이 경쟁력을 유지하는 데 필요한 기술과 역량을 개발하는 데 집중할 수 있도록 합니다.
역량 패러다임에 집중함으로써 조직은 지속적으로 개선을 추진할 수 있습니다. 또한 조직은 올바른 역량에 집중함으로써 성과를 개선하여 향상된 속도와 안정성으로 소프트웨어를 개발 및 제공할 수 있습니다. 실제로 최고의 성과를 내는 기업들은 바로 이러한 방식으로 해마다 지속적으로 성과를 달성하고 어제의 성과에 안주하지 않습니다.
다음 장에서는 소프트웨어 제공 성과를 측정하는 방법과 코호트의 성과에 대해 자세히 설명합니다. 요약하자면, 2017년에 성과가 낮은 팀과 비교했을 때 성과가 높은 팀은 다음과 같은 결과를 얻었습니다:
- 46배 더 빈번한 코드 배포
- 커밋에서 배포까지의 리드 타임 440배 단축
- 다운타임에서 복구하는 데 걸리는 평균 시간 170배 단축
- 변경 실패율 5배 감소(변경이 실패할 확률 1/5)
궁금하실 겁니다: 고성과 팀은 어떻게 놀라운 소프트웨어 제공 성과를 달성할 수 있을까요? 그것은 바로 올바른 레버를 돌리는 것, 즉 올바른 역량을 향상시킴으로써 가능합니다.
4년에 걸친 연구 프로그램을 통해 소프트웨어 배포 성과를 높이고 조직 성과에 영향을 미치는 역량을 파악할 수 있었으며, 이러한 역량이 모든 유형의 조직에 효과가 있다는 것을 발견했습니다. 이 연구는 전 세계의 레거시 및 그린필드 기술 스택을 사용하는 모든 산업, 모든 규모의 조직을 대상으로 조사되었으므로 이 책에 담긴 결과는 조직의 팀에도 적용될 수 있습니다.
2. Measuring Performance
소프트웨어 영역에서는 제조업과 달리 인벤토리가 눈에 보이지 않기 때문에 성과를 측정하기가 어렵습니다. 또한 업무를 세분화하는 방식이 비교적 임의적이며, 특히 애자일 소프트웨어 개발 패러다임에서는 설계와 배포 활동이 동시에 진행됩니다. 실제로 구현을 시도하면서 배운 것을 바탕으로 설계를 변경하고 발전시켜 나가야 합니다. 따라서 첫 번째 단계는 소프트웨어 배포 성능에 대한 유효하고 신뢰할 수 있는 측정을 정의하는 것이어야 합니다.
3. Measuring and Changing Culture
4. Technical Practice
5. Architecture
6. Integrating Infosec into the Delivery Lifecycle
7. Management Practices for Software
8. Product Development
9. Making Work Sustainable
10. Employee Satisfaction, Identity, and Engagement
11. Leaders and Managers
Part 2. The Research
12. The Science Behind This Book
13. Introduction to Psychometrics
14. Why Use a Survey
15. The Data for the Project
Part 3. Transformation
16. High-Performance Leadership and Management