Командно-ориентированная разработка

Командно-ориентированная разработка (КОР) - это термин, который мы придумали для описания гибкой разработки внутри команды. Экспериментируя в нашей команде, мы обнаружили, что нет необходимости искусственно разделять наш подход на «парное программирование», «программирование моба», «параллельное программирование» и «работа с одним бойцом». В течение дня мы меняем методы, как того требует ситуация. КОР описывает этот подход гибкости и непрерывного экспериментирования, не ограничиваясь категоризацией или искусственными барьерами одного метода, а скорее находя наилучший способ продвижения вперед как группа с целью производства наилучшего программного обеспечения, в то же время предоставляя максимально полезный опыт для каждого.

Мы обнаружили, что командно-ориентированная разработка - это идеальная техника для обмена знаниями в команде, улучшения навыков разработчиков, повышения сплоченности и веселья команды. В этой статье мы дадим вам более подробную информацию о КОР и поделимся своим опытом с КОР во время реальных проектов.

Парное программирование - хороший способ начать

Сосредоточение внимания на методах программирования, в которых участвуют два или более человек, помогло нам разумно распространить наши знания во всей команде. Способ, который также является забавным.

Парное программирование - хороший способ начать. Два программиста решают проблему вместе, обсуждают ее, делятся идеями и т. Д. Это также хороший способ привести кого-то в курс дела после отпуска или болезни, не замедляя работу остальной команды.

В различных исследованиях сообщается, что парное программирование дает более высокое качество кода по сравнению с программированием, выполняемым отдельными лицами (которое мы называем «один боец»). Как только вы начнете отказываться от метода "одного бойца", вы заметите разницу. Как положительный побочный эффект, вы начинаете увеличивать фактор автобуса и «We feeling» внутри команды.

Недостаток парного программирования содержится в слове «пара». В этом методе участвуют только два программиста, что ограничивает обмен знаниями. Два программиста участвовали в накоплении знаний, которых не хватает остальной команде. Тем временем остальная часть команды накапливает знания, которые два программиста парной сессии могут пропустить в конце. Парное программирование - отличная техника, но мы обнаружили, что для больших групп другие методы в рамках TOD более эффективны для достижения ваших целей.

Моб-программирование - увеличьте "фактор автобуса" вашей команды

Моб-программирование - это весело, и это отличный способ распространять знания во всей команде. Моб-программирование означает, что команда разработчиков (3-6 человек идеально) используют один компьютер для выполнения одной задачи. Одной из групп является «интеллектуальное устройство ввода», в то время как другие отвечают за навигацию по клавиатуре.

Роль водителя часто меняется, например, каждые 7 минут. Здесь вы должны поэкспериментировать со своей командой, чтобы найти предпочитаемую длину смены. Вам также следует попробовать разные шаблоны драйвера-навигатора. Все это поможет вам распространить знания во всей команде, что положительно скажется на автобусном факторе вашей команды. Фактор автобуса, скажем, означает состояние здоровья вашей команды. Он оценивает, сколько членов команды должно быть сбито автобусом, чтобы команда попала в беду из-за утраченных знаний / навыков.

Эффективное программирование мобов требует навыков, накопленных со временем. Он не будет работать идеально в первый или даже 10-й день. 

Параллельное программирование - прорыв к победе

Строго говоря, моб-программирования и парное программирование позволяют печатать одновременно только одному экрану и одному человеку. Любой, кто работал с ними, согласится с тем, что существуют ситуации, в которых это может быть разочаровывающим и ограничивающим. Есть искусство придерживаться этого достаточно долго, чтобы позволить этому разочарованию заставить вас учиться, но знать, когда действительно настало время расстаться и работать параллельно.

Когда мы дошли до того, что было трудно найти хорошее решение для проблемы, и почти у всех в мобе была идея, как ее решить, мы остановили сеанс программирования мобов и сделали то, что мы называем «параллельное программирование». Каждый пытался решить проблему на своем компьютере, оставаясь в сети во время видеоконференции. Каждому было позволено говорить, и он мог спрашивать друг друга или говорить о способах решения проблемы.

Традиционное моб-программирование разочаровывает в этой ситуации, потому что один человек хочет прочитать документацию, другой хочет попробовать изменить какой-то код или запустить команду, а еще один человек хочет найти ответ в Интернете. А чтение текста на чужом экране само по себе является проблемой, с неожиданной прокруткой и т. д.

Одним из преимуществ моб-программирования является цельный поток - идея, что одновременно обрабатывается только один элемент. Ценность этой концепции поддерживается бережливым производством. Прелесть параллельного программирования в том, что вы поддерживаете единый поток. Все программисты все еще работают над одной и той же задачей. Но параллельная работа дает им свободу смотреть в нужном направлении. Примером этого является исправление ошибок. Когда ошибка, наконец, найдена, человек, который ее обнаружил, объясняет проблему другим. Другие сразу понимают объяснение, потому что они тоже были заняты этой проблемой и контекстом.

Нам было полезно установить временную рамку (около 20 минут). После того, как таймер закончился, мы собрались вместе, чтобы поделиться своими индивидуальными исследованиями и решить, нужно ли нам больше времени (настроить другой таймбокс), или нам нужно присоединиться к сеансу моб-программирования и попробовать одно из найденных решений. Мы также сочли целесообразным устанавливать временные рамки во время программирования мобов и других экспериментов, что сохраняет некоторую дисциплину.

Применение этих методов на практике

В одном из наших последних проектов мы начали с моб-программирования. Через некоторое время нас обескуражили поставленные задачи, и мы перешли на парное и сольное программирование. Но мы продолжали пробовать моб-программирование. В конце концов, мы достигли определенного уровня в моб-программировании и ощутили преимущества. Мы пришли к пониманию, что мы хотим работать как можно больше как одна команда, и что мы должны использовать моб-программирование в качестве основного метода разработки программного обеспечения. Мы очень хотели уменьшить количество задач одного бойца настолько, насколько мы могли бы в нашем повседневном бизнесе. Но это зависело от работы или задачи. Когда это соответствует текущей задаче, работа отдельного бойца имеет смысл. Мы просто стремились свести ее к разумному минимуму.

Одним из недостатков строгого сопряжения и моббинга является необходимость синхронизации рабочего времени. Это несет определенные социальные издержки. Мы нашли, что это лучшая модель, позволяющая всем работать, когда они хотят, свободно привязанные к стандартным 9-5 рабочим часам. Это то, к чему большинство программистов уже привыкли. Если кто-то естественным образом прибывает в офис на 30 минут раньше, чем другие, ему следует выбрать работу, которая лучше всего подходит для сольного программирования. Команды могут ставить соответствующие задачи в список дел, готовых к таким моментам. По мере того, как другие разработчики приходят на работу, он может перейти в парное программирование или моб-программирование и т. д.

Как показывает диаграмма, мы использовали моб-программирование в качестве основного метода. Поскольку мы обнаружили большие преимущества параллельного программирования, мы использовали его чаще, чем парное программирование. Но мы обнаружили эту технику только в более позднем состоянии проекта, что объясняет меньшую полоску на графике.

Найдите путь для вашей команды

Описанный выше процесс обучения команды занял время. Ваша команда должна найти свой оптимальный путь.

Возможно, ваша команда обнаружит, что это наиболее удобно и эффективно при работе в основном с парным программированием. Пока команда счастлива и достигает своих целей, это нормально. В этом суть КОР: команда, свободно экспериментирующая и находящая лучший для них подход вместе. И все же, мышление непрерывного совершенствования означает, что мы действительно только открываем «лучший подход на сегодняшний день». Мы продолжаем испытывать себя, собираем идеи и пробуем новые эксперименты для дальнейшего улучшения.

Командно-ориентированное развитие зависит от команды. Ваша команда может найти идеальный путь, но когда вы, как отдельное лицо, присоединяетесь к новой команде, вы должны быть готовы скорректировать, перезапустить процесс и принять уроки и результаты этого сценария.

Командно-ориентированное развитие укрепляет вашу команду

При внедрении ориентированной на команду разработки мы заметили, что атмосфера «We feeling» и «feel good» возрастают со дня на день. Мы выросли вместе в сильную команду, где каждый член команды был высоко мотивирован и отдавал всю свою энергию. Также мы осознали, что создали нечто вроде безопасного пространства для знаний. У каждого был свой опыт и он мог помочь с разными вещами. И все были готовы учиться. Поэтому никто не побоялся сказать что-то вроде: «Я этого не понял. Не могли бы вы объяснить это мне снова? ».

Все это звучит хорошо для вас? Тогда почему бы не попробовать свой первый небольшой эксперимент сегодня? Сделайте командную работу снова великолепной.

Ссылка на оригинал.