2년 전 나는 개발자의 피로가 소프트웨어 엔지니어에게 미치는 영향을 연구한 결과 발견했습니다. 최근 몇 달 동안 저는 다양한 조직의 소프트웨어 개발에 대한 인식에 대한 추가 연구를 진행해 왔습니다. 그 중에는 소프트웨어 엔지니어의 75%가 비즈니스 리더의 89%가 했다는 사실도 포함되어 있습니다. . 83%가 피로를 겪고 있음을 마지막으로 잘못된 행위를 보고했을 때 보복을 당했고 이에 대해 우려 소프트웨어 정시 납품 Google의 DORA 팀은 수년 동안 소프트웨어 엔지니어를 대상으로 자체 설문 조사를 실시해 왔으며 측정 프레임워크의 원 작성자는 이제 SPACE 및 DevEx를 포함한 다른 프레임워크를 제작했습니다. 처음에는 이 팀이 수행한 연구를 신뢰했지만 추가 연구를 수행하면서 결함이 분명해졌습니다. 휴가 기간 동안 저는 Andrew Jenkinson 박사의 책 "우리가 먹는 이유(너무 많이): 식욕의 새로운 과학"을 읽었습니다. 이 책에서 Jenkinson 박사는 Ancel Keys 박사의 7개국 연구로 알려진 연구를 비판했습니다. Jenkinson 박사는 Keys 박사의 성공을 다음과 같이 설명합니다. “그는 자신의 가장 큰 라이벌에 대한 논쟁에서 승리했으며, 부인할 수 없는 사실로 그를 비난하고 그의 결함 있는 논리를 폭로했습니다. 군중의 환호는 그를 기쁨과 황홀경으로 가득 채웠습니다. 그의 일생의 사업이 결실을 맺었습니다. 그의 연구를 위한 자금이 유입될 것이고, 해당 분야의 선도적인 과학자로서의 그의 명성은 수년 동안 안정될 것입니다. 명성도 좋았지만 이제 그는 진정한 두 가지 상, 즉 권력과 영향력을 확보했습니다.” 그러나 Jenkinson 박사는 다음과 같이 지적합니다. “그는 자신의 연구에 대해 부정직하지 않았습니다. 그렇게 하면 비윤리적이고 그를 불신하게 될 것입니다. 기술적으로 그가 제시한 내용은 진실이었습니다. 그러나 그는 그것이 진실의 전부가 아니라는 것을 잘 알고 있었습니다.” DORA의 연구 결과를 연구하고 나중에 더 자세히 작업하면서 이 설명과 DORA의 DevOps 현황 보고서 및 후속 SPACE 및 DevEx 프레임워크의 연구 엄격함 사이의 유사점이 분명해졌습니다. 데이터는 어디에 있나요? 첫째, DORA 연구는 주관적인 설문 조사를 통해 수천 명의 개발자를 샘플링하여 수행됩니다. 이 연구는 DORA 팀이 자체적으로 수행합니다. 일반적으로 이러한 연구를 직업으로 수행하는 사람들은 시장 조사 협회(MRS) 및 영국 여론 조사 위원회(BPC)와 같은 조직에 가입하여 회원인 조직이 수행하는 연구에 대한 대중의 신뢰를 얻을 수 있습니다. 예를 들어; BPC 규칙은 연구가 출판된 후 영업일 기준 2일 이내에 질문이 포함된 전체 데이터 테이블을 공개하도록 요구하는 엄격한 공개 규칙을 회원에게 적용합니다. 여기에 첫 번째 문제가 있습니다. DORA 팀은 원시 데이터를 게시하지 않고 DevOps 상태 보고서만 게시합니다. 결함이 있는 방법론 Google의 DORA 연구와 팀 설정 내에서 사용되는 SPACE 및 DevEx 프레임워크는 주관적인 설문조사를 사용하여 측정값을 생성합니다. 주관적인 설문조사를 사용할 때는 편견이 작용하지 않도록 조치를 취하는 것이 중요합니다. 그러나 DORA는 결과를 측정하기 위해 변경 리드 타임, 배포 빈도, 변경 실패율 및 복구 시간(이전의 평균 복구 시간)이라는 4가지 주요 지표를 사용합니다. 이는 본질적으로 새로운 기능을 배포하는 속도와 문제 해결 속도를 측정하는 것입니다. 어떤 사람들에게 "당신의 동료들은 녹색 채소를 많이 먹나요?"라고 물었다고 상상해 보십시오. 그리고 “동료들은 운동을 많이 하시나요?”. 자신의 직장에 대해 더 나은 느낌을 갖는 사람들은 아마도 두 질문에 모두 "예"라고 대답할 가능성이 더 높을 것입니다. 이는 더 많은 녹색 채소를 섭취한다고 해서 항상 체육관 출석률이 높아진다는 의미는 아닙니다. 상관관계가 있을 수는 있지만 인과관계를 만들지는 않았습니다. DORA 연구에서는 속도와 신뢰성이 밀접하게 연관되어 있다고 주장하지만 이는 전적으로 속도에 기초한 결과 측정을 기반으로 합니다. 더욱이, 주관적인 설문조사를 사용하면 자신의 작업에 대해 더 나은 느낌을 받는 수신자가 두 질문에 모두 "예"라고 답하도록 편향될 수 있습니다. 그리고 더 유능한 회사는 필연적으로 두 가지 요소 모두에서 더 유능할 수 있지만 이것이 인과 관계를 생성하지는 않습니다. 예를 들어; 항공기에 소프트웨어가 드물게 배포되는 것과 비교하여 항공 소프트웨어의 신뢰성이 얼마나 높은 평가를 받는지 고려하십시오. 또는 애자일 방법론의 선구자인 Toyota가 의도하지 않은 가속 버그에 대한 소프트웨어 신뢰성 사례인 "Bookout v. Toyota"에서 어떻게 사망으로 이어졌는지 내부 커뮤니케이션에서 인정한 방법을 생각해 보십시오. "실제로 안전 장치와 같은 기술은 Toyota의 일부가 아닙니다. 엔지니어링 부문의 DNA". 또는 Horizon IT 스캔들(소프트웨어 개발자인 Fujitsu가 소프트웨어 개발자인 Fujitsu가 임신부를 포함하여 억울하게 투옥된 사람들과 함께 다수의 자살과 "영국 역사상 가장 널리 퍼진 정의의 유산"으로 비난을 받았던) Horizon IT 스캔들 중에 어떻게 방법을 생각해 보십시오. 소프트웨어를 개발하는 민첩한 방법론, 즉 . Rapid Application Development 잘못된 측정 결과 논의한 바와 같이, DORA 연구에서는 성능을 평가하기 위해 새로운 작업을 배포하고 버그를 수정하는 속도를 평가하는 4가지 주요 지표를 기준으로 측정했습니다. 그러나 이러한 지표는 측정하기에 유용한 결과인 경우에만 중요합니다. 나는 수행한 결과 둘 다 속도가 가장 덜 중요한 요소라는 데 동의한다는 사실을 발견했습니다. 대신 대중은 데이터 보안, 데이터 정확성 및 심각한 버그 예방에 가장 관심을 갖습니다. 소프트웨어 개발자와 대중이 가장 중요하다고 말하는 이러한 결과에 4가지 핵심 지표를 연결하는 가설을 찾는 것은 어렵습니다. 특히 심각한 버그를 예방하는 것이 버그를 빠르게 수정하거나 빠르게 작업을 수행하는 것보다 우선순위가 낮다는 점을 고려할 때 더욱 그렇습니다. 데이터 보안과 같은 다른 요소의 경우에도 이것이 4가지 주요 지표와 어떻게 연결되는지 확인하기 어렵습니다. 소프트웨어 엔지니어와 일반 대중의 대표 표본(연구 회사인 Survation과 함께)을 대상으로 연구를 비즈니스 의사결정자 사이에서도 빠른 배송보다 정시 배송이 더 중요한 것으로 보입니다. JL Partners와 함께 실시한 연구에 따르면 영국의 비즈니스 의사 결정자 중 98%, 미국의 96%가 "소프트웨어 엔지니어링 팀의 목표는 고품질 소프트웨어를 적시에 제공하는 것입니다"라는 진술에 동의합니다. 영국에서는 65%, 미국에서는 62%가 강력하게 동의했습니다. 마지막으로; 내가 Survation과 함께 수행한 연구에 따르면 소프트웨어 엔지니어에 대한 신뢰와 대중의 신뢰성 기대치는 산업마다 크게 다를 수 있습니다. 즉, 영국 엔지니어링 위원회(Engineering Council UK)가 : "위험에 비례하고 조직이 정의한 위험 선호도와 일치하는 의사 결정 접근 방식을 채택합니다." 위험에 대한 지침 돈을 따르라 Keys 박사가 연구에서 설탕 업계로부터 자금을 지원받은 것처럼, 많은 조사에서 인센티브가 어디에 있는지 이해하려면 자금을 추적하는 것이 중요합니다. DORA팀은 원래 IT 인프라 자동화에 주력하는 회사인 Puppet을 위해 DevOps 현황 보고서를 작성하기 시작했으며 현재는 Google Cloud에서 이 작업을 수행하고 있습니다. 두 사람 모두 개발자가 가능한 한 빨리 작업을 배포할 수 있도록 하는 데 큰 관심을 갖고 있습니다. 그러나 이것이 우리의 모든 문제에 대한 해결책이라는 의미는 아닙니다. DORA는 프로세스에 어느 정도의 경험적 평가를 추가함으로써 소프트웨어 엔지니어링 세계에 기여했습니다. 그러나 우리는 진실을 위해 혼동을 일으키는 마케팅 자료를 피해야 하며 그러한 연구의 결함을 인식해야 합니다.
