Max Home IndustryЕсть некоторые новости из прошлого года, которые заслуживают второго шанса. Здесь у нас есть один такой — вы наверняка слышали о парном программировании, когда два программиста объединяются для работы над одной и той же проблемой. Теперь есть программирование толпы, которое представляет собой парное программирование, поднятое до власти любого количества людей, которых вы можете бросить на него. Но работает ли это?
(2019-07-29)
Многие руки заставляют свет работать (и я всегда думал, что это фотоны)-хорошо известная поговорка, но применима ли она к программированию? Парное программирование, вероятно, является первым этапом применения этой идеи. Два программиста, рассматривающие одну и ту же проблему и рассматривающие один и тот же код, который создается, по-видимому, имеют преимущества. Проблема в том, что, хотя некоторым программистам действительно нравится работать в парах, другие находят это угнетающим и осуждающим. Я думаю, что многое зависит от пары.
Программирование мобов относительно ново, но это такая же простая идея, как и парное программирование. Большая разница в том, что вся команда работает над одной и той же проблемой и одним и тем же кодом.
Новая исследовательская работа пытается выяснить, действительно ли это хороший способ кодирования:
«Термин» Моб-программирование » был впервые введен в сообществе экстремального программирования (XP) в 2003 году Мозесом Хохманом для описания их практики рефакторинга кода в группе из более чем двух человек. Этот термин в значительной степени погрузился в безвестность, пока Вуди Зуилл не начал популяризировать его снова с 2013 года. Именно тогда Вуди начал выступать на конференциях разработчиков о том, как его команда коммерческих разработчиков, состоящая примерно из 8 человек, «моббингует» полный рабочий день и какие успехи они наблюдают.»
В исследовании участвовала известная компания с примерно 50 командами разработчиков. Одна команда использовала моббинг в течение 2 лет в другой компании и 18 месяцев в текущей.
«Команда состоит из девяти членов, шести разработчиков и одного ведущего разработчика, одного Тестировщика и одного бизнес-аналитика (BA). Помимо одного нового выпускника, команда имеет большой опыт в гибких практиках и кодировании с опытом разработки в диапазоне от 4 до 18 лет. Когда команда была сформирована, ее члены были новичками друг для друга как команда»
Важно отметить, что команда уже занималась гибким программированием и, в частности, подходом Канбана. Они также использовали разработку, основанную на тестировании.
Но как вы на самом деле моб:
«Первоначально моббинг-сессии проходили в конференц-зале, отделенном от обычного рабочего места команды. Конкретный конференц-зал зависел от наличия свободных мест, но в каждом был большой монитор для использования в моббинге. Члены команды принесли свои собственные клавиатуры и один ноутбук для использования во время моббинга. Позже в специальной зоне рядом с обычным рабочим местом команды была установлена специальная моббинговая машина. В этой области был 60-дюймовый экран с центральным столом, за которым все сидели, а также некоторые перегородки, чтобы уменьшить окружающий шум»
Так что только одна машинистка и один экран для просмотра. Машинистку меняли каждые 10 минут.
Было ли это выгодно?
Этот подход привел к некоторым довольно очевидным изменениям в поведении команды. Во-первых, рабочие элементы, как правило, завершаются, прежде чем переходить к следующему. Команда получила совместное владение кодексом. Члены команды выработали общий подход к стилю кодирования и дизайну. Использование инструментов стало стандартизированным, и команда получила знание всей базы кода, потому что не было специалистов. Было много других более мелких достижений.
Недостатки этого подхода также можно рассматривать как долгосрочные преимущества. Например, производство кода было замедлено членами команды, которые не знали, в какой области кода ведется работа, но, конечно, доведение их до скорости-это инвестиции в будущее.
Похоже, что существуют обычные проблемы межличностных отношений и того, как лучше использовать разных людей. Также казалось трудным правильно настроить физическую установку.
«Размер команды моббинга, которая оказалась наиболее эффективной с командой кейса, был мобами из 3-4 человек. При формировании мобов размером более 4 часто люди в толпе саморазрушались, чувствуя, что они не вносят большого вклада. Компромисс между повышением качества и снижением темпов работы более крупных групп мобов часто считался не стоящим того, если только не разрабатывались сложные части кодовой базы.»
В целом вывод положительный:
«В целом программирование мобов в команде case было позитивным, стало обычным способом работы и показало многообещающие потенциальные долгосрочные выгоды. Предварительный онлайн — опрос 82 специалистов по программированию мобов по всему миру показывает общее соответствие опыту и восприятию кейс-команды.»
Однако ясно, что мы могли бы провести больше исследований по этой идее. Программирование комитетом может быть склонно к созданию верблюда, а не лошади, чтобы перевернуть хорошо известную поговорку. Текущее исследование было сосредоточено на том, как команда воспринимает свою работу, а не на какой-либо мере качества или скорости работы. Однако, похоже, стоит попробовать.