Рекомендовать ресурсы для руководителей групп разработчиков [закрыто]

Недавно я стал руководителем группы разработчиков (95% MS SQL Server, 5% misc-Oracle, Sybase, Access), которая управляет и разрабатывает большое количество баз данных в корпоративной среде. Я ищу ресурсы (контрольные списки, утилиты, лучшие практики, процедуры, веб-сайты, книги и т. Д.), Которые помогут мне реализовать основные принципы, которые отсутствовали в этой группе разработчиков в прошлом, такие как обзоры кода, перекрестное обучение, документация , обеспечение соблюдения стандартов, обмен знаниями, наставничество и так далее.

Большая часть того, что я нахожу, - это общие ресурсы по навыкам управления, но я хотел бы найти что-то, что может быть специфическим для руководства командой разработчиков. Корпоративные процессы являются «стандартным» SDLC типа водопада, поэтому ресурсы, ориентированные на Agile, не столь актуальны.

Книги, которые я купил и рекомендую для технических руководителей и руководителей, которые работали на меня:

Быстрое развитие (С. Макконнелл) - отличная «библия» ответов на общие вопросы, связанные с управлением / лидерством (подробнее об управлении)

Становление Техническим Лидером (Джеральд Вайнберг) - прочитанное плотно, но великолепно.

Инструментарий менеджера (Harvard Business Essentials) - опять же, больше ориентирован на управление, но хорошо с некоторыми из межличностных проблем

Объяснение сотрудничества (Жан Табака) - более гибкая сфокусированная, но еще одна хорошая библия "как сделать Х" очень практичная

Помимо этого ... слушай. Учитесь у своей команды. Учитесь у своих сверстников. Учитесь у своего босса. Найдите наставника за пределами вашей цепочки команд, но кого-то, кого вы уважаете и к которому можете прибегнуть, когда вы расстроены или застряли. Встречайтесь с ними раз в две недели на завтрак.

Я недавно прочитал Peopleware и нашел его очень полезным. Это определенно поможет вам понять динамику команды разработчиков (и множество ошибок, которые мы совершаем, управляя ими). Я был рекомендован кем-то здесь, на программистов.

Взгляните на « Отладку процесса разработки » Стива Магуайра.

Хотя это уже не самая современная книга (1994), в ней по-прежнему содержится огромное количество информации, которая должна оказаться полезной для вас, как для руководителя группы, и вы можете купить ее по-настоящему дешево. Я нашел это, чтобы быть превосходным.

Вы также можете рассмотреть " Быстрое развитие " Стивена Макконнелла. Опять же, это старая версия (1996), так что она как бы предшествует работе методологии Agile, поэтому вы найдете обсуждаемые подходы «водопад», «спираль» и «временные рамки» по существу. Вы найдете некоторые из предшественников гибкого подхода (Быстрое прототипирование и т. Д.). Кроме того, что касается «передового опыта», вы найдете огромный диапазон, обобщенный на странице 400, а также должным образом процитированные оценки их эффективности и подробные объяснения внутри.

Обе книги выпущены издательством Microsoft Press, поэтому должны содержать достаточные ссылки на существующие технологии.

Самое главное, что обе книги рассказывают, как управлять командами разработчиков программного обеспечения - мотивация, планирование, стратегическое мышление, лидерство и так далее.

Я в подобной ситуации. Прежде всего вы должны определить, как должна работать команда, какие процессы должны быть на месте, какова роль команды. Создайте страницу вики (или sharepoint или что-то еще), чтобы поместить все это. Затем проведите много регулярных бесед внутри команды, чтобы детально определить каждый из них. Одна вещь, которая важна, состоит в том, чтобы установить культуру и поведение, которое команда хочет иметь. Для командных знаний это то, что мы используем. Начните регулярный двухнедельный или ежемесячный сеанс обмена знаниями, создайте электронную таблицу с различными областями знаний в строках и членами команды в столбцах. Затем присвойте счет 1-5, чтобы узнать сильные и слабые стороны каждого участника. Составьте план назначения первичной, вторичной и третичной ответственности для каждой области с целевым баллом 5, 4 и 3 соответственно.

Документирование всех ваших процессов очень важно. Например, у нас есть процесс проверки кода и контрольный список. Если процессы вовлекают другие команды, поднимите это с руководством и согласитесь с процессами на этом уровне. например, процесс выпуска.

Я не могу подчеркнуть важность документирования (может быть легким в вики), поскольку у вас есть сильная базовая позиция для улучшения и демонстрации управления. Много раз моя команда побеждала в глазах старшего руководства, потому что у нас был сильный документ и процессы.