Làm thế nào để bạn chứng minh hiệu suất trong môi trường lập trình cặp?

Đánh giá hiệu suất đã xuất hiện gần đây trong công việc của tôi, và tôi đã được đặt ở một vị trí thú vị. Nhóm của chúng tôi thực hiện nhiều chương trình cặp, có xu hướng lấy trung bình sự khác biệt về kỹ năng giữa các thành viên trong nhóm (đặc biệt là xem xét chúng tôi xoay cặp). Nói chung, khi thực hiện đánh giá hiệu suất, bạn nhìn lại công việc bạn đã thực hiện và chứng minh những gì bạn đã hoàn thành và cách bạn vượt quá mong đợi để cố gắng thương lượng tăng lương hoặc các lợi ích khác.

Làm thế nào để bạn chứng minh (hoặc thậm chí đo lường) hiệu suất cá nhân trong một môi trường như thế này?

bao gồm giá trị bạn đã thêm vào lập trình cặp trong đánh giá hiệu suất - bạn đã giúp lập trình viên khác học những điều hữu ích chưa? (và ngược lại, bạn có nghe lời khuyên hiền triết của anh ấy / cô ấy và hợp tác tốt không?)

đánh giá hiệu suất không nên là một cuộc thi, nó phải là một đánh giá huấn luyện liên quan đến mục tiêu cá nhân của bạn (có lẽ phù hợp với mục tiêu của công ty và được hai bên thống nhất vào đầu năm; nếu không thì chỉ là tùy ý)

Thật khó để chứng minh một cách dứt khoát một lợi ích hiệu suất so với cái kia một cách khoa học.

Giả thuyết của bạn là lập trình cặp làm tăng hiệu suất của nhà phát triển và cải thiện chất lượng. Thử nghiệm của bạn sẽ liên quan đến việc cung cấp cho một cặp các yêu cầu bị ràng buộc đối với một kiến ​​trúc sư cụ thể và để họ thực hiện nó.

Kiểm soát của bạn trong trường hợp này là bạn đưa ra các yêu cầu tương tự cho một nhà phát triển duy nhất có vị thế, kỹ năng và kinh nghiệm ngang nhau (được đánh giá khách quan bởi các đồng nghiệp của anh ta) và cũng bị ràng buộc trong cùng một kiến ​​trúc.

Để xác minh giả thuyết về hiệu suất thời gian của bạn, các lập trình viên cặp phải hoàn thành công việc của họ trong vòng chưa đến một nửa thời gian làm điều khiển. Để xác minh giả thuyết về chất lượng của bạn, bạn phải có cặp thử nghiệm và mã kiểm soát được xem xét bởi bên thứ ba khách quan và có nhóm QA khách quan kiểm tra kết quả của cả hai nhóm mà không cho họ biết nhóm nào đã tạo ra cái gì. Nhóm lập trình cặp phải có mã tốt hơn và ít lỗi hơn.

Nó không phải là một thử nghiệm hoàn hảo nhưng tôi sẽ rất thích thú khi biết ai đó đã thử làm điều gì đó tương tự.

Bên cạnh đó, tuy nhiên tôi không thể thấy làm thế nào bạn thực sự có thể chứng minh rằng Lập trình cặp là vượt trội so với một lập trình viên duy nhất trên một tính năng nhất định.

Trong các số liệu hiệu suất của bạn, hãy gọi riêng 1) tăng trưởng và phát triển cá nhân, và 2) cố vấn và hỗ trợ đồng đẳng. Cho phép mỗi nhân viên tự đánh giá và kết hợp phản hồi của khách hàng tiềm năng của họ. Nếu nó có ý nghĩa trong văn hóa công ty của bạn, hãy xem xét đánh giá ngang hàng hoặc lời chứng thực.

Nếu được thực hiện một cách chính xác, nhân viên nhận được giá trị giáo dục cao nhất từ ​​việc ghép đôi sẽ được khen thưởng vì khả năng đóng góp lâu dài cho nhóm và nhân viên giúp họ tăng tốc sẽ được khen thưởng khi chuyển giao kiến ​​thức và kinh nghiệm. Những người ở đâu đó ở giữa (học các lĩnh vực mới thay vì chỉ chuyển từ cấp cơ sở sang cấp cao hơn) được công nhận cho cả hai đầu của phương trình.

Trong thực tế, đánh giá hiệu suất cá nhân là khó khăn trong trường hợp tốt nhất. Thật khó để làm điều đó mà không tạo ra một số cảm giác oán giận hoặc cạnh tranh. Nhưng nếu bạn đánh giá đóng góp cá nhân cho nhóm và bạn coi trọng cả việc học và dạy, thì sẽ có một số cơ hội để làm cho nó hoạt động với ít ma sát hơn.

Là các cặp chuyển đổi thường xuyên? Nếu vậy, bạn có thể sử dụng các đánh giá ẩn danh để đưa ra một thước đo. Ví dụ: nếu người A nói rằng B đã làm 60% công việc, thì người C nói rằng người B đã làm 30% công việc và người D nói rằng người B đã làm 90% công việc, bạn có thể tính trung bình cho người B làm 60% công việc. Nếu công việc mà người B hoàn thành trong cặp của mình có hệ số tương đối là 100 điểm, thì người B đã làm được 60 điểm công việc!

Tuy nhiên, điều này không (bất cứ nơi nào gần) hoàn hảo. Mọi người có khả năng cung cấp cho mình nhiều tín dụng hơn họ cung cấp cho người khác, vì vậy bạn có thể cần phải tính đến điều này trong tính toán. Điều này cũng có thể dẫn đến một môi trường nơi các cặp nghi ngờ lẫn nhau. Tính toán cũng có thể được thay đổi bởi một người không thích người họ đang làm việc cùng, v.v.

Tôi nói nếu hai chúng tôi làm việc cùng nhau để tạo X, thì cả hai chúng tôi đều nhận được tín dụng vì đã hoàn thành và triển khai nó. Trường hợp bạn có thể gặp sự cố là khi một phần của một cặp không hoạt động. Trong trường hợp này, người quản lý nên được thông báo về điều này cùng và do đó nên sử dụng phản hồi đó khi điền nhận xét của mình vào đánh giá hiệu suất.

Bạn đang ở trong tình huống chính xác mà giáo viên của tôi đưa chúng tôi học sinh thông qua chương trình phát triển trò chơi của chúng tôi. Chúng tôi được ghép đôi (2, 3 hoặc 4 người tùy thuộc vào quy mô lớp học và quy mô dự án) và cuối cùng, chúng tôi được yêu cầu đánh giá từng thành viên trong nhóm và bản thân chúng tôi liên quan đến dự án và công việc đã được thực hiện cũng như các dự án của các đội khác nói chung. Một lớp được xây dựng dựa trên những đánh giá này.

Trong quá trình xây dựng đội ngũ, giáo viên sẽ cố tình đặt một lập trình viên mạnh và một lập trình viên yếu với nhau với hy vọng họ sẽ làm việc với nhau và / hoặc giúp đỡ nhưng 99% thời gian mà lập trình viên yếu sẽ trượt qua và không làm gì cả không có manh mối gì về những gì họ đang làm (Đây là khóa học nâng cao, nó rất bực bội).

Các đánh giá được cho là riêng tư, nhưng hãy nói rằng, có một vài người mà mọi người từ chối làm việc với nhau nữa.

Lập trình cặp có nghĩa là một người nghĩ những gì và làm thế nào một cái gì đó nên được thực hiện, và người kia đóng vai một con khỉ mã hóa. Sau đó, tại một số thời điểm họ chuyển đổi (một người trở nên buồn chán, mệt mỏi, vv). Điều đó là tốt, bởi vì cả hai không bị gián đoạn tại các hoạt động của họ.

Một số người cũng coi đó là "đánh giá mã về steroid". Bạn nhận được mã được xem xét, có nghĩa là chất lượng cao hơn.

Câu hỏi hay. Điều quan trọng không chỉ đơn thuần là những gì bạn đóng góp, mà là cách các đồng nghiệp nhìn thấy sự đóng góp của bạn. Yêu cầu họ cho phản hồi thẳng thắn của họ cho rằng phản hồi này giúp bạn trở nên tốt hơn 'bất cứ điều gì' . Nghiêm túc mà nói, điều quan trọng là đồng nghiệp của bạn hiểu được sự đóng góp của bạn và họ chỉ hiểu điều đó khi họ có được sự học hỏi công bằng trong khi ghép đôi với bạn. Hạnh phúc mã hóa, chia sẻ và học tập do đó mang lại thu nhập tốt.

Nhược điểm của lập trình cặp là năng suất lập trình viên có nhiều kinh nghiệm hơn bị giới hạn ở năng suất lập trình viên ít kinh nghiệm nhất, trong ngắn hạn, trung hạn. Về lâu dài, kinh nghiệm và năng suất được tăng lên trong nhà phát triển cơ sở.