Tạm biệt DORA: Những sai sót của báo cáo trạng thái DevOps

Hai năm trước, tôi đã nghiên cứu tác động của tình trạng kiệt sức của nhà phát triển đối với các kỹ sư phần mềm, nhận thấy 83% bị kiệt sức . Trong những tháng gần đây, tôi đã tiến hành nghiên cứu sâu hơn về nhận thức về phát triển phần mềm của nhiều tổ chức, bao gồm phát hiện rằng 75% kỹ sư phần mềm phải đối mặt với sự trả thù trong lần cuối cùng họ báo cáo hành vi sai trái và 89% lãnh đạo doanh nghiệp lo ngại về giao phần mềm đúng thời hạn .

Nhóm DORA của Google trong nhiều năm đã tiến hành cuộc thăm dò ý kiến của riêng họ đối với các kỹ sư phần mềm và các tác giả ban đầu của khung đo lường hiện đã tạo ra các khung khác bao gồm SPACE và DevEx. Mặc dù ban đầu tôi tin tưởng vào nghiên cứu do các nhóm này thực hiện nhưng khi tôi tiến hành nghiên cứu sâu hơn thì những sai sót đã trở nên rõ ràng.

Trong kỳ nghỉ lễ, tôi đã đọc cuốn sách "Tại sao chúng ta ăn (quá nhiều): Khoa học mới về sự thèm ăn" của Tiến sĩ Andrew Jenkinson, trong cuốn sách Tiến sĩ Jenkinson đã phê bình một nghiên cứu được gọi là Nghiên cứu về Bảy quốc gia của Tiến sĩ Ancel Keys. Tiến sĩ Jenkinson mô tả thành công của Tiến sĩ Key như sau: “Ông ấy đã giành chiến thắng trong cuộc tranh luận trước đối thủ lớn nhất của mình, đánh bại đối thủ bằng những sự thật không thể chối cãi, vạch trần logic thiếu sót của ông ấy. Sự tán dương của đám đông khiến anh vui mừng và ngây ngất. Công việc của cuộc đời ông đã đạt được kết quả. Nguồn tài trợ cho nghiên cứu của anh ấy sẽ đến và danh tiếng của anh ấy với tư cách là nhà khoa học hàng đầu trong lĩnh vực của mình sẽ được đảm bảo trong nhiều năm. Danh tiếng rất tốt, nhưng giờ anh ấy đã giành được hai giải thưởng thực sự hàng đầu - quyền lực và tầm ảnh hưởng.”

Tuy nhiên, Tiến sĩ Jenkinson lưu ý: “Anh ấy không hề thiếu trung thực trong nghiên cứu của mình - điều đó sẽ là trái đạo đức và làm mất uy tín của anh ấy. Về mặt kỹ thuật những gì anh ấy đã trình bày là sự thật. Nhưng anh ấy biết rất rõ rằng đó không phải là toàn bộ sự thật.”

Khi tôi nghiên cứu các kết quả nghiên cứu của DORA và sau đó nghiên cứu chi tiết hơn, sự tương đồng giữa mô tả này và mức độ nghiêm ngặt của nghiên cứu trong Báo cáo trạng thái DevOps của DORA và khung SPACE và DevEx tiếp theo đã trở nên rõ ràng.

Dữ liệu ở đâu?

Thứ nhất, nghiên cứu DORA được thực hiện bằng cách lấy mẫu hàng nghìn nhà phát triển thông qua việc sử dụng các khảo sát chủ quan. Nghiên cứu này được thực hiện nội bộ bởi nhóm DORA. Thông thường, những người tiến hành nghiên cứu như vậy để kiếm sống đã tham gia các tổ chức như Hiệp hội Nghiên cứu Thị trường (MRS) và Hội đồng Thăm dò ý kiến Anh (BPC) để đảm bảo công chúng có thể tin tưởng vào nghiên cứu do các tổ chức là thành viên thực hiện. Ví dụ; Các quy tắc của BPC đặt ra các quy tắc công bố nghiêm ngặt đối với các thành viên của họ, yêu cầu họ tiết lộ các bảng dữ liệu đầy đủ với các câu hỏi được đặt ra trong vòng 2 ngày làm việc kể từ khi nghiên cứu được công bố.

Đây là vấn đề đầu tiên của chúng ta; nhóm DORA không xuất bản dữ liệu thô của họ mà chỉ xuất bản Báo cáo trạng thái DevOps của họ.

Phương pháp thiếu sót

Nghiên cứu DORA của Google cũng như các khung SPACE và DevEx được sử dụng trong cài đặt nhóm, sử dụng các khảo sát chủ quan để tạo ra các phép đo. Khi sử dụng khảo sát chủ quan, điều quan trọng là phải thực hiện các bước để đảm bảo không có sự thiên vị.

Tuy nhiên, DORA sử dụng Bốn số liệu chính để đo lường kết quả - Thời gian thực hiện thay đổi, Tần suất triển khai, Tỷ lệ thất bại khi thay đổi và Thời gian khôi phục (trước đây là Thời gian trung bình để khôi phục). Về cơ bản, đây là thước đo tốc độ triển khai các tính năng mới và tốc độ giải quyết vấn đề.

Hãy tưởng tượng bạn hỏi một số người "Đồng nghiệp của bạn có ăn nhiều rau xanh không?" và “Đồng nghiệp của bạn có tập thể dục nhiều không?”. Những người cảm thấy tốt hơn về nơi làm việc của họ có nhiều khả năng trả lời “có” cho cả hai câu hỏi - điều này không có nghĩa là ăn nhiều rau xanh sẽ luôn dẫn đến mức độ đến phòng tập thể dục nhiều hơn. Mặc dù có thể có mối tương quan nhưng chúng tôi chưa tạo ra mối quan hệ nhân quả.

Nghiên cứu của DORA lập luận rằng tốc độ và độ tin cậy luôn song hành với nhau, tuy nhiên, chúng làm như vậy dựa trên các thước đo kết quả hoàn toàn dựa trên tốc độ. Hơn nữa, việc sử dụng các cuộc khảo sát chủ quan có thể khiến những người nhận cảm thấy tốt hơn về công việc của họ trả lời “có” cho cả hai câu hỏi. Và mặc dù các công ty có năng lực hơn chắc chắn có năng lực hơn ở cả hai yếu tố, nhưng điều này không tạo ra mối quan hệ nhân quả.

Ví dụ; xem xét mức độ tin cậy của phần mềm hàng không được đánh giá cao như thế nào so với việc triển khai phần mềm không thường xuyên cho máy bay. Hoặc xem xét cách Toyota, công ty tiên phong về các phương pháp linh hoạt, trong trường hợp về độ tin cậy của phần mềm “Bookout v. Toyota” về lỗi tăng tốc ngoài ý muốn dẫn đến tử vong đã thừa nhận trong thông báo nội bộ rằng "Trên thực tế, công nghệ như tính năng an toàn dự phòng không phải là một phần của Toyota." DNA của bộ phận kỹ thuật". Hoặc hãy xem xét vụ bê bối Horizon IT - bị đổ lỗi cho nhiều vụ tự tử và điều được mô tả là "vụ xử oan sai phổ biến nhất trong lịch sử Vương quốc Anh", với những người bị bỏ tù oan bao gồm cả một phụ nữ mang thai - nhà phát triển phần mềm, Fujitsu đã đi tiên phong trong việc sử dụng một phương pháp linh hoạt để phát triển phần mềm, cụ thể là Phát triển ứng dụng nhanh .

Kết quả đo lường sai sót

Như đã thảo luận, nghiên cứu của DORA được đo lường dựa trên Bốn số liệu chính nhằm đánh giá tốc độ triển khai công việc mới và sửa lỗi để đánh giá hiệu suất. Tuy nhiên, những số liệu này chỉ quan trọng ở mức độ chúng là những kết quả hữu ích để đo lường.

Tôi đã tiến hành nghiên cứu với cả kỹ sư phần mềm và mẫu đại diện của công chúng (với công ty nghiên cứu Survation) và nhận thấy rằng cả hai đều đồng ý rằng tốc độ là yếu tố ít quan trọng nhất. Thay vào đó, công chúng quan tâm nhất đến bảo mật dữ liệu, độ chính xác của dữ liệu và ngăn ngừa các lỗi nghiêm trọng. Thật khó để tìm ra giả thuyết có thể kết nối Bốn Số liệu Chính với những kết quả này mà các nhà phát triển phần mềm và công chúng cho là quan trọng nhất - đặc biệt khi việc ngăn chặn các lỗi nghiêm trọng hoàn toàn là ưu tiên thấp hơn việc sửa lỗi nhanh chóng hoặc hoàn thành công việc nhanh chóng. Ngay cả đối với các yếu tố khác như bảo mật dữ liệu, thật khó để biết những yếu tố này kết nối như thế nào với bất kỳ chỉ số nào trong Bốn chỉ số chính.

Ngay cả đối với những người ra quyết định kinh doanh, dường như việc giao hàng đúng hạn quan trọng hơn việc giao hàng nhanh. Theo nghiên cứu mà tôi thực hiện với JL Partners, 98% những người ra quyết định kinh doanh như vậy ở Anh và 96% ở Hoa Kỳ đồng ý với tuyên bố “Mục tiêu của nhóm kỹ thuật phần mềm là cung cấp phần mềm chất lượng cao đúng thời hạn”, với 65% ở Anh và 62% ở Mỹ hoàn toàn đồng ý.

Cuối cùng; nghiên cứu mà tôi thực hiện với Survation cho thấy rằng niềm tin vào các kỹ sư phần mềm và kỳ vọng về độ tin cậy của công chúng có thể khác nhau đáng kể giữa các ngành, nghĩa là không nên khuyến khích cách tiếp cận một kích cỡ phù hợp cho tất cả mà ủng hộ những gì Hội đồng Kỹ thuật Vương quốc Anh đề xuất trong Hướng dẫn về Rủi ro : “áp dụng cách tiếp cận ra quyết định tương xứng với rủi ro và phù hợp với khẩu vị rủi ro đã xác định của tổ chức của họ”.

Theo dõi tiền

Giống như Tiến sĩ Keys đã nhận được tài trợ từ ngành công nghiệp đường cho nghiên cứu của mình - trong nhiều cuộc điều tra, điều quan trọng là phải theo dõi tiền để hiểu động lực nằm ở đâu. Nhóm DORA ban đầu bắt đầu thực hiện các báo cáo State of DevOps cho Puppet, một công ty tập trung vào tự động hóa cơ sở hạ tầng CNTT và giờ họ thực hiện công việc này cho Google Cloud. Cả hai đều quan tâm đến việc các nhà phát triển có thể triển khai công việc nhanh nhất có thể. Tuy nhiên, điều này không có nghĩa là nó là giải pháp cho mọi vấn đề của chúng ta.

DORA đã có đóng góp cho thế giới công nghệ phần mềm trong việc bổ sung thêm mức độ đánh giá thực nghiệm cho quy trình. Tuy nhiên, chúng ta phải tránh nhầm lẫn tài liệu tiếp thị với toàn bộ sự thật và nhận ra những sai sót trong nghiên cứu đó.