Mẹo / thủ thuật để quản lý một nhóm mới với mã mới [đã đóng]

Làm thế nào để bạn xử lý bản thân trong một nhóm mới, nơi bạn là nhà phát triển cao cấp nhất và hầu hết những người khác trong nhóm đều kém bạn vài năm. Nhiệm vụ trước đội là điều mà không ai khác kể cả bạn đã hoàn thành trong sự nghiệp của họ trước đây.

Quản lý nhấn mạnh vào năng suất cao hơn của toàn đội và là nhà phát triển cấp cao, bạn phải chịu trách nhiệm.

Bất kỳ lời khuyên cho ra khỏi trumps trong một tình huống như thế này? Rõ ràng, toàn đội cần có thời gian để học và đừng quên đội mới. Tuy nhiên, thời hạn cũng đang ở phía trước ...

Đừng để thời hạn chặt chẽ hoặc tính mới của dự án can thiệp vào thực hành kỹ thuật tốt. Thiết lập kho lưu trữ phần mềm, đồng ý với phong cách mã hóa, đi kèm với bộ kiểm tra, v.v. Tính mới của nhiệm vụ không phải là vấn đề lớn miễn là bạn có những người chất lượng dưới quyền bạn sẵn sàng làm việc chăm chỉ và học hỏi nhiệm vụ trước mắt họ

Hoặc nói cách khác: bạn được giao trách nhiệm vì ban quản lý tin rằng nền tảng và kinh nghiệm của bạn đã cung cấp cho bạn các công cụ cần thiết để xây dựng phần mềm chất lượng. Đừng đột nhiên quên các kỹ năng của bạn chỉ vì nhiệm vụ này có vẻ khó khăn.

Trước tiên, hãy bắt đầu sử dụng một hệ thống kiểm soát mã nguồn từ dòng mã đầu tiên. Tập thói quen kiểm tra mã sớm và thường xuyên.

Thứ hai, quyết định một chiến lược thử nghiệm . Tất nhiên điều đó có nghĩa là kiểm tra đơn vị, nhưng bạn cũng nên xem xét cách tự động hóa kiểm tra chấp nhận.

Thứ ba, thiết lập một máy chủ tích hợp liên tục để mã của bạn được xây dựng thường xuyên và được kiểm tra thường xuyên.

Một khi bạn có được điều đó, khi một nhóm thiết lập một số tiêu chuẩn mã hóa đơn giản . Bạn muốn mã của bạn dễ dàng được đọc bởi mọi người. Nó không thực sự quan trọng các tiêu chuẩn là gì. Thụt với các tab, thụt lề với dấu cách, dấu ngoặc nhọn trên cùng một dòng, bất cứ điều gì. Không quan trọng chúng là gì, chỉ có điều mọi người đều áp dụng chúng.

Vì nhóm chủ yếu là các nhà phát triển cơ sở, nên thường xuyên lên kế hoạch xem xét mã để đảm bảo họ không thêm quá nhiều nợ kỹ thuật vào hệ thống của bạn.

Cuối cùng, xem xét sử dụng SCRUM . Nếu bạn làm, thuê một huấn luyện viên hoặc đi đào tạo. Vì tất cả các bạn đều đang làm một việc mà bạn chưa từng làm trước đây, nên việc thiết lập thời hạn thực tế đơn giản là không thể. Với SCRUM, quản lý của bạn sẽ có khả năng hiển thị những gì bạn làm hàng ngày để họ có thể thấy tiến trình nào (hoặc không) đang được thực hiện. Và, vì thời hạn của bạn rõ ràng đã được trao cho bạn, ít nhất SCRUM đảm bảo rằng nếu bạn không đáp ứng được thời hạn, thì ít nhất bạn sẽ gửi những câu chuyện đã hoàn thành trên cơ sở gia tăng, có thể nói là tốt hơn là kết thúc với một người khổng lồ hệ thống hoàn toàn không hoạt động.

Ngoài ra câu trả lời của @chrisaycock ... Đừng đánh giá thấp thời gian bạn sẽ cần phân bổ cho cố vấn / đào tạo, v.v. Là người dẫn đầu, bạn sẽ cần học cách từ bỏ chi tiết và tin tưởng vào nhóm của mình. Công việc của bạn là trở thành người tạo khả năng, loại bỏ chặn đường và chạy giao thoa khi quản lý chọc vào đó. Trong một nhóm "bình thường", vào khoảng 7 hoặc 8, người dẫn đầu không còn chương trình, Trong tình huống của bạn, điều này giảm xuống còn 3 hoặc 4 (Có thể thậm chí ít hơn), Bạn không phải là tài nguyên lập trình cho dự án.

Tập trung vào giao tiếp trong hai lĩnh vực.

Không dễ để làm điều này, và đó là một lý do công việc này khó khăn. Nếu đáp ứng thời hạn có nghĩa là cắt các tính năng thì đi qua đó. Một điều bạn đang cố gắng tránh trong tất cả điều này là mã nhanh để đưa ra thời hạn. Đó là sự khởi đầu của sự kết thúc của một cơ sở mã sẽ không tồn tại tốt và sự khởi đầu của nợ kỹ thuật bị bóp nghẹt.

2) Liên lạc giữa các nhóm. Thiết lập các thực hành chính thức như Bryan và những người khác đề nghị. Hãy chắc chắn rằng bạn gặp gỡ thường xuyên như một nhóm, ví dụ mỗi tuần một lần ngoài các scrum hàng ngày. Có được sự tôn trọng và tin tưởng bằng cách lắng nghe , công cụ quan trọng nhất của bạn. Hãy chắc chắn rằng bạn tập trung vào việc giúp đỡ. Tránh những lời chỉ trích tiêu cực bằng mọi giá. Khi cần thiết hãy sử dụng những lời chỉ trích và khuyến khích tích cực, ví dụ: "điều đó thật tuyệt, một khi điều bạn có thể muốn xem xét là X" hơn "đó không phải là điều chúng ta cần, thay vào đó bạn cần phải làm X"

Những gì tôi đã làm là xác định những người có khả năng và phân chia và chinh phục. Tôi đứng đầu 2 hoặc 3 và biến họ thành đội trưởng. Những người khác sau đó được chia thành các đội theo đội trưởng đến các đội nhỏ của họ.

Tôi cung cấp cho các thuyền trưởng khối hoặc mô-đun để làm một chương trình.

Các thuyền trưởng cung cấp cho người mới những nhiệm vụ lập trình hoặc nghiên cứu nhỏ hơn trong khi tự giải thích những gì họ đang làm để cố vấn xảy ra trong khi làm.

Tôi cố gắng sắp xếp phòng để mọi người ở trong cùng một không gian mở nhưng mỗi đội có một vòng tròn máy tính riêng. Tôi thích ở trong khoảng cách hét lên với mọi người để mọi thứ diễn ra nhanh chóng.

Điều này hoạt động tốt cho khoảng 10-20 lập trình viên cho đến nay. Các nhóm nhỏ hơn chỉ tốt hơn trong một nhóm và tôi chưa làm việc với bất cứ điều gì lớn hơn.