Три вещи, которые должен сделать разработчик, чтобы привлечь внимание к своей работе во время парного программирования
Нажмите, чтобы стать средним участником и читать неограниченное количество историй!
Что такое парное программирование?
Из определения Википедии:
Парное программирование — это метод разработки программного обеспечения, при котором два программиста работают вместе на одной рабочей станции. Один, водитель, пишет код, а другой, наблюдатель или навигатор, [1] просматривает каждую строку код по мере его ввода. Два программиста часто меняются ролями.
В наши дни многие компании перенимают практику парного программирования. Некоторые из них первыми начали работать с использованием парного программирования, например, ThoughtWorks, где я работал раньше. Но некоторые новички в этом и постепенно вникают в это.
Сопряжение является сложной задачей, когда вы начинаете сами по себе. Настоящей проблемой становится, когда менеджер оценивает производительность по неправильным показателям. Это беспокоит всех разработчиков в команде. Менеджеры видят только одного человека, фиксирующего журналы в git, или одного человека, назначенного для задач JIRA, и, таким образом, учитывают работу только одного разработчика.
В таких сценариях другой разработчик не виден менеджеру. Менеджеры отмечают разработчиков как «низкоэффективных» членов команды.
Не у всех менеджеров есть эта проблема. Например. В ThoughtWorks менеджеры знают, что над задачей работает пара. Они хорошо осведомлены о том, какой вклад вносит каждый человек в завершение проекта. Но в компаниях, где внедряются эти методы, менеджеры не знают, как измерить производительность разработчика. Они используют те же старые метрики, такие как журнал Git и задачи Jira, чтобы проверить, сколько задач выполняется разработчиками. Таким образом, один разработчик страдает, если коммиты или задачи не назначаются ему напрямую во время сопряжения.
Это плохо сказывается и на ежегодных обзорах. Когда менеджер показывает им, что их производительность не соответствует порогу. Это становится препятствием для парного программирования. Это, безусловно, создает представление о том, что объединение в пары — это нехорошо, потому что их оценивают по неверным основаниям. В конечном итоге вся команда отказывается от практики парного программирования.
Журналы Git и задачи Jira — неверные показатели для измерения производительности разработчика при внедрении парного программирования. Менеджеры, которые его используют, должны избегать таких критериев измерения.
Вы также можете поговорить со своим менеджером, если он дружелюбен и открыт для новых идей и новых знаний. Но не все менеджеры такие. Предоставление обратной связи иногда имеет неприятные последствия, и вы не в хороших отношениях с ними.
Итак, что нужно сделать, чтобы быть видимым для работы, которую они делают во время сопряжения? Из моего собственного опыта я поделюсь с вами тремя вещами, которые хорошо сработают в таких случаях.
1. Добавьте Пари в задачу Jira
При выборе задачи в Jira или любом другом ПО для управления проектами. Убедитесь, что у вас есть дополнительный атрибут «Pairee». Выберите человека, которого вы связываете с вами.
Это поможет, когда менеджер формирует отчет о том, над сколькими задачами работает каждый разработчик. Им придется рассчитать отчет на основе совокупной стоимости задач, которые непосредственно назначены вам, а также задач, в которых вы участвовали как Pairee.
В приведенном выше контекстном разделе Jira показан пример задачи. Я настроил свой рабочий процесс JIRA, чтобы использовать Pairee в качестве еще одного атрибута для задачи.
2. Соавтор фиксации Git
Вы можете приписать фиксацию более чем одному разработчику, используя фиксацию в соавторстве. И Github, и Gitlab поддерживают эту функцию. При работе в паре убедитесь, что вы следуете приведенному ниже формату сообщения фиксации.
This is your normal commit message Co-authored-by: Ninad Ingole <[email protected]>
При этом вы увидите обоих авторов в истории коммитов на GitHub. Он покажет коммиты, сделанные в репозитории обоими разработчиками, в их индивидуальном разделе вкладов GitHub.
Для людей, использующих такие инструменты, как GitHub Desktop. Графический интерфейс показывает возможность включить другого автора в качестве соавтора, например
Для руководителей, занимающихся микроменеджментом. Это будет вашим доказательством. Доказательство того, что вы всегда работали в паре и что вы в равной степени участвуете в выполнении задач.
Также для рабочих процессов PR рецензент знает о людях, вовлеченных в изменение. Это помогает обратиться к любому из разработчиков за отзывами.
3. Парные имена в сообщении фиксации
Не все платформы контроля версий поддерживают совместное редактирование. Последний совет для таких платформ. Для старых коммитов наличие имен пар в сообщениях является инструментом быстрой навигации.
Мне просто нравится сохранять имена пар в формате [First/Second] в сообщении коммита. Это также хорошо видно, когда я делаю git log --oneline
Заключение
Я надеюсь, что практики, которыми я поделился, помогут вам продолжать развивать навыки парного программирования. Это также поможет вам избежать каких-либо проблем с вашим менеджером.
В этом посте я не рассказывал о преимуществах парного программирования. Преимущества, такие как обмен знаниями, быстрые обзоры, правильное планирование и т. Д., Вот лишь некоторые из них. Я бы посоветовал другим, кто этого не делает, попробовать.
Если у вас возникнут дополнительные вопросы, связанные с парным программированием, или возникнут какие-либо проблемы, свяжитесь со мной. Буду рад помочь вам в путешествии по парному программированию 😊
Большое спасибо, что нашли время прочитать мой блог и поделиться им с другими. Ваша ❤️ поддержка очень много значит для меня, и я действительно ценю это. Именно такие люди, как вы, вдохновляют меня продолжать писать и делиться своими мыслями с миром. Еще раз спасибо за вашу доброту и поддержку.
Нажмите, чтобы стать средним участником и читать неограниченное количество историй!
