프로그래밍팀

Programming team

프로그래밍 팀은 컴퓨터 소프트웨어를 [1]개발하거나 유지하는 사람들로 구성된 팀입니다.이들은 다양한 방법으로 조직될 수 있지만, egoless 프로그래밍 팀과 수석 프로그래머 팀은 공통적인 [2]구조였습니다.

묘사

프로그래밍 팀은 컴퓨터 소프트웨어를 [3]개발하거나 유지하는 사람들로 구성됩니다.

팀 구성 프로그래밍

프로그래밍 팀은 다양한 방법으로 구성될 수 있지만, egoless 프로그래밍 팀과 수석 프로그래머 팀은 일반적으로 사용되는 [2]두 가지 구조입니다.프로그래밍 팀 구조를 선택할 때의 주요 결정 요인에는 일반적으로 난이도, 크기, 지속 시간, 모듈성,[2] 신뢰성, 시간 및 사회성이 포함됩니다.

에골레스 프로그래밍

주요 기사: Egoless 프로그래밍

Marilyn Mantei에 따르면, 분산형 프로그래밍 팀에 속한 개인들은 더 높은 직업 [2]만족도를 보고한다고 합니다.그러나 egoless 프로그래밍 팀에는 10명 이하의 프로그래머 그룹이 있습니다.코드가 교환되고 그룹 구성원 간에 목표가 설정됩니다.리더쉽은 특정 기간 동안 요구되는 요구와 능력에 따라 그룹 내에서 순환됩니다.egoless 팀의 구조 부재로 인해 대규모 프로젝트의 효율성, 효율성 및 오류 감지 기능이 약해질 수 있습니다.Egoless 프로그래밍 팀은 매우 복잡한 작업에 가장 적합합니다.

수석 프로그래머 팀

주요 기사:수석 프로그래머 팀

수석 프로그래머 팀은 보통 수석 프로그래머, 상급 프로그래머, 프로그램 사서 등으로 구성된 3인 팀을 포함합니다.필요에 따라 프로그래머와 분석가가 팀에 추가됩니다.이 구조의 약점으로는 팀원 간의 커뮤니케이션 부족, 작업 협력 및 복잡한 작업 완료가 있습니다.최고 프로그래머 팀은 정보 흐름이 제한적이기 때문에 보다 단순하고 간단한 작업에 가장 적합합니다.이 팀 구조에서 일하는 사람들은 일반적으로 업무 [2]사기가 떨어진다고 보고합니다.

공유 워크스테이션 팀

페어 프로그래밍

주요 기사: 페어 프로그래밍

두 명의 프로그래머가 하나의 워크스테이션에서 함께 작업하는 개발 기술입니다.

모브 프로그래밍

주요 기사:모브 프로그래밍

소프트웨어 개발 어프로치에서는 팀 전체가 같은 공간에서 같은 컴퓨터로 동시에 작업합니다.

프로그래밍 모델

프로그래밍 모델을 사용하면 소프트웨어 개발 팀은 이러한 다양한 방법론을 사용하여 프로젝트를 개발, 배포 및 테스트할 수 있습니다.

워터폴 모델

주요 기사:워터폴 모델

보다 전통적인[4] 접근법으로 알려진 폭포수 모델은 선형 생산 모델입니다.이 방법론의 이벤트 시퀀스는 다음과 같습니다.

  1. 요건 수집 및 문서화
  2. 설계.
  3. 코드 및 유닛 테스트
  4. 시스템 테스트 실행
  5. 사용자 수용 테스트(UAT) 실행
  6. 문제를 해결하다
  7. 완제품을 납품하다

각 단계는 소프트웨어 개발 프로세스 중에 구별되며, 일반적으로 각 단계는 다음 단계가 시작되기 전에 완료됩니다.

이 모델을 사용하는 프로그래밍 팀은 개발 프로세스 초기에 프로젝트를 설계할 수 있습니다.이것에 의해, 팀은 항상 설계를 반복하는 대신에, 대부분의 작업중에 코딩과 테스트에 집중할 수 있습니다.이를 통해 팀은 모든 소프트웨어 성과물을 완전히 이해할 수 있도록 완전하고 신중하게 설계할 수 있습니다.

신속한 변화를 위한 모델

주요 기사:신속한 소프트웨어 개발

신속한 변화를 위한 개발 모델은 이전 폭포형 모델보다 팀 기반 개발[4] 방식입니다.팀은 신속한 제공/도입으로 작업을 진행하며, 작업을 "스프린트"라고 불리는 단계로 나눕니다.스프린트는 보통 각 팀/팀 구성원에게 주어지는 2주간의 계획된 소프트웨어 성과물로 정의됩니다.

각 스프린트 후 작업의 우선순위를 변경하고 이전 스프린트에서 학습한 정보를 향후 스프린트 계획에 사용한다.스프린트 작업이 완료되면 프로그래밍 팀에 의해 검토 및 평가되고 다른 반복(즉, 다음 스프린트)을 위해 다시 보내거나 완료 시 종료할 수 있다.

신속한[6] 변화를 위한 선언의 일반적인 원칙은[5] 다음과 같습니다.

  • 고객을 만족시키고 소프트웨어를 지속적으로 개발합니다.
  • 고객의 경쟁 우위를 위해 변화하는 요구사항을 수용합니다.
  • 작업 중인 소프트웨어를 자주 배포하는 데 집중하십시오.배송 우선 순위는 가능한 한 짧은 시간 범위에 배치됩니다.
  • 개발자와 비즈니스맨은 프로젝트 전체를 통해 협력해야 합니다.
  • 프로젝트는 동기부여가 되는 사람을 기반으로 해야 합니다.고객이 필요로 하는 적절한 환경과 지원을 제공합니다.그들이 일을 해낼 수 있도록 신뢰해야 한다.
  • 대면 커뮤니케이션은 팀 간에 정보를 주고받는 가장 좋은 방법입니다.
  • 작업용 소프트웨어는 진보의 주요 척도입니다.
  • 민첩한 프로세스는 지속 가능한 개발을 촉진합니다.스폰서, 개발자 및 사용자는 일정하지 않은 속도를 유지할 수 있어야 합니다.
  • 기술적 우수성과 우수한 설계에 지속적으로 주의를 기울이면 민첩성이 향상됩니다.
  • 단순성은 완성되지 않은 작업을 최대화하는 기술로 간주되며, 이는 필수적입니다.
  • 자기 조직화된 팀은 보통 최고의 디자인을 만듭니다.
  • 팀은 정기적으로 어떻게 하면 더 효과적으로 할 수 있을지 생각해 보고 그에 따라 행동을 조정하고 조정할 것입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Jack Belzer, Albert George Holzman, Allen Kent (October 1, 1979), Encyclopedia of computer science and technology, vol. 13, ISBN 9780824722630{{citation}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  2. ^ a b c d e Marilyn Mantei (March 1981). "The Effect of Programming Team Structures on Programming Tasks" (PDF). Communications of the ACM. Vol. 24, no. 3. p. 106–113. Retrieved 2019-03-26.
  3. ^ Jack Belzer, Albert George Holzman, Allen Kent (October 1979), Encyclopedia of computer science and technology, vol. 13, ISBN 9780824722630{{citation}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  4. ^ a b Mary Lotz (July 5, 2018), Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?
  5. ^ Linchpin SEO Team (March 26, 2019), A Beginners Guide To The Agile Method & Scrums
  6. ^ "Principles behind the Agile Manifesto". 2019-06-11.