Я не хочу пробовать работать в паре, потому что знаю, что мне это не понравится, и это замедляет меня, чтобы работать более продуктивно.
Некоторые из них, которые никогда не пробуют парное программирование, скажут, что это сложно, тратя время зря, не хватает ресурсов (людей, времени и т. Д.) Для выполнения практики. И я с этим согласен, но пробовали ли вы хоть раз? Я объясню, почему вы должны пытаться и как делать пары и выигрывать.
Почему парное программирование?
Парное программирование - это один из подходов к гибкому, особенно экстремальному программированию (XP), когда два человека на одном компьютере (1 ПК, 1 монитор, 1 клавиатура и 1 мышь) анализируют, проектируют и тестируют для решения проблем.
Передача знаний - произошла очень быстро, когда пара состоит из младших и старших. Пока младшие спрашивают, почему и как, старший объяснит и покажет, как решать проблемы. Это могут быть инструменты или даже более эффективный способ решения определенной проблемы.
Поощрение к общению - один из основных эффектов от этого. Поскольку пара решает проблему по-своему, они могли бы спорить, почему это должно быть сделано именно так, и эта пара должна в конце концов прийти к согласию, какой путь они хотят избрать. После того, как они закончат, каждая пара может сменить свою пару и продолжить работу над проектом и так далее. С этой точки зрения информация быстро распространяется по команде. По мере распространения он становится более насыщенным и насыщенным. Он обогащен опытом и пониманием каждого члена команды.
Лучше, чем разбивать на две части - вы поймете, что это более продуктивно и эффективно. Когда вы объединяетесь в пары, возникают дебаты. Если этого не произошло, знаете ли вы и ваша пара, что делать, или один из вас не хочет знать и постоянно кивает, и это плохо. Когда происходят дебаты, вы утверждаете, что ваш способ решения проблем лучше, чем ваша пара. Эта дискуссия закончилась удобным решением. Вы и ваша пара согласны и знаете, почему так должно быть.
Больше дисциплины - скорее всего, это заставит вас не отступать, если случилось что-то плохое. Мы склонны пропускать написание тестов, откладывать рефакторинг и избегать интеграции, когда мы обходимся без сопряжения, и особенно когда случается что-то плохое. Выполняя эту дисциплину, он будет производить код более высокого качества.
Почему не парное программирование?
Не каждая команда или компания может внедрить парное программирование в свой образ жизни. Либо они не подходят к тому, как работает парное программирование, ЛИБО они никогда не пробовали хотя бы раз. Если кто-то из вас никогда не пробовал, то я предлагаю вам попробовать хотя бы один раз, сделайте это с друзьями или коллегами. Начните с небольшого проекта или любой игровой площадки, которая вам нравится. В конце концов, вы поймете, что либо парное программирование подходит вашей команде, либо нет.
Команда не согласна - если ваша команда уже пыталась и в итоге не получила пользы, они могут отменить ее и вернуться к выполнению проектов без объединения в пары.
Личная проблема - вы не можете заниматься парным программированием, если вам приходится работать в паре с кем-то, кто может конфликтовать с вами, будь то личный или профессиональный бизнес. Очевидно, что если у вас возникли проблемы с вашей парой перед началом, вы можете поспорить без каких-либо объективных, но личных проблем.
Невозможно использовать - сочетание не всегда работает с каждой практикой, даже если это одна из гибких методологий (кроме XP). Если ваша команда реализует гибкую методологию полностью или наполовину, это не может гарантировать вам, что ваша команда будет делать это в рамках парного программирования. Может быть и наоборот, когда вы реализуете парное программирование, вам может понадобиться гибкость, особенно экстремальное программирование.
Слишком консервативен - когда ваша компания не согласна с вашими аргументами, почему вам нужно заниматься именно этим, а не обычным. Не спрашивайте меня, почему, но многие компании все еще не верят, что практика, которая могла бы принести больше пользы для бизнеса, чем обычный способ. Одна из причин, по которой они не хотят делиться, заключается в том, что они уже находятся в своей зоне комфорта, комфортно иметь больше времени на исправление ошибок, чем на новые улучшения.
Правила при спаривании
Играйте с правилами, а не с тем, что вы чувствуете. Это общие правила успешного парного программирования.
- Убедитесь, что у вас есть кто-то, кто действительно умеет это делать.
- Спорите с данными, решайте, как пара / команда, какой путь будет более удобным.
- Монитор следует разместить посередине пары.
- Один должен быть водителем, который берет на себя клавиатуру + мышь, и другой должен быть навигатором, который может думать иначе и показывать что-то упущенное.
- В какой-то момент измените положение на более сбалансированное, водитель должен быть штурманом, а штурман должен быть водителем.
- Активно задавайте вопросы, особенно о том, чего вы не понимали, и не забывайте показывать дорогу, если чувствуете, что ваш ответ более способен решить проблемы.
- Сделайте командное соглашение. У каждой команды, применяющей парное программирование, должны быть правила, например, в какое время начинать работать, даже если в вашей компании гибкий рабочий график.
- Общаться! Ваша команда не узнает, что у вас есть проблема, если вы им не расскажете. Поднимите руки, чтобы получить хоть немного помощи от команды.
Заключение
Парное программирование применимо не ко всем на Земле. Вам всегда придется выбирать, когда вы работаете с командой, которая работает в паре: работать в команде или за ее пределами, а не присоединяться к ним. Потому что парное программирование - это не то, к чему можно присоединиться.
Хотя парное программирование не приносит пользы вашей команде, но вы можете понять, что, выполняя парное программирование, вы получаете более качественный код. Это заставит вас как пару продолжать непрерывное обсуждение и повторение того, что вводит пара. Придумайте лучшую идею, лучший дизайн, сделайте меньше ошибок, познакомьте ваши пары с кодом и поймите причины каждого решения.
Продуктивность невозможно измерить, но, по крайней мере, вы можете сделать это с помощью парного программирования и получить что-то более эффективно, чем без него. Если вы никогда не учили и не пробовали это раньше, возможно, вам и вашей команде стоит попробовать, независимо от того, чувствуете ли вы, как команда, более эффективно спаривание или нет.
Вы можете делать это по-своему, или, возможно, захотите следовать перечисленным правилам, которые могут помочь вам начать парное программирование. В конце концов, парное программирование - это общение и приверженность. Обязуйтесь писать тесты, проектировать просто и интегрировать каждый раз для решения проблем. Сообщайте, когда что-то происходит: о выполненных работах, ошибках в системе, новых проблемах или даже о компромиссах при принятии решений.
Когда ваш партнер наблюдает за вами, шансы проигнорировать вашу приверженность остальной команде намного меньше в парах, чем когда вы работаете в одиночку. Когда ваш партнер наблюдает, шансы на то, что вас вдохновят на общение с остальной частью команды, намного выше, потому что вы знаете, что решение принимается за команду.
В GOJEK инженеры занимаются парным программированием, не глядя на личности. Даже они поощряют всех инженеров из разных команд заниматься парным программированием. Они, инженеры из другой команды, не знают, какие инструменты и какие знания использует другая команда, но они могут легко преобразовать их, как один из членов, который работает с командой все время. И это может быть одной из причин, по которой мы можем работать быстрее, имея более надежную систему и масштабируемую до бесконечности! Хотите узнать и испытать это на себе? Присоединяйтесь к нашей двухдневной сессии, подав заявку на bit.ly/gojekupscale и удачи!
Источники:
- Объяснение экстремального программирования: примите перемены, Кент Бек
- Мартин Фаулер
