Làm thế nào để có được thành viên nhóm mới cập nhật với dự án? [đóng cửa]

Chúng tôi sắp thuê 1-2 kỹ sư mới cho nhóm phần mềm (bao gồm 3 nhà phát triển, 1 người thử nghiệm).

Các bước để tích hợp chúng vào nhóm là gì?

Ý tưởng của tôi là:

• đọc tài liệu (tiêu chuẩn mã hóa, tài liệu trong phương pháp phát triển chúng tôi sử dụng)
• khiến họ đọc mã hiện có
• giao cho họ một số nhiệm vụ đơn giản
• cuối cùng, làm cho họ chịu trách nhiệm cho phần mã

Chúng tôi có thể làm gì nữa?

Dự án là trong một lĩnh vực y tế (hệ thống siêu âm), và đã 5 năm. Chúng tôi có các bản phát hành hàng năm và chúng tôi sắp hoàn thành một bản phát hành, khi chúng tôi muốn thêm 1-2 kỹ sư.

Dự án đang trong giai đoạn bảo trì (tái cấu trúc mã kế thừa, cộng với việc thêm các tính năng mới). Mọi thứ khá nhiều trong lịch trình (nhiều hay ít).

Đến từ một người phải tăng tốc trên nhiều loại tiền mã hóa khác nhau trong sự nghiệp của tôi, đây là những gì tôi muốn đề xuất:

1. Dành một khoảng thời gian ngắn (có thể một hoặc hai ngày) với các hoạt động liên quan đến việc sử dụng sản phẩm để họ có thể làm quen với những gì sản phẩm làm. Điều này có thể là xác minh lỗi hoặc thực hiện kế hoạch kiểm tra QA hoặc trải qua đào tạo người dùng.
2. Làm việc trên các lỗi nhỏ, cục bộ. Điều này giúp kỹ sư làm quen với cách xây dựng và gỡ lỗi ứng dụng mà không phải đối phó với việc học nhiều kiến ​​trúc.
3. Lý tưởng nhất là viết một tính năng mới nhỏ được bản địa hóa. Điều này cho phép họ viết một đoạn mã và khi họ viết nó, họ sẽ trở nên quen thuộc với các đoạn mã xung quanh mà mã mới của họ cần để làm việc.

Từ đó, mở rộng phạm vi và độ phức tạp của các bài tập theo thời gian tùy thuộc vào mức độ kinh nghiệm và năng khiếu của kỹ sư. Điều đó sẽ cho phép nhà phát triển mở rộng kiến ​​thức về codebase một cách tự nhiên.

Tôi sẽ tránh chỉ đọc các nhiệm vụ (tài liệu hoặc mã). Đọc tài liệu trở nên thực sự nhàm chán rất nhanh và đọc mã ngẫu nhiên không hữu ích vì họ sẽ không có bất kỳ bối cảnh nào để làm việc. Thật khó để đọc mã cho các đánh giá mã khi bạn đã biết sản phẩm & codebase. Tôi không thể thấy bất cứ điều gì hữu ích khi có một kỹ sư hoàn toàn mới chỉ đọc mã.

Cảm giác của tôi là hầu hết khả năng chịu đựng của mọi người đối với việc đọc tài liệu là khá thấp (Tốt trong một hoặc hai ngày, nhưng ngoài ra họ có thể sẽ cảm thấy khó chịu khi làm điều gì đó thực tế hơn một chút).

Tôi không nghĩ rằng bạn thực sự có thể hiểu được mã của ứng dụng mà không có sự hiểu biết hợp lý về chính ứng dụng đó. Phần mềm có lẽ có nhiều chức năng mà họ có thể 'đồ chơi' với tư cách là người dùng; cuối cùng họ sẽ cần phải có thể kiểm tra nó, vì vậy tôi mong rằng điều quan trọng là họ biết cách cài đặt nó, định cấu hình và thực hiện các tác vụ chung với nó

Cá nhân tôi thấy rằng một tổng quan kiến ​​trúc cấp cao thường khá tiện lợi để có được cảm giác cơ bản về cách mọi thứ hoạt động - Có thể phân bổ một hoặc hai giờ của một kỹ sư cao cấp (hoặc chính bạn nếu cần thiết?) Trong tuần đầu tiên của họ chỉ đơn giản là trải qua các hạt cơ bản của ứng dụng chính. ví dụ: hiểu tất cả các hệ thống con và cách mọi thứ gắn kết với nhau, biết các bit nào được xử lý bởi phần mềm / thư viện của bên thứ 3 và các bit nào cần được duy trì trong nhà. (Trừ khi tổ chức của bạn có tài liệu cập nhật về chất lượng thực sự đặc biệt, tôi đoán rằng sẽ không có cách nào họ có thể nắm bắt được những thứ đó mà không có ai giải thích trực tiếp với họ bằng bảng trắng: - ))

Đối với việc cho họ một cái gì đó "thực hành", các nhiệm vụ theo đuổi bảo trì / sửa lỗi có thể là một cách tốt để giúp họ tăng tốc trong một thời gian (một vài tuần / tháng?) - họ sẽ ở trong các tình huống trong đó các lĩnh vực chức năng cụ thể cần được hiểu, thử nghiệm và gỡ lỗi; giúp xây dựng kiến ​​thức về mã, các yêu cầu, các công cụ được sử dụng bởi công ty, các quy trình phát triển và (các) sản phẩm trong khi hy vọng không cần phải mất quá nhiều thời gian từ phần còn lại của nhóm phát triển

Là người dẫn đầu, tôi dành ít nhất 2 ngày với các nhà phát triển mới. Tôi đã phát hiện ra rằng việc phát triển một mối quan hệ trong đó cảm thấy thoải mái khi đặt câu hỏi không thể tránh khỏi "tiến triển của bạn như thế nào?" là một PHẢI. Có sự sợ hãi trong bất kỳ cộng đồng mới nào để phù hợp với ... chúng tôi che giấu sai lầm, hành động hoàn hảo, làm mọi thứ tốt hơn so với hiện tại, giảm bớt khó khăn. Một người quản lý dành 2 ngày với ai đó sẽ cho họ biết đó không phải là văn hóa của họ và cho phép họ dẫn dắt bằng ví dụ. Các lập trình viên mới cần một bài học lịch sử về nơi bạn đến và khoảng cách bạn đi cùng. Tài liệu chỉ không làm nhiệm vụ công lý.

Tôi mới chỉ làm việc trong ngành được 10 tháng (Về vị trí) nhưng tôi thấy những điều sau đây đã giúp tôi:

• Hợp tác với các nhà phát triển khác và quan sát cách họ giải quyết các vấn đề.
• Kiểm tra phần mềm đã giúp, tôi sẽ cần kiểm tra tính năng x có nghĩa là tôi đã đọc tài liệu về tính năng x. Tôi đã làm điều này rất nhiều, nó đã giúp.

Cả hai đều giúp tôi một chút công bằng. Chúc may mắn.

Tôi sẽ đi từ cấp cao đến thấp.

Demo ứng dụng càng sớm càng tốt

Một trong những điều quan trọng nhất là nhà phát triển có ý tưởng về những gì họ sẽ làm việc. Trong bản demo, chỉ ra một số điều đang được phát triển gần đây và hướng ứng dụng đang đi.

Giải thích kiến ​​trúc cấp cao

Điều này cũng rất quan trọng. Cho phép các nhà phát triển mới lắng nghe và đặt câu hỏi. Làm điều này như một bài tập nhóm với các nhà phát triển khác, những người hy vọng sẽ hòa nhập và giúp đỡ bạn. Điều này sẽ cho nhà phát triển mới biết rằng bạn có thể lên tiếng cởi mở và trung thực.

Có một tài liệu nội trú tuyệt vời đã sẵn sàng

Có một tài liệu trên máy bay tuyệt vời không chỉ giúp các nhà phát triển mới, mà cả những người cũ. Nó có thể chứa các kỳ vọng, các liên kết hữu ích và thông tin thiết lập môi trường. (Tôi không thể nói với bạn bao nhiêu lần tôi đã sử dụng máy bay nội trú của chúng tôi để thiết lập môi trường của tôi khi tôi nhận được một máy tính mới ...) ít chi tiết.

Khuyến khích anh ấy / cô ấy đặt câu hỏi (và sẵn sàng trả lời chúng)

Với câu trả lời, hãy hướng dẫn họ, nhưng đừng nói họ phải làm gì. Cung cấp cho họ gợi ý nhưng cho phép họ cuối cùng tự tìm ra nó.

Giúp các thành viên khác trong nhóm chào đón người mới

Có hai mặt của đồng tiền khi ai đó tham gia vào một nhóm. Nhóm cần phải có các công cụ để chào đón nhà phát triển mới.

Hãy để họ nhận một hoặc hai nhiệm vụ nhỏ

Cho phép họ thêm một cái gì đó mới và hiển thị cho dự án có khả năng demo. Khi nó được demo, hãy gọi ai đã làm nó và họ đã làm tốt công việc gì. Điều này thực sự có thể thúc đẩy lòng tự trọng. Họ càng nhanh cảm thấy mình đang gia tăng giá trị, họ càng cảm thấy mình là một phần của đội. Nhanh hơn họ sẽ cảm thấy được trao quyền để làm tốt nhất có thể.

Khuyến khích họ tham gia vào các nhiệm vụ khó khăn hơn một khi họ cảm thấy ngày càng thoải mái hơn

Ứng cử viên tốt sẽ làm điều này một cách tự nhiên.

Một luồng "định hướng" mà tôi đã trải qua (và thấy hữu ích) là một thứ gì đó dọc theo dòng:

1. Một bản trình bày ngắn gọn cho "Bức tranh lớn" các thành phần là gì, mức độ phù hợp và kiến ​​trúc chung.
2. Tổng quan về mã, giới thiệu các hàm xử lý logic chính cho (các) thành phần được gán cho tôi. Bao gồm một số thứ liên quan đến quy ước và phong cách mã hóa.
3. Một loạt các vấn đề mở và các lỗi ưu tiên thấp đã được chỉ định (phần lớn được bản địa hóa cho thành phần được gán cho tôi và khá đơn giản).
4. Tôi dự kiến ​​sẽ gỡ lỗi thông qua ứng dụng và yêu cầu trợ giúp với những thứ mà tôi không thể giải mã được.
5. Sau khi sửa lỗi, tôi đã thực hiện quy trình (xem lại mã, kiểm tra mức độ, v.v.) để phát hành tích hợp.
6. Lặp lại cho các nhiệm vụ / lỗi còn lại được phân bổ.

Tôi cảm thấy phương pháp này (và các biến thể của nó) sẽ hữu ích vì:

• Đây là một thực hành nhiều hơn và tương đối độc lập (liên tục không cầm tay, vv). Vì vậy, nó cung cấp đủ phòng / thời gian để người mới làm quen với mã và cách mọi thứ được thực hiện trong nhóm.
• Nó cũng có lợi cho toàn bộ nhóm vì một vài nhiệm vụ / lỗi ưu tiên thấp có thể được giải quyết. Người giúp đỡ những người mới cũng có nhiều thời gian hơn để xử lý các nhiệm vụ được giao cho họ vì không cần phải cầm tay liên tục và thời gian có thể được lên lịch cụ thể để xử lý các vấn đề / vấn đề mà người mới có thể gặp phải.

Thuê ban đầu cần một nhiệm vụ nhỏ, nhưng không quá nhỏ và được xác định rõ để làm việc. Bằng cách này, họ có thể bắt đầu cảm nhận về cách cấu trúc mã bằng cách cố gắng tìm ra cách hoàn thành nhiệm vụ của họ. Trong quá trình, các câu hỏi sẽ xuất hiện và tại thời điểm đó, bạn có thể hướng chúng đến tài liệu hoặc các tài nguyên khác mà chúng có thể sử dụng để giúp chúng nội hóa cơ sở mã. Nó cũng giúp nếu chu kỳ phát triển, cam kết, triển khai của bạn ngắn và họ có thể thấy thành quả lao động của mình trong hành động càng nhanh càng tốt.

Đây là cách tôi đi

1. Cung cấp cho họ một số tác vụ liên quan đến dự án (ví dụ: Nếu dự án của bạn là ứng dụng cơ sở dữ liệu, hãy yêu cầu họ chỉ tạo một ứng dụng để kết nối với cơ sở dữ liệu và thực hiện một số thao tác đơn giản.)
2. Khi bạn thấy họ đã hiểu ý tưởng làm việc, hãy đưa cho họ bản demo của Dự án
3. Yêu cầu họ đọc tài liệu.
4. Làm cho họ quen thuộc với các phong cách và tiêu chuẩn mã hóa
5. Sau đó cung cấp cho họ một số bài tập gỡ lỗi (để biết dòng chảy của dự án).
6. Yêu cầu họ sửa một điểm mà bạn đã sửa (chỉ để tìm hiểu logic của họ với nó).
7. Cuối cùng làm cho họ một phần của dự án.

Hãy nhớ rằng: cho dù bạn cố gắng bao nhiêu, cho đến khi và trừ khi người tham gia hiểu hoàn toàn dự án, bạn sẽ không thể hoàn thành công việc một cách hiệu quả nhất từ ​​anh ấy.

Số một - trước tiên hãy tìm hiểu cách sử dụng phần mềm để khám phá những vấn đề mà nó giải quyết từ quan điểm của người dùng. Nếu nó không có UI (ví dụ: dịch vụ phụ trợ hoặc thứ gì đó), hãy để họ sử dụng bất kỳ giao diện nào có sẵn để sử dụng giao diện đó. Nhận được một cái nhìn mới về quan điểm của người dùng đối với phần mềm của bạn luôn tốt và nó có thể giúp nhân viên mới thấy những thứ mà bạn không thể, do bạn đã được nhúng vào dự án.

Sau này, một dự án đầu tiên tốt có thể là một cái gì đó giống như một phần bổ sung hoặc mô-đun mới để thêm vào phần mềm, giảm thiểu lượng kiến ​​thức cần thiết cho cơ sở mã hiện có. Viết một cái gì đó mới sẽ luôn dễ dàng hơn việc thực hiện sửa lỗi, có thể yêu cầu nhiều thay đổi trên nhiều tệp nguồn. Theo tôi, việc cho nhân viên mới một nhiệm vụ sửa lỗi có thể sẽ khiến họ tắt công ty của bạn.

Phác thảo của bạn để làm quen những cái mới với dự án có vẻ hợp lý. Nhưng hãy nhớ rằng họ sẽ có nhiều thứ để học ngay từ đầu. Đây thường là một tình huống áp đảo. Bạn sẽ phải kiên nhẫn và trả lời các câu hỏi tương tự lặp đi lặp lại. Điều này là bình thường, các nhà phát triển mới phải học hỏi rất nhiều, đừng đánh giá thấp điều này. Nếu bạn tức giận về những câu hỏi lặp đi lặp lại này, bạn sẽ có nguy cơ rằng họ sẽ không hỏi và cố gắng tìm hiểu những điều một mình có thể rất chậm nhưng tốt nhất là không thể. Ngoài ra họ sẽ phải học biệt ngữ. Hầu hết các dự án nhóm phát triển ngôn ngữ riêng của họ. Khi giải thích có ý thức cố gắng tránh các biệt ngữ. Giải thích những thứ này giống như bạn sẽ giải thích nó cho mẹ của bạn. Một lần nữa, hãy kiên nhẫn.

Ngoài ra, bạn có thể thử tích hợp chúng với những người khác đã có trong nhóm bằng cách thử một số nhiệm vụ kiểu trung tâm đánh giá, ví dụ: xây dựng cây cầu trong 45 phút từ 4 tờ giấy hỗ trợ cốc cà phê. Chúng tôi sử dụng kỹ thuật này trong một khóa học thực tế về công nghệ phần mềm để khiến một nhóm 8 sinh viên phá băng trước khi họ làm việc trong một dự án duy nhất trong 3 tuần. Nó giúp tăng tốc các pha hình thành đội.

1) Cung cấp cho họ một lời giải thích về các quy tắc và hướng dẫn mã của bạn. Cũng đưa ra một lời giải thích chung về cách ứng dụng của bạn hoạt động và cấu trúc mã chung.

2) Tìm một số lỗi nhỏ hoặc dự án phần lớn độc lập với mã khác. Giải thích những gì cần phải được thực hiện, nơi trong mã và kiểm tra chúng thường xuyên.

3) Từ từ bắt đầu cung cấp cho họ các dự án lớn hơn và lớn hơn trong khi kiểm tra chúng ngày càng ít hơn.

4) Thỉnh thoảng ngồi cạnh họ. Bạn có thể học được rất nhiều bằng cách chỉ nhìn cách người khác giải quyết vấn đề. Những điều nhỏ như "oh, bạn có thể tìm các hàm trong mã của mình bằng cách đặt trước ctrl-." rất hữu ích

Bây giờ, tôi đã thấy rằng có hai thái cực :

• Một người hỏi một câu hỏi cứ sau năm phút. "Con đường này làm gì. Làm thế nào?". Họ nên Google trước để có câu trả lời và chỉ đến với bạn khi họ không thể tìm thấy câu trả lời.

• Và cực đoan khác, một người làm việc trong nửa ngày mà không hỏi một câu hỏi nào. Họ nên cảm thấy như đó là một điều tốt để đặt câu hỏi. Tôi chỉ muốn họ thử nó trước.

Đây là công thức của tôi và được sử dụng với một số người mới - những bước này đã được chứng minh là có hiệu quả cao.

a) Tất cả các nhà phát triển mới sẽ được giới thiệu một số yêu cầu về dự án và quy trình phát triển trong 2 ngày.

b) Chỉ định 3 tuần nhiệm vụ viết các bài kiểm tra Junit cho mã không có đủ độ bao phủ.

c) Sau khi hoàn thành 3, chỉ định các nhiệm vụ nhỏ

d) Phân công các nhiệm vụ phức tạp và thực hiện.

Tôi nghĩ chỉ cần giao một số nhiệm vụ nhỏ, yêu cầu họ viết một vài bài kiểm tra đơn vị, làm cho chúng gỡ lỗi một số hồi quy thất bại. Không có gì quá lớn hoặc đòi hỏi, nhưng đủ để có chúng trên đôi chân của họ.

Bạn cũng nên chỉ định một nhà phát triển cao cấp, tốt nhất là cho mỗi nhà phát triển mới có thể giúp cố vấn cho ứng viên.

Và vâng, làm cho họ ghi lại những gì họ đang tìm hiểu về hệ thống. Tôi giả sử ở đây rằng bạn có một số loại trang wiki nội bộ. Nếu không, đó chắc chắn là điều bắt buộc trong cả dài hạn và ngắn hạn - cách nhanh chóng đáng ngạc nhiên để khiến mọi người nổi giận. Các trang Wiki không chỉ chứa tài liệu mã, mà còn chứa các thứ như giới hạn đã biết (đây là phần mềm: D), cách giải quyết, số liệu hiệu suất thời gian / bộ nhớ, v.v.

Đừng chỉ giải thích các thực tiễn và tiêu chuẩn tốt về mã hóa, mà hãy giải thích cách mã đọc được cấu trúc. Giải thích những gì phần mềm được cho là phải làm và làm thế nào để đạt được điều này.

Họ sẽ không hiểu cho đến khi có một số việc phải làm, vì vậy tôi đề nghị sẽ chia thành hai phần, một phần trước khi họ bắt đầu công việc thực sự và phần hai, sau khi họ bắt đầu làm việc. Họ sẽ xem xét một số mã hoặc tài liệu và nghĩ " WTF!? ". Khi điều này xảy ra, ai đó sẽ đi cùng họ và giải thích các chi tiết nhỏ.