У программистов есть такая практика как "парное программирование". Сейчас я попытаюсь разложить на роли, ролевые интересы и системы в которых это происходит.
Первое что я хочу выделить это продукт, который получается в парном программировании:
1. Это более качественный продукт, чем если бы над решением задачи работал только один программист.
2. Распределение знаний об проекте. За счет работы в паре, знание распределены между многими и нету зависимости от одного разработчика, так как он может на себе нести очень много знаний о проекте.
3. Так как ревью кода происходит в момент его написания, не требуется ждать пока еще кто проверит код, а значит это кусок кода можно сразу пропускать на следующий этап разработки. (деплой или отправка к тестировщикам)
Для этой практики необходимо два разработчика, которым необходимо вступить в роли: драйвера и навигатора.В роли драйвера, разработчик отвечает за то что бы результат размышлений пары выводился на экран монитора, за счет контроля клавиатуры.А роль навигатора отвечает за постоянную проверку того что напечатано и помощь в контроле мыслительного процесса пары.
Оба заинтересованы в успешном завершении задачи,а значит оба находятся в роли дипломатов, что бы приходить к соглашению о том какое решение является верным. Поэтому личные вкусы отходят на задний план, и мастерство собранности необходимо включать на полную.
Невозможно, что бы два программиста были на одном уровне знания, поэтому всегда кто-то будет чуточку умнее на данную тему. Поэтому, точно одни из них выступает в роли ученика, соответственно, второй одевает еще и шляпу наставника(учителя). Получается что продукт парного программирования или побочный продукт (интересно есть ли такое понятие). Повышение прикладного мастерства команды.
Станислав, интересная практика! Для роли менеджера такой подход может влечь удвоение затрат. Ты не сталкивался с аналитикой - окупается ли задвоение? Понимаю, что некоторые неосязаемые вещи типа взаимного обучения или распределенного знания сложно оценить. Но возможно, они пишут быстрее, без необходимости возврата и переписывания?
Привет Тихон!
Твой вопрос одни из мифов с которыми приходиться разъясняться. Согласен, что со стороны кажется по отдельности они бы могли в два раза больше сделать. Но если разобраться:
- Если ты работаешь одни, то чаще всего в командах есть процесс код ревью. Ты должен попросить кого-то из команды отвлечься и проверить твой код. Во время парного прогрмирования это проичходит естественным способом и когда решение готово, его сразу можно дальше пропускать. Идет экономия времени.
- Так же когда работаешь один не возможно использовать брейншторм как инструмент для поиска решения проблемы. Когдва вдоем можно это использовать и бытсрее найдется решение, а значит еще время с экономиться.
- Еще парное программирование это лучший "экзокортекс" для входа в роль программиста. Когда одни ты намного быстрее отвлечешься, так как не у всех достаточно развито мастерство собранности. Про работе в паре идет полное уделение внимание (если практика парного знакома для программистов) на работу.
Так что с первого взляда кажется не очень выгодным эта практика, но даже на короткой дистанции идет выгода для команды разработчиков и их менеджеров.
Станислав, спасибо за описание практики!
Описание рабочего продукта можно уточнить: например, в первом пункте утверждается, что “продукт более качественный”, но сам продукт так и не назван) лучше уточнить, например, рабочий продукт – кусок кода, который выливается в прод на х часов/дней быстрее, содержит на n ошибок меньше / иные критерии качества. Но сначала – название самого рабочего продукта, потом – критерии качества (почему по итогам применения этой практики он лучше). Собственно, это косвенно указано в пункте 3 – но мы на протяжении всего курса будем учиться назвать объекты прямо, не косвенно (именно это делает системное мышление мощным).
Помимо куска кода, рабочим продуктом может быть и “прикладное мастерство разработчика”, и “функциональный кусок мозга, обладающий прикладным знанием о проекте” (либо “разработчик со знаниями о проекте” как ресурс, который операционный менеджер может подключить на проект – рассмотрение может слегка меняться в зависимости от роли). Называть какой-то рабочий продукт “побочным” вполне можно, если его получение не было основной целью выполнения практики)
Я бы предложила больше рассказать о самой практике, те алгоритме действий. И еще уточнить названия ролей: например, по названию ролей “драйвера” и “навигатора” функции не очень понятны. Роль “дипломата” можно переназвать ролью “коммуникатора” или “объяснятеля / доносителя информации”.