Các chỉ số kỹ thuật của DORA giúp hợp lý hóa phân phối phần mềm

Mọi nhóm kỹ sư sử dụng chỉ số kỹ thuật DORA sẽ có những tỷ lệ khác nhau. Nhưng mục đích chung khi áp dụng là để cải thiện việc năng suất và quy trình làm việc.

Các chỉ số kỹ thuật DORA  (DevOps Research and Assessment) dùng để đo lường hiệu suất làm việc của nhóm kỹ sư phần mềm và tính ổn định của sản phẩm mà họ phát triển được. Nếu có thể cải thiện các chỉ số này thì chúng có thể làm việc với năng suất tốt hơn và cung cấp phần mềm có chất lượng cao hơn cho khách hàng.

04 chỉ số kỹ thuật DORA

Tần suất triển khai

Tần suất triển khai là tần suất một nhóm kỹ sư phần mềm triển khai code vào hoạt động sản xuất. Đây là một chỉ số thể hiện cho tần suất của nhóm kỹ sư tạo ra được bao nhiêu sản phẩm.

Nó cho biết quy trình làm việc của nhóm hiệu quả như thế nào. Ví dụ: Nếu tần suất triển khai chậm lại, điều đó có thể cho thấy sự cố với quy trình làm việc.

Việc đo lường tần suất này cho chúng ta thấy những tác động lớn hơn của sự thay đổi của nhóm. Điều này sẽ đảm bảo khi có các thay đổi cũng không ảnh hưởng đến công việc đang thực hiện. 

Tần suất triển khai thường được báo cáo mỗi ngày, bạn có thể tự động hóa chỉ số đo lường này bằng cách lấy dữ liệu từ công cụ phân phối và tích hợp liên tục của nhóm.

Có một số phương pháp kỹ thuật DORA có thể áp dụng để cải thiện tần suất triển khai: 

• Giảm quy mô của các công việc để một nhóm kỹ sư có thể xử lý công việc tốt hơn
• Tích hợp với công cụ tích hợp và phân phối liên tục để nâng cao hiệu quả quy trình tạo ra sản phẩm
• Sử dụng các bài kiểm tra tự động để gia tăng độ tin cậy về chất lượng code và giảm các bài kiểm tra thủ công làm tốn nhiều thời gian

Một đội ngũ chất lượng sẽ triển khai các thay đổi nhiều lần mỗi ngày để liên tục gia tăng giá trị và cải thiện tần suất tạo ra sản phẩm cho khách hàng. 

Mean change lead time (đo lường thời gian thay đổi trung bình)

Đo lường thời gian thay đổi trung bình (Mean change lead time) còn được gọi là thời gian chu kỳ, đây là từ thời điểm code được xác nhận đến khi code chạy thành công. Chỉ số này cho phép bạn theo dõi tốc độ của nhóm kỹ sư phần mềm. Các nhóm làm việc tốt hơn sẽ có quy trình tối ưu hóa và phát triển các tính năng mới nhanh hơn. Hiệu quả gia tăng này mở ra cơ hội để tăng doanh thu cho tổ chức. Đồng thời, chúng ta có thể cải thiện tỷ lệ gia hạn của khách hàng và tạo ra một đội nhóm hiệu quả. Mặt khác, nếu sản phẩm đội ngũ kỹ sư tạo ra chậm hơn có tức là quy trình quản lý kém hiệu quả, lãng phí thời gian.

Việc chúng ta đo lường thời gian giúp nhóm nhà phát triển tìm ra vấn đề tồn đọng trong quy trình làm việc của họ. Từ đó, họ sẽ tìm cách tối ưu hóa và cải thiện quy trình làm việc.

Nhóm kỹ sư phần mềm nên làm gì để cải thiện Mean change lead time (đo lường thời gian thay đổi trung bình)?

• Thêm công đoạn tích hợp thử nghiệm sản phẩm vào quá trình phát triển
• Tự động hóa các bài kiểm tra thay vì kiểm tra thủ công
• Tích hợp các công cụ phân phối liên tục 
• Kiểm tra code để đánh giá chất lượng tiến độ làm việc

Mean time to recovery (đo lường thời gian trung bình để phục hồi)

Đo lường thời gian trung bình khôi phục dùng để đo lường tốc độ phục hồi, quay lại công việc của nhóm kỹ sư phần mềm sau một sự cố. Sự cố là bất cứ điều gì làm gián đoạn chất lượng dịch vụ và ảnh hưởng đến tiến độ làm việc. Đo lường thời gian trung bình cho biết đội kỹ thuật phần mềm có thể giải quyết các sự cố xảy ra trong quá trình sản xuất nhanh như thế nào. 

Đo lường thời gian trung bình để khôi phục được tính bằng cách theo dõi thời gian trung bình trong quá trình làm việc và thời gian để nhóm kỹ sư khắc phục vấn đề đó. 

Dưới đây là một số cách mà nhóm kỹ sư phần mềm có thể cải thiện thời gian khôi phục trung bình của họ:

• Giới thiệu các công cụ giám sát báo cáo nhanh sự cố trong quá trình phát triển sản phẩm
• Triển khai hệ thống tài liệu hỗ trợ 
• Cải thiện thời gian bắt đầu khắc phục sự cố
• Sử dụng chức năng bật/tắt trong khi làm việc, điều này có thể giảm thời gian khôi phục trung bình xuống còn vài giây  

Thay đổi tỷ lệ thất bại

Yếu tố này dùng để đo lường tần suất nhóm kỹ sư phần mềm đưa ra một thay đổi nếu quá trình phát triển sản phẩm xảy ra sự cố. Đây là những thay đổi dẫn đến sự cố hoặc không đáp ứng được mong đợi của khách hàng. Số liệu này cho biết chất lượng của phần mềm mà nhóm xây dựng.

Sửa lỗi và khôi phục code là một công việc tốn kém vì nó mất nhiều thời gian có thể dành để tạo ra các tính năng mới nhằm tăng giá trị cho khách hàng. Do đó, tỷ lệ thay đổi thất bại cao cho thấy phần mềm chất lượng thấp hơn khiến khách hàng thất vọng. 

Tỷ lệ thất bại thay đổi được tính theo phần trăm, nó là tỷ lệ giữa số lần thất bại trên số lần triển khai vào thực tế. 

Các nhóm kỹ thuật phần mềm có thể thực hiện các phương pháp này để cải thiện tỷ lệ thay đổi thất bại của họ:

• Giới thiệu các công cụ xem xét code tự động để nắm bắt các vấn đề mà việc kiểm tra code thủ công có thể bỏ sót
• Thêm các bài kiểm tra tự động cho tất cả các code mới
• Chạy tất cả các thử nghiệm tự động như một phần của quá trình phát hành bằng cách sử dụng công cụ tích hợp liên tục, phân phối liên tục
• Phân tích sự cố để nhóm kỹ sư có thể hiểu nguyên nhân, từ đó sẽ hạn chế được các lỗi tương tự

Một nhóm làm việc hiệu quả sẽ đặt mục tiêu có tỷ lệ thay đổi thất bại từ 0 đến 15%. 

Tất nhiên 04 số liệu này không phải là duy nhất có thể sử dụng khi đánh giá hiệu suất của nhóm kỹ sư phần mềm. Tuy nhiên các chỉ này có liên quan nhiều nhất đến sự thành công của tổ chức nhờ việc cải thiện năng suất làm việc của nhóm kỹ sư.

Một số lưu ý dành cho bạn

Bốn chỉ số DORA có vẻ đơn giản, nhưng khi sử dụng không đúng cách chúng sẽ gây ra những vấn đề tiêu cực.

Mọi nhóm kỹ sư sử dụng chỉ số kỹ thuật DORA sẽ có những tỷ lệ khác nhau. Nhưng mục đích chung của chúng ta khi áp dụng là để cải thiện việc năng suất và quy trình làm việc. Các chỉ số này sẽ không phù nếu bạn so sánh các tỷ lệ của nhóm này với nhóm khác. Bởi vì các nhóm sẽ có những mục tiêu khác nhau nên yêu cầu về chỉ số DORA không có sự tương đồng nào. 

Nhóm kỹ sư cần xem xét tất cả 04 chỉ số cùng nhau thay vì chỉ tập trung vào một chỉ số nào đó. Các chỉ số này hướng đến sự cân bằng giữa tốc độ và chất lượng của công việc. Do đó, việc chúng ta tập trung vào một dữ liệu có thể dẫn đến hiệu suất kém hơn.

Nhóm kỹ sư cần nhớ rằng cải thiện các số liệu không bao giờ  là mục tiêu chính của bạn. Định luật Goodhart nói, “Bất kỳ biện pháp nào trở thành mục tiêu sẽ không còn trở thành một biện pháp tốt”. Nhà phát triển cần đặt ra mục tiêu là cung cấp liên tục có hiệu quả giá trị cho khách hàng. Việc bạn sử dụng các chỉ số này có thể để phản ánh sự tiến bộ của nhóm đối với mục tiêu đó.

Các chỉ số DORA giúp nhóm nhà phát triển đánh giá và cải thiện hiệu suất làm việc của họ. Nhưng để  lập trình viên thực hiện có ý nghĩa, họ cần hiểu những gì các yếu tố này đề cập. Nên khi xác định tỷ lệ của chỉ số DORA, bạn sẽ cần dựa trên thực tế về khả năng làm việc của nhóm.

Lời kết

Nhiều nhà phát triển phần mềm không ngừng tìm cách cải thiện quy trình và phân phối sản phẩm. Trong nhiều năm, các đội ngũ kỹ sư đã đặt các tiêu chí thiếu khách quan và chỉ có ý nghĩa để đo lường thành tích của họ. DORA có thể giúp bạn thay đổi điều đó bằng cách tập trung vào các chỉ số giúp nhóm xác định được vấn đề trong quy trình làm việc.

Công Sơn

Nguồn: https://stackoverflow.blog/2021/11/29/the-four-engineering-metrics-that-will-streamline-your-software-delivery/