Ну бизнесмены они же такие занятые, им так необходимо знать, не повис ли сайт их огромной компании и у них нет времени глянуть с утра или озадачить сисадмина?))
Тут ты прав. Большим компания это совершенно не нужно. У "больших" будет zabbix, prometheus, grafana. Особенно если у них есть отдел разработки. А что на счет других?
Например, коллеги программисты, которые запускают свои небольшие пет-проекты? Конечно, они могут и сами написать что-то подобное. А можно воспользоваться чем-то готовым. Или для примера - небольшой бизнес / стартап, который на аутсорсе сделал сайт и просто хочет быть уверен, что он доступен. У него нет в штате "сисадмина" или программиста. Таких людей много.
Спасибо за комментарий. Я хотел бы напомнить, что все выше написанное — это мой опыт и мои наблюдения, которыми я хотел поделиться. То что действительно у нас работало и помогало.
Пару слов про твой комментарий:
вперед выдвигается совместимость людей, психология, социология, и т.д., а умение программировать уходит на задний план. Программисты часто бывают интроверты и им психологически тяжело выполнять совместную работу на регулярной основе.
Без условно ты прав. Именно поэтому я в статье и писал, что людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.
В паре люди проникаются общей идеей и начинают не замечать ее недочеты,
Я не в коем случаи не говорю что надо отменить ревью. Но при написание кода в паре они могут замечать и отлавливать какие-то ошибки. Подсказывать более оптимальный подход или паттерн. Делиться «на лету» своим опытом.
Шаринг кода/процессов/знаний и т.д. все же лучше формализовывать в виде хотя бы статей на внутренней вики или чем-то подобном.
Я согласен. Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация по всем приложениям и процессам?
Люди все очень разные, если часть людей будет работать в паре, а часть категорически нет — значит ли это что сплачиваться будет только часть коллектива?
Нет. Не значит. Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
Совместные Тимбилдинги, походы в бар, поедания пиццы, и просто разговор по душам или помощь никто не отменял. Это всегда будет на первом месте для сплочения людей и командообразования
Спасибо за добрые слова. Могу предложить прочитать предыдущую мою статью о плюсах парного программирования. И мою статью про новичков. Возможно, тоже что-нибудь интересное для себя найдете. Ну или наоборот, напишете с чем и почему вы не согласны, что бы я посмотрел на эти вопросы и с другой стороны.
Не готов говорить за всех. И какой-то статистики у меня нет.
Но по моим наблюдениям все как раз наоборот. Так как есть еще некий момент поддержки и мотивации друг друга.
Встречал случаи, когда человек в «одиночку» сидел со «своей задачей». И видно было, что у него чуть ли на апатия к ней… Но когда он сел в пару, сделали ее буквально за пару часов.
Тут, конечно, все индивидуально сильно.
Но на мой взгляд, что ПП наоборот часто помогает не выгореть.
Оно не лучше и не хуже. Это просто совсем другое.
В предыдущей статье я рассказывал, как я вижу, какие задачи помогает решить ПП. Там есть разные кейсы по составу пар и по целям, которые могут быть достигнуты в ПП.
Если очень коротко, то, во-перых, скорость — не главный показатель. Иногда мы осознано жертвуем скоростью для других «плюсов». Так как ПП это далеко не всегда про скорость.
Во вторых, иногда придумать «что и как» написать занимает больше времени, чем само написание кода. И в паре порой решить сложную задачу получается быстрее.
Это один из стереотипов и глубокое заблуждение, имхо, что при работе в паре ценность каждого меньше, и что каждый работает в два раза меньше.
Это путь про «утилизацию ресурса программиста». И если у вас это есть в команде, то это не очень хорошо, имхо.
1. Люди не сидят в паре весь спринт. И не делают все задачи в парах. Увидеть их индивидуальные способности не составит труда, имхо.
2. Работа и перформанс команды в целом — не менее важно (а чаще и больше), чем работа отдельного человека
3. Если человек еще берет на себя работу по обучению коллег в паре и делится знаниями (хардовыми или бизнесовыми), то это, на мой взгляд, только плюс человеку при вопросе о промоуте.
Да, иногда бывают «неприятные моменты». Но не стоит забывать, что пока этот продукт у них в бета-тесте. Буду надеяться, что они все недочеты подправят.
Да, вроде как одно их первых упоминаний про парное программирование было в книге Кента Бека «Экстремальное программирование» в 1999 году. Хотя я не готов утверждать, что это было прям первое описание этого инструмента.
Что же касается твоего утверждения, что ПП вредит программистам «выше мидла», то я тут не могу с тобой согласиться. Свои доводы, в чем я вижу плюсы этого инструмента, где я это использую, я написал в предыдущей статье (вначале этой статьи есть ссылка). Это мой опыт, мои наблюдения и выводы.
Но я бы с радостью послушал бы и твои доводы, где и как это может вредить. Возможно, я пересмотрю свои взгляды.
По поводу, что это не пошло в массы. Тут я скорее соглашусь. Это не используют поголовно все. Но есть очень-очень много компаний где практикуют ПП в том или ином объеме.. И в России и за рубежом.
Я, к сожалению, не смогу дать точного совета, как тебе поступить.
Но я хотел бы напомнить, что ПП это не только непосредственное написание кода. Это инструмент, который можно использовать на разных задачах. И я думаю, что ты мог бы это попробовать стоять у доски (рисуя новую архитектуру, или алгоритм, или что-то еще) с кем-то в паре. И придумывать вместе. Это как вариант.
Еще в предыдущей статье я рассказывал как ПП помогает в процессах шаринга знаний, обучения коллег и уменьшения «башен знаний».
Ну и даже при таком подходе к работе как у тебя, ты мог бы попробовать раз в спринт, например, на 1 час сесть с кем-то в паре и написать код. Можно сколько угодно говорить о ПП. Ругать. Хвалить. Но пока сам несколько раз не попробуешь, ты не поймешь что и как именно тебе подходит.
Ну и не стоит забывать, что я не утверждаю, что ПП подходит всем.
Согласен почти со всеми тезисами и мыслями. Единственное что вызывает вопрос, это состав «Хирургической бригады»
Там (в твоем переложении на текущие реалии) есть тимлид/архитектор и старший, но нет места обычным программистам (не говоря уж о том, что титулы вообще — это не самое хорошее)
Инструментальщика ты назвал DevOps'ом. Но все же, на мой взгляд, девопс лучше воспринимать как процесс, а не как отдельный человек. И по-хорошему, его должны делать все, а не кто-то один.
Секретарь. На мой взгляд, очень расточительно иметь под это отдельного человека. Во-первых команда должны стремиться быть самоорганизующейся и самодостаточной. И многие вопросы связанные с техническими вещами или уточнениями требований от заказчика брать сама (что бы не было лишней передачи знаний и «сломанного телефона»). А не технические вопросы по проекту (и не только это) должен брать на себя владелец продукта (PO / PM)
Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта
Как раз в следующий раз хотел написать про то как начать практиковать парное программирование. И как мы это делаем на удалёнке. Не претендую на глобальную истину, но поделиться как это делаем мы хотел.
Но и там не будет ответов, которые подойдут всем. Очень много зависит как от команды, так и от инструментов, которыми пользуется команда и которые разрешены в компании.
Ок, даже если не говорить про scrum и agile, мне кажется очень странно и не правильной практика, когда получает и декомпозирует задачу только "тимлид", и потом их спускает вам. Но это отдельная история.
Что касается применения парного программирования у вас. Я в статье попытался донести, что ПП не решение всех проблем. А инструмент, которым можно решать разные задачи. Который может быть полезен всем.
Про деление зп не совсем корректный вопрос. Не должно же быть желания просто утилизировать ресурс программиста только на написание кода. Шаринг знаний, обучение коллег, пбр — это тоже работа. И вот такая работа, по моей практики, лучше получается в паре, чем в одиночку.
Если у вас принято планировать задачи не на команду, а на человека, то это не совсем хороший подход (особенно, если вы хотите в scrum). И в таком случаи, на мой взгляд, рано думать о парном программировании
Я понимаю твою печаль, но не знаю как тебе помочь.
Если вы берете Джуна «на вырост», что бы самим его обучить до нужного вам уровня, то у вас должна быть под это условная вакансия под мидла.
Если вы можете позволить только Джуна, то, наверное, не стоит удивляться, что они потом, когда набираются опыта, уходят на позицию выше, где им ее могут предложить?
Тут, на мой взгляд, другого не может быть.
Даже если у вас Мега крутая компания и люди, они рано или поздно уйду на позицию выше, если вы сами ее им не дадите.
я очень рад, что ни разу у меня не было, что просят взять «детей уважаемых людей.» :)
Либо это что-то из прошлого. Либо что-то в конкретном твоем случаии.
Хочу в это верить :)
скорее всего ему делают предложение «от которого нельзя отказаться».
Может где-то такое и есть, но я не встречал.
Зачем ему конкретно головняк, ради какого-то «светлого будующего» банка или отрасли в целом.
У каждого свои причины. Кому-то нравится учить. Кто-то так развивает софт-скилы. У кого-то единственный способ усилить команду, это взять джуна (других не дают)
Ну бизнесмены они же такие занятые, им так необходимо знать, не повис ли сайт их огромной компании и у них нет времени глянуть с утра или озадачить сисадмина?))Тут ты прав. Большим компания это совершенно не нужно. У "больших" будет zabbix, prometheus, grafana. Особенно если у них есть отдел разработки.
А что на счет других?
Например, коллеги программисты, которые запускают свои небольшие пет-проекты? Конечно, они могут и сами написать что-то подобное. А можно воспользоваться чем-то готовым.
Или для примера - небольшой бизнес / стартап, который на аутсорсе сделал сайт и просто хочет быть уверен, что он доступен. У него нет в штате "сисадмина" или программиста.
Таких людей много.
Пару слов про твой комментарий:
Без условно ты прав. Именно поэтому я в статье и писал, что людей в пару надо подбирать, а не сажать случайных. Что нельзя навязывать ПП. И что вначале надо делать маленькие по времени сессии парного программирования.
Я не в коем случаи не говорю что надо отменить ревью. Но при написание кода в паре они могут замечать и отлавливать какие-то ошибки. Подсказывать более оптимальный подход или паттерн. Делиться «на лету» своим опытом.
Я согласен. Документация нужна. Но одно второго не отменяет. И давай будет честны. Во всех ли компаниях где ты работал, была идеальная и полная документация по всем приложениям и процессам?
Нет. Не значит. Я всего лишь сказал, что ПП часто обладает «дополнительным» эфектом по сплочению. Конечно при условии, что это не навязывают сверху, а люди сами хотят.
Совместные Тимбилдинги, походы в бар, поедания пиццы, и просто разговор по душам или помощь никто не отменял. Это всегда будет на первом месте для сплочения людей и командообразования
Но по моим наблюдениям все как раз наоборот. Так как есть еще некий момент поддержки и мотивации друг друга.
Встречал случаи, когда человек в «одиночку» сидел со «своей задачей». И видно было, что у него чуть ли на апатия к ней… Но когда он сел в пару, сделали ее буквально за пару часов.
Тут, конечно, все индивидуально сильно.
Но на мой взгляд, что ПП наоборот часто помогает не выгореть.
В предыдущей статье я рассказывал, как я вижу, какие задачи помогает решить ПП. Там есть разные кейсы по составу пар и по целям, которые могут быть достигнуты в ПП.
Если очень коротко, то, во-перых, скорость — не главный показатель. Иногда мы осознано жертвуем скоростью для других «плюсов». Так как ПП это далеко не всегда про скорость.
Во вторых, иногда придумать «что и как» написать занимает больше времени, чем само написание кода. И в паре порой решить сложную задачу получается быстрее.
Это путь про «утилизацию ресурса программиста». И если у вас это есть в команде, то это не очень хорошо, имхо.
2. Работа и перформанс команды в целом — не менее важно (а чаще и больше), чем работа отдельного человека
3. Если человек еще берет на себя работу по обучению коллег в паре и делится знаниями (хардовыми или бизнесовыми), то это, на мой взгляд, только плюс человеку при вопросе о промоуте.
Что же касается твоего утверждения, что ПП вредит программистам «выше мидла», то я тут не могу с тобой согласиться. Свои доводы, в чем я вижу плюсы этого инструмента, где я это использую, я написал в предыдущей статье (вначале этой статьи есть ссылка). Это мой опыт, мои наблюдения и выводы.
Но я бы с радостью послушал бы и твои доводы, где и как это может вредить. Возможно, я пересмотрю свои взгляды.
По поводу, что это не пошло в массы. Тут я скорее соглашусь. Это не используют поголовно все. Но есть очень-очень много компаний где практикуют ПП в том или ином объеме.. И в России и за рубежом.
Но я хотел бы напомнить, что ПП это не только непосредственное написание кода. Это инструмент, который можно использовать на разных задачах. И я думаю, что ты мог бы это попробовать стоять у доски (рисуя новую архитектуру, или алгоритм, или что-то еще) с кем-то в паре. И придумывать вместе. Это как вариант.
Еще в предыдущей статье я рассказывал как ПП помогает в процессах шаринга знаний, обучения коллег и уменьшения «башен знаний».
Ну и даже при таком подходе к работе как у тебя, ты мог бы попробовать раз в спринт, например, на 1 час сесть с кем-то в паре и написать код. Можно сколько угодно говорить о ПП. Ругать. Хвалить. Но пока сам несколько раз не попробуешь, ты не поймешь что и как именно тебе подходит.
Ну и не стоит забывать, что я не утверждаю, что ПП подходит всем.
Подробнее можно почитать можно тут, например
Как раз в следующий раз хотел написать про то как начать практиковать парное программирование. И как мы это делаем на удалёнке. Не претендую на глобальную истину, но поделиться как это делаем мы хотел.
Но и там не будет ответов, которые подойдут всем. Очень много зависит как от команды, так и от инструментов, которыми пользуется команда и которые разрешены в компании.
Ок, даже если не говорить про scrum и agile, мне кажется очень странно и не правильной практика, когда получает и декомпозирует задачу только "тимлид", и потом их спускает вам. Но это отдельная история.
Что касается применения парного программирования у вас. Я в статье попытался донести, что ПП не решение всех проблем. А инструмент, которым можно решать разные задачи. Который может быть полезен всем.
Про деление зп не совсем корректный вопрос. Не должно же быть желания просто утилизировать ресурс программиста только на написание кода. Шаринг знаний, обучение коллег, пбр — это тоже работа. И вот такая работа, по моей практики, лучше получается в паре, чем в одиночку.
Если вы берете Джуна «на вырост», что бы самим его обучить до нужного вам уровня, то у вас должна быть под это условная вакансия под мидла.
Если вы можете позволить только Джуна, то, наверное, не стоит удивляться, что они потом, когда набираются опыта, уходят на позицию выше, где им ее могут предложить?
Тут, на мой взгляд, другого не может быть.
Даже если у вас Мега крутая компания и люди, они рано или поздно уйду на позицию выше, если вы сами ее им не дадите.
Либо это что-то из прошлого. Либо что-то в конкретном твоем случаии.
Хочу в это верить :)
Может где-то такое и есть, но я не встречал.
У каждого свои причины. Кому-то нравится учить. Кто-то так развивает софт-скилы. У кого-то единственный способ усилить команду, это взять джуна (других не дают)
Не могу ответить за всех