Tôi đang kiếm được gấp 4-5 lần điểm câu chuyện so với mức trung bình, nhưng tạo ra lỗi với một nửa tỷ lệ. Đồ thị cho biết đó là lỗi gấp 2 lần, làm thế nào để đối phó với điều đó?

Vì vậy, người ta thường chấp nhận rằng các lập trình viên hàng đầu có thể tạo ra một thứ tự cường độ lớn hơn / mã tốt hơn so với các đồng nghiệp trung bình hơn của họ.

Thông thường cũng chấp nhận rằng tỷ lệ lỗi được thực hiện trong mã là tương đối ổn định đối với các lập trình viên.

Thay vào đó, nó có xu hướng bị tác động bởi các quy trình được sử dụng khi viết mã và sau khi mã được viết . (Theo tôi hiểu) Con người có xu hướng mắc lỗi với tốc độ khá ổn định - các lập trình viên tốt hơn chỉ cần chú ý đến chúng nhiều hơn và nhanh chóng sửa chữa chúng hơn.

• Lưu ý rằng cả hai xác nhận trên đều đến từ Code Complete của Steve McConnell - vì vậy đây không phải là vấn đề về quan điểm khác nhau.

Vì vậy, tôi đã bắt đầu thấy điều này gần đây trong mã của tôi. Tôi có thể rút ra khoảng 4-5 lần số lượng mã như nhiều đồng nghiệp của mình (được đo bằng số điểm câu chuyện được ước tính bởi nhóm), với chất lượng cao hơn (dựa trên số liệu hiệu suất và số lượng thay đổi được thực hiện sau khi đăng ký). Nhưng tôi vẫn mắc lỗi. Giữa các bài kiểm tra đơn vị tốt hơn, hiểu rõ hơn về những gì mã đang làm và một vấn đề tốt hơn khi thực hiện đánh giá mã Tôi không tạo ra số lỗi gấp 4-5 lần.

Nhưng tôi vẫn đang tạo ra khoảng gấp đôi số lỗi mà QA tìm thấy so với các nhà phát triển khác trong nhóm của tôi. Như bạn có thể tưởng tượng, điều này gây ra một số vấn đề với những người không có kỹ thuật thực hiện các phép đo hệ mét (đọc: ông chủ của tôi).

Tôi đã cố gắng chỉ ra rằng tôi đang tạo ra các lỗi với tỷ lệ bằng một nửa so với các đồng nghiệp của tôi (và sửa gấp đôi số lượng), nhưng thật khó bán khi có các biểu đồ nói rằng tôi tạo ra gấp đôi số lỗi.

Vậy, làm thế nào để đối phó với thực tế là tăng năng suất sẽ dẫn đến số lượng lỗi tăng lên?

Tôi nghĩ rằng bạn đang trộn lẫn mối quan tâm của bạn. Và không có gì trên của bạn phụ mà bạn cần phải thay đổi.

Năng suất là một gợi ý về việc một dự án sẽ được hoàn thành nhanh như thế nào. Người quản lý dự án và mọi người khác muốn biết khi nào dự án sẽ giao. Năng suất cao hơn hoặc nhanh hơn có nghĩa là chúng ta sẽ thấy dự án phân phối sớm hơn.

Tỷ lệ lỗi không liên quan đến năng suất mà là quy mô của dự án. Ví dụ: bạn có thể có Nlỗi trên mỗi Ydòng mã. Không có gì trong số liệu đó nói (hoặc quan tâm!) Những dòng mã đó được viết nhanh như thế nào.

Để gắn kết điều đó với nhau, nếu bạn có năng suất cao hơn, vâng, bạn sẽ "thấy" các lỗi được viết nhanh hơn. Nhưng dù sao bạn cũng sẽ có số lượng lỗi đó vì nó gắn với quy mô của dự án.

Nếu bất cứ điều gì, năng suất cao hơn có nghĩa là bạn sẽ có nhiều thời gian hơn vào cuối dự án để săn những lỗi đó hoặc nhà phát triển sẽ nhanh hơn trong việc tìm ra các lỗi họ tạo ra. ¹

Để giải quyết các khía cạnh cá nhân hơn của câu hỏi của bạn.

Nếu sếp của bạn đang xem xét nghiêm ngặt số lượng lỗi bạn tạo ra trái ngược với tỷ lệ lỗi bạn tạo ra, một phiên giáo dục sẽ theo thứ tự. Số lỗi được tạo ra là vô nghĩa nếu không có tỷ lệ sao lưu.

Để lấy ví dụ đó đến mức cực đoan, xin vui lòng nói với sếp của bạn rằng tôi muốn tăng gấp đôi lương của bạn. Tại sao? Tôi đã tạo ra hoàn toàn không có lỗi trong dự án của bạn và do đó tôi là một lập trình viên vượt trội hơn bạn nhiều. Gì? Anh ta sẽ gặp vấn đề là tôi đã không tạo ra một dòng mã nào để mang lại lợi ích cho dự án của bạn? Ah. Bây giờ chúng tôi đã hiểu tại sao tỷ lệ là quan trọng.

Có vẻ như nhóm của bạn có số liệu để đánh giá lỗi trên mỗi điểm câu chuyện. Nếu không có gì khác, tốt hơn là được đo bằng số lượng lỗi được tạo. Các nhà phát triển tốt nhất của bạn sẽ tạo ra nhiều lỗi hơn vì họ đang viết nhiều mã hơn. Yêu cầu sếp của bạn đưa ra biểu đồ đó hoặc ít nhất là ném một loạt khác đằng sau nó cho thấy có bao nhiêu điểm câu chuyện (hoặc bất kỳ giá trị kinh doanh nào bạn đo lường) cùng với số lượng lỗi. Biểu đồ đó sẽ kể một câu chuyện chính xác hơn.

¹ _{Nhận xét đặc biệt này đã thu hút sự chú ý hơn nhiều so với dự định. Vì vậy, hãy là một chút phạm vi (ngạc nhiên, tôi biết) và đặt lại trọng tâm của chúng tôi vào câu hỏi này.}

_{Căn nguyên của câu hỏi này là về một người quản lý nhìn vào những điều sai trái. Họ đang xem xét tổng số lỗi thô khi họ nên xem xét tốc độ tạo so với số lượng nhiệm vụ đã hoàn thành. Chúng ta đừng bị ám ảnh bởi việc đo lường "các dòng mã" hoặc các điểm câu chuyện hoặc độ phức tạp hoặc bất cứ điều gì. Đó không phải là câu hỏi trong tầm tay và những lo lắng đó làm chúng ta mất tập trung vào câu hỏi quan trọng hơn.}

_{Như được trình bày trong các liên kết của OP, bạn có thể dự đoán một số lỗi nhất định trong một dự án hoàn toàn chỉ bằng quy mô của dự án. Có, bạn có thể giảm số lượng lỗi này thông qua các kỹ thuật phát triển và thử nghiệm khác nhau. Một lần nữa, đó không phải là điểm của câu hỏi này. Để hiểu câu hỏi này, chúng ta cần chấp nhận rằng đối với một dự án quy mô và phương pháp phát triển nhất định, chúng ta sẽ thấy một số lỗi nhất định sau khi quá trình phát triển "hoàn tất".}

_{Vì vậy, cuối cùng chúng ta hãy quay lại nhận xét này mà một vài người hoàn toàn hiểu lầm. Nếu bạn chỉ định các tác vụ có kích thước tương đương cho hai nhà phát triển, nhà phát triển có tỷ lệ năng suất cao hơn sẽ hoàn thành nhiệm vụ của họ trước các nhà phát triển khác. Do đó, nhà phát triển năng suất cao hơn sẽ có nhiều thời gian hơn ở cuối cửa sổ phát triển. "Thời gian thêm" đó (so với nhà phát triển khác) có thể được sử dụng cho các tác vụ khác, chẳng hạn như xử lý các khiếm khuyết sẽ thấm qua quy trình phát triển tiêu chuẩn.}

_{Chúng tôi phải nói với OP rằng họ có năng suất cao hơn các nhà phát triển khác. Không có gì trong những tuyên bố đó ngụ ý rằng OP hoặc các nhà phát triển năng suất cao hơn đang bị trượt trong công việc của họ. Chỉ ra rằng sẽ có ít lỗi hơn nếu họ dành nhiều thời gian hơn cho tính năng này hoặc cho rằng việc gỡ lỗi không phải là một phần của thời gian phát triển này bỏ lỡ những gì đã được hỏi. Một số nhà phát triển nhanh hơn những người khác và tạo ra chất lượng công việc tương đương hoặc tốt hơn. Một lần nữa, hãy xem các liên kết mà OP đặt ra trong câu hỏi của họ.}

Dành một số thời gian thêm đó để làm sạch, đánh bóng và kiểm tra mã của bạn. Vẫn sẽ có sai lầm, nhưng sẽ có ít hơn. Điều đó cần có thời gian. Tốc độ đầu ra mã của bạn sẽ giảm, nhưng đầu ra mã không có lỗi của bạn sẽ tăng lên và điều đó sẽ mang lại năng suất tốt hơn. Vì bọ rất đắt.

Bạn có thể giữ mã của bạn trong một nhánh hoặc một môi trường thử nghiệm cho đến khi bạn đá nó và bắt được nhiều lỗi hơn không? Lỗi trong một nhánh thường gây ra ít sóng hơn lỗi trong mã sản xuất.

Nhưng tôi không chính xác đào những lời khẳng định của bạn dẫn đến câu hỏi của bạn. Và có lẽ ông chủ của bạn cũng không.

Tôi không nghĩ rằng mọi lập trình viên đều tạo ra tỷ lệ lỗi như nhau. Liên kết thứ hai của bạn thực sự hoàn toàn lạc đề vì nó so sánh các ngôn ngữ khác nhau, không phải các cấp độ kỹ năng mã hóa khác nhau. Mã hoàn thành đề cập đến một số phép đo mẫu lớn đang xem xét quy trình hơn là kỹ năng của các lập trình viên. Và khi họ nói rằng các lập trình viên hàng đầu tạo ra nhiều mã / tốt hơn, một phần của điều đó có nghĩa là nó có ít lỗi hơn. Phụ thuộc vào ứng dụng. Vì vậy, yeah, tôi nghĩ đó là một vấn đề của quan điểm khác nhau.

Cuối cùng, nếu ông chủ muốn mã sạch hơn, hãy đưa cho ông mã sạch hơn.

Tôi sẽ đi ra ngoài trên chi và trở thành người ủng hộ của quỷ. Điều đó không có nghĩa là tôi không đồng cảm với hoàn cảnh của bạn, nhưng, tốt, sự thông cảm của tôi sẽ không giúp bạn. Vì vậy, cho phép tôi thêm vào quan điểm của Philip :

Sếp của bạn quan tâm đến chất lượng của sản phẩm, một phần vì tên và danh tiếng của họ sẽ được gắn với nó. Một phần của chất lượng là số lượng lỗi nhận thức . Nếu bạn bán một máy khoan tuyệt vời, khoan nhanh hơn bốn lần so với bất kỳ máy khoan cạnh tranh nào, nhưng cũng bị hỏng gấp đôi thường xuyên, bạn sẽ bị mang tiếng xấu. Ngay cả khi người ta cho rằng máy khoan hoạt động tốt hơn, mọi người vẫn quen với tốc độ, nhưng họ sẽ nhớ các sự cố.

Nhìn nhận lại, hầu hết các lỗi rõ ràng là có thể phòng ngừa được. Nếu chỉ cần bạn cẩn thận hơn một chút, sếp của bạn sẽ cảm thấy, bạn có thể tránh những vấn đề này và bất kỳ việc dọn dẹp cần thiết nào. Từ quan điểm của anh ấy, đó là một điều tầm thường, nhạy cảm để hỏi, và bất kỳ tranh luận nào bạn làm về nó đều không hiệu quả và sẽ làm cho bạn trông xấu.

Anh ta không thể đo năng suất vượt trội của bạn. Bạn yêu cầu năng suất cao hơn dựa trên một số liệu có thể kiểm chứng, vậy làm thế nào để đồng nghiệp của bạn cảm thấy về nó? Họ có đồng ý, có lẽ miễn cưỡng, rằng bạn là một lập trình viên năng suất hơn, hoặc bạn chỉ có một mình trong quan điểm của bạn? Bạn sẽ làm cho một điểm mạnh hơn nếu bạn có người khác sao lưu các xác nhận của bạn.

Đó là cho quan điểm. Bây giờ, làm thế nào để bạn đi về 'sửa chữa' tình huống bực bội này bạn đang ở?

Làm chậm lại một chút. Đề cập rõ ràng đến bất cứ ai phân phối các nhiệm vụ mà bạn sẽ cố gắng giảm tỷ lệ lỗi (*), để họ không ngạc nhiên về mức tiêu thụ thấp hơn của bạn. Nếu bất cứ điều gì, làm chậm sẽ làm giảm số lượng lỗi được chỉ định cho bạn do thiếu nguồn cung cấp.

_{(*) Có sự khác biệt giữa, một mặt, thừa nhận rằng có những lỗi tên của bạn và rằng bạn sẽ cố gắng để giảm bớt số tiền đó và, mặt khác, thừa nhận rằng bạn có quá nhiều lỗi tên của bạn và nên hành động.}

Đừng cố gắng thuyết phục sếp của bạn, bởi vì nó sẽ không hoạt động. Một lần nữa, điều đó không có nghĩa là bạn phải thừa nhận quan điểm của mình; bạn có thể trình bày một quan điểm và giữ ý kiến ​​của bạn mà không bỏ qua mối quan tâm của anh ấy. Bởi vì nếu bạn tranh luận quan điểm và không thể chứng minh thỏa đáng năng suất vượt trội của bạn (và thậm chí nếu bạn có thể), bạn sẽ có nguy cơ xúc phạm đồng nghiệp của mình, hoặc tỏ ra coi thường họ. Bạn không muốn trở thành anh chàng đó .

Giả sử bạn sẽ tạo ra "số lượng" mã giống như các đồng nghiệp của mình trong 20% ​​thời gian của họ, bạn có thể chi tiêu gấp 4 lần cho việc thực sự gỡ lỗi mã và làm cho nó hoàn hảo, điều này sẽ làm giảm tỷ lệ lỗi của bạn nhiều hơn. Sau đó, bạn có thể gọi cho mình một lập trình viên tốt.

Câu hỏi lớn nhất là tại sao bạn lại mã hóa gấp 5 lần so với những người khác thay vì nhắm đến chất lượng. Đây có phải là cái gì đó cái tôi của bạn ra lệnh cho bạn hoặc ông chủ của bạn ép buộc bạn?

Ngoài ra, bạn cần xem xét chi phí để sửa lỗi. Khi bạn tìm thấy nó sớm, bạn vẫn có thể "bên trong" mã đủ để sửa nó một cách nhanh chóng. Nếu nó chỉ xuất hiện sau một tháng phát triển, có thể khó tìm hoặc thậm chí buộc bạn phải thay đổi phần lớn của mã đã được lập trình.

Bạn dường như có các kỹ năng để tạo mã và bạn có thể làm cho nó trở nên tuyệt vời nếu bạn tập trung vào chất lượng thay vì tốc độ. Hãy thử một lúc, tôi đoán là bạn sẽ thích nó.

Vấn đề tiếp theo sau đó là để có được sự thừa nhận (nói tiền) cho hiệu suất tốt hơn của bạn. Nói chuyện với sếp của bạn và hỏi anh ta cách tiến hành, đó là công ty và tiền của anh ta, và nếu anh ta muốn bạn sản xuất ít lỗi hơn, anh ta cũng nên quyết định theo cách nào nó xảy ra.

Các nhà phát triển có thể thông minh, thậm chí là thiên tài, có khả năng hiểu và mã hóa độc tấu, mà không phải là nhà phát triển TỐT. Một nhà phát triển giỏi tạo ra một tác phẩm chất lượng và làm cho toàn bộ dự án tốt hơn.

Tôi không nói đây là bạn, nhưng một trong những lập trình viên khó chịu nhất tôi từng làm việc đã viết nhiều mã hơn bất kỳ ai trong nhóm và chúng tôi có những người tốt trong nhóm. Chúng tôi đã theo dõi các cam kết với một phần mềm xếp hạng, vì vậy nó gần như là một cuộc cạnh tranh đối với một số người. Anh ta đưa ra những dòng mã, để lại cho anh ta tài liệu ZERO, những khu rừng bất khả xâm phạm và thực sự khiến tôi hiểu được một số mã của riêng tôi (tôi có thể tự mình làm điều đó, cảm ơn rất nhiều!). Cuối cùng anh ấy gần như trật bánh dự án, bởi vì anh ấy đã trở thành một người đàn ông cho thấy. Mọi người không thể theo anh ta. Chúng tôi không đồng bộ như một đội. Chúng tôi thực sự viết lại một số tính năng của anh ấy nhiều năm sau đó, chỉ để lấy lại khả năng bảo trì.

Điều tôi muốn từ anh ấy là làm chậm và dành nhiều thời gian hơn: 1) Cải thiện chất lượng của cơ sở mã 2) Giao tiếp với nhóm 3) Làm việc trên những thứ giúp người khác cũng như giúp anh ấy hoàn thành các tính năng / câu chuyện 4) Khắc phục lỗi

Tôi không đồng ý với việc đo lường năng suất theo các dòng mã, nhưng đó là một số liệu chính. Mã truy cập của bạn bao gồm ý kiến? Nếu vậy, có một cách dễ dàng để duy trì đầu ra dòng của bạn trong khi giảm "tỷ lệ lỗi"; chỉ cần tăng chất lượng và số lượng ý kiến ​​bạn viết. Nhận xét hiếm khi có lỗi (mặc dù chúng có thể) và nói chung, chúng tôi không có đủ nhận xét chất lượng. Tôi không bỏ qua lạm phát mã, nhưng hành động bình luận giống như một đánh giá mã nhỏ, nó buộc bạn phải suy nghĩ, tái cấu trúc và cải thiện.

Cố gắng để giác ngộ quản lý là một người không bắt đầu. Có một câu sáo rỗng cũ, "Bạn sẽ tin tôi hay đôi mắt dối trá của bạn?" Những gì ông chủ của bạn quan tâm là số lỗi. Không có số lượng hợp lý hóa sẽ cho họ biết nó có thể chấp nhận được. Đó là rủi ro nhiều hơn gấp đôi. Ngoài ra, bạn không phải là người duy nhất bị ảnh hưởng bởi số lượng lỗi của bạn. QA có hai lần công việc cố gắng xác định lỗi của bạn, vì vậy ban quản lý sẽ muốn bạn giảm bớt chúng.

Giải pháp tốt nhất là giảm số lượng lỗi bạn tạo ra , thời gian. Không chỉ quản lý sẽ hạnh phúc hơn, mà bạn cũng sẽ như vậy. Không bạn Vì tôi khá chắc chắn rằng bạn thích khoe khoang bạn vượt trội so với đồng nghiệp của mình theo hệ số bốn, bạn rất thích nói rằng bạn làm điều đó với cùng một số lỗi, hoặc thậm chí ít hơn so với họ.

Như bạn đã nói, "Chiếm tỷ lệ lỗi được thực hiện trong mã, có xu hướng bị ảnh hưởng bởi các quy trình được sử dụng khi viết mã và sau khi mã được viết." Nếu bạn muốn thay đổi tốc độ bạn tạo ra lỗi, bạn sẽ phải thay đổi các quy trình bạn sử dụng để viết mã.

Các lập trình viên sử dụng các phương thức sản xuất để sản xuất mã, giống như một dây chuyền lắp ráp sử dụng các phương thức để tạo ra một số đối tượng được sản xuất hàng loạt. Được rồi, thực tiễn của ngành công nghiệp phần mềm giống như những mẹo vặt trong các chi nhánh được tìm thấy trong rừng. Nhưng vì chúng tôi đang sản xuất máy móc, chúng tôi nên sử dụng cùng một quy tắc nghiêm ngặt và kỷ luật được sử dụng cho các máy sản xuất hàng loạt tốc độ cao.

Điều đó bao gồm các kỹ thuật tương tự được sử dụng trong sản xuất hàng loạt để giảm tỷ lệ lỗi: phân tích nguyên nhân gốc rễ để xác định lý do tại sao các lỗi được tạo ra và thay đổi quy trình để chúng không xảy ra. Hoặc ít nhất là bạn bắt trước khi QA làm.

1. Tạo một danh sách các lỗi của bạn. Có lẽ bạn đã có một lời cảm ơn đến các bạn QA. Có thể phân loại quá. Loại lỗi, mức độ nghiêm trọng, điểm mà lỗi được đưa vào mã, v.v.

2. Chọn loại lớn nhất của lỗi. Vì âm lượng của bạn quá cao, bạn nên nhắm mục tiêu đó trước. Các loại khác bao gồm những loại dễ tìm nhất và những loại dễ làm nhất.

3. Biết được những lỗi đó được đưa vào mã ở đâu, hãy xem xét các thay đổi ở giai đoạn đó (và trước đó) để ngăn những lỗi đó xảy ra và cách để bắt chúng dễ dàng hơn trong giai đoạn đó.

4. Hãy chắc chắn xem xét các sự cố không liên quan đến lập trình cũng như chúng có thể tạo ra sự khác biệt trong chất lượng công việc của bạn. Nhạc nền, gián đoạn, giờ ăn, làm việc quá lâu mà không nghỉ, đói, v.v.

Những gì bạn tìm thấy có thể dẫn bạn đi chậm hơn. Mặt khác, nó có thể giúp bạn sản xuất nhanh hơn vì bạn sẽ không cần phải làm lại những thứ bạn đã đặt phía sau bạn. Như vậy, mã nhiều gấp bốn lần không phải là một thứ tự có độ lớn tốt hơn so với đồng nghiệp của bạn, vì vậy thay đổi quy trình của bạn chắc chắn là cách tốt nhất.

Thay đổi mục tiêu của bạn từ sản xuất nhiều mã nhất để giúp công ty tiến lên phía trước nhiều nhất.

Vì có vẻ như bạn có nhiều đồng nghiệp cộng thêm thời gian có sẵn, hiệu quả nhất bạn có thể có trong việc cung cấp nhanh hơn các tính năng và sửa lỗi là giúp đỡ đồng nghiệp của bạn.

Giúp đỡ đồng nghiệp của bạn bằng cách

• sử dụng đánh giá mã để cải thiện chất lượng mã và giáo dục.
• tạo ra quá trình tự động hóa để làm cho công việc của họ nhanh hơn và cuộc sống của họ dễ dàng hơn.
• viết bài kiểm tra tốt hơn với họ
• tấn công mã kỹ thuật để cải thiện cơ sở mã
• trở thành anh chàng luôn sẵn sàng giúp đỡ người khác.
• viết / cải thiện các công cụ giúp tăng năng suất của nhà phát triển
• làm cho trường hợp với quản lý cho các công cụ / thiết bị / điều kiện làm việc tốt hơn cho đồng nghiệp của bạn nếu bạn có nhiều ảnh hưởng hơn.
• chuẩn bị và dẫn đầu các phiên giáo dục về viết mã tốt hơn.
• rèn luyện sự khiêm nhường

Vậy, làm thế nào để đối phó với thực tế là tăng năng suất sẽ dẫn đến số lượng lỗi tăng lên?

Sếp của bạn là người duy nhất có thể trả lời điều này trong trường hợp của bạn. Nói chuyện với anh ta, chỉ ra tỷ lệ tốt hơn của bạn và để anh ta quyết định. Nếu sự quyết định của anh ta không có ý nghĩa, đã đến lúc tìm kiếm một công ty với cách suy nghĩ của bạn.

Là chuyên nghiệp, bạn sẽ có thể làm việc với bất kỳ điều kiện khách hàng cụ thể nào, chỉ cần đảm bảo rằng họ hiểu hậu quả. Một biểu đồ lỗi / câu chuyện hay có thể giúp sếp của bạn hiểu được năng suất của bạn sẽ giảm bao nhiêu nếu bạn dành thời gian để tạo ra ít lỗi hơn.

Bạn cũng cần xem xét những điểm sau:

• độ phức tạp của các câu chuyện, ví dụ các trình bao bọc getter / setter đơn giản so với các phép tính thống kê hoặc lập trình thời gian thực hoặc thậm chí là thống kê thời gian thực ...
• mức độ nghiêm trọng của lỗi, đó là lỗi chính tả nhỏ trên các trường văn bản hoặc kết quả tính toán sai, sự cố chương trình
• chi phí để sửa lỗi, cả nếu bạn làm điều đó ngay bây giờ, sau này hoặc nếu người khác phải hiểu mã của bạn vì bạn đã để lại

Tình huống là bạn làm việc nhanh gấp bốn lần so với lập trình viên trung bình, nhưng bạn mắc lỗi nhiều gấp đôi trong một khoảng thời gian nhất định. Liên quan đến số lượng công việc bạn làm, bạn thực sự mắc HALF nhiều lỗi như "trung bình".

Bạn có thể cố gắng chỉ ra những sai lầm thấp của bạn đối với tỷ lệ làm việc, hoặc thậm chí sai lầm đối với sản phẩm đã hoàn thành (mà bạn có thể hoàn thành trong một phần tư thời gian bình thường). Hầu hết các ông chủ sẽ chấp nhận điều đó.

Có một vài ông chủ sẽ không vì họ làm việc với tư duy "trợ cấp" cho những sai lầm mỗi lần. Sau đó, bạn có thể làm chậm tiến độ công việc của mình, thực hiện TWICE nhiều công việc ở mức trung bình trong một thời gian nhất định và mắc lỗi tương tự (hoặc ít hơn) vì bạn có nhiều thời gian hơn để kiểm tra công việc của mình.

Nếu sếp của bạn muốn bạn cải thiện chất lượng công việc, thì hãy cải thiện chất lượng công việc.

Bạn nên nhắm đến các lỗi không, không nhằm mục đích chỉ sản xuất gấp đôi so với lập trình viên giỏi nhất tiếp theo.

Bạn nên nói với sếp của bạn rằng các số liệu anh ta đang sử dụng là khá thiếu sót. Nếu bạn nhìn vào doanh thu của những người bảo vệ tại NBA, bạn sẽ thấy rằng họ có xu hướng có số lượng cao hơn về phía trước. Nhưng, đó là bởi vì họ đang xử lý bóng nhiều hơn. Nếu một người bảo vệ không bắt đầu chơi 1/5 nhiều như một người bảo vệ bắt đầu và bật bóng trên 3 lần trung bình .vs. một người bảo vệ bắt đầu quay bóng hơn 7 lần mỗi trận - thoạt nhìn có vẻ như người bảo vệ bắt đầu tệ hơn. Nhưng, nếu bạn chia số doanh thu cho số phút đã chơi, thì rõ ràng người bảo vệ bắt đầu có số tốt hơn nhiều dựa trên số phút đã chơi.

Tương tự như vậy, bạn có số lượng tốt hơn nhiều nếu số lượng lỗi được chia cho số điểm câu chuyện hoàn thành. Vì vậy, đó là những gì tôi sẽ đề xuất với người quản lý của bạn. Thay đổi số liệu thành số lỗi được chia cho các điểm câu chuyện đã hoàn thành hoặc ít nhất là thêm một số liệu mới cho điều này nếu tổng số lỗi cho mỗi nhà phát triển là cần thiết. Nhưng, vì một số điểm câu chuyện khó hơn và phức tạp hơn nhiều so với các điểm câu chuyện khác, nên có thể và sẽ có khá nhiều phương sai và điều này cũng cần được người quản lý tính đến.

Những gì tôi không nghĩ bạn nên làm là chậm lại.

Đo lường giá trị gia tăng

Lập luận rằng những gì thực sự được tính là giá trị bạn thêm. Sau đó đi và giới thiệu phép đo thô (thủ công) của điều đó:

• Ước tính giá trị của chức năng bạn sản xuất
• Trừ tiền lương của bạn
• Trừ chi phí ước tính cho các lỗi của bạn (ít nhất là chi phí để sửa chúng)
• Trừ chi phí ước tính của tất cả các khoản nợ kỹ thuật khác mà bạn tạo ra

Phần còn lại là giá trị gia tăng của bạn. Tương tự như vậy đối với mọi người khác.

Những ước tính này là khó, nhưng ngay cả những người thô có thể làm cho điểm. Và quá trình chỉ thảo luận về các ước tính này là hữu ích cho nhóm và dự án.

Các lập trình viên hàng đầu có xu hướng viết mã rất thường xuyên, dễ gỡ lỗi và hiểu, họ sử dụng các công cụ có sẵn (phân tích tĩnh, lỗi trình biên dịch, mã gỡ lỗi) đến mức tối đa. Ngoài ra, các lập trình viên hàng đầu đã học được giá trị của kiểm thử đơn vị thông qua kinh nghiệm khó khăn của riêng họ.

Vì vậy, trong khi số lượng vấn đề ban đầu trên mỗi dòng là như nhau, thì các vấn đề được loại bỏ nhanh hơn.