Рекомендувати ресурси керівникам команд розвитку [закрито]

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

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

Книги, які я придбав і рекомендую для технічних керівників та менеджерів, які працювали на мене:

Швидкий розвиток (С. МакКоннелл) - чудова "біблія" відповідей на загальні речі управління / провідного типу (більше управління тхо)

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

Інструментарій керівника (Гарвардський бізнес-основи) - знову ж таки, більш орієнтований на управління, але добре вирішує деякі міжособистісні питання

Пояснена співпраця (Жан Табака) - більш спритний фокус, але ще одна хороша біблія про те, як зробити X, дуже практична

Поза тим ... слухайте. Вчіться у своєї команди. Вчіться у своїх однолітків. Вчіться у свого начальника. Знайдіть наставника поза вашою командною ланкою, але когось, кого ви поважаєте, і до якого можна побігти, коли ви засмучені або застрягли. Зустрічайтеся з ними раз на два тижні на сніданок.

Нещодавно я лише читав Peopleware і вважав це дуже освічуючим. Це, безумовно, допоможе вам зрозуміти динаміку команди розвитку (і багато помилок, які ми робимо в управлінні / ведучому їх). Мене тут рекомендували хтось із програмістів.

Погляньте на " Налагодження процесу розвитку " Стіва Магуайра.

Хоча це вже не найсучасніша книга (1994 р.), Вона все ще має багато інформації, яка повинна виявитися корисною вам як керівнику команди, і ви можете підібрати її по-справжньому дешево. Я вважав це відмінним.

Ви також можете розглянути " Швидкий розвиток " Стівена МакКоннелла. Знову ж таки, це олджі (1996), тому він на зразок передує роботі з методологією Agile, тож ви знайдете підходи "водоспад", "спіраль" та "таймбокс", які обговорюються по суті. Ви знайдете деякі з попередників Agile підходу (швидке прототипування тощо). Крім того, стосовно "Кращих практик" ви знайдете величезний діапазон, зведений на сторінці 400, а також відповідні цитовані оцінки щодо їх ефективності та детальних пояснень.

Обидві книги видані Microsoft Press, тому вони повинні бути достатніми посиланнями на існуючі технології.

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

Я в подібній позиції. Перше, що ви визначаєте, як повинна працювати команда, які процеси мають бути, яка роль команди. Створіть сторінку wiki (або pointpoint або будь-яку іншу), щоб помістити все це. Потім проведіть багато регулярних розмов у команді, щоб детально визначити кожну з них. Єдине, що важливо - це встановити культуру та поведінку, яку хоче мати команда. Для знань команди - це те, що ми використовуємо. Почніть регулярний щотижневий або щомісячний сеанс обміну знаннями, створіть таблицю з різними напрямами знань у рядках та членів команди в стовпцях. Потім призначте бал від 1-5, щоб знати сильні сторони та прогалини для кожного члена. Складіть план, призначте первинну, вторинну та третинну відповідальність за кожну область із цільовим балом 5, 4 та 3 відповідно.

Документування всіх ваших процесів дуже важливо. Наприклад, у нас є процес перегляду коду та контрольний список. Якщо в процесах беруть участь інші команди, це піднімає керівництво і погоджується на процеси на цьому рівні. наприклад, процес випуску.

Я не можу наголосити на важливості документування (може бути легким у вікі), оскільки у вас є сильна основна позиція для покращення та демонстрації управління. Багато разів моя команда перемагала в очах вищого керівництва, оскільки у нас були сильні документи та процеси.