Кращі книги про керування командою з розробки програмного забезпечення? [зачинено]

Канонічні книги з розробки програмного забезпечення досить добре встановлені. Однак, прочитавши жахливу книгу, повну поганих порад щодо управління командами програмування, у ці вихідні я шукаю рекомендації щодо дійсно хороших книг, орієнтованих на управлінську сторону програмування (підбір персоналу, вимірювання ефективності / управління, мотивація, кращі практики, організаційна структура і т. д.) і не стільки на побудові самого програмного забезпечення.

Будь-які пропозиції?

Програмне забезпечення для людей: продуктивні проекти та команди .

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

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

Після того, як ви прочитали Peopleware (трохи застарілий, 1999 р., Але це класика), тут з'явився останній автор того ж автора ( Том ДеМарко )

Відніміть обходячи Burnout, марну роботу, і міф про Total ефективності

Міфічна людина-місяць . Це важливе читання.

Управління людьми

Немало конкретних предметів дій, але це цікаве прочитання і забезпечує перспективу.

Окрім написання Code Complete, Стів МакКоннелл також написав програму швидкого розвитку: приборкання диких програмних програм, що стосується управління проектами з розробки програмного забезпечення та для керівників проектів програмного забезпечення майже так само добре, як і Code Complete.

Він також написав оцінку програмного забезпечення: Демістифікація чорного мистецтва та посібник із виживання програмного забезпечення, які обидва варто переглянути, хоча Оцінка програмного забезпечення досить ... детально описана в одній конкретній темі, тому якщо ви насправді не зацікавлені в тому, що ви можете хотіти керувати ясним.

Динаміка розробки програмного забезпечення Джима Маккарті також хороша (як це стосується книг МакКоннелла, це Microsoft Press - компанія, яка відома тим, що доставляє посереднє програмне забезпечення пізно, якось встигла опублікувати кілька дуже хороших книг про те, як це слід зробити правильно).

Він містить 54 "правила" для розробки програмного забезпечення - деякі очевидні, деякі менш такі, майже все, що варто пам’ятати, і менше 200 сторінок (із зображеннями), такі дуже читабельні (плюс 54 структури правил означають, що це в хороших шматках).

Що стосується набору розумних і отримує речі, зроблених деяким хлопцем під назвою Джоелем Спольським, це чесно бути дуже коротким із хорошими розуміннями. Дещо з того, про що йдеться, не буде легко здійснити в кожній компанії / країні, але часто існують альтернативи, які принесуть вам певні переваги.

Хоча ми розповідаємо про речі Джоела, перша книга Джоеля з програмних нарисів також є хорошою, хоча всі вони доступні в Інтернеті. Короткий, читабельний і викликає думки.

(Помирає від лицемірства після того, як він стогнав над тим, як люди стукають про те, як прекрасний Джоел та / або Джефф.)

(посилання на книгу)

Швидкий чи ні, важливий ретроспективний процес (озираючись на недавню роботу команди та шукаючи способи зробити це краще). У цій книзі є багато корисних прийомів, які команда може використати для відновлення того, що сталося, з'ясування першопричин та вирішення, що робити вперед.

Пастухові коти написані особливо для програмістів, які стали менеджерами.

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

Багато згаданих вище книг для фронту програмного забезпечення. Я б сказав, що жодної книги чи пари недостатньо. Саме управління - це складне завдання і є дуже суб'єктивним. Я б порекомендував того, хто планує менеджмент, прочитати багато книг з оглядів Harvard Business. Всі вони мають конкретну ідею, щоб поділитися, і для цього потрібно багато читання та зусиль у впровадженні.