팀 프로젝트 계획

업데이트: 2007년 11월

팀 프로젝트를 만들려면 먼저 프로젝트의 범위를 신중하게 계획하고 팀 프로젝트를 수정, 확장 및 유지 관리하기 위한 이후의 과정을 고려해야 합니다. 이 항목에서는 새 팀 프로젝트를 만들지 기존 프로젝트를 확장할지 결정하기 위해 고려해야 할 사항의 목록을 제공합니다. 이 질문 목록은 심사 숙고를 위한 출발점일 뿐이지 모든 소프트웨어 개발 프로젝트에 완벽하게 적용되는 절대적인 목록이 아닙니다. 질문은 네 그룹으로 나뉘어 있습니다.

• 현재 팀 프로젝트 및 이후의 작업에 대한 질문

• Team Foundation Server의 용량 및 성능에 대한 질문

• 팀 프로젝트 구성을 위한 구조 또는 계층에 대한 질문

• 기본 소프트웨어 개발 프로세스에 대한 질문

대부분의 질문에 대해 예라는 대답이 나온다면 새 팀 프로젝트를 만드는 것이 좋습니다.

다음 다이어그램에서는 문제점을 결정 트리로 표시하여 다양한 문제점들이 서로 어떻게 연관되는지를 시각적으로 보여 줍니다.

현재 팀 프로젝트 및 이후의 작업에 대한 질문

다음 질문에 답하려면 현재 팀 프로젝트에 대해 생각해 보고 이후의 작업도 현재와 동일한 방식으로 계속 진행할지 고려해야 합니다. 팀 프로젝트에 이후의 작업을 처리하기에 충분한 용량이 있는지도 확인해야 합니다.

다음 다이어그램에서는 문제점을 결정 트리로 표시하여 다양한 문제점들이 서로 어떻게 연관되는지를 시각적으로 보여 줍니다.

새로 설치한 Team Foundation Server가 있습니까?

Team Foundation Server를 처음 설치한 경우 Team Foundation의 기능이나 도구를 사용하려면 먼저 새로운 팀 프로젝트를 만들어야 합니다. 기존의 설치 환경에서 작업하는 경우 서버에 이미 팀 프로젝트가 있을 수 있으므로 그러한 프로젝트를 이후의 작업에 계속 사용해도 괜찮을지 평가해야 합니다.

새로운 팀 포털이 필요합니까?

현재 팀 포털의 내용과 포커스를 검토해야 합니다. 포털의 내용과 포커스가 이후의 작업에도 계속 관련되는지 여부를 확인합니다. 이후의 작업에 주로 초점을 맞춘 다른 팀 포털을 만들려면 새로운 팀 프로젝트와 팀 포털을 만들어야 합니다. 각 팀 프로젝트마다 팀 포털은 하나만 사용하는 것이 좋습니다.

사람마다 서로 다른 권한을 부여해야 합니까?

모든 팀 프로젝트 멤버의 작업 할당 및 보안 권한을 검토해야 합니다. 여기서 확인할 사항은 다음과 같습니다.

• 현재 팀 프로젝트 멤버가 이후의 작업에서 여러 역할을 수행할지 여부

• 동일한 사용자가 프로젝트의 서로 다른 부분에 대해 각기 다른 권한을 필요로 하는지 여부

• 여러 사람이 현재 팀 멤버로서 동일한 역할을 수행할지 여부

권한이 다른 여러 사람이 프로젝트 작업을 진행해야 한다면 새 팀 프로젝트를 만들어야 합니다.

다른 체크 인 정책을 사용하려 합니까?

현재 팀 프로젝트에 대한 현재 체크 인 정책을 검토해야 합니다. 현재 체크 인 정책이 이후의 작업에도 적합한지 확인합니다. 이후의 작업에 대해 다른 체크 인 정책을 사용하려면 새 팀 프로젝트를 만들고 새 체크 인 정책을 정의해야 합니다. Team Foundation Server에서는 각 팀 프로젝트에 대해 체크 인 정책 집합을 하나만 사용할 수 있습니다.

다른 설정을 사용하려 합니까?

팀 프로젝트를 계속 사용하고 작업하다 보면 프로젝트 설정을 변경해야 하는 경우가 생길 수 있습니다. 일부 설정은 기존 팀 프로젝트에서 변경할 수 있지만 나머지 설정은 작업을 계속하기 위해 새로운 팀 프로젝트를 만들어야 변경할 수 있습니다. 현재 설정이 적절한지 판단하기 위해서는 다음 사항을 고려해 볼 필요가 있습니다.

다른 프로세스 템플릿을 사용하려 합니까?

프로세스 템플릿을 확인하고, 가능한 경우 현재 팀 프로젝트에 사용되는 프로세스 지침을 확인합니다. 템플릿이 이후의 작업에도 계속 적합한지 확인합니다. 이후의 작업에 대해 다른 프로세스 템플릿을 사용하려면 이 새로운 템플릿을 사용하여 새 팀 프로젝트를 만들어야 합니다. Team Foundation Server에서는 각 팀 프로젝트에 대해 프로세스 템플릿을 하나만 사용할 수 있습니다. 팀 프로젝트를 시작한 후에는 팀 프로젝트에 따라 사용되는 프로세스 템플릿을 직접 사용자 지정할 수 있습니다. 그러나 Team Foundation 서버에 저장된 프로세스 템플릿에 이와 같이 사용자 지정된 변경 내용을 저장하지 않으면 해당 템플릿을 기반으로 한 새 팀 프로젝트에 변경 내용이 반영되지 않습니다.

다른 작업 항목 형식을 사용하려 합니까?

현재 팀 프로젝트에 사용되고 있는 작업 항목의 형식을 확인합니다. 현재 작업 항목 형식이 이후의 작업에도 계속 적합한지 확인합니다. 다른 작업 항목 형식을 사용하려는 경우나 형식은 같지만 내용이 다른 작업 항목을 사용하려는 경우에는 새 팀 프로젝트를 만들고 새 작업 항목 형식을 정의해야 합니다. Team Foundation Server에서는 각 팀 프로젝트에 대해 작업 항목 형식 집합을 하나만 사용할 수 있습니다.

프로세스나 기타 팀 프로젝트 설정을 시험해 보려 합니까?

Team Foundation Server에 익숙하지 않거나 팀 기능을 향상시키려는 경우 다른 워크플로, 분류 계층 구조, 빌드 프로세스, 정책 등을 시험해 볼 수 있습니다. 이러한 시도를 위해서는 별도의 팀 프로젝트를 만들어야 합니다.

관리를 위해 마스터 .mpp 또는 .xls 파일을 사용합니까?

팀을 관리하는 데 사용하는 정보와 도구를 검토합니다. 특히 둘 이상의 팀 프로젝트를 관리하는 경우 이러한 검토가 중요합니다. 팀 프로젝트를 관리하는 주 도구로 Microsoft Project나 Microsoft Excel을 사용하는 경우 동일한 마스터 .mpp 또는 .xls 파일에서 모든 프로젝트 작업을 추적하려면 새 팀 프로젝트를 만드는 대신 프로젝트에 더 많은 반복을 계속 추가해야 합니다. Team Foundation Server에서는 여러 팀 프로젝트 간에 공유되는 작업 항목을 Microsoft Project나 Microsoft Excel을 사용하여 표시할 수 없습니다. 즉, 두 개 이상의 팀 프로젝트를 관리하고 있고 여러 팀 프로젝트에 관련된 작업 항목이 있는 경우 Microsoft Project나 Microsoft Excel에서는 이러한 작업 항목을 표시할 수 없습니다. 이러한 공유 작업 항목을 보고 관리하려면 Team Foundation Server의 다른 보고 도구 중 하나를 대신 사용해야 합니다.

프로젝트의 작업 항목 버전이 천만 개 이상입니까?

현재 팀 프로젝트에 있는 작업 항목의 총 수를 계산하고 Team Foundation Server의 용량을 절반 이상 사용했는지 확인합니다. Team Foundation Server에서는 단일 팀 프로젝트에서 작업 항목의 버전을 최대 20백만 개까지 지원합니다. 용량을 절반 이상 사용한 경우 새 팀 프로젝트를 마치기도 전에 용량이 부족해질 수 있습니다. 또한 작업 항목의 복잡성이 Team Foundation Server 성능에 부정적인 영향을 미칠 수 있습니다.

프로젝트의 모든 활성 작업 항목을 수동으로 옮기려 합니까?

현재 팀 프로젝트의 활성 작업 항목 수를 계산합니다. 새 팀 프로젝트를 만들려면 이러한 작업 항목을 현재 팀 프로젝트에서 새 팀 프로젝트로 복사해야 합니다. Team Foundation Server에서는 프로젝트 사이에 작업 항목을 대량으로 복사하거나 이동할 수 없습니다. 팀 프로젝트 간에 작업 항목 하나를 복사하여 붙여넣는 데 30초가 걸린다고 가정할 때 500개의 작업 항목을 복사하려면 쉬지 않고 계속해도 250분 즉 4시간 이상 걸립니다.

또는 Microsoft Excel을 사용하여 팀 프로젝트 간에 작업 항목을 대량으로 복사할 수 있습니다. 그러나 대량 복사를 사용하면 작업 항목의 현재 정보는 복사되지만 작업 항목 기록, 첨부 파일 및 새 팀 프로젝트에 대한 링크는 복사되지 않습니다. Microsoft Excel을 사용하여 작업 항목을 대량으로 복사하는 방법에 대한 자세한 내용은 Microsoft Excel 및 Microsoft Project에서 작업 항목 사용을 참조하십시오.

새 팀 프로젝트를 만드는 것과 작업 항목을 복사하는 것 중 어느 쪽이 유리한지 결정해야 합니다.

소프트웨어 기능이 크게 변경됩니까?

이후의 작업에서 새로운 기술이나 전혀 새로운 소프트웨어 기능을 도입하려는 경우에는 새 팀 프로젝트를 만드는 것이 유리할 수 있습니다. 새로운 기술이나 기능에는 크게 다른 워크플로, 테스트, 빌드 스크립트 등이 필요할 수 있고, 이는 다시 말해 현재 프로세스 템플릿이나 프로세스 지침을 크게 수정해야 함을 의미할 수 있습니다.

Team Foundation Server의 용량 및 성능에 대한 질문

다음 질문에 답하려면 현재 팀 프로젝트가 저장되어 있고 이후의 작업을 배치할 Team Foundation 서버에 대해 고려해야 합니다. 이후의 작업 부하를 처리하기에 충분한 용량과 성능이 서버에 있는지도 확인해야 합니다.

다음 다이어그램에서는 문제점을 결정 트리로 표시하여 다양한 문제점들이 서로 어떻게 연관되는지를 시각적으로 보여 줍니다.

서버에 성능 문제가 있습니까?

Team Foundation Server에 작업 항목, 소스 코드, 문서 및 기타 아티팩트가 누적되면 서버에서 쿼리를 반환하거나 파일을 체크 인하거나 소프트웨어 프로젝트를 빌드하는 데 더 많은 시간이 걸릴 수 있습니다. Team Foundation Server를 처음 사용할 때보다 이러한 작업을 처리하는 데 훨씬 오래 걸린다면 이는 Team Foundation 서버에 있는 수많은 팀 프로젝트로 인해 서버 성능이 저하되었음을 나타내는 것일 수 있습니다. 서버의 팀 프로젝트 수가 늘어날수록 서버의 처리 속도는 느려집니다. 서버 성능이 문제가 될 상황이라면 서버 하드웨어를 업그레이드하고 현재 팀 프로젝트를 계속 진행하거나 새 팀 프로젝트를 다른 서버에 만드는 것을 고려해 볼 필요가 있습니다.

서버를 업그레이드했습니까?

쿼리, 체크 인 또는 빌드 성능이 문제가 된다면 Team Foundation Server 관리자에게 문의하여 서버 하드웨어 업그레이드가 완료되었는지 또는 이후의 작업에 맞춰 서버 업그레이드를 계획 중인지 확인해야 합니다. 서버 하드웨어를 업그레이드하지 않았다면 업그레이드를 통해 성능을 적절한 수준까지 향상시킬 수 있습니다. 업그레이드 일정이 계획에 잡혀 있지만 아직 시행이 완료되지 않았다면 기존 프로젝트에 반복을 추가하는 대신 새 팀 프로젝트를 만들 수도 있습니다.

문서 라이브러리에 있는 문서 수가 백만 개 이상입니까?

Team Foundation Server 관리자에게 문의하여 Team Foundation 서버에 저장된 문서의 수를 확인합니다. Windows SharePoint Services에서 지원할 수 있는 서버의 문서 수는 최대 2백만 개입니다. 문서 수가 최대값에 근접할수록 서버 성능이 저하되고 결국에는 문서를 저장할 수 있는 공간이 부족하게 됩니다. 서버의 용량을 절반 이상 사용했다면 Team Foundation 서버를 새로 만들고 이 새 서버에 새 팀 프로젝트를 만드는 것이 좋습니다. 자세한 내용은 "Capacity Planning for Windows SharePoint Services"(https://office.microsoft.com/en-us/assistance/HA011607741033.aspx)를 참조하십시오.

참고:
프로젝트의 용량을 계획할 때에는 나중에 서버 간에 팀 프로젝트를 이동할 수 없다는 점을 고려해야 합니다. 팀 프로젝트를 백업했다가 본래의 서버에 복원할 수는 있지만 Team Foundation Server 서버 간에 팀 프로젝트를 이동할 수는 없습니다.

Team Foundation Server에 있는 팀 프로젝트 수가 200개 이상입니까?

Team Foundation Server 관리자에게 문의하여 Team Foundation 서버에 있는 팀 프로젝트의 수를 확인합니다. MSF for Agile Software Development 프로세스 템플릿을 사용하여 프로젝트를 만드는 경우 Team Foundation Server에서 지원할 수 있는 최대 팀 프로젝트 수는 500개입니다. MSF for CMMI Process Improvement 프로세스 템플릿을 사용하여 프로젝트를 만드는 경우 Team Foundation Server에서 지원할 수 있는 최대 팀 프로젝트 수는 250개입니다. 팀 프로젝트 수가 최대값에 근접할수록 서버 성능이 저하되고 결국에는 팀 프로젝트를 저장할 수 있는 공간이 부족하게 됩니다. 서버의 용량을 절반 이상 사용했다면 Team Foundation 서버를 새로 설치한 다음 이 새 서버에 새 팀 프로젝트를 설치하는 것이 좋습니다. 자세한 내용은 Team Foundation Server 계획 로드맵을 참조하십시오.

Team Foundation Server에 있는 사용자 수가 1000명 이상입니까?

Team Foundation Server 관리자에게 문의하여 Team Foundation 서버에 있는 개별 사용자의 수를 확인합니다. Team Foundation Server에서 지원할 수 있는 단일 서버의 사용자의 수는 서버 하드웨어에 따라 최대 2,000명입니다. 사용자 수가 최대값에 근접할수록 서버 성능이 저하되고 결국에는 개별 사용자를 추가할 수 있는 공간이 부족하게 됩니다. 서버의 용량을 절반 이상 사용했다면 Team Foundation Server 서버를 새로 만들고 이 새 서버에 새 팀 프로젝트를 만드는 것이 좋습니다. 자세한 내용은 Team System의 서버 요구 사항을 참조하십시오.

이후 감사 또는 기록 검토를 위해 일정 기간 동안 팀 프로젝트 아티팩트를 보존하려 합니까?

정기적으로 팀 프로젝트 아티팩트(예: 소스 코드, 작업 항목, 문서 또는 보고서)의 기록 레코드를 만들고 의도적이거나 실수로 인한 모든 추가 변경 내용으로부터 이 레코드를 보호하려면 주요 반복, 중요 시점 또는 릴리스 후에 새 팀 프로젝트를 만드는 것이 좋습니다. 새 팀 프로젝트를 만들고 기존 소스 트리를 분기하고 다른 개체를 새 팀 프로젝트에 추가한 다음 원래 프로젝트에서 변경 작업을 수행하는 데 필요한 모든 권한을 제거하면 레코드를 보호할 수 있습니다.

계획 프로세스의 이 시점에서 새 팀 프로젝트를 만들지 기존 팀 프로젝트를 이후의 작업에 계속 사용할지 결정해야 합니다. 새 팀 프로젝트를 만들기로 결정했다면 다음 질문으로 넘어가기 전에 다음 사항도 결정해야 합니다.

• 소프트웨어 개발 프로젝트를 만들고 명명하기 위한 5개년 계획 등과 같은 장기 계획

• 포함하거나 제외할 항목의 유형 등과 같은 새 팀 프로젝트의 개념적 경계

이 두 가지 사항은 대부분 Team Foundation 외부 요소에 따라 결정되며 조직에 따라 크게 다를 수 있으므로 이 항목에서는 여기에 대해 자세히 설명하지 않습니다.

팀 프로젝트 구성을 위한 구조 또는 계층에 대한 질문

다음 질문에 답하려면 현재 팀 프로젝트가 어떻게 구성되어 있는지 생각해 보고 이후의 작업도 동일한 방식으로 구성하는 것이 좋을지 고려해야 합니다. 이후 작업의 구성이 소스 코드의 구성 및 조직의 나머지 부분에 대해 어떠한 관계를 갖는지 확인해야 할 수도 있습니다.

다음 다이어그램에서는 문제점을 결정 트리로 표시하여 다양한 문제점들이 서로 어떻게 연관되는지를 시각적으로 보여 줍니다.

구조가 외부 그룹을 통해 적용되었습니까?

조직에서 이미 소프트웨어를 필요로 하는 비즈니스 단위, 작업을 위한 자금 출처, 중요한 조직 이벤트, 소프트웨어 개발 수명 주기 외부의 요인 등을 기반으로 한 소프트웨어 프로젝트의 표준 구조를 사용하고 있을 수 있습니다. 필요한 구조에 일치하도록 팀 프로젝트의 영역과 반복 계층 구조를 설정합니다.

팀에서 제품을 만들고 있습니까?

이후 작업의 주된 초점이 새로운 독립 실행형 제품을 만드는 것이라면 제품 기능에 따라 소스 코드, 반복 및 영역을 구성할 수 있습니다. 각각의 새로운 제품이 개별 팀 프로젝트가 되어야 합니다.

새 버전을 만들고 있습니까?

이후 작업의 주된 초점이 기존 제품의 새 버전을 만드는 것이라면 소프트웨어 버전에 따라 소스 코드, 반복 및 영역을 구성할 수 있습니다. 각각의 새로운 버전이 개별 팀 프로젝트가 되어야 합니다.

시작 날짜와 종료 날짜가 정해져 있습니까?

이후 작업의 주요 초점이 확정된 시작 날짜와 종료 날짜에 맞춰져 있다면 소프트웨어 버전을 구성의 기준으로 사용할 수 있습니다. 주요 시작 날짜 및 종료 날짜의 각 집합이 개별 팀 프로젝트가 되어야 합니다.

누적되는 항목을 처리해야 합니까?

소프트웨어에 대한 작업이 진행됨에 따라 팀 프로젝트의 작업 항목, 문서, 보고서, 빌드 스크립트 및 기타 팀 프로젝트 항목과 작업 산출물이 누적될 수 있습니다. 이러한 항목을 모니터링하고 관리하는 데는 저장 비용뿐 아니라 인건비도 듭니다. 누적되는 팀 프로젝트 항목을 처리하고 가능한 한 빨리 이러한 항목을 보관하거나 삭제하려는 경우에는 소프트웨어 버전을 구성의 기준으로 사용할 수 있습니다. 각각의 주요 버전이 개별 팀 프로젝트가 되어야 합니다.

소스 코드를 팀별로 저장하려 합니까?

전체 팀 프로젝트에 대해 소스 코드 프로젝트를 하나만 사용하고 제품, 버전 또는 비즈니스 단위별로 개별 소스 코드 프로젝트를 만들지 않으려는 경우에는 전체 소프트웨어 개발 팀의 조직과 일치하도록 영역 및 반복 계층 구조를 구성할 수 있습니다.

소프트웨어 유지 관리 작업만 합니까?

이후 작업의 초점이 소프트웨어나 조직 인프라를 조직 외부에 배포하는 것이 아니라 단순히 유지 관리하는 데 집중되어 있다면 영역 및 반복 계층 구조를 전체 소프트웨어 개발 팀의 조직과 일치하도록 구성할 수 있습니다.

기본 소프트웨어 개발 프로세스에 대한 질문

다음 질문에 답하려면 이후 작업을 수행하는 데 사용하려는 소프트웨어 개발 프로세스에 대해 생각해 보아야 합니다. 프로세스 향상을 위한 필수 프로세스나 우선 순위가 있는지도 확인해야 합니다.

다음 다이어그램에서는 문제점을 결정 트리로 표시하여 다양한 문제점들이 서로 어떻게 연관되는지를 시각적으로 보여 줍니다.

법률이나 계약에 따라 CMMI를 사용해야 합니까?

상황에 따라서는 새 팀 프로젝트를 만드는 데 사용되는 프로세스 템플릿을 직접 선택할 수 없는 경우가 있습니다. 예를 들어, 소프트웨어를 개발하는 데 CMMI 프로세스를 사용하도록 해당 지역 법률에 명시되어 있을 수 있습니다. 이 경우 팀 프로젝트를 만들려면 MSF for CMMI Process Improvement 템플릿을 선택해야 합니다. 또는 자금을 지원하는 조직에서 CMMI를 사용하도록 요구할 수도 있습니다.

많은 수의 역할이 필요합니까?

이후의 작업에 많은 수의 팀 멤버 역할이 필요하다면 MSF for CMMI Process Improvement 템플릿을 사용하는 것이 적합한지 결정해야 합니다. 예를 들어, MSF for Agile Software Development 템플릿을 사용하여 팀 프로젝트를 방금 완성했지만 해당 템플릿에 표준으로 제공되는 다음과 같은 역할보다 더 많은 역할이 필요하다는 사실을 뒤늦게 발견할 수도 있습니다.

• 비즈니스 분석가

• 프로젝트 관리자

• 설계자

• 개발자

• 테스터

• 릴리스 관리자

MSF for CMMI Process Improvement 템플릿에는 다음과 같이 더 복잡한 역할 집합이 표준으로 제공됩니다.

• 프로젝트 관리자

• 스폰서

• 설계자

• 실무 전문가

• 개발자

• 개발 관리자

• 빌드 엔지니어

• 테스터

• 테스트 관리자

• 감사 담당자

• 서비스 품질 전문가

• 릴리스 관리자

• IPM 담당자

• 사용자 경험 설계자

• 사용자 교육 전문가

• 제품 관리자

• 비즈니스 분석가

외부 그룹에서 프로세스 개선을 권유합니까?

조직의 주된 관심사 중 하나가 프로세스 향상이라면 조직 내부나 외부의 전담 그룹에 의뢰하여 현재 워크플로와 비즈니스 프로세스를 검토하고 개선책을 제안 받을 수 있습니다. 전담 그룹을 운영하고 있다면 새 팀 프로젝트를 만들 때 MSF for CMMI Process Improvement 템플릿을 사용해야 합니다.

프로세스를 현재 문서화하고 있습니까?

조직의 주된 관심사 중 하나가 프로세스에 대한 것이라면 조직 내부나 외부의 전담 그룹에 의뢰하여 현재 워크플로와 비즈니스 프로세스를 검토하고 개선책을 제안 받을 수 있습니다. 전담 그룹을 운영하고 있다면 새 팀 프로젝트를 만들 때 MSF for CMMI Process Improvement 템플릿을 사용해야 합니다.

적절한 타사 템플릿이 있습니까?

조직에서 이미 타사 공급업체가 제공하는 프로세스 템플릿을 채택했을 수도 있습니다. 이미 템플릿을 선택했다면 새 팀 프로젝트를 만들 때 타사 템플릿을 사용해야 합니다.

현재 프로세스에 만족합니까?

현재 워크플로 프로세스에 만족한다면 공식적인 템플릿을 변경하거나 사용할 필요가 없습니다. 작업에 문제가 없다면 현 상태를 유지해도 됩니다.

프로젝트의 수명 주기가 짧습니까?

팀 프로젝트의 수명 주기가 90일 미만으로 비교적 짧다면 CMMI 같은 공식적인 프로세스에서 요구하는 추가 오버헤드가 불필요할 수도 있습니다. 이 경우에는 MSF for Agile Software Development 템플릿을 사용합니다.

참고:
프로젝트의 용량을 계획할 때에는 나중에 서버 간에 팀 프로젝트를 이동할 수 없다는 점을 고려해야 합니다. 팀 프로젝트를 백업했다가 본래의 서버에 복원할 수는 있지만 Team Foundation Server 서버 간에 팀 프로젝트를 이동할 수는 없습니다.

참고 항목

작업

연습: 새 팀 프로젝트 만들기

연습: 기존 팀 프로젝트에서 새 팀 프로젝트 만들기

개념

팀 프로젝트 만들기

기타 리소스

팀 프로젝트 만들기 및 관리