본문으로 이동

프로그래밍 팀

위키백과, 우리 모두의 백과사전.

프로그래밍 팀(programming team)은 컴퓨터 소프트웨어를 개발하거나 유지보수하는 사람들로 구성된 팀이다.[1] 이들은 여러 방식으로 조직될 수 있지만, 비자아적 프로그래밍 팀과 수석 프로그래머 팀이 일반적인 구조였다.[2]

설명

[편집]

프로그래밍 팀은 개발하거나 유지보수하는 사람들로 구성된다.[3]

프로그래밍 팀 구조

[편집]

프로그래밍 팀은 여러 방식으로 조직될 수 있지만, 비자아적 프로그래밍 팀과 수석 프로그래머 팀이 일반적으로 사용되는 두 가지 공통 구조이다.[2] 프로그래밍 팀 구조를 선택할 때 주요 결정 요인은 일반적으로 어려움, 규모, 기간, 모듈성, 신뢰성, 시간 및 사회성을 포함한다.[2]

비자아적 프로그래밍

[편집]
 이 부분의 본문은 비자아적 프로그래밍입니다.

매릴린 만테이에 따르면, 분산된 프로그래밍 팀에 속한 개인들은 더 높은 직무 만족도를 보고한다.[2] 비자아적 프로그래밍 팀은 10명 이하의 프로그래머로 구성된 그룹을 포함한다. 코드는 그룹 구성원들 사이에서 교환되고 목표가 설정된다. 리더십은 특정 시간 동안 필요한 요구 사항과 능력에 따라 그룹 내에서 순환된다. 비자아적 팀의 구조 부족은 대규모 프로젝트에서 효율성, 효과성 및 오류 감지의 약점으로 이어질 수 있다. 비자아적 프로그래밍 팀은 매우 복잡한 작업에 가장 적합하다.

수석 프로그래머 팀

[편집]
 이 부분의 본문은 수석 프로그래머 팀입니다.

수석 프로그래머 팀은 일반적으로 수석 프로그래머, 선임 프로그래머 및 프로그램 사서로 구성된 3인 팀을 포함한다. 필요한 경우 추가 프로그래머와 분석가가 팀에 추가된다. 이 구조의 약점은 팀 구성원 간의 의사소통 부족, 작업 협력 및 복잡한 작업 완료가 포함된다. 수석 프로그래머 팀은 팀 내 정보 흐름이 제한되므로 더 간단하고 명확한 작업에 가장 적합하다. 이 팀 구조에서 일하는 개인들은 일반적으로 낮은 업무 의욕을 보고한다.[2]

공유 워크스테이션 팀

[편집]

페어 프로그래밍

[편집]
 이 부분의 본문은 페어 프로그래밍입니다.

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

모브 프로그래밍

[편집]
 이 부분의 본문은 모브 프로그래밍입니다.

팀 전체가 같은 시간, 같은 공간에서 같은 컴퓨터로 같은 작업을 하는 소프트웨어 개발 접근 방식이다.[4]

프로그래밍 모델

[편집]

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

이러한 두 가지 프로그래밍 모델 전체에서 팀 구성원은 일반적으로 매일 5~15분간의 스탠드업 회의에 참여한다. 전통적으로 팀의 각 구성원은 일어서서 이전 스탠드업 회의 이후에 작업한 내용, 다음 스탠드업 회의까지 작업할 내용, 그리고 진행을 방해하는 요소(종종 "블로커"라고 알려짐)가 있는지 여부를 말한다.[5]

폭포수 모델

[편집]
 이 부분의 본문은 폭포수 모델입니다.

더 전통적인 접근 방식으로 알려진 [6] 폭포수 모델은 선형적인 생산 모델이다. 이 방법론의 이벤트 순서는 다음과 같다.

  1. 요구 사항 수집 및 문서화
  2. 설계
  3. 코드 및 단위 테스트
  4. 시스템 테스트 수행
  5. 사용자 인수 테스트 (UAT) 수행
  6. 모든 문제 해결
  7. 완성된 제품 제공

각 단계는 소프트웨어 개발 프로세스 동안 명확하게 구분되며, 일반적으로 다음 단계가 시작되기 전에 각 단계가 완료된다.

이 모델을 사용하는 프로그래밍 팀은 개발 프로세스 초기에 프로젝트를 설계할 수 있어, 팀이 지속적으로 설계를 반복하는 대신 작업의 대부분 동안 코딩 및 테스트에 집중할 수 있다. 이는 또한 팀이 모든 소프트웨어 산출물을 완전히 이해할 수 있도록 완전히 그리고 더 신중하게 설계할 수 있게 한다.

애자일 모델

[편집]
 이 부분의 본문은 애자일 소프트웨어 개발입니다.

애자일 개발 모델은 이전 폭포수 모델보다 개발에 대한 더 팀 기반의 접근 방식이다.[6] 팀은 "스프린트"라고 불리는 단계로 작업을 분할하는 빠른 납품/배포 방식으로 작업한다. 스프린트는 일반적으로 각 팀/팀 구성원에게 주어진 2주간의 계획된 소프트웨어 산출물로 정의된다.

각 스프린트 후에 작업의 우선순위가 재조정되고 이전 스프린트에서 얻은 정보는 향후 스프린트 계획에 사용된다. 스프린트 작업이 완료되면 프로그래밍 팀에 의해 검토 및 평가될 수 있으며, 다음 반복(예: 다음 스프린트)을 위해 다시 보내지거나 완료되면 종료된다.

애자일 선언문의 일반적인 원칙[7][8]은 다음과 같다.

  • 고객을 만족시키고 소프트웨어를 지속적으로 개발한다.
  • 고객의 경쟁 우위를 위해 변화하는 요구 사항을 수용한다.
  • 작동하는 소프트웨어를 자주 제공하는 데 집중한다. 가능한 가장 짧은 시간 내에 제공하는 것을 선호한다.
  • 개발자와 비즈니스 담당자는 프로젝트 전반에 걸쳐 협력해야 한다.
  • 프로젝트는 동기 부여된 사람들을 기반으로 해야 한다. 그들에게 적절한 환경과 필요한 지원을 제공해야 한다. 그들이 업무를 완료할 것이라고 신뢰해야 한다.
  • 대면 의사소통은 팀에 정보를 주고받는 가장 좋은 방법이다.
  • 작동하는 소프트웨어가 진행 상황의 주요 측정 기준이다.
  • 애자일 프로세스는 지속 가능한 개발을 촉진한다. 스폰서, 개발자 및 사용자는 무기한으로 일정한 속도를 유지할 수 있어야 한다.
  • 기술적 우수성과 좋은 디자인에 대한 지속적인 관심은 민첩성을 향상시킬 것이다.
  • 단순성은 완료되지 않은 작업을 최대화하는 기술로 간주되며, 이는 필수적이다.
  • 자율 조직 팀은 일반적으로 최고의 디자인을 만든다.
  • 정기적인 간격으로 팀은 어떻게 더 효과적으로 될 것인지 반성하고 그에 따라 행동을 조정하고 조절한다.

같이 보기

[편집]

각주

[편집]
  1. ↑ Jack Belzer, Albert George Holzman, Allen Kent (1979년 10월 1일), 《Encyclopedia of computer science and technology》 13, CRC Press, ISBN 9780824722630 
  2. ↑ 가 나 다 라 마 Marilyn Mantei (March 1981). “The Effect of Programming Team Structures on Programming Tasks” (PDF). 《Communications of the ACM》. 24권 3호. 106–113쪽. 2019년 3월 26일에 확인함. 
  3. ↑ Jack Belzer, Albert George Holzman, Allen Kent (October 1979), 《Encyclopedia of computer science and technology》 13, CRC Press, ISBN 9780824722630 
  4. ↑ Jack Belzer, Albert George Holzman, Allen Kent (October 1979), 《Change Management Process》 13, ISBN 9780824722630 
  5. ↑ Griffin, Christina; Roldan, Margaret (2013년 10월 29일). “Swimming up the waterfall: agile processes in a waterfall world”. 《Project Management Institute》. 2023년 10월 10일에 확인함. 
  6. ↑ 가 나 Mary Lotz (2018년 7월 5일), 《Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?》 
  7. ↑ Linchpin SEO Team (2019년 3월 26일), 《A Beginners Guide To The Agile Method & Scrums》 
  8. ↑ “Principles behind the Agile Manifesto”. 2019년 6월 11일. 
원본 주소 "https://ko.wikipedia.org/w/index.php?title=프로그래밍_팀&oldid=40771906"