Comments 11
Подождите, а сейчас точно 2024ый год, а не 2001ый?
Мне казалось, что от идеи парного программирования на постоянной основе ещё лет десять назад отказались, потому что оно только мешает.
Вон, Сэм Альтман практикует. (автор chatGPT).
Очень многое зависит от того как его практиковать. Из этой статьи ощущение складывается, что это должно быть постоянным режимом работы.
В принципе, все практики ХР — это не панацея, применять их следует, отталкиваясь от задачи и команды. Также необязательно всегда кодить в парах, но это хорошие профилактика замыливания взгляда и способ, когда нужно писать что-то нестандартное, например. Один прокладывает направление, держа код в голове «целиком», а второй реализует конкретный кусочек. А как вы считаете, как следует практиковать парное программирование?
Программисты работают в парах, обмениваясь опытом и контролируя качество кода.
Я считаю, что писать вот в таком ключе это некорректно - это звучит так будто бы так надо работать в постоянном режиме.
А в постоянном режиме это как раз снижает эффективность программиста, ну по сути дела один что-то пишет, другой смотрит, если так постоянно делать, то это утомляет, один из пары по сути не работает толком, плюс сидеть они должны за одним столом, через расшаренный экран это вообще неудобно делать долго, а значит прощай удаленка.
Парным программированием удобно проводить обучение, показывать какие-то фишки или штуки, ну или набрасывать примерный план для решения сложных вопросов, но это совершенно не подходит для каждодневного режима работы.
У меня другой опыт
Лучший код, который я написал в сжатые сроки был как раз в паре
И быстрее, и меньше багов в итоге, потому что почти все они отлавливаются ещё в момент написания, когда один сосредоточен на том, чтобы его генерировать, а второй следит за мыслью со стороны и сразу подмечает дичь
И удалёнка этому никак не мешает
Суть парного программирования в том, что в пару ставят быстрого чувака и медленного. Быстрый помогает медленному, за счёт чего медленный становится быстрее. Естественно, что быстрый при этом становится медленнее. Поэтому медленным разработчикам это нравится, а быстрым - нет. Если же смотреть со стороны и принять за единицу продуктивность медленного программиста, а продуктивность быстрого за 2, то при парном программировании получим продуктивность в 1.5. Если же посадить их работать отдельно, то скммарная продуктивность будет 1+2=3
Расписали достоинства, принципы, но забыли упомянуть, что такое это ваше экстремальное программирование, и чем оно отличается от обычного. В одном из пунктов вместо "экстремального" оно вдруг становится "парным", что наводит на мысли, что это одно и то же. Но это настолько неявно указано, что никак нельзя быть уверенным в этом.
..., что позволяет команде быстро адаптироваться к новым требованиям заказчика.
Попробую предположить, с чего бы это у заказчика появились т.н. "новые требования", т. е. по сути изменяется Техническое задание (далее-ТЗ):
==1 вариант: ПО разрабатывается по индивидуальному заказу, Требования Заказчика адекватны и вменяемы , НО ! ТЗ было составлено плохо, а это значит что виновны Бизнес-аналитики и/или Системные-аналитики на стороне компании-Заказчика и/или на стороне компании-разработчика ПО., а тогда, почему разработчики должны разгребать чужие косяки ?
==2 вариант: ПО разрабатывается по индивидуальному заказу, НО ! Требования Заказчика не совсем адекватны и вменяемы, и/или имеют очень узкую специфику. Как следствие, ТЗ просто не может быть адекватным или слишком сложно, и требует глубоких и специфичных знаний. Далее, на этапе разработки вылазят косяки ТЗ, и опять начинай сначала.
==3 вариант: ПО разрабатывается для широкого круга заказчиков, для некоей отрасли, исходя из сложившейся бизнес-практики, требований регуляторов, здравого смысла и уровня имеющегося программно-аппаратного обеспечения.
В этом случае - требования - весьма консервативны и медленно изменяются со временем,
Соответственно, необходимость перерабатывать ТЗ проистекает опять же от низкой компетенции и профессионализма Бизнес-аналитиков и/или Системных-аналитиков на стороне компании разработчика ПО.
================
Напрашивается вывод:
Agile нужен как способ замутить воду, пустить дымовую завесу, чтоб вывести из под ответственности некомпетентных "манагеров", Бизнес-аналитиков и/или Системных-аналитиков (последние -в меньшей мере) и переложить бремя ответственности и исправления ошибок на разработчиков.
Реальный выход, как мне видится - строгие нотации описания Бизнес-процессов, и ПО, превращающее эти описания в некий код (или псевдо-код), поддающийся профилированию, дебаггингу и визуализации узких и некорректных (на уровне бизнес-логики) мест.
Кручу-верчу, запутать хочу...
Когда клиент меняет требования в середине спринта...
О каком клиенте идёт речь?
1. о компании-заказчике ?
2. или о подразделении вашей компании, т. к компании-подрядчика, формирующей ТЗ ?
Что 1-е, что 2-е - это уже ЧП, и некое отклонение от нормы.
- если 1- пусть клиент заряжает дополнительное финансирование и сдвигает сроки.
- если 2- то кто нанял, кто утвердил некомпетентных сотрудников на ключевые должности ?
Представьте аналогию в дорогостоящем строительстве какого-нибудь высокозатратного и высоко технологичного производства: ошибка на стадии ТЗ (т.е. проекта) будет стоить ну очень дорого.
А почему здесь должно быть иначе ?
Ищете волшебную пилюлю, которую можно дать дебилу, и он - обана - всезнайка, и не нужно учиться 10 лет в школе, 5 лет в вузе, и еще 5-10 лет на производстве ?
Экстремальное программирование: полное руководство