다음을 통해 공유


특정 필드에 대한 업데이트가 관리되는 방법 이해

하나 이상의 필드가 Visual Studio Team Foundation Server와 Microsoft Project Server 간에 정상적으로 동기화되지 않으면 이 항목의 내용을 검토해야 합니다. 동기화 엔진이 특정 필드를 업데이트하는 방식은 해당하는 필드 하나 이상의 데이터 형식, OnConflict 필드 매핑 특성 및 작업 계층 구조의 영향을 받습니다. 프로젝트 관리자가 전송 업데이트 하나 이상을 거부하거나 프로젝트 계획이 게시되지 않으면 작업이 올바르게 업데이트되지 않습니다. 계획이 게시되지 않은 경우 중첩된 자식 작업 항목은 승인 큐로 이동하지 못합니다.

항목 내용

  • 필드 업데이트 프로세스 개요

  • 거부된 전송 업데이트

  • 제목 또는 작업 이름 업데이트

  • 시작 및 완료 날짜 업데이트

  • 시간이 포함된 필드 업데이트

  • 작업 배정 업데이트

  • 요약 작업, 작업 계층 구조 및 다중 중첩 작업 항목 전송

  • 선택 목록 또는 조회 테이블과 연결된 필드 업데이트

필드 업데이트 프로세스 개요

다음 그림에 나와 있는 것처럼 데이터는 Project Server, Team Foundation Server, PWA 인스턴스의 상태 큐, Enterprise 프로젝트 계획으로 차례대로 이동한 다음 마지막에 Project Server로 돌아옵니다. 다음 테이블에는 동기화 프로세스 및 각 프로세스 단계에서 필드가 업데이트되는 방식에 대한 추가 참고 사항이 나와 있습니다.

중요

작업 항목 또는 작업이 동기화에 참가하도록 예약된 경우에는 프로젝트 계획에서 작업을 삭제해야 동기화에서 제거할 수 있습니다.작업에 할당된 팀 프로젝트에 게시 값은 수정할 수 없으며 Team Foundation에서 Project Server에 전송 필드를 변경할 수도 없습니다.또한 작업을 Team Foundation Server에 게시하거나 전송한 후에는 다른 작업 항목 형식으로 변경할 수 없습니다.

Updates to Mapped and Mirror Fields

단계

동기화 프로세스

필드 업데이트

Step 1

Team Foundation 동기화: 동기화 엔진이 Project Server에 게시된 추가 및 변경 내용을 자동으로 검색하여 Team Foundation Server로 가져옵니다.

이 단계에서는 Project Server에서 Team Foundation Server로 매핑된 필드(targetToTfs 매핑)만 업데이트됩니다. 동기화 엔진은 미러 필드는 항상 업데이트하지만 참조 필드는 OnConflict 특성이 PSWin으로 설정된 경우에만 업데이트합니다. 그러나 작업을 Project Server에 처음 게시하는 경우에는 OnConflict 특성이 할당된 값과는 상관없이 참조 필드와 미러 필드가 모두 설정됩니다. 미러 필드는 읽기 전용입니다.

남은 작업 시간 및 완료된 작업 필드에 대해서는 기본적으로 OnConflict 특성이 지정되지 않습니다. 따라서 Team Foundation Server와 Project Server간에 매핑된 필드가 다를 수 있습니다. 자세한 내용은 이 항목 뒷부분의 시간이 포함된 필드 업데이트를 참조하세요.

Step 2

상태 동기화: 팀 멤버가 Project Server에 전송으로 설정된 작업 항목을 추가하거나 수정하면 동기화 엔진이 업데이트를 상태 큐에 자동으로 전송합니다.

상태 큐에 전송하기 위해 매핑된 필드(tfsToTarget 매핑)만 전송됩니다.

시작 및 종료 날짜 변경 내용은 작업 항목을 처음 전송할 때만 전송됩니다. Team Foundation의 필드는 Project의 자원 필드에 매핑되므로 자원 남은 작업 시간, 자원 완료된 작업 등의 자원 필드에 대해 업데이트가 수행됩니다.

Step 3

승인 동기화: 승인된 업데이트는 Enterprise 프로젝트 계획 내에 표시됩니다. 승인 또는 거부 알림은 Team Foundation의 작업 항목 기록에 작성됩니다.

Project Professional용 Team Foundation 추가 기능을 사용하면 pjTask* 필드 및 pjResource* 필드 값을 올바르게 동기화할 수 있습니다. 따라서 Visual Studio 2013 또는 Team Explorer 2013이 설치된 클라이언트 컴퓨터에서 Project Professional을 사용하여 팀 프로젝트에 매핑된 Enterprise 프로젝트 계획을 편집해야 합니다.

Step 4

게시 동기화: 프로젝트 관리자가 프로젝트 계획을 게시하면 업데이트가 Project Server에 기록됩니다.

프로젝트 계획의 모든 작업에 대한 변경 내용은 Project Server에서 업데이트됩니다.

자세한 내용은 다음 항목을 참조하십시오.

거부된 전송 업데이트

프로젝트 관리자가 요구 사항이나 작업에 대한 상태 업데이트를 거부하면 거부를 해결할 때까지 해당하는 작업 항목이 더 이상 동기화되지 않습니다. 거부 이유가 기록 필드에 표시되며 Project Server 탭의 마지막 승인 상태 필드에 거부됨이 표시됩니다. 팀 멤버는 작업 항목 동기화를 다시 시작하려면 거부 상태를 변경해야 합니다.

업데이트 상태가 거부됨인 작업 항목을 찾는 팀 쿼리를 만들 수 있습니다. 자세한 내용은 작업 항목 전송 모니터링 및 거부 해결을 참조하십시오.

제목 또는 작업 이름 업데이트

Team Foundation Server의 제목 필드와 Project Server의 작업 이름은 양방향 동기화 프로세스에 사용됩니다. 즉, 한 서버의 변경 내용이 다른 서버에 항상 업데이트됩니다. 그러나 제목(System.Title) 필드의 매핑을 변경하는 경우 이 동작을 변경할 수 있습니다.

시작 및 완료 날짜 업데이트

일정 필드는 단방향 동기화 프로세스에 사용됩니다. 다시 말해서 Team Foundation Server의 시작 날짜 및 종료 날짜 필드는 Project Server에서 할당된 값을 항상 반영하며 Team Foundation Server에서 이러한 필드에 대해 수행하는 변경 내용은 Project Server에 전송되지 않습니다. Project는 일정 엔진을 사용하여 작업의 시작 날짜와 완료 날짜를 결정하므로 이러한 규칙이 적용됩니다.

기본적으로 시작 날짜 및 완료 날짜 필드는 OnConflict="PSWin"과 매핑되므로 Team Foundation의 날짜 필드는 항상 Project Server에서 할당된 값을 반영합니다. 두 값 집합을 허용하도록 매핑 특성을 변경하더라도 작업 항목을 처음 전송하는 경우를 제외하면 Team Foundation의 날짜 필드에 대한 변경 내용은 Project Server로 전송되지 않습니다. 첫 번째 동기화 이벤트 이후에는 이러한 필드가 프로젝트 계획에 대해 수행된 업데이트를 반영합니다.

시간이 포함된 필드 업데이트

기본적으로 완료된 시간 및 남은 시간 필드는 두 값 집합을 유지 관리하는 동기화 프로세스에 사용됩니다. 시간은 프로젝트 계획 또는 Team Foundation에서 변경될 수 있습니다. 그러나 변경을 할 때 이 두 위치의 정보를 반드시 덮어쓰는 것은 아닙니다. 매핑 필드에 대해 정의되지 않은 OnConflict 특성이 이 기능을 적용합니다.

아래 시나리오에 나와 있는 것처럼 업데이트 수행자 및 업데이트가 프로젝트 계획으로 수락되는지 여부에 따라 필드가 업데이트됩니다.

  • 팀 멤버가 시간을 업데이트한 후 프로젝트 관리자가 전송을 승인하고 계획을 게시하면 참조 필드와 미러 필드가 Team Foundation Server의 다음 동기화와 일치하게 됩니다.

  • 팀 멤버가 시간을 업데이트했는데 프로젝트 관리자가 전송을 거부하면 업데이트가 프로젝트 계획으로 수락되지 않습니다. 이 경우 참조 필드와 미러 필드의 값이 달라집니다.

  • 프로젝트 관리자가 프로젝트 계획에서 시간을 변경하면 Team Foundation Server의 다음 동기화에서 미러 필드만 업데이트됩니다.

두 서버 제품 간에 작업 시간이 다르면 팀 리더와 프로젝트 관리자는 차이를 조정해야 합니다. 이러한 방식으로 각 멤버는 다른 멤버가 적용하는 변경 내용을 확인하면서 독립적으로 작업을 업데이트할 수 있습니다. 값이 미러 필드와 일치하지 않는 필드를 찾는 방법에 대한 자세한 내용은 Find Work Items Where the Work in Team Foundation Differs from that in Project Server를 참조하세요.

프로젝트 관리자가 초기 계획을 설정할 때마다 다음 그림과 같이 Team Foundation의 원래 예상 값 필드 값이 업데이트됩니다. 이 필드는 기본적으로 OnConflict="PSWin" 특성에 매핑됩니다.

Work estimates

참고

Visual Studio 스크럼 프로세스 템플릿은 완료된 작업 및 원래 예상 값 필드를 사용하지 않으므로 데이터 동기화에 사용할 작업 항목 형식에 이러한 필드를 추가해야 합니다.또한 작업 종류 정의를 수정하여 <EMPTY /> 워크플로 문을 제거해야 합니다.자세한 내용은 스크럼 프로세스 템플릿에서 만든 팀 프로젝트에 매핑할 때 필요한 변경 사항을 참조하세요.

배정 또는 자원 이름 필드 업데이트

Team Foundation의 배정 대상 필드는 Project Server의 자원 이름 필드에 매핑됩니다. 이 필드는 기본적으로 OnConflict="PSWin" 특성에 매핑됩니다. Enterprise 프로젝트 계획에서 자원을 작업에 배정할 때는 다음 규칙을 고려하세요.

  • 동기화 엔진은 두 서버 제품 간에 자원 정보를 동기화하지 않습니다. 기본적으로 Team Foundation Server는 Active Directory에서 자원을 동기화하지만 Project Server는 동기화하지 않습니다. Project Server에서 수동으로 자원을 추가할 수 있습니다. 가장 좋은 방법은 Active Directory와 자원을 동기화하는 것입니다. Team Foundation Server와의 동기화에 참가하는 Enterprise 프로젝트 계획에서 작업에 자원을 할당하려면 Project Server에 자원을 추가해야 합니다. PWA 인스턴스에서 팀 멤버 그룹에 자원을 추가하거나 Project에서 프로젝트 열기 및 프로젝트 사이트 보기 권한을 자원에 부여합니다. 또한 동기화 엔진이 업데이트된 리소스 목록에 액세스할 수 있도록 Enterprise 프로젝트 계획에 대해 자원 목록에 자원을 추가한 다음 프로젝트 계획을 게시해야 합니다. 자세한 내용은 TFS와 Project Server 통합을 지원하기 위한 권한 할당을 참조하십시오.

  • 프로젝트 세부 정보를 관리하는 경우에는 각 작업에 자원을 하나씩만 배정합니다. 자원이 여러 개 필요한 작업은 여러 하위 작업으로 분할하고 각 하위 작업에 자원을 하나씩 배정합니다.

    하향식 계획을 통해서만 비즈니스 요구 사항을 관리하는 경우 각 사용자 스토리 또는 요구 사항을 개발 리드에게 배정합니다.

    프로젝트 계획을 게시할 때 Team Foundation용 클라이언트 추가 기능은 각 작업에 자원이 하나만 배정되었는지를 확인합니다. 작업에 여러 자원이 배정된 경우에는 유효성 검사 확인 대화 상자가 표시되며, 하나의 자원만을 활성 배정으로 지정해야 합니다. 자세한 내용은 유효성 검사 오류 해결을 참조하십시오.

  • 작업을 작업 항목에 연결하거나 매핑한 후에는 롤업되지 않은 작업에만 자원을 배정하거나 다시 배정할 수 있습니다. 롤업된 작업은 연결되지 않은 자식 작업 항목을 포함하는 작업 항목과 연결됩니다. 일반적으로 롤업된 작업의 자원 이름 필드에는 이름이 여러 개 포함됩니다. 동기화 엔진은 각 자원이 작업한 시간과 자원 롤업을 전송합니다. 자세한 내용은 팀 프로젝트에 매핑된 Enterprise 프로젝트의 리소스 롤업 사용을 참조하십시오.

요약 작업, 작업 계층 구조 및 여러 수준에서 중첩된 작업 항목 전송

동기화 엔진은 Enterprise 프로젝트 계획에서 하위 작업을 포함하는 연결된 작업에 대해 Project 필드를 업데이트하지 않도록 설계되어 있습니다. 프로젝트 계획이 이러한 작업의 작업량을 계산하므로 동기화 프로세스에서는 이러한 작업의 업데이트를 건너뜁니다. 제목 및 기타 비작업 필드에 대한 변경 내용도 이러한 작업에는 업데이트되지 않습니다. 이 동작은 두 서버 제품의 통합과 관련하여 알려진 제한입니다.

프로젝트 관리자가 요구 사항 및 연결된 작업을 포함하는 세부 작업 집합을 Team Foundation Server에 게시하면 동기화 엔진이 작업 계층 구조를 잠급니다. 팀 멤버는 Team Foundation에서 작업 계층 구조를 수정할 수는 없지만 팀 프로젝트의 팀 멤버에게 작업을 다시 배정할 수는 있습니다. 다음 그림과 같이 작업은 요구 사항 아래에 나열되며 부모 및 자식 작업 간의 계층 링크는 잠겨 있습니다(Locked link icon). 잠긴 링크는 요구 사항 및 자식 작업이 Project Server에서 팀 프로젝트에 추가되었음을 나타냅니다. 프로젝트 계획의 프로젝트 관리자만이 작업 계층 구조를 수정할 수 있습니다.

Work breakdown schedule in Team Explorer

팀이 Team Foundation에서 Project Server에 여러 작업 항목 수준을 전송할 때는 첫 번째 수준이 승인되어 Project Server에 게시되어야 다음 수준을 전송할 수 있습니다. 예를 들어 팀이 3개 자식 항목 수준을 포함하는 새 작업 항목 배치를 전송하는 경우 프로젝트 관리자가 프로젝트 계획을 4번 게시해야 모든 작업 항목이 Project Server와 동기화됩니다. 프로젝트 관리자가 각 작업 항목 수준을 승인하고 Project Server에 게시하면 전체 링크 계층이 잠길 때까지 계층 링크 관계가 Team Foundation에서 잠깁니다. 팀 멤버는 이와 같은 매핑된 작업 항목의 계층 구조를 수정할 수 없습니다.

선택 목록 또는 조회 테이블과 연결된 필드 업데이트

선택 목록과 연결된 Team Foundation Server 필드 또는 조회 테이블과 연결된 Project Server 필드를 매핑할 때는 효율적인 사용자 환경을 유지하기 위해 추가 단계를 고려해야 합니다. 동기화 엔진은 이러한 목록이나 테이블에 해당하는 연결된 목록을 자동으로 만들거나 다른 서버에서 허용된 값을 동기화하지 않습니다. 이러한 경우에는 Team Foundation에 정의된 선택 목록과 일치하도록 Project Server에서 조회 테이블을 만들고 Project Server에 정의된 조회 테이블과 일치하도록 Team Foundation에서 선택 목록을 만드는 것이 가장 좋습니다. 선택 목록 또는 조회 테이블이 변경되는 경우에는 항상 다른 서버 제품의 해당 목록을 수동으로 업데이트해야 합니다.

참고 항목

개념

데이터 동기화를 지원하기 위해 TFS에 추가된 Project Server 필드

기타 리소스

TFS와 Project Server 통합을 사용하여 프로젝트 관리

TFS와 Project Server 간 필드 매핑 사용자 지정