Паровое программирование означает двойную стоимость за разработчика. Стоит ли это денег?

Ответ 1

Как вы знаете, что ваши непарные программисты более эффективны? Я иногда думаю, что сингл/пара сравнима со старой сказкой кролика и черепахи.

Сопряжение не дрейфует в дни контрпродуктивной работы. Я не знаю, как часто я видел, как разработчики проводят недели, работая над вещами, которые позже оказываются замененными чем-то намного более простым. Единственный программист "в зоне" часто делает глупые вещи. Слишком просто создать слишком много кода, когда вы хотите больше пробить с меньшим количеством кода.

И в потомстве, когда пыль оседает, вы найдете сотни, если не тысячи строк кода, которые могли быть написаны не потому, что кто-то не знал о библиотеке X или технике Y. Спаривание улучшает эту проблему, но не убери это. Это побуждает как отдельных лиц, так и пар делать больше исследований, прежде чем погрузиться в бессмысленную эйфорию кода.

Мне жаль, что я не смог больше пары....

Ответ 2

Мы используем этот подход в нашей компании, но только для сложных задач или когда вы не уверены в том, над чем работал кто-то еще, который, как я считаю, работает очень хорошо. Это избавляет вас от застревания в колею и способности отскакивать идеи от людей, где это необходимо, хотя они могут работать независимо для большинства простых задач.

Я также считаю, что это более выгодно, чем обзор кода, что мы делаем там, где я работаю. Часто бывает сложно полностью понять, что происходит при выполнении обзора кода, не предоставляя значительного контекста, и в этот момент у вас не всегда есть время подумать обо всех входах и выходах. Паровое программирование дает вам этот контекст с самого начала и позволяет вам тратить больше времени на размышления о краевых случаях, которые могут или не могут вызвать проблемы.

Ответ 3

Хотя я согласен с большинством ответов до сих пор о том, что парное программирование - это хорошо, я буду играть адвоката дьявола и утверждать, что это не всегда имеет смысл.

Когда вы паритесь, вы не получаете программиста, который получил вдвое больше мозгов. Вы получаете программиста, что союз обоих ваших мозгов. Так что в основном в любое время, когда я заворачиваю, и мой партнер ловит или находит какой-то способ лучше, это плюс. Однако в любое время, когда я пишу правильный код самостоятельно, это пустая трата денег, так как мой партнер не нужен.

В принципе, вам нужно оценить код, над которым вы работаете. Простые задачи обычно не стоят денег, чтобы заплатить кому-то за плечо и убедиться, что вы правильно написали свой цикл. Однако на некотором пороге задачи достаточно сложны, чтобы сделать roi для парного программирования обоснованным.

Ответ 4

Это не означает удвоенную стоимость, если требуется меньше 1/2 времени, которое было бы принято с помощью одного разработчика. Я думаю, что на трудных или низкоуровневых задачах это было бы полезно. Я считаю, что это того стоит, потому что у вас есть кто-то сказать "нет, не делайте этого!" задолго до того, как он попадет в производственный код, где он ДЕЙСТВИТЕЛЬНО будет стоить вам времени и денег.

Я написал операционные системы и вещи такого рода, где было неоценимо, что кто-то сидел рядом со мной, чтобы проверить мою логику.

Ответ 5

С парным программированием вы комбинируете:

• Код более высокого качества
• Лучшее распространение внутреннего знания
• Больше командного духа

Вы не получите такую ​​отдачу от инвестиций, как это легче.

И снова вы не должны использовать его для всех задач.

Ответ 6

На работе мы все время используем парное программирование. Хитрость заключается в том, чтобы знать, какие задачи должны выполняться в паре, и которая будет "пустой тратой времени", если это будут делаться двумя разработчиками. Правило большого пальца состоит в том, что задачи, которые являются более ориентированными на исследования (т.е. POC и шипы), должны выполняться парами, а также создавать новые функции (чтобы знания существовали более чем в одном уме). Задачи, которые являются более mundain, такие как установка сервера CI или замена значков аддонов, выполняются одним разработчиком. Другим фактором является текущая доступность членов команды и текущие задачи, которые необходимо выполнить на этой итерации.

Ответ 7

Нет, нет. Каждый программист получает ровно одну зарплату.

Считаете ли вы, что ваши программисты не будут разговаривать друг с другом, если вы не называете это "парным программированием"? Считаете ли вы, что программирование отлично распараллеливается?

Ответ 8

Трудно сказать - я потратил много времени на работу в среде с принудительной партией, а также в среде с дополнительным интерфейсом. Код высокого качества, который я видел, не находится в спаренной среде. Вероятно, это больше связано с калибром и дисциплиной отдельных разработчиков. Иногда вы получаете деньги от спаривания, особенно если некоторые из кодеров не являются топ-уровнями. Но если все кодеры являются опытными, хорошо дисциплинированными кодировщиками, вы просто тратите свои деньги, если они все время спариваются.

Один из видов опыта, который я имел несколько раз, который оказывает огромное влияние на мою дисциплину кодирования и качество продукта, которое я производю, это: перенос пейджера. Когда я должен поддерживать систему, для которой я кодирую, она меняет порядок кодирования. То есть, я кодирую таким образом, чтобы этот пейджер не уходил. В результате получается продукт лучшего качества и, как правило, лучшее качество кода. Кодеры, которых я видел, никогда не носили код пейджера, который более хрупкий. Это не то, что они могут даже понять и улучшить, пока не окажутся в поддержке.

Ответ 9

Чем быстрее обнаружится ошибка/дефект, тем дешевле это исправить, поэтому использование денег для найма большего количества людей qa против других разработчиков будет стоить вам больше времени/денег из-за того, сколько поездок от DEV до QA.

Сказав это, пара-программирование не работает со всеми, некоторые разработчики не хорошо сочетаются, они отвлекают друг друга, проводят все свое время и т.д.

Если у вас есть разработчики, которые могут спарить программу, это может быть более выгодным в долгосрочной перспективе, когда вы добавляете более удобный код, уменьшаете количество дефектов и меньше времени в QA, и, самое главное, если один из разработчиков получает автобус, вам не нужно ждать, пока кто-то придет на скорость по проекту, прежде чем на нем будет сделана еще одна работа.

Если ваши разработчики не могут спарить программу, не вставляйте их в нее, все, что вы собираетесь делать, это тратить время и деньги.

Ответ 10

Программирование пар может быть удивительно эффективным, однако вы не должны нанимать программистов в парах. Вы не можете заставить разработчиков спрятать программу. Он работает только тогда, когда два разработчика нажимают и решают, что они могут учиться друг у друга и создавать что-то потрясающее вместе. Мой совет - нанять столько самых умных разработчиков, которых вы можете найти, и поместить их в настройку, которая, естественно, подталкивает к поощрению парных партитур. Разработчики должны иметь возможность кода самостоятельно, но также поговорить с другими в команде об этом.

Поиск правильного сочетания, который работает для вас и вашей компании, будет более искусным, чем наука, и, конечно же, не то, что вы можете сделать, слепо следуя требованиям какой-либо опубликованной методологии.

Тем не менее, чем больше ошибок вы раздавите, прежде чем они когда-либо будут проверены, тем больше вы сохраните их в долгосрочной перспективе. Еще один разработчик, смотрящий по мере того, как вы что-то архитектор, всегда будет более эффективным, чем после него, после того, как он получит черный ящик. Я бы назвал это хорошо потраченными деньгами.

Ответ 11

Первое предположение, сделанное с помощью парного программирования, состоит в том, что история-карта будет стоить в два раза больше, чем нужно. Предположение ошибочно. Вот почему?

• Улучшенное качество. Пара активных программистов, работающих на одной и той же сюжетной карте, завершит карточку с меньшими дефектами.
• Повышенная производительность: пара, скорее всего, будет замедлен, если не будет блокирована при решении проблемы. Кроме того, сложнее взять электронную почту или веб-отпуск, когда вы работаете с партнером... вы не хотите, чтобы партнер был вниз. Вы решите проблему с более чистым дизайном и меньшим количеством строк кода при работе в паре.
• Устранить силосы знаний. С вращающимися парами вы узнаете знание приложений и знаний о домене в команде. Команда с меньшей вероятностью будет заблокирована, потому что Сью, когда в отпуске, и никто другой не знает ее код.
• Передача знаний: Вращающиеся пары учат новые навыки (инженерное дело и домен) друг другу, работая вместе. Уровень команды будет расти для всех, и знания распространяются через команду.
• Команда самостоятельно выбирает: Команда изучает одно из своих навыков и быстро вытесняет тех, кто не выполняет.

Из фактического опыта мы видели падение падения значительно. Новые члены команды могут быть добавлены без замедления команды (попробуйте это с непарной командой). Для испытания одна команда оценила работу над набором карточек с рассказами, как если бы шесть отдельных разработчиков заполнили код отдельно. Шестому разработчику было предложено пару. Они завершили работу в срок с высоким качеством. Если вы не спариваетесь, вы тратите много времени, чтобы довести до низкого качества, у вас нет возможности масштабироваться, и у вас слишком много силосов опыта.

Во втором примере мы, по оценкам, завершили работу за запрошенное время, нам нужно будет взять команду от 4 пар до 7 пар. Мы дали себе 1 месяц на новые пары. Мы объединили нового разработчика с опытным разработчиком и повернули пары через карты рассказов. Команда поразила все результаты с качеством в запланированное время. Без спаривания нельзя было добавить 6 разработчиков в команду из 8 разработчиков и попал в цель!

Итог, вы сэкономите деньги при спаривании. Вы возьмете примерно то же время, доставку с более высоким качеством, улучшите производительность команд, навыки и знания и выселите мертвую древесину. Ваши сбережения будут обеспечены устойчивыми темпами и значительно меньшим количеством недостатков, чтобы замедлить работу команды.

Ответ 12

Предпосылка заключается в том, что ваша производительность более чем удваивается. Часть выигрыша реализуется сразу (например, перед проверкой кода), а часть реализована далее, когда количество ошибок и сбоев меньше.

Когда я преподаю студентам с опытом двух семестров, для большинства пар их производительность более чем удваивается, потому что они задают друг другу вопросы, и они учатся и заканчивают быстрее. Но это не повсеместно верно; плохо подобранная пара может занять больше времени и сделать хуже, чем более квалифицированная половина.

Ответ 13

Опыт управления качеством из других отраслей промышленности учит нас тому, что предотвращение дефектов в долгосрочной перспективе является более дешевым, чем обнаружение дефектов (также известное как QA) и последующая фиксация.

Они также узнали, что длительный диапазон варьируется в большинстве случаев от 1 до 2 лет, а это означает, что после этого ваши инвестиции окупаются. Учитывая, что инвестиции в этот масштаб, как правило, должны достичь перерыва даже после 4 лет, это очень хорошо!

Проблема в том, что другим отраслям промышленности потребовалось несколько десятилетий для накопления достаточного количества данных, чтобы доказать, что это так. Вы можете легко найти данные, чтобы поддержать их вывод, и сделать вывод для программного обеспечения по аналогии с этим, но на сегодняшний день нет доказательств для бизнеса в области программного обеспечения.

Я считаю, что аналогичный вывод справедлив: пара разработчиков и один тестер более продуктивны, чем один разработчик и два тестировщика.

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

Ответ 14

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

Ответ 15

Паровое программирование не удваивает стоимость - оно лишь вдвое увеличивает количество ввода. Ввод не является программированием. Выполнение функциональных возможностей программного обеспечения - это программирование. Это решение проблемы. Вы не можете просто измерить его в строках кода. Некоторые программисты будут использовать лучший алгоритм, чтобы они в конечном итоге набрали меньше.

Как бы вы определили соотношение цены и качества? Возможно, общее время, прошедшее между началом кодирования и завершенной рабочей функцией в live?

Стоимость не спаривания часто не учитывается правильно: Проблема заключается в том, что большинство людей не измеряют количество дефектов или количество дополнительного времени, затраченного на исправление работы, которая не была в первую очередь, правильно - они просто измеряют время, затраченное на то, чтобы "бросить работу над забором" в первую очередь.

Есть несколько попыток измерения производительности при парировании, но, к сожалению, она немного привязана к "количеству строк кода" - это фиктивная метрика.

Вы можете найти это исследование релевантным: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Ответ 16

Ничего себе! в компании, в которой я работаю, мы практикуем много парного программирования! это делает вещи очень быстро и эффективно! просто попробуйте! вы будете оценивать его позже!

Ответ 17

Профессор Лори Уильямс из штата Северная Каролина является главным авторитетом в академических кругах об эффективности парного программирования, она провела целую кучу исследований по этому вопросу.

Если вы хотите "официальное слово", посетите ее publication.

Ее статья: "Укрепление дела для парного программирования" чрезвычайно известна.

Ответ 18

Это зависит от разработчиков. К сожалению, вы не можете просто придерживаться любых двух разработчиков вместе и ожидать своевременных и качественных результатов. Не все вырезаются для парного программирования или даже вырезаны для работы в гибкой среде разработки. Две вещи о спаренном программировании, которые, на мой взгляд, стоят того, чтобы сделать это: (1) кросс-тренинг между разработчиками; и (2) рецензирование в режиме реального времени. Кросс-тренинг поможет укрепить навыки команды в целом, а рецензирование в режиме реального времени может устранить необходимость в официальных экспертных обзорах. Я узнал больше от своих сверстников за эти годы, чем когда-либо учился на техническом обучении.

Ответ 19

Если вы не очень маленький магазин, вы, вероятно, уже платите зарплату двум программистам. Пара-программирование - это всего лишь способ (теоретически) получить больше отладки и рабочего программного обеспечения из этих двух за тот же промежуток времени.

Ответ 20

Это не черная и белая вещь, ни серебряная пуля любого рода, концепция парного программирования.

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

Итак, парное программирование - это всего лишь один из способов решения проблемы, и мне трудно смотреть на нее с точки зрения вопроса. Это не так, как вам нужно нанять вдвое больше разработчиков для этого. Это интересно, стоит ли нанимать мальчика/девочку, чтобы иметь двух сотрудников в одном отделе друг с другом... когда очевидным решением является заставить их говорить друг с другом напрямую без дополнительного мессенджера.

Ответ 21

Я не делал статистику - и я подозреваю, что вам будет сложно провести статистически обоснованное исследование, - но помните о якобы имеющейся цели создания рабочего кода без ошибок, а не только о количестве код. Хорошая пара должна иметь возможность создавать как минимум такой же правильный код, как два программиста, работающие отдельно.