Стратегии формирования команды разработчиков ПО: от идеи к эффективному сотрудничеству

О книге

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

Почетное место в литературе жанра программирование отведено книге «Время — деньги. Создание команды разработчиков программного обеспечения» Салливан Эд. Рассматривая в своей работе актуальные вопросы современности, автор целиком и полностью погружает нас в мир главных героев. Увлекательный сюжет, реалистичное описание обстановки и детально проработанные персонажи произведения определенно произведут на Вас впечатление.

Усиливающая важность Гибких методологий в комплексе создания программного обеспечения

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

Все больше команд используют Agile-практики не только для улучшения качества и скорости разработки, но и для повышения мотивации и удовлетворенности клиента конечными продуктами.

Ключевые принципы работы по Agile-методологиям

Работая по гибким методологиям, команда разработчиков концентрируется на нескольких ключевых принципах. Во-первых, главное — это люди и взаимодействие, а не процессы и инструменты. Уровень вовлеченности участников в проект обычно выше, чем у тех, кто работает по традиционным методологиям. Второе, работающий программный продукт важнее подробной документации: клиенту важен конечный результат, а не сколько бумаг описывают процесс его создания. Постоянное сотрудничество с заказчиком и гибкость к изменениям также являются неотъемлемыми составляющими гибкой методологии.

• Люди и взаимодействие более важны, чем процессы и инструменты
• Работающий продукт — это то, что действительно имеет значение
• Конструктивное взаимодействие с клиентом важнее множества контрактов на подряд
• Готовность к изменениям важнее следования первоначальному плану

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

Число Данбара. Природные ориентиры

Частый вопрос от групп разработчиков: «Насколько большой должна быть команда?» Работа антрополога Робина Данбара дает интересные идеи при попытке ответить на вопрос.

Автор предоставляет убедительные доводы, что 150 является верхним пределом для организациилюдей. Данбар заметил указанное число в воинских формированиях со времён Древнего Рима, в неолитических поселениях, в общинах амишей и в современных научно-исследовательских группах.

Сообщества свыше 150 членов менее сплочённые, требующие повышенного контроля поведения и иерархии. В исследованиях и анализе подчёркиваются основные моменты в формировании групп. Параметр грамотнее назвать «Числами Данбара». Характеристики применимы к различным группам, входящим в состав крупных формирований. Меньшие команды крепче и по предположению опираются на числа с множителем 3. Следуя тезису, у большинства людей круг близких друзей от 3 до 5 человек. Следующий уровень приятелей от 10 человек до 13–15 (при определенных усилиях). Очередная группа содержит от 30 до 50 — типичный боевой взвод. Популяция в 150 представляет минимальный независимый блок в военной компании и точку создания на предприятиях отдельных группировок.

Данбар предполагает существование формирования в 500 и 1500. Автор поддерживает Платона в определении идеального размера для демократии в 5300 единиц. Можно провести интересные параллели между размерами военных блоков.

Oрганизация	Размер
Пожарная дружина	4 или меньше человек
Секция/Отряд	8–12 участников (несколько пожарных дружин)
Взвод	15–30 служащих (2 отряда)
Рота	80–250 солдат (несколько взводов)
Батальон	300–800 бойцов

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

Модели программирования

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

Модель водопада

Модель водопада, отмеченная как более традиционный подход, представляет собой линейную модель производства. Последовательность событий этой методологии следующая:

1. Сбор и документирование требований
2. Дизайн
3. Код и модульное тестирование
4. Выполнение тестирования системы
5. Выполнение пользовательское приемочное тестирование (UAT)
6. Устранение любых проблем
7. Доставка готового продукта

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

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

Agile Model

Модель Agile-разработки — это более командный подход к разработке, чем предыдущая модель водопада. Команды работают в режиме быстрой доставки / развертывания, который разбивает работу на этапы, называемые «спринтами». Спринты обычно определяются как две недели запланированных программных продуктов, предоставляемых каждой команде / члену команды.

После каждого спринта приоритеты работы меняются, и информация, полученная в предыдущем спринте, используется для будущего планирования спринта. Когда работа над спринтом завершена, она может быть просмотрена и оценена командой программистов и отправлена ​​обратно для другой итерации (например, следующего спринта) или закрыта, если завершена.

Общие принципы Agile Manifesto заключаются в следующем:

Удовлетворять клиента и непрерывно разрабатывать программное обеспечение.
Изменяющиеся требования принимаются ради конкурентного преимущества клиента.
Сосредоточьтесь на частой доставке работающего программного обеспечения. Предпочтение в доставке будет отдано как можно более короткому промежутку времени.
Разработчики и деловые люди должны работать вместе на протяжении всего проекта.
В основе проектов должны лежать люди, которые мотивированы. Обеспечьте им подходящую среду и поддержку, в которой они нуждаются. Им следует доверять в выполнении их работы.
Личное общение — лучший способ передачи информации в команду и из нее.
Работающее программное обеспечение является основным показателем прогресса.
Гибкие процессы будут способствовать устойчивому развитию

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

Мастерство совместного создания программного обеспечения

Важность этого искусства определяется несколькими основными факторами. Прежде всего, это ускорение процесса разработки, так как совместная работа позволяет выполнить задание быстрее, чем одному

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

Ключевые аспекты мастерства совместной разработки

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

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

1. Распределение обязанностей. Четкое определение задач и ответственностей позволяет оптимизировать работу коллектива.
2. Контроль выполнения задач. Регулярный мониторинг помогает вовремя обнаруживать и исправлять проблемы, своевременно вносить коррективы.

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

Немаловажно также сохранение положительной рабочей атмосферы и умение грамотно разрешать возникающие конфликты

Магическая семерка Миллера (кошелёк Миллера)

Принято считать мудрым выбором размер команды из 7 человек (± 2). Практического смысла в утверждении нет. Доказательства тезиса об оптимальном количестве членов команды в 5–9 человек отсутствуют.

Сторонники размера апеллируют к знаменитой статье Миллера 1956 года «Магическое число семь плюс минус два: некоторые ограничения нашей способности обработки информации». На практике большинство ссылающихся труд не читали.

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

Значимость магии числа 7 под вопросом.

В заключении автор говорит: «Я чувствую, что мой рассказ здесь должен остановиться, т. к. он уже стал достаточно интересным». С публикации статьи Миллера прошло более 50 лет. По общему мнению, диапазон команды 5–9 человек удовлетворителен для управления изменениями. Снизу интервала оправдана необходимость проведения тестов и выполнение требований к команде специалистов. На верхней границе диапазона сложно осуществлять полный контроль системы. Поэтому число сотрудников от 5 до 9 человек имеет смысл.

Описанное количество не отменяет существование команд большего размера в зависимости от обстоятельств.

Роль командной работы в разработке ПО: основные моменты и преимущества

Основными моментами командной работы в разработке ПО являются:

1. Разделение задач и ролей. Каждый член команды имеет свои обязанности и ответственность, что способствует повышению эффективности работы и распределению нагрузки.
2. Взаимодействие и коммуникация. Члены команды должны постоянно общаться друг с другом, обмениваться информацией и координировать свои действия для достижения общей цели. Эффективное взаимодействие способствует повышению производительности и качества проекта.
3. Взаимная помощь и поддержка. Команда разработчиков должна быть сплоченной и готовой помогать друг другу при возникновении трудностей или проблем в процессе работы. Поддержка команды способствует решению сложных задач и достижению лучших результатов.
4. Управление конфликтами. В процессе командной работы могут возникать конфликты и разногласия между участниками. Умение правильно управлять конфликтами и находить компромиссы поможет сохранить эффективность командной работы и достичь взаимопонимания.
5. Постоянное обучение и саморазвитие. Все члены команды должны постоянно совершенствовать свои навыки и знания в своей области, чтобы быть готовыми к решению новых задач и использованию новых технологий.

Командная работа имеет ряд преимуществ, которые способствуют успешной разработке ПО:

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

Таким образом, командная работа играет важную роль в разработке ПО, обеспечивая эффективность, качество и инновации в проекте.

Закон Паркинсона и Закон Хофштадтера

Попробуем ответить на вопрос: «Помните ли вы обучение в ВУЗе? В какой момент реализовывались задания?» Большинство читателей выполняли работу за несколько дней до дедлайна. Часть занималась проектом в ночь перед сдачей.

И подавляющее большинство укладывалось в срок.

Ученые подтверждают: люди плохо справляются с оценкой периода, требующегося на выполнение работы, но преуспевают с решением задачи к четко оговоренной дате (например, Buehler, Гриффин и Peetz, 2010).

При избытке времени на проект происходит чрезмерное расширение объема работ исполнителем.

На разработку программного обеспечения влияют законы Паркинсона и Хофштадтера. Выбирая дату дедлайна, неизбежно возникнет недооценка требуемого времени. В итоге сроки и объем работ увеличатся. Проведенное исследование (Бюлер, Гриффин и Питз, 2010) свидетельствует: оптимизм относительно даты выполнения задачи дает возможность осуществить работу раньше, чем при пессимистичной оценке сроков. Но общее время выполнения проекта оптимистом окажется дольше, чем у пессимиста. Срок дедлайна может быть важнее предполагаемого времени завершения проекта (Арили и Wertenbroch, 2002).

FAQ: Командная разработка по

Какие методологии существуют для управления командной разработкой ПО?

Существует несколько методологий, используемых для управления процессом командной разработки ПО. Некоторые из наиболее популярных включают гибкую (Agile), водопадную (Waterfall), постоянный интегральный подход (Continuous Integration), спринт (Scrum) и экстремальное программирование (Extreme Programming). Эти методологии имеют свои сильные стороны и слабые стороны, и лучший выбор зависит от специфики конкретного проекта и команды разработки.

Какое значение имеет коммуникация в командной разработке ПО?

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

Что такое системы контроля версий и зачем они нужны в командной разработке ПО?

Система контроля версий — это инструмент, используемый программистами для отслеживания изменений в коде и возвращения к более ранним версиям при необходимости. Она также упрощает совместную работу, позволяет команде работать над одним проектом одновременно и устраняет конфликты в коде. Git — наиболее популярная система контроля версий, широко используемая в мире разработки ПО.

Какие основные этапы включает в себя управление процессом командной разработки ПО?

Управление процессом командной разработки ПО включает в себя несколько ключевых этапов, таких как планирование, организация команды, координация задач, контроль за ходом выполнения, а также анализ и внесение коррективов в процесс разработки.

Какие стратегии можно использовать для контроля эффективности командной разработки ПО?

Для контроля эффективности командной разработки ПО можно использовать метрики производительности, такие как количество сделанных коммитов, количество исправленных ошибок, время выполнения задач и трекинг проекта. Также применяются методологии Agile и Scrum, позволяющие управлять проектами гибко и учесть непредвиденные ситуации.

Какие роли могут быть у участников команды при разработке ПО?

В команде разработки ПО могут быть следующие роли: проектный менеджер, который координирует процесс работы над проектом; программисты, выполняющие кодирование; тестировщики, проверяющие работу ПО; аналитики и системные архитекторы, разрабатывающие модель системы; дизайнеры и специалисты по UI/UX, ответственные за визуальную часть продукта и его удобство использования.

Как при помощи методологий Agile и Scrum можно повысить эффективность командной разработки?

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

Как регулярно стоит проводить анализ работы команды в процессе разработки ПО?

Анализ работы команды желательно проводить по окончании каждого этапа разработки (итераций, спринтов). Это позволяет своевременно выявлять проблемы, принимать корректирующие меры и повышать эффективность работы команды.

Закон Брукса

Ни одно обсуждение команд разработчиков не проходит без упоминания данного принципа:

Бесчисленные команды разработчиков подтвердили постулат. Законы Брукса и Конвея составляют базу.

Присоединяя нового человека, команда тратит усилия на введение в курс дела, на объяснение используемых трюков и устройства. Участники расходуют время на информирование и синхронизацию с новобранцем, на обучение труду в команде и передачу знаний. Работа замедляется.

Свежий персонал нуждается в помощи не только в первую неделю. Часть авторов (например, Коплиен и Харрисон) предполагают годичный интервал до получения от новичка продуктивности. Не стоит придавать утверждению излишнего значения из-за влияния разных факторов. Разумно предположить, что часть сотрудников обойдется без помощи в первые три месяца.

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

Резюме следует обдумать и написать либо отказ, либо вызов на собеседование. В случае одобрения кандидата составляется контракт и отправляется предложение о приеме в команду.

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

Закон Брукса не означает полный отказ от расширения команд. Но рост объединения редко происходит быстро. Если команда решила расширяться, будет использоваться часть производительности для наращивания мощности.

Ричард Шеридан сделал смелое заявление:

В книге автор преподносит среду разработки ПО отличную от реальной для большинства разработчиков и менеджеров. Корпорация Menlo не скупится в вопросах построения, участия и укрепления собственной культуры и сообщества. Пока компании не опробуют подход на практике, не возникнет достаточное количество примеров для изучения, трудно сказать, стоит ли копировать образцы Шеридана.

Методы, описанные автором, заслуживают доверия. Отлично, если закон Брукса будет нарушен.

Закон Голла. Парнас и Александер

Закон перекликается со словами Дэвида Парнаса:

«Как правило, системы ПО не работают хорошо, пока они не были использованы, и не раз, в «боевых» условиях».

Авторы подчеркивают различные аспекты одного явления, называемого Кристофером Александером «органическим ростом».

При создании ПО, применяя технику под названием «ходячий скелет», рекомендуется сделать простой, базовый рабочий кусок кода. «Скелет», хоть и с определенным риском, но проталкивающий систему вперед. Создав базу, команда добавляет «плоть» — слой функционала.

Принцип может применяться к группам, к ПО:

«Эффективная сложная команда неизменно возникает из простого продуктивного аналога. Сложная команда, собранная с нуля, результативно функционировать не может. И никакие изменения не заставят ее работать. Дело стоит начинать с уже сработавшейся командой».

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

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

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

Размер команды в методологии Scrum

Как статья Миллера об объемах обработки информации человеческим мозгом может применяться к определению размера команды разработчиков ПО? Обратимся к методологии Scrum. В учебнике говорится: «Команда в Scrum должна быть семь плюс или минус два человека» (Димер и др., 2008). Одновременно в руководстве по Scrum за 2011 утверждается: «Команды из более девяти членов вызывают слишком много проблем в координации. Большие команды разработчиков заметно усложняют весь процесс» (Сазерленд и Швабер, 2013).

Учебное пособие гласит:

Параллельно введение руководителя команды Scrum предполагает, что владелец продукта находится вне команды.

Другие источники дают различные рекомендации по определению членов группы и «просто участвующих».

Команды в диапазоне 4–8 человек видны повсеместно. Статьей Миллера рационально обосновать выбор размеров групп из 7 ± 2. Опыт подтверждает оптимальный предел численности. Количество может быть больше заявленного в источниках по Scrum.

С этой книгой читают

Создание Web-страниц: HTML, CSS, JavaScriptМархвида И. В.

Книга посвящена основным технологиям написания Web-страниц: языку гипертекстовой разметки HTML, применению каскадных таблиц стилей CSS, а также созданию сценариев на…

Python: создание приложенийБиблиотека профессионала, 3-е изданиеЧан Уэсли

Вы уже знаете язык Python, но хотите узнать больше? Намного больше? Погрузитесь в разнообразие тем, связанных с реальными приложениями. Книга охватывает регулярные…

1
 (1)

Мифический человеко-месяц или как создаются программные системыБрукс Фредерик

Эта книга — юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975…

4.1
 (1)

Создание электронных книг из сканов. DjVu или Pdf из бумажной книги легко и быстроTWDragon, 4u4undr

Эта мини инструкция в картинках, описывающая полный цикл создания электронной версии научно-технической книги, и предназначена для человека, искренне захотевшего…

4.8
 (5)

Создание электронных книг в формате FictionBook 2.1: практическое руководствоКондратович Михаил Иосифович Юзич

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

3.2
 (2)

Создание сайтовЕвдокимов Николай Семенович, Бабаев Анар, Боде Михаил М.

Данная книга от признанных авторитетов в сфере интернет-технологий, создания сайтов, контекстной рекламы, веб-аналитики и поисковой оптимизации поможет определиться с…

3.33
 (6)

Создание ePub: программы и алгоритм работыМурашов Николай docking the mad dog

Краткий обзор программ для создания ePub 2.0 и алгоритм работы. Это отдельная глава из Руководства по созданию ePub 2.0, версия PDF (140х190 mm, 24 c). В обзоре…

Люди как нелинейные и наиболее важные компоненты в создании программного обеспеченияКоуберн Алистэр

Мы, методологи, проектируем сложные системы, но не принимаем во внимание рабочие характеристики активного компонента этих систем, компонента, который известен своей… 3
 (4)

3
 (4)

Путь к мастерству в сфере разработки программного обеспечения: от новичка до эксперта

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

Методы и подходы к развитию в группе разработчиков

• Менторство. Это может быть формальное или неформальное, где более опытные члены команды обучают новичков, помогают им разобраться в проектах или предоставляют поддержку при преодолении трудностей.
• Парное программирование. При этом подходе два программиста совместно работают над одной задачей на одном компьютере. Это не только способствует ускорению процесса кодирования, но и обеспечивает обмен знаниями и навыками между участниками.
• Совместное обучение. Обучение в группах часто подразумевает участие в образовательных семинарах, дискуссионных клубах и других событиях, которые способствуют обмену идей и расширению знаний.
• Технические обзоры. Регулярный просмотр и обсуждение работ других членов команды может быть очень образовательным процессом. Он способствует общему пониманию кодовой базы и методик разработки.

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

Вывод

Числа Данбара определяют лимит размера эффективной команды. Опираясь на закон Конвея, можно говорить о потенциальном пределе системы. Единственный способ обойти аксиому — разделить большую систему на компактные группы. Команды не рождаются полностью сформированными и эффективными. Закон Конвея работает в совокупности с тезисом Голла. Группы должны расти постепенно. Постулат Брукса подразумевает, что команды не могут расшириться слишком быстро. Закон Паркинсона означает занятость излишне крупных команд поддержанием собственного существования.

Второй постулат Келли подсказывает решение: избегайте большого, сосредоточьтесь на малом.

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

Статья является отрывком из новой книги Аллана Келли «Xanpan книга 2: средство производства». Будет доступна в конце 2015 года.

ссылка на оригинал статьи http://habrahabr.ru/post/272483/