Продолжу пост, начатый здесь. Напомню, что я остановился на том, что недавно, а именно в февральском номере журнала IEEE Transactions on Software Engineering была опубликована статья Erik Arisholm, Hans Gallis, Tore Dyba и Dag I.K. Sjøberg посвящённая проведённому ими исследованию в области парного программирования.
Исследование Simula Research Laboratory
Данная работа отличается от всех вышеупомянутых исследований своей масштабностью, гораздо более тщательным и аккуратными утверждениями и большей продуманностью выводов. Кроме того, хотел бы обратить внимание, что 4-й эксперимент, упомянутый в предыдущем моем посте и данное исследование проводились практически одновременно - просто официальная публикация была в разное время. Поэтому данные можно считать взаимно дополняющими.
- В описываемом эксперименте принимало участие 295 Java-разработчиков - 98 пар и 99 соло программистов из различных европейских компаний (всего 29 компаний).
- Эксперимент состоял из двух фаз - первая фаза была проведена в 2001 году и в ней участвовали только соло-программисты.
- Вторая фаза состоялась в конце 2004 начале 2005 годов и в ней участвовали пары
- В данном эксперименте, в отличии от всех предыдущих, участники не должны были выполнить некоторую программистскую задачу с нуля. Все задания (кроме тренировочного) состояли в том, что необходимо было внести некоторое изменение в уже существующую программу.
- Задания:
- Тренировочное задание: сначала каждому участнику была выдана простое задание : прочесть цифры с клавиатуры и вывести их в порядке обратном порядку ввода. Данное задане все участники выполняли для того чтобы ознакомиться с окружением и правилами эксперимента
- Индивидуальное тестовое задание: каждый из участников должен был внести изменение в программу. Все участники должны были внести одно и тоже изменение в одну и ту же программу. В рассматриваемой программе было 7 классов и 354 строки кода. Необходимо было добавить лог а также возможность распечакти баланса банковского счета. Данная программа не была похожа на программы, использовавшиеся во время самого эксперимента. Тестовое задание использовалось для того, чтобы сравнить относительные уровни программистов, участвующих в тестах.
- Основные задания эксперимента (4 задания):Основные задания были основаны на программе управления кофе-машиной. При этом существовало два вида такой программы, с одной и той же исходной функциональностью. Одна из программ была устроена более сложно и состояла из 12 классов. Другая программа была устроена проще и состояла из 7 классов. Для каждой из программ существовали UML описания сценариев работы, для того чтобы можно было лучше понять архитектуру программ. Сами задания состояли в добавлении следующих новых возможностей в программу управления кофе-машиной:
- Реализации кнопки: возврат монеты
- Добавление нового вида напитка (бульон)
- Проверка того, имеются ли в наличии все ингредиенты для выбранного вида напитка
- Добавление возможности содания своего собственного напитка, при помощи разрешения пользователю выбора из всех доступных ингредиентов.
- Синхронизационное задание: последнее предлагаемое участникам задание имело специальную цель. Результаты его выполнения не учитывались, но участники об этом не знали. Таким образом им приходилось работать над всеми реальными заданиями со всей возможной скоростью.
- Обстановка эксперимента:
- Сам эксперимент проводился в течение 27 дней - 10 дней для соло-программистов и 17 дней для пар
- Все происходило в собственных офисах разработчиков или в офисах Simula Research Laboratory.
- Всем участникам был предоставлен доступ в интернет, книги и так далее
- Каждый участник мог также пользльваться любым средством разработки по желанию: Eclipse, IntekkiJ Idea, JBuilder, NetBeans - чем угодно.
- Все это было сделано для того, чтобы максимально приблизить условия эксперимента к реальным, в которых консультанта нанимает компания-клиент, для того чтобы произвести некоторое изменение в программе.
- Для того, чтобы более точно учитывать потраченное время, перерывы разрешалось делать только между заданиями, но не во время выполнения одного задания.
- Что оценивалось:
- Длительность - время (в минутах), потраченное на то, чтобы справиться с основными заданиями эксперимента
- "Цена" - человеко-минуты ( ну то есть попросту говоря зарплата), потребовавшиеся на задания. Для пар цена представляла собой длительность, умноженную на 2
- Правильность - 1, если все 4 задания были сделаны верно и 0, в противном случае. Решения проверялись двумя независимыми экспертами, а также специальными тестами, которые сравнивали результат выполнения программ с заранее изаготовленным правильным результатом.
- Факторы, влияющие на результат (факторы, которые рассматривались исследователями при анализе)
- Парное или соло программирование
- Сложность системы - некоторым программистам выдавалась программа написанная более "сложно", а некоторым "менее сложно"
- Уровень программистов - Junior, Intermediate, Senior
- Проверяемые гипотезы
Изначально экспериментаторы поставили цель проверить следующие гипотезы (замечу, что каждая из гипотез - это некотрое предположение о том как один из факторов влияет на одну из оценок - то есть количество гипотез = кол-во факторов*кол-во оценок = 9): - H01 - влияние парного программирования на длительность: парам и соло требуется одинаковое время для выполнения заданий
- H02 - влияние сложности системы на длительность: разница во времени, нужном для выполнения заданий парам и соло не зависит от сложности системы
- H03 - влияние опытности программистов на длительность: разница во времени, нужном для выполнения заданий парам и соло не зависит от опытности программистов
- H04 - влияние парного программирования на "цену": цена одинакова для пар и для соло
- H05 -влияние сложности системы на "цену": Разница в цене между парами и соло, не зависит от сложности системы
- H06 -влияние опытности программистов на "цену": Разница в цене между парами и соло не зависит от опытности программистов
- H07 -влияние парного программирования на правильность: Правильность одинакова для пар и соло
- H08 -влияние сложности системы на правильность: Разница в правильности между парами и соло не зависит от сложности системы
- H09 -влияние опытности программистов на правильность: Разница в правильности между парами и соло не зависит от опытности программистов.
- Результаты
Подробные результаты в процентах, а также допущения и статистические погрешности эксперимента можно увидеть в статье авторов. Я же здесь приведу лишь сами выводы.
- H05 - не достоверна
- H06 - достоверна
- H08 - не достоверна
- H09 - достоверна
- Выводы
- Основной вывод, который делают авторы состоит в том, что на соновании их эксперимента можно считать, что junior-программистов, при работе со сложными системами выгоднее объединять в пары. При этом можно добиться существенного увеличения качества результатов. Этот вывод, кстати близок к выводам авторов четвёртого исследования из моего предыдущего поста, о том что парное программирование лучше работает в, так сказать, "неизведанных" областях.
Вообще, хочу сказать, что исследование проведено очень аккуратно и вдумчиво. Экспериментаторы вполне отдавали себе отчёт в том, каких аспектов они не рассмотрели и почему (например практически никто из участников раньше на занимался парным программированием, из-за чего эффективность пар могла быть не такая высокая).
ОбсуждениеКонечно эффекты парного программирования пока что изучены мягко говоря не очень хорошо. Все исследователи, о которых я тут писал, сделали только первые шаги, с чем они и сами согласны.
На самом деле, я даже больше скажу. Мне кажется что исследованиями, возможно, занимаются специалисты не совсем в правильной области. Не специалисты по компьютерам должны изучать парное программирование и другие подобные вещи, а специалисты по людям. Психологи, или может быть социологи. С этим согласны и сами экспериментаторы (Erik Asholm et al. об этом прямо говорят в конце статьи). Ведь парное программирование - это гораздо больше взаимоотношения между людьми, чем программирование.
Собственный опытУ меня есть и собственный опыт парного программирования, о котором хотелось бы кратко рассказать. Мне приходилось программировать в парах с несколькими людьми и на разных уровнях собственного "развития". То есть я ощущал себя в парах и "новичком", который сидит рядом с "гуру" и "гуру" который сидит рядом с новичком. Было и программирование в парах с равными. Какие впечатления?
- Знание распространяется существенно лучше и больше людей знают о том что и как внутри работает. Это на мой взгляд очень важный и очень положительный эффект. Меньше становится мест, про которые знает только один человек в команде. Знаете есть такой тест для менеджеров - сколько человек в команде должно уволиться, чтобы проект провалился?( ну то есть чтобы он страшно опоздал или вообще оказался незавершенным). В плохой ситуации количество людей - 1. В случае парного программирования - как минимум два, для тех кусков кода которые "участвовали" в парном програмировании.
- Для меня-"новичка" парное программирование дало очень много - это совсем неплохой способ обучения, очень быстрый. Приятно чему-то научиться :-)
- Для меня-"гуру", то есть в тот момент когда рядом был менее опытный в данном вопросе программист - это отличный как нынче модно говорить "мотиватор". Приятно короче говоря кого-то чему-то научить :-)
- Качество кода: по моему опыту качество кода при парном программировании возрастает. Особенно с точек зрения "понятности" и поддерживаемости".
- Скорость написания - непонятно. Сильно зависит от того над чем работаешь.
- Недостатки - как легко догадаться большинство недостатков связаны с "человеческими" сторонами парного программирования:
- я-"новичок": чувство "какой-же я идиот" вполне может отравить жизнь - у меня такое бывало, особенно, когда рядом сидит настоящий мастер
- я-"гуру": чувство "какой-же он идиот, нет смысла на него тратить время" тоже далеко не самое приятное
- в программировании, как и во многих других делах, по завершении какой-то работы возникает чрезвычайно приятное чувство свершения - того что ты чего то добился, и добился этого лично ты. При парном программировании у меня это чувство иногда пропадало, "смазывалось", что-ли.
- Общий вывод: в целом мой опыт парного программирования положительный. Ну просто попадались очень хорошие "пары" и это конечно их заслуга.
blog: 
LinkedIn
Мой Круг
