Pull to refresh

Comments 17

А зарплату потом тоже пополам будут делить, так как планы были разные и занимались решением задачи только одного из коллег? )
Если у вас принято планировать задачи не на команду, а на человека, то это не совсем хороший подход (особенно, если вы хотите в scrum). И в таком случаи, на мой взгляд, рано думать о парном программировании
В scrum не хотим (про данный метод, справедливости ради, в статье и не упоминается).
Есть команда, у команды есть TeamLead — он получает задачу на команду, дробит на части (составляет планы на месяц для каждого), следит за соблюдением сроков, делает CodeReview.
Именно потому я и оставил свой первый комментарий что усомнился в применимости парного программирования в нашей модели программирования. У нас применяется мозговой штурм с бОльшим количеством участников и меньшим количеством затрачиваемого на совместную работу временем.

Вероятно, это моя «детская травма» от учебы в гимназии, когда учителя физики и математики, видя в старших классах что ученики советуются на контрольной (а советуются именно про правильность предполагаемого метода решения задачи, делегируя одному роль «штурмана») задавала как раз тот самый вопрос: «Когда сдадите решения — ваши оценки тоже пополам делить?»

Ок, даже если не говорить про scrum и agile, мне кажется очень странно и не правильной практика, когда получает и декомпозирует задачу только "тимлид", и потом их спускает вам. Но это отдельная история.


Что касается применения парного программирования у вас. Я в статье попытался донести, что ПП не решение всех проблем. А инструмент, которым можно решать разные задачи. Который может быть полезен всем.
Про деление зп не совсем корректный вопрос. Не должно же быть желания просто утилизировать ресурс программиста только на написание кода. Шаринг знаний, обучение коллег, пбр — это тоже работа. И вот такая работа, по моей практики, лучше получается в паре, чем в одиночку.

Про обмен знаниями, обучение и т.д. — полностью согласен… ровно как и утилизацию в написание кода.
Спасибо, теперь есть над чем задуматься.
Шаринг знаний, обучение коллег, пбр — это тоже работа.


Подскажите, пожалуйста, что такое пбр.
Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта

Подробнее можно почитать можно тут, например
Вероятно, это моя «детская травма» от учебы в гимназии, когда учителя физики и математики, видя в старших классах что ученики советуются на контрольной (а советуются именно про правильность предполагаемого метода решения задачи, делегируя одному роль «штурмана») задавала как раз тот самый вопрос: «Когда сдадите решения — ваши оценки тоже пополам делить?»

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

Ну так это и не Scrum, а XP.
Если практика парного программирования в принципе используется в команде, то ТимЛид просто закладывает её в объём работы при распределении, а то и в трудооценку.
А как насчет удаленного парного программирования? Для себя решил, что точно не мое, и ушел из компании, где ПП было обязательным. Проблемы коммуникации — задержки с ответом, плохое звуковое оборудование участников. В результате борешься не с проблемой, а со средствами связи и моя обычная производительность падала в несколько раз.

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


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

Естественно надо сначала убирать проблемы с оборудованием, задержки и.т.д.
Но есть ещё проблема с удобным совместным доступом к коду.
Пока нашли более менее приемлемое решение во встроенном в Visual Studio Live Share.
Что используете вы?
To vdovin_ds: Дмитрий, если когда-нибудь (или вдруг) попадете на Запад, постарайтесь поменьше употреблять в общежитии слово «джун» — сейчас это приравнивается, практически, у частому употреблению слова «Jew», или еще хуже — тут не скажу ;) В западных (а, точнее, американских) компаниях такой термин не употребляется от слова «вообще» — все ваши коллеги будут инженеры (а их «ранжир» будет в соответствии с company policy — то-ли software engineer II, или senior software engineer etc.), но junior-ов там не будет 100% (но могут быть interns — это другое дело).

Что же касательно «парного программирования», то задолго до того, как это стало «модным, молодежным трендом», подобный подход употреблялся в индустрии десятилетиями (просто без особого хайпа и паблисити). Дело тут в особенностях человеческого мышления: зачастую, когда рассказываешь/делишься идеей с кем-то другим, мысль неожиданно находит новый, «улучшенный» вариант или путь. В этом, собственно, и весь секрет («секрет Полишинеля»). Да, подобная практика весьма полезна, и лично я ее очень люблю; кстати даю новаторскую идею (опробуйте в деле!): вовсе не обязательно чтобы этот «кто-то второй», рядом, был умудренным «сеньором», архитектором или гуру, вовсе нет! Посадите рядом жену, ребенка (ничего не понимающих в программировании), и попробуйте развить им свою идею, которую вы собрались реализовывать в коде — сработает не хуже (а, возможно, и лучше), если бы рядом сидел умудренный годами и опытом программер. И, кстати, от того, что вы перейдете на «общежитейскую» лексику, у вас может открыться абсолютно иной взгляд на решение проблемы (со мной такое случалось неоднократно!).
новаторскую идею

Эту идею можно еще сильнее обобщить, заменив ребенка на неодушевленный или даже несуществующий предмет — получится метод утенка.
«Метод утёнка» — прямой путь к безалкогольному пиву и резиновой женщине! :D Но, если серьезно, то неодушевленные предметы «не работают» (по крайней мере, для меня).
Можно ещё проще:
Моя кошка замечательно разбирается в программировании. Стоит мне объяснить проблему ей — и все становится ясно.
John Robbins (с).
Sign up to leave a comment.