Đề xuất nguồn lực cho các nhà lãnh đạo nhóm phát triển [đóng]

Gần đây tôi đã trở thành trưởng nhóm của một cơ sở dữ liệu (95% MS SQL Server, 5% misc-Oracle, Sybase, Access) quản lý và phát triển một số lượng lớn cơ sở dữ liệu trong môi trường doanh nghiệp. Tôi đang tìm kiếm các tài nguyên (danh sách kiểm tra, tiện ích, thực tiễn tốt nhất, quy trình, trang web, sách, v.v.) sẽ giúp tôi thực hiện các nguyên tắc cơ bản đã thiếu trong nhóm phát triển này, như đánh giá mã, đào tạo chéo, tài liệu , thực thi các tiêu chuẩn, chia sẻ kiến ​​thức, cố vấn và vv.

Hầu hết những gì tôi tìm thấy là tài nguyên kỹ năng quản lý chung, nhưng tôi muốn tìm bất cứ điều gì có thể cụ thể để lãnh đạo một nhóm các nhà phát triển. Các quy trình của công ty là SDLC kiểu thác nước "tiêu chuẩn", do đó, tài nguyên hướng đến Agile gần như không liên quan.

Những cuốn sách tôi đã mua và giới thiệu cho Người dẫn đầu và Người quản lý đã làm việc cho tôi:

Phát triển nhanh chóng (S. McConnell) - "kinh thánh" tuyệt vời của câu trả lời cho những điều quản lý chung / loại khách hàng tiềm năng (quản lý nhiều hơn)

Trở thành một nhà lãnh đạo kỹ thuật (Gerald Weinberg) - một người đọc dày đặc, nhưng là một người tuyệt vời.

Bộ công cụ của người quản lý (Harvard Business Essentials) - một lần nữa, tập trung quản lý nhiều hơn, nhưng tốt với một số vấn đề liên cá nhân

Giải thích hợp tác (Jean Tabaka) - tập trung hơn vào Agile, nhưng một cuốn kinh thánh hay khác về "cách làm X" rất thiết thực

Ngoài ra ... hãy lắng nghe. Học hỏi từ nhóm của bạn. Học hỏi từ các đồng nghiệp của bạn. Học hỏi từ ông chủ của bạn. Tìm một người cố vấn bên ngoài chuỗi mệnh lệnh của bạn nhưng ai đó bạn tôn trọng và có thể chạy đến khi bạn thất vọng hoặc bị mắc kẹt. Gặp họ hai tuần một lần cho bữa sáng.

Tôi mới đọc Peopleware gần đây và thấy nó rất ngộ. Nó chắc chắn sẽ giúp bạn hiểu được động lực của nhóm phát triển (và rất nhiều sai lầm chúng tôi mắc phải trong việc quản lý / lãnh đạo chúng). Tôi đã được đề nghị bởi một số người ở đây trên các lập trình viên.

Hãy xem " Gỡ lỗi cho quá trình phát triển " của Steve Maguire.

Mặc dù nó không phải là cuốn sách hiện đại nhất nữa (1994), nhưng nó vẫn có rất nhiều thông tin hữu ích cho bạn với tư cách là một trưởng nhóm và bạn có thể mua nó với giá rẻ thực sự. Tôi thấy nó là tuyệt vời.

Bạn cũng có thể muốn xem xét " Phát triển nhanh " của Steven McConnell. Một lần nữa, đó là một oldie (1996) vì vậy nó sắp xếp trước phương pháp Agile hoạt động để bạn sẽ tìm thấy các cách tiếp cận "thác nước", "xoắn ốc" và "thời gian" được thảo luận về giá trị của chúng. Bạn sẽ tìm thấy một số tiền thân của phương pháp Agile (Tạo mẫu nhanh và vv). Ngoài ra, liên quan đến "Thực tiễn tốt nhất", bạn sẽ tìm thấy một phạm vi rộng lớn được tóm tắt trên trang 400 cùng với các đánh giá được trích dẫn thích hợp về hiệu quả và giải thích chi tiết của chúng trong đó.

Cả hai cuốn sách được phát hành bởi Microsoft Press vì vậy sẽ trình bày đủ tài liệu tham khảo với các công nghệ hiện có của bạn.

Quan trọng nhất, cả hai cuốn sách đều đề cập đến cách quản lý các nhóm phát triển phần mềm - động lực, lập kế hoạch, tư duy chiến lược, lãnh đạo, v.v.

Tôi đang ở một vị trí tương tự. Điều đầu tiên là bạn xác định cách nhóm nên làm việc, quy trình nên được thực hiện, vai trò của nhóm là gì. Tạo một trang wiki (hoặc sharepoint hoặc bất cứ điều gì) để đặt tất cả những trang này. Sau đó, có rất nhiều cuộc trò chuyện thường xuyên trong nhóm để xác định chi tiết từng người trong số họ. Một điều quan trọng là thiết lập văn hóa và hành vi mà nhóm muốn có. Đối với kiến ​​thức nhóm đây là những gì chúng tôi sử dụng. Bắt đầu một buổi chia sẻ kiến ​​thức hai tuần một lần hoặc hàng tháng, tạo một bảng tính với các lĩnh vực kiến ​​thức khác nhau trong các hàng và các thành viên trong nhóm trong các cột. Sau đó chỉ định điểm từ 1-5 để biết điểm mạnh và khoảng trống cho từng thành viên. Lập kế hoạch phân công trách nhiệm chính, phụ và đại học cho từng khu vực với điểm số tương ứng là 5, 4 và 3.

Tài liệu tất cả các quy trình của bạn là rất quan trọng. ví dụ: Chúng tôi có một quy trình xem xét mã và danh sách kiểm tra. Nếu các quy trình liên quan đến các nhóm khác nâng cao điều đó với quản lý và đồng ý với các quy trình ở cấp đó. ví dụ như một quá trình phát hành.

Tôi không thể nhấn mạnh tầm quan trọng của tài liệu (có thể nhẹ trong wiki) vì bạn có một vị trí cơ bản mạnh mẽ để cải thiện và thể hiện sự quản lý. Nhiều lần nhóm của tôi đã giành chiến thắng trong mắt quản lý cấp cao bởi vì chúng tôi đã có tài liệu và quy trình mạnh mẽ.