Як ознайомити нових членів команди з проектом? [зачинено]

Ми збираємось найняти 1-2 нових інженерів для команди програмного забезпечення (що складається з 3 розробників, 1 тестер).

Які кроки щодо їх інтеграції до команди?

Мої ідеї:

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

Що ще ми могли зробити?

Проект знаходиться в медичній галузі (ультразвукова система), і вже йде 5 років. У нас є щорічні випуски, і ми готові закінчити один випуск, коли ми хочемо додати 1-2 інженерів.

Проект знаходиться у фазі обслуговування (застарілий код рефакторингу, плюс додавання нових функцій). Речі в значній мірі за графіком (більш-менш).

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

1. Витратьте невеликий проміжок часу (можливо, день чи два) на дії, пов’язані з використанням продукту, щоб вони могли ознайомитися з тим, що робить продукт. Це може бути перевірка помилок або виконання тестових планів якості QU або проходження навчання користувачів.
2. Робота над маленькими локалізованими помилками. Це інформує інженера про те, як створювати та налагоджувати додаток, не маючи справу з вивченням багато архітектури.
3. В ідеалі напишіть невелику нову функцію, локалізовану. Це дозволяє їм написати фрагмент коду, і коли вони напишуть, вони ознайомляться з навколишніми бітами коду, з якими повинен працювати їх новий код.

Звідти розширюйте сферу та складність завдань у часі залежно від рівня досвіду та здатності інженера. Це дозволить розробнику природно розширити свої знання про кодову базу.

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

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

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

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

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

Як ведучий, я проводжу принаймні 2 дні з новими розробниками. Я виявив, що розвиваючи стосунки, в яких комфортно задавати неминуче питання "як твій прогрес?" це ОБОВ'ЯЗКОВО. У будь-якій новій громаді є страх вписатись ... ми приховуємо помилки, діємо досконало, робимо речі кращими, ніж вони є, зменшують труднощі. Менеджер, який проводить 2 дні з кимось, дасть їм знати, що це не їх культура, і дозволяє їм вести приклад. Новим кодерам потрібен урок історії про те, звідки ви прийшли та як далеко ви знаходитесь. Документи просто не виконують завдання справедливості.

Я працюю в галузі лише 10 місяців (щодо розміщення), але виявив, що мені це допомогло:

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

Обидва мені допомогли неабияк. Удачі.

Я б перейшов від високого рівня до низького.

Демонструйте додаток якомога швидше

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

Поясніть архітектуру високого рівня

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

Підготуйте чудовий бортовий документ

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

Заохочуйте його / її задавати питання (і будьте готові відповісти на них)

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

Допоможіть іншим членам команди вітати новачка

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

Нехай вони підберуть невелике або два завдання

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

Заохочуйте їх до виконання складніших завдань, як тільки вони почуватимуться більш комфортно

Хороші кандидати зроблять це природно.

Один "орієнтаційний" потік, який я пройшов (і вважав корисним), був чимось таким чином:

1. Коротка презентація, що дає «Великій картині», що таке компоненти, як вписуються та загальна архітектура.
2. Огляд коду, вступ до функцій, що керують основною логікою для призначеного мені компонента (ив). Охоплює деякі речі, пов'язані з умовами кодування та стилем.
3. Було призначено купу відкритих проблем та помилок з низьким пріоритетом (які були значною мірою локалізовані для призначеного мені компонента та досить прості).
4. Я повинен був налагоджувати програму через програму і просити допомоги з речами, які я не міг розшифрувати.
5. Після виправлення я пройшов процес (огляд коду, тестування рівня розробників тощо) відпуску до інтеграції.
6. Повторіть для інших задач / помилок, що виділяються.

Я вважаю, що цей підхід (і його варіанти) буде корисним, оскільки:

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

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

Ось як я йду

1. Поставте їм кілька завдань, пов’язаних із проектом. (Наприклад, якщо ваш проект є додатком для баз даних, попросіть їх просто створити додаток для з'єднання з базою даних та виконати просту операцію.)
2. Коли ви виявите, що вони зрозуміли ідею роботи, дайте їм демонстрацію проекту
3. Попросіть їх прочитати документацію.
4. Ознайомте їх зі стилями та стандартами кодування
5. Пізніше дайте їм кілька вправ налагодження (щоб знати потік проекту).
6. Попросіть їх зафіксувати точку, яку ви вже зафіксували (лише щоб з’ясувати їх логіку).
7. Нарешті зробіть їх частиною проекту.

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

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

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

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

Крім того, ви можете спробувати інтегрувати їх з іншими, які вже є в команді, спробувавши кілька завдань у стилі оцінювання, наприклад, побудувати міст за 45 хв. З 4 аркушів паперу, що підтримують чашку кави. Ми використовуємо цю методику на практичному курсі з програмної інженерії, щоб змусити групу з 8 студентів розбити лід, перш ніж вони працювати над одним проектом протягом 3 тижнів. Це допомагає прискорити формування фази команди.

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

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

3) Повільно почніть давати їм більші та більші проекти, перевіряючи їх все менше і менше.

4) Сидіти поруч з ними час від часу. Ви можете багато чого навчитися, просто подивившись, як хтось інший вирішує проблему. Невеликі речі, такі як "о, ви можете шукати функції у своєму коді, натиснувши ctrl-." дуже корисні.

Тепер я виявив, що є дві крайності :

• Хтось, хто задає питання кожні п’ять хвилин. "Що робить цей Path.Join?". Спершу вони повинні Google отримати відповідь і прийти до вас лише тоді, коли вони не зможуть знайти відповідь.

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

Це була моя формула, яку я використовував разом з кількома новими бажаючими - ці кроки виявилися високоефективними.

a) Усі нові розробники отримають деяке ознайомлення з вимогами проекту та процесами розробки протягом 2 днів.

b) Призначення тритижневого завдання написання тестів Junit для коду, який не має достатнього покриття.

в) Після того, як 3 зроблено, призначте невеликі завдання

г) Призначте складні завдання і виконано.

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

Ви також повинні призначити старшого розробника, бажано, для нового розробника, який міг би допомогти наставнику кандидата.

І так, змусьте їх документувати те, що вони дізнаються про систему. Я припускаю, що у вас є якісь внутрішні сторінки вікі. Якщо ні, то це, безумовно, обов'язково як в довгостроковій, так і в короткостроковій перспективі - напрочуд швидкий спосіб, щоб люди наростали. Сторінки Вікі не повинні містити лише документацію з кодом, а й такі речі, як відомі обмеження (це програмне забезпечення: D), обхідні шляхи, показники продуктивності часу / пам'яті тощо.

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

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