Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
Так же интересует вопрос, не знает ли кто-нибудь, используется ли данная техника в МС? И если да, то в каких командах (продукт какой разрабатывают). И как к этой технике относятся в МС вообще?
Те, кто лично сталкивался с парным программированием, как можете прокоментировать такие мысли:
1. парное программирование хорошо для фирмы в целом, т.к.
оно (программирование) распределяет уровень знаний и мастерство между членами команды, делает их взаимозаменяемыми. + осуществляется контроль друг друга и люди меньше фигней страдать начинают, в карты играть по порносайтам лазить и т.п.
В то же время оно снижает уровень ценности каждой отдельной личности для фирмы, т.к. эта личность заменяема. Что для личности этой уже не есть хорошо. И для того, чтобы данный фактор не превалировал необходимо в сочетании с парным программированием вести умную политику самой фирме (что редко наблюдается), дабы личность не чувствовала, что она теряет свою уверенность в завтрешнем дне, т.к. становится заменяемой.
2. Кроме того непонятно вот что... Хорошо. Знания распределились. Кто-то их повысил, узнал что-то новое. А дальше? вариться в своем котле? При отсутствии в коллективе человека, который сам постоянно стремится к чему-то новому, может получиться застой и отстой. Кроме того, остальные рискуют превратиться просто в "нахлебников". А при здором наборе личных амбиций, тот самый человек-движок должен чувствовать себя ущемленным.
3. Пришел новый человек. С помощью парного программирования он абсорбирует концентрированные знания с огромной скоростью. НО он получает их даром и на блюдечке... Что будет дальше, думаю сам представляешь... Этот человек не будет уметь способность к самостоятельному обучению в принципе, он сможет только существовать за счет готовых знаний.
Спасибо.
PS
Просьба отвечать на вопросы людей, действительно имеющих реальный опыт парного программирования. Любителей порассуждать прошу не беспокоиться, я и сам теоретических идей могу наплодить...
Здравствуйте, John Scherbatov, Вы писали:
JS>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
у нас не практикуется, и я не слышал ни об одной конторе поблизости в Нске, где бы практиковалось.
ИМХО, парное программирование — это просто порнография какая-то
единственное, имеет некоторый смысл для обучения — если ставится именно такая цель, на каком-то тренировочном проекте.
у меня складывается впечатление, что ХР вместе с парным программированием — это просто "белый слон", очередной раскрученный бренд для зашибания денег, не имеющий реальной ценности
всё вышесказанное — это ИМХО
Здравствуйте, John Scherbatov, Вы писали:
JS>Господа, доброго времени суток.
JS>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
JS>Так же интересует вопрос, не знает ли кто-нибудь, используется ли данная техника в МС? И если да, то в каких командах (продукт какой разрабатывают). И как к этой технике относятся в МС вообще?
JS>Те, кто лично сталкивался с парным программированием, как можете прокоментировать такие мысли:
JS>1. парное программирование хорошо для фирмы в целом, т.к. JS>оно (программирование) распределяет уровень знаний и мастерство между членами команды, делает их взаимозаменяемыми. + осуществляется контроль друг друга и люди меньше фигней страдать начинают, в карты играть по порносайтам лазить и т.п.
Точно.
JS>В то же время оно снижает уровень ценности каждой отдельной личности для фирмы, т.к. эта личность заменяема. Что для личности этой уже не есть хорошо. И для того, чтобы данный фактор не превалировал необходимо в сочетании с парным программированием вести умную политику самой фирме (что редко наблюдается), дабы личность не чувствовала, что она теряет свою уверенность в завтрешнем дне, т.к. становится заменяемой.
Это звучит как утверждение, причем достаточно категоричное. Вообще такие вещи либо строго матекатически доказываются, либо подкрепляются несколькими примерами.
Могу сказать, что ПП должным образом подчеркивает роль человеческой коммуникации в разработке. Коллектив сплачивается сильнее. Нахлебники естественным образом отсеиваются. Ведь никому не хочется делать всю работу самому в паре. Проверено, что даже совершенные новички при обучении в паре дают свой вклад.
JS>2. Кроме того непонятно вот что... Хорошо. Знания распределились. Кто-то их повысил, узнал что-то новое. А дальше? вариться в своем котле? При отсутствии в коллективе человека, который сам постоянно стремится к чему-то новому, может получиться застой и отстой. Кроме того, остальные рискуют превратиться просто в "нахлебников". А при здором наборе личных амбиций, тот самый человек-движок должен чувствовать себя ущемленным.
Тоже бездоказательное утверждение.
Про нахлебников см. выше. Застоя не получается из-за peer pressure. Никому не получается застаиваться в уголке за перегородкой в одиночку.
JS>3. Пришел новый человек. С помощью парного программирования он абсорбирует концентрированные знания с огромной скоростью. НО он получает их даром и на блюдечке... Что будет дальше, думаю сам представляешь... Этот человек не будет уметь способность к самостоятельному обучению в принципе, он сможет только существовать за счет готовых знаний.
Неправда. Как раз динамика получения новых знаний устанавливает для него планку для дальнейшего развития. Благодаря ПП разработчики становятся намного активнее.
JS>Спасибо.
JS>PS JS>Просьба отвечать на вопросы людей, действительно имеющих реальный опыт парного программирования. Любителей порассуждать прошу не беспокоиться, я и сам теоретических идей могу наплодить...
Уже один любитель успел ответить, так что твое предупреждение оказалось предсказуемо бесполезным.
Здравствуйте, Дарней, Вы писали:
JS>>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление? Д>у нас не практикуется, и я не слышал ни об одной конторе поблизости в Нске, где бы практиковалось.
Мне кажется, что фирма, которая может хотя бы попробовать ПП, должна:
а) Либо быть очень богатой, чтобы выделять двух человек, получая столько же результата, сколько выдает один. Подавляющему большинству просто элементарная жадность не даст так организовать работу.
б) Либо очень мало интересоваться результатом. Отличный пример — ВУЗ, НИИ, исследовательская лаборатория.
Д>единственное, имеет некоторый смысл для обучения — если ставится именно такая цель, на каком-то тренировочном проекте.
Это как раз второй случай.
Д>у меня складывается впечатление, что ХР вместе с парным программированием — это просто "белый слон", очередной раскрученный бренд для зашибания денег, не имеющий реальной ценности
Ну есть же там очень разумные части. Я имею в виду TDD.
Здравствуйте, John Scherbatov, Вы писали:
JS>Господа, доброго времени суток.
JS>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
Работал три месяца в паре над проектом . Впечатление осталось очень хорошее — работать интереснее , меньше устаешь, потому что не все время на пимпы жмешь . Багов меньше получается , потому что недосмотров меньше. В новых технологиях разбираться легче. И вообще, одна голова хорошо, а две лучше. Только, правда, когде обе не считают себя Биллами Гейтсами (см. замечание автора про амбиции). Эффект получается больше, чем от одного человека, хотя и не скажу, что как от двух — нельзя было сравнить Способствует большей сплоченности коллектива, а всякие дремучие и нелюдимые типы, которые считают, что "мой код — как хочу, так и пишу. Мои интимные подробности" отсеиваются сами собой. В последсвтии это не приводит к ступору из-за ухода одного человека из команды.
Здравствуйте, John Scherbatov, Вы писали:
JS>1. парное программирование хорошо для фирмы в целом, т.к. JS>оно (программирование) распределяет уровень знаний и мастерство между членами команды, делает их взаимозаменяемыми. + осуществляется контроль друг друга и люди меньше фигней страдать начинают, в карты играть по порносайтам лазить и т.п.
Зато можно весело поиграться в какие-нибудь гоночки на одном компе
Насчет "для фирмы в целом" — ничего такого не знаю, парный программизм скорее дает что-то программерам. Разве что скорость решения проблем повышается.
JS>В то же время оно снижает уровень ценности каждой отдельной личности для фирмы, т.к. эта личность заменяема. Что для личности этой уже не есть хорошо. И для того, чтобы данный фактор не превалировал необходимо в сочетании с парным программированием вести умную политику самой фирме (что редко наблюдается), дабы личность не чувствовала, что она теряет свою уверенность в завтрешнем дне, т.к. становится заменяемой.
Тоже как-то смутно — "личность заменяема". Да ничего подобного. Парный программизм — не значит одни и те же мысли и одни и те же способности. Это крайняя степень. Про политику тоже сильно сказано. Зачем контора будет целенаправленно этим заниматься? Кто программит? Девелоперы. Вот они пусть и разбираются меджу собой.
JS>2. Кроме того непонятно вот что... Хорошо. Знания распределились. Кто-то их повысил, узнал что-то новое. А дальше? вариться в своем котле? При отсутствии в коллективе человека, который сам постоянно стремится к чему-то новому, может получиться застой и отстой. Кроме того, остальные рискуют превратиться просто в "нахлебников". А при здором наборе личных амбиций, тот самый человек-движок должен чувствовать себя ущемленным.
Гммм... Вот здесь есть некая доля правды. Без стремления КАДЖОГО члена команды развиваться, скоро вся команда превратится в "застой и отстой". С другой стороны, как я уже говорил, каждый программер имеет свои личные особенности как в мышлении, так и в конкретных способностях. Мне кажется, что идея парного программизма преследовала скорее обмен идеями и подходами, а это достаточно широкое поле.
JS>3. Пришел новый человек. С помощью парного программирования он абсорбирует концентрированные знания с огромной скоростью. НО он получает их даром и на блюдечке...
Эээ... не факт, см. выше.
JS>Что будет дальше, думаю сам представляешь... Этот человек не будет уметь способность к самостоятельному обучению в принципе, он сможет только существовать за счет готовых знаний.
Как мне кажется, такой человек и программистом-то быть не сможет... "не иметь способности к самостоятельному обучению" — без этого вообще сложно что-то девелопить.
Резюм.
В конторе где я работаю парный программизм часто применяется для решения "упорных" проблем, отслеживания глубоко закопанных багов, развития новых нестандартных подходов. То бишь не сидим круглыми сутками по два человека за машиной. Каждый решает свои задачи, но в случае необходимости может рассчитывать на работу вдвоем.
На вопрос о парном программировании менеджеры мне всегда отвечали, что ресурсов не хватает. Потому вопрос не в том хорошо это или плохо, а в том насколько это выгодно. Качество кода — это не всегда самый важный фактор. Иногда надо просто сдать прокект в срок и получить за него деньги. А 2 программера за одним компом будут производить в 2-3 раза меньше кода. И всем наплевать, что он будет высшего качества, ведь этого же специально не требовалось.
можно по 14 часов в сутки развивать бешеную активность с нулевым результатом. Или даже хуже. Я имею в виду код, на отладку которого потом уйдет в несколько раз больше времени, чем на его написание.
Стремление писать код "во что бы то ни стало" обычно именно в это и развивается, за редчайшими исключениями.
_>Уже один любитель успел ответить, так что твое предупреждение оказалось предсказуемо бесполезным.
Я предполагаю, перед нами именно человек, который имеет опыт реального парного программирования на реальных проектах, хотя бы одном?
В таком случае — очень хотелось бы услышать про:
примерное описание сути проекта
объем работ и численность команды
примененные средства
результаты проекта
общие впечатления
Здравствуйте, John Scherbatov, Вы писали:
Постановка вопросов острая, но , мне кажется, весьма интересная
JS>Те, кто лично сталкивался с парным программированием, как можете прокоментировать такие мысли:
было совсем немного опыта парного программирования, не то, чтобы в "конторе", однако ..
JS>2. Кроме того непонятно вот что... Хорошо. Знания распределились. Кто-то их повысил, узнал что-то новое. А дальше? вариться в своем котле? При отсутствии в коллективе человека, который сам постоянно стремится к чему-то новому, может получиться застой и отстой. Кроме того, остальные рискуют превратиться просто в "нахлебников". А при здором наборе личных амбиций, тот самый человек-движок должен чувствовать себя ущемленным.
Согласен на 100%. В случае, если 2 человека имеют приблизительно одинковый и высокий уровень знаний, а еще лучше, если у них вследствии опыта сложились "разные точки зрения, видения", то парное программирование ( и в большей мере, решение некоторых текущих дизайн-проблем) хорошо влияет на результат. По опыту. Бывает даже в 2 раза, особенно если нужен даже простой несколько другой взгяд на вещи, с другой стороны.
Но так, если нет движения, то ...согласен.
JS>3. Пришел новый человек. С помощью парного программирования он абсорбирует концентрированные знания с огромной скоростью. НО он получает их даром и на блюдечке... Что будет дальше, думаю сам представляешь... Этот человек не будет уметь способность к самостоятельному обучению в принципе, он сможет только существовать за счет готовых знаний.
Всякое бывает, от человека зависит..Конечно, если ты говоришь, что приходит новый человек, который "не имеет способности к сам. обучению в принципе", то проблема такая имеет место. А если человек уже может все сам, отчего бы не вывести его на более высокий уровень.
JS>PS JS>Просьба отвечать на вопросы людей, действительно имеющих реальный опыт парного программирования. Любителей порассуждать прошу не беспокоиться, я и сам теоретических идей могу наплодить...
Надеюсь, что в прокрустово ложе втиснулся. А то бы еще написал ты пострашнее " 7 летний опыт парного программирования"
Здравствуйте, Дарней, Вы писали:
Д>Я предполагаю, перед нами именно человек, который имеет опыт реального парного программирования на реальных проектах, хотя бы одном? Д>В таком случае — очень хотелось бы услышать про:
Д>примерное описание сути проекта Д>объем работ и численность команды Д>примененные средства Д>результаты проекта Д>общие впечатления
Здравствуйте, John Scherbatov, Вы писали:
JS>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
Основное впечатление — очень сильное утомление, из-за того, что надо контролировать код всегда. И отвлечься не даст напарник.
JS>1. парное программирование хорошо для фирмы в целом, т.к. JS>оно (программирование) распределяет уровень знаний и мастерство между членами команды, делает их взаимозаменяемыми. + осуществляется контроль друг друга и люди меньше фигней страдать начинают, в карты играть по порносайтам лазить и т.п.
Согласен. Кроме того, качество кода лучше. И гораздо меньше проблем с его развитием
JS>В то же время оно снижает уровень ценности каждой отдельной личности для фирмы, т.к. эта личность заменяема. Что для личности этой уже не есть хорошо. И для того, чтобы данный фактор не превалировал необходимо в сочетании с парным программированием вести умную политику самой фирме (что редко наблюдается), дабы личность не чувствовала, что она теряет свою уверенность в завтрешнем дне, т.к. становится заменяемой.
Очень спорно. Для того, чтобы не быть заменяемым, надо быть уникальным. Пути выхода: быть качественно уникальным или делать что-то свое, в чем никто не разбирается. Первый вариант предпочтительней, как для конторы, так и для отдельно взятой личности. Творческих людей ценят всегда и везде. А если человек является просто хорошим кодером, то опять-таки и без парного программирования он не может быть уверен в том, что его не заменят таким же хорошим кодером или кем-то творческим.
JS>2. Кроме того непонятно вот что... Хорошо. Знания распределились. Кто-то их повысил, узнал что-то новое. А дальше? вариться в своем котле? При отсутствии в коллективе человека, который сам постоянно стремится к чему-то новому, может получиться застой и отстой. Кроме
Это нормально для любого коллектива, не важно программистов, парных программистов, музыкантов, дворовой компании и т.д.
JS> того, остальные рискуют превратиться просто в "нахлебников". А при здором наборе личных амбиций, тот самый человек-движок должен чувствовать себя ущемленным.
Нахлебников можно заменить... См. выше.
JS>3. Пришел новый человек. С помощью парного программирования он абсорбирует концентрированные знания с огромной скоростью. НО он получает их даром и на блюдечке... Что будет дальше, думаю сам представляешь... Этот человек не будет уметь способность к самостоятельному обучению в принципе, он сможет только существовать за счет готовых знаний.
Я был именно таким человеком — подключился к уже развивающемуся проекту. Даром ничего не дается — все требует осмысления. Кроме того, это только на начальном этапе ты — наблюдатель и слушатель. Чуть начнешь понимать — все, тут уж действительно парное программирование — участвуешь, то бишь сам пишешь и "встраиваешься" в систему. А это и есть самостоятельно обучение в реально-функционирующей системе, а не в полученном схематическом представлении.
ИМХО, большой негатив парного программирования — это то, что оно должно быть парным То бишь оба программиста должны по крайней мере быть не против. Мне, например, парное программирование не нравится — характер у меня такой
Здравствуйте, Дарней, Вы писали:
Д>ИМХО, парное программирование — это просто порнография какая-то Д>единственное, имеет некоторый смысл для обучения — если ставится именно такая цель, на каком-то тренировочном проекте.
Займись им. Пусть на тренировочном проекте, но попробуй. Хотя бы месяц, хотя бы 2 часа в день.
Д>у меня складывается впечатление, что ХР вместе с парным программированием — это просто "белый слон", очередной раскрученный бренд для
Это не "белый слон", это отдельная философия. И как и всякую философию ее нельзя рассматривать без истоков возникновения. Кастрируешь и будешь пользоваться только выводами — пролетишь. Сам пройдешь путем авторов и поймешь суть — успех обеспечен. Потому как в последнем случае ты никогда не будешь применять все в лоб — переваришь, оценишь, и приспособишь для своего конкретного случая. Иначе — ну никак.
Стоит разделить XP-философию и XP-методологию. Первое — это еще немного информации, которые добавляют тебе свободы. Второе — это ограничитель той самой свободы.
Д>зашибания денег, не имеющий реальной ценности
И кто на этом зашибает деньги?
Здравствуйте, flax, Вы писали:
F>может имеет смысл поинтересоваться и на http://xprogramming.ru
угу. а про Windows почитаем на microsoft.com, про Java — на java.sun.com
честно говоря, меня больше интересует мнение простых разработчиков, которые занимаются своей работой, а не проповедников
Здравствуйте, mapa3m, Вы писали: M>Резюм.
M>В конторе где я работаю парный программизм часто применяется для решения "упорных" проблем, отслеживания глубоко закопанных багов, развития новых нестандартных подходов. То бишь не сидим круглыми сутками по два человека за машиной. Каждый решает свои задачи, но в случае необходимости может рассчитывать на работу вдвоем.
Это называется партнерское программирование, а не парное.
Здравствуйте, John Scherbatov, Вы писали:
JS>Господа, доброго времени суток.
JS>Спасибо.
На практике хорошо себя показало только при работе студент + топ девелопер. иначе полная чуш. между двумя работующими в паре должна быть огромная разница, тогда и только тогда это что-то дает.
например когда обучал студентов работе в команде приходилось сидеть рядом и расказывать как пользоваться тулзами, где-что лежит в сети... очень часто студент долго не может въехать в архитектуру и тогда приходиться сидеть рядом и объяснять или если время критично — то студент аля пишет под диктовку...
Здравствуйте, John Scherbatov, Вы писали:
JS>Господа, доброго времени суток.
JS>Отзовитесь пожалйста те, у кого в конторе практикуется парное программирование. Каково впечатление?
у нас используется, только не постоянно
т.е. когда нужно знания двух людей то и сидят вместе делают, а так по отдельности
АМ> Мне кажется, что фирма, которая может хотя бы попробовать ПП, должна: АМ> а) Либо быть очень богатой, чтобы выделять двух человек, получая столько же результата, сколько выдает один. АМ> АМ>Подавляющему большинству просто элементарная жадность не даст так организовать работу. АМ> б) Либо очень мало интересоваться результатом. Отличный пример — ВУЗ, НИИ, исследовательская лаборатория.
Я это и не фанат парного программирования, и вообще чувствовал себя довольно некомфортно,
когда приходилось работать подобным образом, но и то и другое — на мой взгляд неверно.
Например, известно, что значительна часть разработчиков тратит непосредственно на
разработку менее 100% рабочего времени. Остальное тратися на всякие "нерабочие" вещи,
сёрфинг. Так вот попробуйте почитайте анекдот.ру вдвоем за одним компьютером.
Лучше уж работать.
Второе. Если время разработки и увеличивается незначительно, то время на отладку
должно уменьшаться — за счет дабл-чека кода хотя бы, и вообще повышения его качества.
Просто элементарно неудобно будет перед партнером писать корявый код, с тем что бы
поправить его потом.
Третье — значительно снижается количество затыков, или клинчей. Что очевидно.
Все это описано в соответствующей литературе, но то, что я написал, я проверил
на своей практике.
Замечен и негатив. Можно обсудить где-нибудь.
Д>>у меня складывается впечатление, что ХР вместе с парным программированием — это просто "белый слон", очередной Д>раскрученный бренд для зашибания денег, не имеющий реальной ценности АМ> Ну есть же там очень разумные части. Я имею в виду TDD.
Вообще при надлежащем подходе очень неплохая методика, довольно здравая и практичная.
Другое дело, что лишний фанатизм всегда вреден, и любую методику надо внедрять с
умом и обтесывать под нужды проекта (ов).
. Впечатление осталось очень хорошее — работать интереснее 
, меньше устаешь, потому что не все время на пимпы жмешь 
. Багов меньше получается 
, потому что недосмотров меньше. В новых технологиях разбираться легче. И вообще, одна голова хорошо, а две лучше. Только, правда, когде обе не считают себя Биллами Гейтсами 
(см. замечание автора про амбиции). Эффект получается больше, чем от одного человека, хотя и не скажу, что как от двух — нельзя было сравнить 
