Đo lường năng suất kỹ thuật là một quá trình phức tạp — thật khó để có được bức tranh đầy đủ về cách các nhà phát triển sử dụng thời gian của họ. Một cách phổ biến để đo lường năng suất là phân tích các số liệu hệ thống như DORA hoặc SPACE. Đây có thể là số liệu cực kỳ hữu ích để hiểu năng suất của nhóm so với tiêu chuẩn ngành. Đi sâu vào từng số liệu đó cũng có thể cung cấp thông tin chi tiết về những gì đang làm chậm nhóm. Nhưng đôi khi, cũng có những “khoảng thời gian ẩn” mà các nhà phát triển dành suốt cả ngày mà có thể không được coi là ảnh hưởng đến năng suất. Tuy nhiên, khi chúng ta bắt đầu cộng những thứ đó lại, những con số có thể đáng báo động. Ví dụ: hãy xem xét lượng thời gian mà nhà phát triển dành để gỡ lỗi một thử nghiệm không ổn định để cố gắng tìm hiểu xem liệu nó có thất bại do sự thay đổi của họ hay không. Hoặc thời gian mà nhà phát triển đang cố gắng giải quyết lỗi xây dựng tuyến chính. Để cung cấp quan điểm đó, chúng tôi đã xây dựng một máy tính giúp đánh giá hiệu quả kỹ thuật. Điều này không có nghĩa là cung cấp bản phân tích đầy đủ về hiệu quả của nhóm kỹ thuật của bạn. Những gì nó cung cấp là một cái nhìn thoáng qua về “những khoảng thời gian ẩn” bị lãng phí mà thường không hiển thị trong các số liệu năng suất phổ biến hơn. Công cụ tính tập trung vào lượng thời gian mà bạn và nhóm của bạn bị mất do lỗi xây dựng và kiểm tra trong quy trình làm việc của nhà phát triển. Nếu bạn so sánh điều này với các số liệu DORA, thì thời gian thực hiện các thay đổi sẽ bị ảnh hưởng đáng kể bởi sự không ổn định của quá trình xây dựng và thử nghiệm. Tác động đó có thể được đánh giá bằng cách sử dụng máy tính này. Làm thế nào nó hoạt động Chúng tôi yêu cầu bạn nhập dữ liệu dựa trên hoạt động GitHub của bạn và cách bạn sử dụng các nhánh GitHub. Để giải thích các phép tính thực tế bên dưới, hãy gán các biến cho từng phép tính: M – PR được hợp nhất mỗi ngày X – lỗi đường dây chính trong một tuần T - thời gian CI trung bình F – hệ số bong tróc % Dựa trên những thông tin đầu vào này, chúng tôi ước tính lượng thời gian mà nhóm kỹ thuật của bạn lãng phí hàng tuần để quản lý các lỗi xây dựng và xử lý các thử nghiệm không ổn định. Chúng ta hãy xem xét từng kết quả một. Lãng phí hàng giờ để sửa chữa Điều này tính toán số giờ bị lãng phí để xác định, phân loại, sửa chữa và lấy lại thẻ xây dựng khi phát hiện thấy lỗi xây dựng tuyến chính. Thông thường, trong một nhóm lớn, sẽ có người chú ý và báo cáo việc xây dựng đường chính bị hỏng. Chúng tôi giả định rằng một lỗi xây dựng tuyến chính cần trung bình 1-3 nhà phát triển gỡ lỗi và sửa lỗi. Nếu chúng tôi coi thời gian cần thiết để báo cáo sự cố và đưa ra giải pháp khắc phục là trung bình một giờ thì chúng tôi đang dành để theo dõi, điều tra và giải quyết vấn đề. (2*T + 1) giờ Điều đó có nghĩa là nếu có X lỗi mỗi tuần, chúng tôi sẽ dành (( trong thời gian dành cho nhà phát triển để giải quyết các lỗi xây dựng tuyến chính mỗi ngày. 2 nhà phát triển * X/5 * (2*T + 1)) giờ Hàng giờ lãng phí khi giải quyết xung đột hợp nhất Việc khôi phục và xung đột hợp nhất có thể gây ra nhiều vấn đề hơn. Giả sử rằng có khoảng 2% PR có xung đột hợp nhất trong khoảng thời gian xây dựng bị hỏng và PR xuất hiện mỗi giờ, chúng tôi sẽ chi tiêu lãng phí khi giải quyết những xung đột này. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0,02 * M/8 Lỗi CI hàng tuần do bản dựng bị hỏng Nếu nhóm không sử dụng nhánh vàng để làm cơ sở cho các nhánh đặc trưng của mình, họ có thể sẽ tạo các nhánh đặc trưng trên nhánh chính bị lỗi. Vì số lượng PR được tạo trong bất kỳ thời điểm nào sẽ tương tự như số lượng nhánh tính năng trung bình dựa trên dòng chính, điều này sẽ gây ra số lỗi CI xảy ra mỗi ngày . (2*T + 1 giờ) * X/5 * M/8 Thời gian giải quyết CI Với khoảng mười lăm phút chuyển ngữ cảnh để xử lý mỗi lần xây dựng lỗi, tức là giờ thời gian của nhà phát triển bị lãng phí mỗi ngày với lỗi CI. (2*T + 1 giờ) * X/5 * M/8 * 0,25 Đã dành thời gian để chạy lại các bài kiểm tra không ổn định. Tương tự, với các thử nghiệm không ổn định, thời gian chuyển đổi ngữ cảnh cần thiết để điều tra xem thử nghiệm là không ổn định hay thực tế và việc chạy lại các thử nghiệm này mất trung bình 15 phút mỗi lần chạy. Tùy thuộc vào yếu tố dễ bong tróc, các nhà phát triển sẽ lãng phí giờ mỗi ngày. (0,25 * M * F / 100) Nâng cao hiệu quả Mặc dù hầu hết những điều này đều tác động đến các số liệu DORA liên quan đến chúng tôi vẫn chỉ mới sơ lược về mặt đo lường sự thiếu hiệu quả trong quy trình làm việc của nhóm kỹ thuật. Tác động của lỗi xây dựng và thử nghiệm cũng dẫn đến việc phát hành bị trì hoãn, ảnh hưởng đến các số liệu DORA khác như và sự tồn tại của các thử nghiệm không ổn định trong hệ thống, điều này có thể dẫn đến tỷ lệ Thất bại cao hơn. . Thời gian thực hiện các thay đổi, nhưng tần suất triển khai, thời gian khôi phục dịch vụ Tìm hiểu thêm về số liệu DORA Hoặc tìm hiểu thêm về nhược điểm của họ. Chúng tôi đã xây dựng để giải quyết một số thách thức tiềm ẩn này cho các nhóm kỹ thuật lớn. Ngày nay, bằng cách sử dụng Aviator MergeQueue, nhiều tổ chức kỹ thuật có thể mở rộng quy trình hợp nhất của họ mà không làm gián đoạn các bản dựng. Kết hợp điều đó với hệ thống ngăn chặn thử nghiệm không ổn định như , các nhóm có thể tiết kiệm hàng trăm giờ kỹ thuật mỗi tuần. Aviator TestDeck Cũng được xuất bản . ở đây
