팀 프로그래밍
Team programming |
소프트웨어 공학에서 팀 프로그래밍은 컴퓨터 소프트웨어 개발 프로젝트에서 작업 분배를 조정하기 위한 프로젝트 관리 전략으로, 대규모 프로그래밍 프로젝트 내에서 개별 서브태스크에서 공동으로 작업하도록 두 명 이상의 컴퓨터 프로그래머를 할당합니다.일반적으로 이 용어의 사용방법은 현재 소프트웨어 개발업계에서 유행하고 있는 방법을 말합니다.이러한 시스템에서는 프로그래머가 같은 컴퓨터 워크스테이션에서 동시에 작업하고 있는 다른 사용자가 소프트웨어 및 alt에서 작업하는 것을 관찰하는 경우가 많습니다.일정 간격으로 역할을 조정합니다.
기존 팀 관리 방법
기존의 소프트웨어 개발에는 거의 항상 여러 명의 프로그래머가 상당한 범위와 규모의 프로젝트를 위해 컴퓨터 시스템의 개별 부품에서 작업하는 방식, 즉 분업 방법이 포함되어 있었습니다.한 명의 프로그래머가 실행 가능한 기간 내에 복잡한 시스템에서 필요한 모든 작업을 충분히 완료할 수 있다고는 생각할 수 없습니다.또한 개발 프로젝트가 복잡해짐에 따라 시스템 분석, 품질 보증 등의 측면에서 전문지식이 가장 중요해집니다.개별 컴포넌트로 인해 발생하는 기술적 문제 등입니다.처음에는 비공식적인 과정이었지만, 상용 소프트웨어 개발이 실현 가능한 산업으로 부상함에 따라 보다 산업적이고 체계적인 접근이 필요하게 되었습니다.
원래는 정부 프로젝트를 수행하기 위해 설계된 종이 지향 시스템 방법론(SSADM)으로, 개별 작업을 수행할 사람을 할당하고 설계자의 역할을 워터폴 소프트웨어 개발에서 프로그래머의 역할과 명확하게 분리하도록 지정했습니다.이 방법론은 또한 시스템 개발 프로젝트가 진행되는 각각의 "라이프 사이클" 단계를 명확하게 구분했습니다.시스템 개발 프로젝트의 "서류 추적"은 구축에 너무 오래 걸릴 수 있으며, 실제 개발 시점까지 분석 문서의 일부 또는 전체 내용이 최신이 아닌 경우가 많습니다.
최신 트렌드: 여러 명의 프로그래머가 하나의 서브태스크에 대응
이러한 낡은 방법에서는, 시스템의 확장에 수반해 코스트가 걷잡을 수 없게 되어, 시장 투입까지의 목표치를 달성하지 못하는 등, 어려움이 있었습니다.이러한 문제는 Boehm Spiral과 같은 새로운 시스템 라이프사이클 구조와 함께 페어 프로그래밍, 몹 프로그래밍(앙상블 프로그래밍)과 같은 기술을 발생시켰다.이러한 새로운 접근방식의 사양은 1980년대 중반에 시작되어 오늘날에도 계속되고 있습니다.이러한 전략의 대부분은 여러 프로그래머가 개별 태스크를 개별적으로 책임지는 것이 아니라 동일한 소스 코드로 공동으로 작업하는 것입니다.예를 들어, "쌍 프로그래밍"에서 결과물에 대한 책임은 할당된 하위 태스크를 함께 수행하는 두 프로그래머 간에 동등하게 공유됩니다.이 접근방식의 이점에는 한 프로그래머의 지식이 부족하여 다른 프로그래머의 특정 영역에서의 능력으로 보완되는 경우가 있습니다.또한 책임 공유는 프로젝트 마감일 및 품질 목표를 충족하기 위한 인센티브를 증가시키는 것으로 생각됩니다.
이 기술은 Rational Unified Process 및 Extreme Programming(acronym "XP")과 같은 객체 지향 프로그래밍 기법(UML)에 초점을 맞춘 새로운 프로그래밍 방법론에서 자주 사용됩니다.객체 지향 프로그래밍 언어에서 소프트웨어 기능은 모듈러 단위, 이산 단위(기능 요소를 위한 용어 클래스 및 특정 함수를 실행하는 상호 연결된 클래스 집합을 위한 패키지)를 형성합니다. 이들 중 가장 잘 알려진 두 가지는 C++와 Java입니다.이것은 프로그래밍 프로젝트를 서브팀으로 분할하는 데 도움이 되지만, 각 서브태스크가 완료된 후 결과물을 통합하는 데 있어 여전히 종종 문제가 발생합니다.
