Представлення нових тем колегам

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

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

Я спробую наступного разу. Я просто хочу, щоб цей проект вийшов із дверей.

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

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

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

Щоб "довести" і тому реально імплантувати ідею в чиюсь голову, теорії (розмови) ніколи недостатньо.

Ви повинні використовувати цю практику у власному коді і змусити їх "виявити", що це вирішує проблеми приємно.

Це означає, що ваша практика повинна бути ефективною, і ви повинні зробити це очевидним.

Таким чином, читання вашого коду надихне їх, оскільки вони "побачать його в дії".

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

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

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

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

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

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

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

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

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

Найкраща практика полягає у реальному виробничому коді. Катас - це приємне вступ, але, на мій досвід, не дотримуйтесь того самого "Еврика!" Моменти, коли бачиш це зроблено по-справжньому .

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

Успіхів у ваших починаннях.