Підказки щодо керування новою командою з новим кодом [закрито]

Як ти ведеш себе в новій команді, де ти є старшим самим розробником, а більшість інших в команді молодші за тебе на кілька років. Завдання перед командою - це те, що раніше ніхто, крім вас, не робив у своїй кар’єрі.

Керівництво наполягає на підвищенні продуктивності всієї команди, і як старший розробник ви відповідаєте.

Будь-які поради щодо виходу козирів у такій ситуації? Зрозуміло, що всій команді потрібен час, щоб навчитися, і не будемо забувати нове. Однак терміни також випереджають ...

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

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

Спочатку спочатку почніть використовувати систему управління вихідним кодом з самого першого рядка коду. Звичайте перевіряти код на початку та часто.

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

По-третє, встановіть сервер безперервної інтеграції, щоб ваш код будувався регулярно і регулярно перевірявся.

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

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

Нарешті, подумайте про використання SCRUM . Якщо ви це зробите, найміть тренера або перейдіть на якесь тренування. Оскільки ви все робите щось, чого ніколи раніше не робили, встановити реалістичні строки просто неможливо. За допомогою SCRUM ваше керівництво матиме можливість бачити, чим ви займаєтесь щодня, щоб вони могли бачити, який прогрес (чи ні) досягнуто. І оскільки, очевидно, вам були надані ваші терміни, SCRUM принаймні гарантує, що якщо ви не зможете дотриматись терміну, принаймні ви будете роздавати завершені історії поступово, що, мабуть, краще, ніж закінчуватися з гігантом система, яка взагалі не працює.

На додаток до відповіді від @chrisaycock ... Не варто недооцінювати час, який вам потрібно буде виділити на наставництво / навчання тощо. В якості ведучого вам потрібно буде навчитися відпускати деталі та довіряти своїй команді. Ваша робота полягає в тому, щоб стати активізатором, зняттям дорожнього блоку та запускати перешкоди, коли керівництво твориться туди. У "нормальній" команді, приблизно в 7 або 8, ведучий більше не програмує. У вашій ситуації це падає до 3 або 4 (можливо, навіть менше), ви не ресурс програмування для проекту.

Зосередьтеся на спілкуванні у двох сферах.

Зробити це непросто, і це одна з причин, що ця робота важка. Якщо дотримання терміну означає функції скорочення, тоді перейдіть це. Єдине, чого ви намагаєтесь уникнути у всьому цьому, це швидкий код, щоб скласти термін. Це початок кінця кодової бази, яка не триватиме добре, і початок технічної заборгованості, яка задихається.

2) Міжкомандна комунікація. Налаштуйте офіційні практики, як рекомендує Брайан та інші. Переконайтесь, що ви регулярно зустрічаєтесь як команда, наприклад, раз на тиждень на додаток до щоденних скандалів. Слухайте повагу та довіру, слухаючи , ваш найважливіший інструмент. Не забудьте зосередитись на наданні допомоги. Уникайте негативної критики будь-якою ціною. У разі необхідності використовуйте позитивну критику та заохочення, наприклад, "що це здорово, коли тільки ви, можливо, хочете подумати, що це" X "- це не те, що нам потрібно, вам потрібно зробити X замість цього"

Що я зробив, це визначити здібних і розділити та перемогти. Я беру верхній 2 або 3 і роблю їх капітанами. Інші потім рівномірно розбиваються на команди, що слідують за капітанами, до їх власних маленьких команд.

Я даю капітанам шматки або модулі для виконання програми.

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

Я намагаюся облаштувати кімнату, щоб усі перебували в одному відкритому просторі, але кожна команда має своє коло комп’ютерів. Мені подобається бути на відстані до всіх, щоб все швидко рухалося.

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