Contents

    1. Quick Reference: Capabilities to Drive Improvement
    2. Preface
  2. Part 1. What We Found
    1. 1. Accelerate
    2. 2. Measuring Performance
    3. 3. Measuring and Changing Culture
    4. 4. Technical Practice
    5. 5. Architecture
    6. 6. Integrating Infosec into the Delivery Lifecycle
    7. 7. Management Practices for Software
    8. 8. Product Development
    9. 9. Making Work Sustainable
    10. 10. Employee Satisfaction, Identity, and Engagement
    11. 11. Leaders and Managers
  3. Part 2. The Research
    1. 12. The Science Behind This Book
    2. 13. Introduction to Psychometrics
    3. 14. Why Use a Survey
    4. 15. The Data for the Project
  4. Part 3. Transformation
    1. 16. High-Performance Leadership and Management
    2. Conclusion

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 CAPABILITIES

ARCHITECTURE CAPABILITIES

PRODUCT AND PROCESS CAPABILITIES

LEAN MANAGEMENT AND MONITORING CAPABILITIES

CULTURAL CAPABILITIES

Preface

Part 1. What We Found

1. Accelerate

To remain competitive and excel in the market, organizations must accelerate:

이 가속(acceleration)의 핵심에는 소프트웨어가 있다. 은행도 더 이상 골드바를 금고에 넣는 방식으로 가치를 전달하지 않고, 거래를 더 빠르고 안전하게, 또 고객과 대면할 새로운 채널과 제품을 발견하는 방식으로 가치를 전달한다 (소프트웨어를 사용한다는 얘기.)

소프트웨어와 기술이 차별점이다.

데브옵스 성숙도에 대한 경영진과 실무자의 추정치 사이의 불일치에 대한 이러한 조사 결과는 리더가 종종 놓치는 두 가지 고려 사항을 강조합니다.

FOCUS ON CAPABILITIES, NOT MATURITY

성숙도 모델은 업계에서 매우 인기가 있지만, 성숙도 모델은 사용하기에 적절한 도구나 마음가짐이 아니라는 점은 아무리 강조해도 지나치지 않습니다. 대신, 소프트웨어 배포를 가속화하려는 조직은 역량 측정 모델로 전환하는 것이 필수적입니다. 이는 네 가지 요인 때문입니다.

첫째, 성숙도 모델은 조직이 성숙한 상태에 '도달'한 후 여정이 끝났다고 선언하는 데 중점을 두는 반면, 기술 혁신은 지속적인 개선 패러다임을 따라야 합니다. 또는 역량 모델은 기술 및 비즈니스 환경이 끊임없이 변화하고 있음을 인식하고 조직이 지속적으로 개선하고 발전하도록 돕는 데 중점을 둡니다. 가장 혁신적인 기업과 최고의 성과를 내는 조직은 항상 더 나은 기업이 되기 위해 노력하며, 개선 또는 혁신 여정을 '성숙'하거나 '완료'했다고 생각하지 않으며, 이러한 사실은 연구에서도 확인할 수 있습니다.

둘째, 성숙도 모델은 모든 팀과 조직이 거쳐야 할 유사한 기술, 도구 또는 역량 세트를 규정하는 '잠금 단계' 또는 선형 공식인 경우가 많습니다. 성숙도 모델은 '레벨 1'과 '레벨 2'가 모든 팀과 조직에서 동일하게 보인다고 가정하지만, 기술 분야에서 일하는 사람들은 그렇지 않다는 것을 알고 있습니다. 반면 역량 모델은 다차원적이고 역동적이기 때문에 조직의 여러 부분이 개선에 대한 맞춤형 접근 방식을 취하고 현재 상황과 장단기 목표에 따라 가장 큰 이점을 얻을 수 있는 역량에 집중할 수 있습니다. 팀마다 고유한 상황, 고유한 시스템, 고유한 목표, 고유한 제약 조건이 있으며, 혁신을 가속화하기 위해 다음에 집중해야 할 것은 이러한 요소에 따라 달라집니다.

셋째, 역량 모델은 주요 결과와 역량 또는 레버리지가 이러한 결과의 개선을 주도하는 방법, 즉 결과 기반에 중점을 둡니다. 이를 통해 기술 리더십은 주요 결과를 개선하기 위한 역량에 초점을 맞춘 높은 수준의 목표에 대한 명확한 방향과 전략을 제시할 수 있습니다. 또한 팀 리더와 개별 기여자가 현재 팀이 집중하고 있는 역량과 관련된 개선 목표를 설정할 수 있습니다. 대부분의 성숙도 모델은 조직의 기술 숙련도 또는 도구 설치 기반을 성과와 연결하지 않고 단순히 측정합니다. 이러한 지표는 비교적 쉽게 측정할 수 있지만, 비즈니스에 미치는 영향에 대해서는 아무 것도 알려주지 않기 때문에 결국 허영 지표가 됩니다.

넷째, 성숙도 모델은 달성해야 할 기술, 프로세스 및 조직 능력의 정적인 수준을 정의합니다. 끊임없이 변화하는 기술 및 비즈니스 환경의 특성을 고려하지 않습니다. 자체 연구와 데이터에 따르면 업계는 변화하고 있으며, 현재 충분히 우수하고 심지어 '높은 성과'를 내는 것이 내년에는 더 이상 충분하지 않을 수 있습니다. 반면 역량 모델은 역동적으로 변화하는 환경에 대응하고 팀과 조직이 경쟁력을 유지하는 데 필요한 기술과 역량을 개발하는 데 집중할 수 있도록 합니다.

역량 패러다임에 집중함으로써 조직은 지속적으로 개선을 추진할 수 있습니다. 또한 조직은 올바른 역량에 집중함으로써 성과를 개선하여 향상된 속도와 안정성으로 소프트웨어를 개발 및 제공할 수 있습니다. 실제로 최고의 성과를 내는 기업들은 바로 이러한 방식으로 해마다 지속적으로 성과를 달성하고 어제의 성과에 안주하지 않습니다.

다음 장에서는 소프트웨어 제공 성과를 측정하는 방법과 코호트의 성과에 대해 자세히 설명합니다. 요약하자면, 2017년에 성과가 낮은 팀과 비교했을 때 성과가 높은 팀은 다음과 같은 결과를 얻었습니다:

궁금하실 겁니다: 고성과 팀은 어떻게 놀라운 소프트웨어 제공 성과를 달성할 수 있을까요? 그것은 바로 올바른 레버를 돌리는 것, 즉 올바른 역량을 향상시킴으로써 가능합니다.

4년에 걸친 연구 프로그램을 통해 소프트웨어 배포 성과를 높이고 조직 성과에 영향을 미치는 역량을 파악할 수 있었으며, 이러한 역량이 모든 유형의 조직에 효과가 있다는 것을 발견했습니다. 이 연구는 전 세계의 레거시 및 그린필드 기술 스택을 사용하는 모든 산업, 모든 규모의 조직을 대상으로 조사되었으므로 이 책에 담긴 결과는 조직의 팀에도 적용될 수 있습니다.

2. Measuring Performance

소프트웨어 영역에서는 제조업과 달리 인벤토리가 눈에 보이지 않기 때문에 성과를 측정하기가 어렵습니다. 또한 업무를 세분화하는 방식이 비교적 임의적이며, 특히 애자일 소프트웨어 개발 패러다임에서는 설계와 배포 활동이 동시에 진행됩니다. 실제로 구현을 시도하면서 배운 것을 바탕으로 설계를 변경하고 발전시켜 나가야 합니다. 따라서 첫 번째 단계는 소프트웨어 배포 성능에 대한 유효하고 신뢰할 수 있는 측정을 정의하는 것이어야 합니다.

The Flaws in Previous Attempts to Measure Performance

이전 성과 측정 시도의 결함

소프트웨어 팀의 성과를 측정하려는 시도는 많이 있었습니다. 이러한 측정의 대부분은 생산성에 초점을 맞춥니다. 일반적으로 두 가지 단점이 있습니다. 첫째, 결과보다는 아웃풋에 초점을 맞춘다는 점입니다. 둘째, 팀 또는 글로벌 측정보다는 개인 또는 로컬 측정에 초점을 맞춥니다. 코드 줄 수, 속도, 활용도 세 가지를 예로 들어 보겠습니다.

코드 줄 수로 생산성을 측정하는 것은 소프트웨어 분야에서 오랜 역사를 가지고 있습니다. 일부 회사에서는 개발자에게 일주일에 투입한 코드 줄 수를 기록하도록 요구하기도 했습니다.1 하지만 실제로는 1,000줄의 문제 해결 방법보다는 10줄의 해결 방법을 선호합니다. 개발자에게 코드 작성에 대한 보상을 제공하면 소프트웨어가 비대해져 유지보수 비용과 변경 비용이 높아집니다. 이상적으로는 최소한의 코드로 비즈니스 문제를 해결한 개발자에게 보상을 제공해야 하며, 코드를 전혀 작성하지 않거나 코드를 삭제(비즈니스 프로세스 변경 등)하여 문제를 해결할 수 있다면 더욱 좋습니다. 하지만 코드 줄을 최소화하는 것 역시 이상적인 방법은 아닙니다. 극단적으로 말하자면, 아무도 이해할 수 없는 한 줄의 코드로 작업을 수행하는 것은 쉽게 이해하고 유지 관리할 수 있는 몇 줄의 코드를 작성하는 것보다 바람직하지 않다는 단점도 있습니다.

애자일 소프트웨어 개발의 등장과 함께 생산성을 측정하는 새로운 방법인 속도가 등장했습니다. 많은 애자일 학파에서는 문제를 스토리로 분류합니다. 그런 다음 개발자가 스토리를 추정하고 스토리를 완료하는 데 예상되는 상대적인 노력을 나타내는 여러 "포인트"를 할당합니다. 반복이 끝나면 고객이 승인한 총 포인트 수가 기록되며, 이것이 팀의 속도입니다. 예를 들어 팀이 계획하고 예상한 모든 작업을 완료하는 데 걸리는 시간을 추정하는 데 사용할 수 있는 등, 벨로시티는 역량 계획 도구로 사용하도록 설계되었습니다. 하지만 일부 관리자는 팀 생산성을 측정하거나 팀을 비교하는 방법으로도 사용하기도 합니다.

속도를 생산성 지표로 사용하는 데에는 몇 가지 결함이 있습니다. 첫째, 속도는 절대적인 것이 아니라 상대적이고 팀에 따라 달라지는 측정치입니다. 팀마다 처한 환경이 크게 다르기 때문에 속도를 비교할 수 없는 경우가 많습니다. 둘째, 속도를 생산성 척도로 사용할 때 팀은 필연적으로 속도를 높이기 위해 노력합니다. 예상 시간을 부풀리고 다른 팀과의 협업을 희생하면서까지 최대한 많은 스토리를 완성하는 데 집중하게 됩니다(이로 인해 자신의 속도는 감소하고 다른 팀의 속도는 증가하여 좋지 않게 보일 수 있습니다). 이는 의도된 목적에 대한 속도 활용도를 떨어뜨릴 뿐만 아니라 팀 간의 협업을 저해합니다.

마지막으로, 많은 조직에서 생산성을 대신하여 사용률을 측정합니다. 이 방법의 문제점은 높은 사용률은 어느 정도까지만 좋다는 것입니다. 사용률이 일정 수준 이상이 되면 계획에 없던 작업, 계획 변경 또는 개선 작업을 수용할 수 있는 여유 용량(또는 '여유')이 없습니다. 그 결과 작업을 완료하는 데 걸리는 시간이 길어집니다. 수학의 대기열 이론에 따르면 사용률이 100%에 가까워지면 리드 타임은 무한대에 가까워집니다. 즉, 사용률이 매우 높은 수준에 도달하면 팀이 작업을 완료하는 데 기하급수적으로 더 많은 시간이 소요됩니다. 작업을 얼마나 빨리 완료할 수 있는지를 측정하는 리드 타임은 앞서 살펴본 다른 지표의 단점이 없는 생산성 지표이므로, 경제적으로 최적의 방식으로 리드 타임과 균형을 맞추기 위해 활용도를 관리하는 것이 필수적입니다.

Measuring Software Delivery Performance

성공적인 성과 측정에는 두 가지 주요 특징이 있어야 합니다. 첫째, 팀이 서로 경쟁하지 않도록 글로벌 성과에 초점을 맞춰야 합니다. 개발자에게는 처리량에 대한 보상을, 운영자에게는 안정성에 대한 보상을 주는 것이 대표적인 예입니다. 이는 개발자가 품질이 낮은 코드를 운영팀에 넘기고, 운영팀은 변화를 억제하기 위해 까다로운 변경 관리 프로세스를 마련하는 '혼란의 벽'을 만드는 주요 원인입니다. 둘째, 성과 측정은 산출물이 아닌 결과에 초점을 맞춰야 합니다. 실제로 조직 목표 달성에 도움이 되지 않는 많은 양의 바쁜 업무에 투입된 직원에게 보상을 제공해서는 안 됩니다.

이러한 기준을 충족하는 제공 성과 측정 기준을 찾던 중 제공 리드 타임, 배포 빈도, 서비스 복구 시간, 변경 실패율의 네 가지를 결정했습니다. 이 섹션에서는 이러한 특정 지표를 선택한 이유에 대해 설명합니다.

리드 타임을 지표로 삼는 것은 린 이론의 핵심 요소입니다. 리드 타임은 고객이 요청을 한 후 요청이 충족될 때까지 걸리는 시간을 말합니다. 그러나 고객이 예상하지 못한 방식으로 여러 고객을 만족시키는 것을 목표로 하는 제품 개발의 경우 리드 타임에는 제품 또는 기능을 설계하고 검증하는 데 걸리는 시간과 고객에게 기능을 제공하는 데 걸리는 시간이라는 두 가지 부분이 있습니다. 리드 타임의 설계 부분에서는 언제 시계를 시작해야 할지 불분명하고 변동성이 큰 경우가 많습니다. 이러한 이유로 라이너슨은 리드 타임의 이 부분을 "퍼지 프런트 엔드"라고 부릅니다(Reinertsen 2009). 그러나 리드 타임의 전달 부분, 즉 작업이 구현, 테스트 및 전달되는 데 걸리는 시간은 측정하기가 더 쉽고 변동성이 낮습니다. 표 2.1(Kim et al. 2016)은 이 두 영역의 차이점을 보여줍니다.

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

accelerate 2023-06-14 082233.jpg

Figure 16.4: High-Performance Team, Management, and Leadership Behaviors and Practices (not a complete list, for a larger, downloadable version visit https://bit.ly/high-perf-behaviors-practices)

transformation_practices.pdf

Conclusion

Capabilities to Drive Improvement

Our research has uncovered 24 key capabilities that drive improvements in software delivery performance in a statistically significant way. Our book details these findings. This appendix provides you with a handy list of these capabilities, each with a pointer to the chapter that covers it in detail (see also Figure A.1).

We have classified these capabilities into five categories:

CONTINUOUS DELIVERY CAPABILITIES

Use version control for all production artifacts.

Version control is the use of a version control system, such as GitHub or Subversion, for all production artifacts, including application code, application configurations, system configurations, and scripts for automating build and configuration of the environment. See Chapter 4.

Automate your deployment process.
Deployment automation is the degree to which deployments are fully automated and do not require manual intervention. See Chapter 4.
Implement continuous integration.
Continuous integration (CI) is the first step towards continuous delivery. This is a development practice where code is regularly checked in, and each check-in triggers a set of quick tests to discover serious regressions, which developers fix immediately. The CI process creates canonical builds and packages that are ultimately deployed and released. See Chapter 4.
Use trunk-based development methods.
Trunk-based development has been shown to be a predictor of high performance in software development and delivery. It is characterized by fewer than three active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged into master; and application teams rarely or never having “code lock” periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases. See Chapter 4.
Implement test automation.
Test automation is a practice where software tests are run automatically (not manually) continuously throughout the development process. Effective test suites are reliable—that is, tests find real failures and only pass releasable code. Note that developers should be primarily responsible for creation and maintenance of automated test suites. See Chapter 4.
Support test data management.
Test data requires careful maintenance, and test data management is becoming an increasingly important part of automated testing. Effective practices include having adequate data to run your test suite, the ability to acquire necessary data on demand, the ability to condition your test data in your pipeline, and the data not limiting the amount of tests you can run. We do caution, however, that teams should minimize, whenever possible, the amount of test data needed to run automated tests. See Chapter 4.
Shift left on security.
Integrating security into the design and testing phases of the software development process is key to driving IT performance. This includes conducting security reviews of applications, including the infosec team in the design and demo process for applications, using preapproved security libraries and packages, and testing security features as a part of the automated testing suite. See Chapter 4.
Implement continuous delivery (CD).
CD is a development practice where software is in a deployable state throughout its lifecycle, and the team prioritizes keeping the software in a deployable state over working on new features. Fast feedback on the quality and deployability of the system is available to all team members, and when they get reports that the system isn’t deployable, fixes are made quickly. Finally, the system can be deployed to production or end users at any time, on demand. See Chapter 4.

ARCHITECTURE CAPABILITIES

Use a loosely coupled architecture.
This affects the extent to which a team can test and deploy their applications on demand, without requiring orchestration with other services. Having a loosely coupled architecture allows your teams to work independently, without relying on other teams for support and services, which in turn enables them to work quickly and deliver value to the organization. See Chapter 5.
Architect for empowered teams.
Our research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance. No one knows better than practitioners what they need to be effective. See Chapter 5. (The product management counterpart to this is found in Chapter 8.)

PRODUCT AND PROCESS CAPABILITIES

Gather and implement customer feedback.
Our research has found that whether organizations actively and regularly seek customer feedback and incorporate this feedback into the design of their products is important to software delivery performance. See Chapter 8.
Make the flow of work visible through the value stream.
Teams should have a good understanding of and visibility into the flow of work from the business all the way through to customers, including the status of products and features. Our research has found this has a positive impact on IT performance. See Chapter 8.
Work in small batches.
Teams should slice work into small pieces that can be completed in a week or less. The key is to have work decomposed into small features that allow for rapid development, instead of developing complex features on branches and releasing them infrequently. This idea can be applied at the feature and the product level. (An MVP is a prototype of a product with just enough features to enable validated learning about the product and its business model.) Working in small batches enables short lead times and faster feedback loops. See Chapter 8.
Foster and enable team experimentation.
Team experimentation is the ability of developers to try out new ideas and create and update specifications during the development process, without requiring approval from outside of the team, which allows them to innovate quickly and create value. This is particularly impactful when combined with working in small batches, incorporating customer feedback, and making the flow of work visible. See Chapter 8. (The technical counterpart to this is found in Chapter 4.)

LEAN MANAGEMENT AND MONITORING CAPABILITIES

Have a lightweight change approval processes.
Our research shows that a lightweight change approval process based on peer review (pair programming or intrateam code review) produces superior IT performance than using external change approval boards (CABs). See Chapter 7.
Monitor across application and infrastructure to inform business decisions.
Use data from application and infrastructure monitoring tools to take action and make business decisions. This goes beyond paging people when things go wrong. See Chapter 7.
Check system health proactively.
Monitor system health, using threshold and rate-of-change warnings, to enable teams to preemptively detect and mitigate problems. See Chapter 13.
Improve processes and manage work with work-in-process (WIP) limits.
The use of work-in-process limits to manage the flow of work is well known in the Lean community. When used effectively, this drives process improvement, increases throughput, and makes constraints visible in the system. See Chapter 7.
Visualize work to monitor quality and communicate throughout the team.
Visual displays, such as dashboards or internal websites, used to monitor quality and work in process have been shown to contribute to software delivery performance. See Chapter 7.

CULTURAL CAPABILITIES

Support a generative culture (as outlined by Westrum).
This measure of organizational culture is based on a typology developed by Ron Westrum, a sociologist who studied safety-critical complex systems in the domains of aviation and healthcare. Our research has found that this measure of culture is predictive of IT performance, organizational performance, and decreasing burnout. Hallmarks of this measure include good information flow, high cooperation and trust, bridging between teams, and conscious inquiry. See Chapter 3.
Encourage and support learning.
Is learning, in your culture, considered essential for continued progress? Is learning thought of as a cost or an investment? This is a measure of an organization’s learning culture. See Chapter 10.
Support and facilitate collaboration among teams.
This reflects how well teams, which have traditionally been siloed, interact in development, operations, and information security. See Chapters 3 and 5.
Provide resources and tools that make work meaningful.
This particular measure of job satisfaction is about doing work that is challenging and meaningful, and being empowered to exercise your skills and judgment. It is also about being given the tools and resources needed to do your job well. See Chapter 10.
Support or embody transformational leadership.

Transformational leadership supports and amplifies the technical and process work that is so essential in DevOps. It is comprised of five factors: vision, intellectual stimulation, inspirational communication, supportive leadership, and personal recognition. See Chapter 11.

accelerate-capabilities-figure.png

책/Accelerate (last edited 2023-06-13 23:36:41 by 정수)