Парне програмування / співпраця в невеликій компанії

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

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

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

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

Моє запитання - чи хтось колись був у подібній ситуації, і що на них спрацювало?

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

Всі ми працюємо в загальній зоні, розробники не мають індивідуальних офісів / кабінетів.

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

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

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

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

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

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

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

Без цієї динаміки користь парного програмування втрачається.

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

TL; DR : Я не думаю, що програмування пар буде працювати для вас. Замість цього ви повинні спробувати отримати людина , стурбовані довгострокового якості їх коди і зробити їх хочуть , щоб знайти відповіді. Це потрібно робити неофіційно.

Про культуру та якість

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

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

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

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

Парне програмування та мікроменеджмент

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

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

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

• Заохочуйте їх брати участь у SO під відповідним мовним тегом або розміщувати деякі фрагменти коду для огляду на Code Review SE. Розпочніть невеликий неформальний конкурс щодо того, хто може набрати найбільшу кількість повторних балів за тиждень.

  Так можна творити чудеса для розробників-початківців, оскільки він забезпечує постійний зворотній зв'язок і слідкує за серцебиттям спільноти.

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

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

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

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

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

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

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

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

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

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

Що я з’ясував, це те, що ПРАВДІ люди з часом (у невеликій команді) збираються та синхронізуються з тим, що роблять інші. Не потрібно мікроконтролювати чи розповідати комусь, що вони роблять неправильно весь час.

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