Команда программистов

Из Википедии, бесплатной энциклопедии

Команда программистов — это группа людей, которые разрабатывают или поддерживают компьютерное программное обеспечение . [1] Они могут быть организованы по-разному, но команда программистов без эго и команда главных программистов представляют собой общие структуры. [2]

Описание [ править ]

Команда программистов состоит из людей, которые разрабатывают или поддерживают компьютерное программное обеспечение . [3]

Структуры команд программистов [ править ]

Команды программистов могут быть организованы по-разному, но команда программистов без эго и команда главных программистов . обычно используются две распространенные структуры: [2] Основными определяющими факторами при выборе структуры команды программистов обычно являются: сложность, размер, продолжительность, модульность, надежность, время и коммуникабельность. [2]

программирование Безэгоистическое

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

Команда главных программистов [ править ]

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

Команды на общих рабочих станциях [ править ]

Парное программирование [ править ]

Метод разработки, при котором два программиста работают вместе на одной рабочей станции.

Программирование мафии [ править ]

Подход к разработке программного обеспечения, при котором вся команда работает над одним и тем же, в одно и то же время, в одном пространстве и на одном компьютере. [4]

Модели программирования [ править ]

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

В рамках обеих этих моделей программирования члены команды обычно участвуют в ежедневных 5–15-минутных стендапах. Традиционно каждый член команды встает и заявляет, над чем он работал с момента предыдущего стендапа, над чем он намерен работать до следующего стендапа и есть ли что-то, что мешает им добиться прогресса. часто известный как «блокатор». [5]

Модель водопада [ править ]

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

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

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

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

Гибкая модель [ править ]

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

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

Общие принципы [7] Agile -манифеста [8] следующие:

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

См. также [ править ]

Ссылки [ править ]

  1. ^ Джек Белзер, Альберт Джордж Хольцман, Аллен Кент (1 октября 1979 г.), Энциклопедия информатики и технологий , том. 13, CRC Press, ISBN  9780824722630 {{citation}}: CS1 maint: несколько имен: список авторов ( ссылка )
  2. ^ Перейти обратно: а б с д Это Мэрилин Мантей (март 1981 г.). «Влияние структуры команды программистов на задачи программирования» (PDF) . Коммуникации АКМ . Том. 24, нет. 3. С. 106–113 . Проверено 26 марта 2019 г.
  3. ^ Джек Белзер, Альберт Джордж Хольцман, Аллен Кент (октябрь 1979 г.), Энциклопедия информатики и технологий , том. 13, CRC Press, ISBN  9780824722630 {{citation}}: CS1 maint: несколько имен: список авторов ( ссылка )
  4. ^ Джек Белзер, Альберт Джордж Хольцман, Аллен Кент (октябрь 1979 г.), Процесс управления изменениями , том. 13, ISBN  9780824722630 {{citation}}: CS1 maint: несколько имен: список авторов ( ссылка )
  5. ^ Гриффин, Кристина; Ролдан, Маргарет (29 октября 2013 г.). «Плавание вверх по водопаду: гибкие процессы в мире водопадов» . Институт управления проектами . Проверено 10 октября 2023 г.
  6. ^ Перейти обратно: а б Мэри Лотц (5 июля 2018 г.), «Водопад» или «Agile»: какая методология разработки подходит для вашего проекта?
  7. ^ Команда Linchpin SEO (26 марта 2019 г.), Руководство для начинающих по гибкому методу и Scrums
  8. ^ «Принципы Agile-манифеста» . 11.06.2019.