PMP Drag and Drop 문제_1

 

1. 한 회사가 비즈니스의 디지털 트랜스포메이션 프로젝트를 추진하기 위해 교차 기능 팀을 만들었습니다. 이 팀은 가능한 한 짧은 시간 내에 시장 요구를 해결하는 MVP(Minimum Viable Product)를 제공할 것으로 예상됩니다.

 

 

 

답 :

1. Development Team (개발 팀)
   → Determine how to organize and carry out work to complete the minimum viable product (MVP)
2. Project Manager/Scrum Master (프로젝트 매니저/스크럼 마스터)
   → Take responsibility for removing blockers that affect the team’s productivity
3. Product Owner (제품 책임자, PO)
   → Determine the version of the product that can be released to the market

2. 자동차 회사의 프로젝트 관리자가 복잡한 프로젝트에 대한 활동을 계획하고 있습니다 . 프로젝트 요구 사항 중 일부는 고정되어 있고 일부는 유연합니다 . 왼쪽의 항목을 프로젝트 관리자가 사용하는 오른쪽의 방법론과 일치시킵니다

Drog and Drop

답 :

• Estimate "tire compound mixing" duration and include it in the project schedule -> 예측적 방법론, Traditional Methodology
• Assign story points to the stories in the backlog -> 애자일 방법론, Agile Methodology
• Get team members' support to estimate duration or complexity -> All Methodologies
• Make sure each project phase ends when an iteration ends and vice versa -> Hybrid

 

Predictive Methodology (예측적 방법론)

문장: "Estimate 'tire compound mixing' duration and include it in the project schedule."

✅ 전통적 예측 기반(Predictive / Traditional Methodology)과 연결된 이유

• Predictive 방식은 사전에 프로젝트 전체 일정을 계획하는 방식입니다.
• 특정 작업(예: 타이어 화합물 혼합, "tire compound mixing")의 소요 시간을 미리 예측하고, 이를 고정된 프로젝트 일정에 포함시키는 것은 전통적인 예측 방법론에서 흔히 사용됩니다.
• 특징:
  • 전체 프로젝트의 작업을 초기 계획 단계에서 상세하게 예측함.
  • 변경을 최소화하고 가능한 한 세부적인 일정(Schedule)을 확정함.

📌 왜 Predictive인가?
✅ 작업을 사전에 예측하여 일정에 포함하는 것은 전통적인 계획 방식.
✅ Predictive 방식에서는 프로젝트 시작 전에 전체적인 작업 시간을 계산하고 스케줄을 고정함.

Agile Methodology (애자일 방법론)

문장: "Assign story points to the stories in the backlog."

✅ 애자일 방법론(Agile Methodology)과 연결된 이유

• 애자일에서는 작업 단위를 "스토리(Story)"로 정의하고, 스토리 포인트를 할당하여 상대적인 복잡도나 난이도를 평가합니다.
• 스토리 포인트는 절대적인 시간이 아니라, 다른 작업과 비교했을 때의 상대적인 복잡도를 나타내는 방식입니다.
• 특징:
  • 애자일에서는 정확한 일정 예측보다는 작업의 상대적인 크기를 추정함.
  • 팀이 협업하여 스토리 포인트를 활용한 우선순위 및 일정 조정을 진행함.
  • 개발이 짧은 반복 주기(Sprint)로 진행되므로 고정된 일정이 아님.

📌 왜 Agile인가?
✅ 애자일에서는 일정을 고정하는 대신, 작업의 난이도와 크기를 상대적으로 추정함.
✅ 예측 기반 방식처럼 미리 확정된 일정이 아니라, 매 스프린트마다 조정 가능.

All Methodologies (모든 방법론에서 사용 가능)

문장: "Get team members' support to estimate duration or complexity."

✅ 모든 방법론과 연결된 이유

• 어떤 방법론을 사용하든, 프로젝트의 작업을 정확하게 예측하려면 팀원들의 피드백과 지원이 필요합니다.
• 예측적 방법론에서는 초기 계획 단계에서 팀원들에게 작업 시간을 묻고,
• 애자일 방법론에서는 팀원들이 스토리 포인트를 협의하고,
• 하이브리드 방법론에서도 각 방식에 맞춰 팀원들과 협력하여 추정합니다.
• 특징:
  • 프로젝트 방법론과 관계없이, 팀원들과 협업하여 일정과 난이도를 평가하는 것은 모든 프로젝트에서 중요한 요소.

📌 왜 All Methodologies인가?
✅ 팀원들의 협조를 얻어 일정이나 난이도를 예측하는 것은 Predictive, Agile, Hybrid 모두에서 적용 가능.
✅ 모든 프로젝트에서 팀원과 협력하여 정확한 일정과 복잡도를 예측해야 함.

Hybrid Methodology (하이브리드 방법론)

문장: "Make sure each project phase ends when an iteration ends and vice versa."

✅ 하이브리드 방법론(Hybrid Methodology)과 연결된 이유

• 하이브리드 방법론은 Predictive(예측 기반)과 Agile(애자일)을 결합한 방식입니다.
• 여기서 중요한 점은 전통적인 프로젝트의 "단계(Phase)"와 애자일의 "이터레이션(Iteration)"을 동기화하는 것입니다.
• 전통적인 예측 기반 프로젝트에서는 각 단계가 명확한 종료 시점을 가지며, 단계별 승인(Gate) 후 다음 단계로 이동합니다.
• 애자일에서는 짧은 주기의 이터레이션(Sprint 또는 Iteration)이 반복되면서 결과물이 점진적으로 개선됩니다.
• 하이브리드에서는 두 가지 방식을 결합하여, 각 프로젝트 단계가 애자일 이터레이션과 맞물려 진행되도록 조정합니다.

📌 왜 Hybrid인가?
✅ 예측 기반 방식의 Phase 종료 시점과 애자일의 Iteration 종료 시점을 동기화하는 방식은 두 가지 방법론을 결합하는 것.
✅ 예측 기반(Predictive)의 명확한 일정 관리와 애자일(Agile)의 유연한 개발 주기를 함께 운영하는 방식.

 

3. 프로젝트의 기술을 현대화하기 위한 노력의 일환으로 프로젝트 관리자는 프로젝트 팀과 위험 우선 순위에 대해 논의해 왔습니다. 프로젝트 관리자는 프로젝트 위험을 반복적으로 평가하고 우선 순위를 지정하기 위해 추가 매개 변수가 필요하다고 결정합니다.

답 :

• Assess the amount of time before the risk can impact one or more project objectives.
  → Proximity (근접성)
  • Proximity(근접성)은 특정 리스크가 발생하기 전까지의 시간(얼마나 빠르게 영향을 미칠지)을 평가하는 요소입니다.
  • 즉, 리스크가 프로젝트 목표에 영향을 미치기까지의 시간을 측정합니다.
• Assess if the risk is related to other individual project risks.
  → Connectivity (연결성)
  • Connectivity(연결성)은 해당 리스크가 다른 프로젝트 리스크와 어떤 관계가 있는지를 평가하는 요소입니다.
  • 어떤 리스크는 단독으로 존재하지만, 다른 리스크와 상호작용할 수도 있습니다.
• Assess how quickly the risk response needs to be implemented in order to be effective.
  → Urgency (긴급성)
  • Urgency(긴급성)은 리스크에 대한 대응이 얼마나 빠르게 이루어져야 하는지를 평가합니다.
  • 즉, 대응이 지연되면 프로젝트에 더 큰 영향을 미칠 가능성이 있는 리스크를 식별하는 데 사용됩니다.
• Assess how long after a risk has occurred before its impact is discovered.
  → Dormancy (휴면성)
  • Dormancy(휴면성)은 리스크가 발생한 후, 그것이 프로젝트에 영향을 미치기까지 걸리는 시간을 측정하는 요소입니다.
  • 즉, 리스크가 잠재적으로 존재하지만 즉시 감지되지 않고 나중에야 발견될 수 있습니다.요약 
• Proximity (근접성) → 리스크가 프로젝트 목표에 영향을 미치기까지 걸리는 시간
• Connectivity (연결성) → 특정 리스크가 다른 리스크와 얼마나 연결되어 있는지
• Urgency (긴급성) → 리스크 대응이 얼마나 빨리 이루어져야 하는지
• Dormancy (휴면성) → 리스크가 발생하고 나서 실제 영향을 미칠 때까지의 시간

 

4. 왼쪽에 있는 Tuckman’s Ladder 단계의 특성을 오른쪽에 있는 올바른 단계(Forming, Storming, Norming, Performing, Adjourning)와 연결하십시오.

답 :

Tuckman의 팀 개발 5단계(Stage of Team Development)

• Forming (형성 단계):
  • 팀원들이 처음 만나고, 역할과 목표를 정의하는 시기입니다.
  • 이때는 주로 각자 독립적으로 일하며 조심스러운 분위기가 형성됩니다.
• Storming (격동 단계):
  • 팀원 간 갈등이 발생하고 의견 충돌이 생기는 단계입니다.
  • 서로의 차이를 극복하는 과정에서 협업이 어려울 수 있습니다.
• Norming (정리 단계):
  • 팀원들이 서로 신뢰를 형성하고 협력하는 방법을 조율합니다.
  • 갈등이 줄어들고 협력적인 관계가 발전하는 시기입니다.
• Performing (성과 단계):
  • 팀이 안정적으로 운영되며, 높은 수준의 협업과 독립적인 업무 수행이 가능해집니다.
  • 효과적인 커뮤니케이션과 생산성이 극대화되는 단계입니다.
• Adjourning (해산 단계):
  • 프로젝트가 종료되고, 팀원들이 다른 프로젝트로 이동하거나 팀이 해체됩니다.
  • 성공적인 마무리를 위한 평가와 피드백이 이루어지는 시기입니다.

 

5. 왼쪽의 커뮤니케이션 이벤트를 오른쪽의 각 이벤트 중 논의된 주요 주제와 연결하십시오.

 

답: 

 

• Daily Meeting (일일 미팅)
  • 매일 진행되며, 팀원들이 작업 진행 상황을 공유하는 자리.
  • 장애물이나 문제를 신속히 파악하고 해결하기 위한 목적.
• Iteration Retrospective (이터레이션 회고)
  • 이터레이션이 끝난 후 진행되는 회고 회의.
  • 팀이 개선할 점을 찾고, 향후 더 나은 프로세스를 만들기 위한 논의.
• Iteration Planning (이터레이션 계획)
  • 새로운 이터레이션을 시작하기 전에 목표와 작업 계획을 수립하는 회의.
  • 백로그에서 우선순위가 높은 작업을 선정하고, 구체적인 목표를 설정.
• Iteration Review (이터레이션 리뷰)
  • 이터레이션 종료 후 작업 결과물을 검토하는 회의.
  • 스프린트 목표가 달성되었는지, 백로그 아이템이 완료되었는지 평가.

 

6. 한 병원이 청구, 환자 데이터 및 기록 관리를 포함한 내부 중요 시스템 프로젝트를 실행 중입니다.
왼쪽의 각 위험 유형을 오른쪽의 올바른 예제와 연결하십시오.

답;

기술적 위험 (Technical Risk) -

Availability of the output formats of the files to interface with the data and record management systems on time as they are not available with the project manager
프로젝트 관리자가 사용할 수 없기 때문에 데이터 및 기록 관리 시스템과 인터페이스하기 위한 파일 출력 형식의 가용성이 제때에 제공되지 않음 

 

상업적 위험 (Commercial Risk) -

Needs regulatory compliance and clearance standards for incorporation into the system
시스템에 통합하기 위해서는 규정 준수 및 승인 기준이 필요합니다. 

 

관리적 위험 (Management Risk) -

Availability of resources for the documentation and user manual preparation needs as this was not originally planned to be taken up by the project team
프로젝트 팀에서 원래는 이를 담당할 계획이 아니었지만 문서화 및 사용자 매뉴얼 준비에 필요한 리소스의 가용성

 

외부 위험 (External Risk) -

The interfaces to medical devices require support from vendors
의료 기기 인터페이스에는 공급업체의 지원이 필요합니다.

7. 프로젝트 관리자가 팀 구성원 중 한 명과 의사 소통하는 데 어려움을 겪고 있습니다 . 팀 구성원은 최근 교육 과정에 참석하여 다른 팀 구성원에게 새로운 애자일 기술을 교육하고 있습니다 . 그러나 때로는 팀원이 다른 팀원이 불편해하더라도 아이디어를 밀어붙이는 데 강압적입니다 . 프로젝트 관리자가 이 팀 구성원과 어떤 커뮤니케이션 스타일을 사용할지 결정할 때 고려해야 할 성격 지표는 무엇입니까 ?
왼쪽의 설명을 오른쪽의 적절한 커뮤니케이션 스타일과 연결하십시오.

 

 

답 : Extroverted (E), Judging (J)

 

 

• 내향형 (I): 조용하고 신중하며, 혼자서 일하는 것을 선호함. 깊이 있는 관계를 선호하며, 내면의 사고를 중요하게 여김.
• 외향형 (E): 사교적이며 활발하게 사람들과 교류하는 것을 선호함. 팀 활동을 좋아하고, 에너지를 외부 환경에서 얻음.

 

• 판단형 (J): 계획적이고 체계적인 업무 스타일을 선호함. 명확한 일정과 목표를 세우며, 일관된 방식으로 문제를 해결하려 함.
• 인식형 (P): 유연하고 즉흥적인 스타일을 선호함. 변화를 수용하며, 상황에 따라 계획을 바꾸는 것을 편안하게 여김.

 

8. 경험이 풍부한 프로젝트 관리자가 인수 합병 프로젝트를 감독 중입니다.
왼쪽의 완화 전략을 오른쪽의 프로젝트 관리자의 작업과 연결하십시오.

답 : 

 

• 완화 (Mitigate) ↔ 프로젝트 관리자가 위협을 분석하고, 발생 가능성을 줄이기 위한 조치를 취했으며 추가 테스트를 수행함. (the project manager analyzed the threat, took action to reduce the probability of occurence, and conducted som additional test.)
  
  • 리스크 완화(Mitigation)는 위협이 발생할 가능성을 줄이거나 그 영향을 최소화하는 전략입니다. 프로젝트 관리자가 위협을 분석하고 추가 테스트를 수행하는 것은 리스크를 줄이려는 적극적인 대응 전략에 해당합니다.
• 수용 (Accept) ↔ 프로젝트 관리자가 위협을 식별했지만, 조치를 취하지 않고 주기적으로 검토하기로 결정함.(the project manager identified the threat and decided to review it periodically rather than take action)
  • 리스크 수용(Acceptance)은 위협이 존재하지만, 그 영향이 크지 않거나 조치가 어렵기 때문에 받아들이는 전략입니다. 위협을 주기적으로 검토하면서 상황을 모니터링하는 것은 ‘소극적 수용’의 대표적인 예시입니다.
• 회피 (Avoid) ↔ 프로젝트 관리자가 위협을 심각하게 판단하고, 프로젝트 전략을 변경하며 범위를 줄여 리스크를 제거함. (the project manager determined the threat was severe and acted promptly to handle this risk by changing project strategies and reducing project scope) 
  • 리스크 회피(Avoidance)는 위협을 완전히 없애거나 프로젝트에서 제거하는 전략입니다. 프로젝트 전략을 변경하고 범위를 줄이는 것은 위협 자체를 제거하려는 적극적인 회피 전략입니다.
• 확대 (Escalate) ↔ 프로젝트 관리자가 위협을 분석한 결과, 자신의 권한과 범위를 벗어난다고 판단함 (the project manager studied the threat and found it is out of their authority and scope)
  • 리스크 확대(Escalation)는 프로젝트 관리자가 직접 해결할 수 없는 리스크를 상위 조직이나 관련 부서에 보고하는 것입니다. 위협이 자신의 권한을 벗어난다고 판단한 것은 이를 상위로 보고해야 한다는 의미이므로, 확대 전략에 해당합니다.
• 전가 (Transfer) ↔ 프로젝트 관리자가 위협을 인식한 후, 스폰서와 논의하여 보험을 구매하는 방식으로 리스크를 처리함.( The project manager idendified the treat, discussed it with the sponsor, and bought and insurance plan to handle it)
  • 리스크 전가(Transfer)는 리스크를 제3자(보험사, 계약업체 등)에게 이전하는 전략입니다. 보험을 구매하는 것은 전형적인 리스크 전가 방법 중 하나로, 재정적 위험을 줄이기 위해 활용됩니다.

8-1. 프로젝트 관리자는 주요 이해 관계자가 프로젝트에 참여하지 않는 것을 걱정하고 이해 관계자가 더 많이 참여했을 때 최종 제품이 좋지않다는 결론을 내렸습니다 . 왼쪽의 시나리오를 오른쪽의 올바른 위험 대응 전략으로 끌어옵니다

 

• Check for options to exclude the stakeholder
  → Avoid (회피)
  • 특정 이해관계자가 프로젝트에 부정적인 영향을 미칠 경우, 프로젝트에서 제외하는 것은 리스크를 완전히 회피(Avoid)하는 전략입니다.
• Analyze if someone else could contribute
  → Transfer (이전)
  • 리스크를 제3자(다른 사람이 기여할 수 있는지 분석)에게 넘기는 것은 리스크 이전(Transfer) 전략에 해당합니다.
• Discuss with the stakeholder and earn buy-in
  → Mitigate (완화)
  • 이해관계자와 논의하여 협력을 이끌어내는 것은 리스크의 영향을 줄이는 완화(Mitigate) 전략입니다.
• Record the observations and move ahead
  → Accept (수용)
  • 특별한 조치를 취하지 않고 리스크를 받아들이는 것은 수용(Accept) 전략에 해당합니다.
• Address the issue with the stakeholder's superior
  → Escalate (상향 보고)
  • 프로젝트 매니저가 해결하기 어려운 리스크를 상위 관리자(이해관계자의 상사)에게 보고하는 것은 상향 보고(Escalate) 전략입니다.

 

9. 정부 기관의 프로젝트 관리자가 이해 관계자 참여 문제를 해결하고 있습니다.
왼쪽의 프로젝트 관리자가 사용해야 하는 대인 관계 기술을 오른쪽의 올바른 상황과 연결하십시오.

답:

• 의사결정 (Decision Making) ↔ 현장 근로자들이 작업 환경에 대한 불만을 자주 제기하지만, 프로젝트 관리자는 이를 개선할 수 없는 상황.(Site workes often come up with comlpains about working conditions, but the project manager cannot improve the conditions) 
  • 프로젝트 관리자는 제한된 권한 속에서도 근로자들의 불만을 효과적으로 처리해야 합니다. 이러한 상황에서는 작업 환경을 직접 개선할 수 없어도, 근로자들의 우려를 듣고 해결 가능한 대안을 마련하는 등 신속한 의사결정 능력이 필요합니다.
• 협상 (Negotiation) ↔ 새로운 정부가 출범했고, 프로젝트 관리자가 정부 정책 개혁을 위한 의장직을 맡게 됨.(A new govermment has been formed, and the project manager has been awarded a chair position to reform goverment policies)
  • 정부 정책 개혁을 위해서는 다양한 이해관계자와의 협상이 필수적입니다. 프로젝트 관리자는 정책을 추진하는 과정에서 여러 부처 및 이해관계자와 협의하며 균형 잡힌 결정을 내려야 하므로 협상력이 중요합니다.
• 정치적 인식 (Political Awareness) ↔ 프로젝트 관리자는 정부 내 불안정한 상황과 현재 정부 지도자의 사임 가능성에 대한 정보를 지속적으로 파악하고자 함.(the project manager wants to stay updated on instability in the goverment and the possibility that the current govermment leader may resign.)
  • 정치적 변화는 프로젝트 운영에 큰 영향을 미칠 수 있습니다. 따라서 프로젝트 관리자는 정부의 정책 변화나 정치적 불안정성에 대한 정보를 지속적으로 파악하여 이에 따른 전략을 세울 필요가 있습니다.
• 문화적 인식 (Cultural Awareness) ↔ 프로젝트 관리자가 다른 문화적 배경을 가진 사람들이 사는 지역에서 일해야 하는 상황. ( The project manager is assigned to work in rural area where people have different customs)
  • 문화적 차이를 이해하고 존중하는 것은 원활한 프로젝트 수행에 필수적입니다. 특히, 새로운 환경에서 지역 주민이나 근로자와 원만한 관계를 유지하고 협력하려면 문화적 인식이 필요합니다.

 

10. 애자일 팀이 여러 대륙에 걸쳐 지리적으로 분산되어 있습니다.
왼쪽의 해당 도구를 오른쪽의 각 프로젝트 작업과 연결하십시오.

답: 

 

• Online bulletin boards (온라인 게시판) - Routine information (정기적인 정보 공유)
  • 프로젝트 팀원들이 공지사항, 진행 상황, 일정 등을 공유하는 용도로 사용됩니다.
• Chat rooms (채팅방) - Team discussion (팀 토론)
  • 팀원 간 실시간으로 간단한 논의 및 의견 교환을 할 수 있는 공간입니다.
• Video conferencing (화상 회의) - Negotiation (협상)
  • 보통 원격 협상이나 중요한 논의가 필요할 때 사용됩니다.
• Version control system (버전 관리 시스템)- Project deliverables (프로젝트 산출물)
  • 소스 코드, 문서 등의 버전을 관리하여 프로젝트 산출물을 체계적으로 관리할 때 사용됩니다

 

11. 프로젝트 관리자가 개발 흐름이 잘 진행되지 않는다는 업데이트를 받습니다 . 일부 팀 구성원은 배송이 늦어 작업을 시작할 수 없습니 다 . Kanban 보드와 WIP(Work in Progress) 라인을 살펴보면 프로젝트 관리자가 병목 현상을 관찰합니다 . 아래 Kanban 보드에서 병목 현상을 완화하기 위해 추가 리소스가 필요한 큐의 제목을 클릭합니다

답: Test 단계의 WIP 제한을 늘리거나 추가 리소스를 투입하면 전체 작업 흐름이 원활

12. 왼쪽의 항목을 오른쪽의 올바른 프로젝트 접근 방식 내에서 일치하는 용어로 드래그합니다 .

답:

Requirements (요구사항)

• Predictive (예측적): "are defined up-front before development team begins"
  
  • 요구사항이 프로젝트 초기에 명확히 정의되며, 개발이 시작되기 전에 확정됩니다
• Agile (애자일): "are elaborated frequently during delivery"

2. Changes (변경 사항)

• Predictive (예측적): "are constrained as much as possible"
  • 변경 사항은 최소화되며, 프로젝트 진행 중에 변경을 최대한 억제합니다.
• Agile (애자일): "are elaborated frequently during delivery"

3. Risk and Cost (위험 및 비용)

• Predictive (예측적): "are controlled by detailed planning"
  • 세부적인 계획을 수립하여 위험과 비용을 관리합니다.
• Agile (애자일): "are incorporated in real-time during delivery"
  • 프로젝트 진행 중 실시간으로 위험과 비용을 조정하고 반영합니다.

4. Key Stakeholders (주요 이해관계자)

• Predictive (예측적): "are involved at specific milestones"
  • 특정 마일스톤(단계)에서만 이해관계자가 개입합니다.
• Agile (애자일): "are continuously involved"
  • 이해관계자가 개발 과정 전반에 걸쳐 지속적으로 참여합니다.

13. 프로젝트 팀은 네트워크 다이어그램 작성 방법을 사용하여 초기 일정을 개발하고 전체 프로젝트 기간에 도달했습니다 . 일정을 검토 한후 프로젝트 관리자는 잠재적인 일정 충돌을 완화하거나 제거하기 위해 버퍼가 필요할 수 있는 몇 가지 활동이 있음을 알게 됩니 다 . 다음 일반 용어를 버퍼 또는 제약 조건을 평가하는 설명과 일치시킵니다 .

1. Parkinson's Law (파킨슨의 법칙)
   ➤ 설명:
   “Workers use all the time allocated for an activity regardless of how long it actually takes to complete the task.”
   ⟶ 주어진 시간이 실제보다 많아도, 그 시간을 전부 쓰려고 하는 경향.
   📌 예: 2일짜리 일을 하루 만에 할 수 있어도 2일을 꽉 채워 일함.

---

1. Self-Protection (자기 보호)
   ➤ 설명:
   “Workers are reluctant to finish tasks early so as not to communicate their efficiency and set precedents for future tasks.”
   ⟶ 너무 빨리 일을 끝내면 앞으로도 그렇게 하길 기대할까 봐, 일부러 천천히 일함.
   📌 예: 상사가 다음번에도 같은 속도를 요구할까 봐 속도를 감춤.

---

1. Student Syndrome (학생 증후군)
   ➤ 설명:
   “Procrastination in starting activities can use up valuable slack built into the activity duration.”
   ⟶ 마감이 가까워질 때까지 미루다가 급하게 시작함.
   📌 예: 시험 전날 밤 벼락치기처럼 일을 미루다 결국 여유 시간을 다 써버림.

---

1. Dropped Baton (인계 실패)
   ➤ 설명:
   “An activity is not ready to start and the preceding activity finishes early, resulting in lost time between activities.”
   ⟶ 이전 업무는 빨리 끝났는데, 다음 사람이 준비가 안 되어 있어 지연 발생.
   📌 예: 개발팀이 일찍 마쳤는데 QA팀이 바로 시작할 준비가 안 됨.

14. 왼쪽의 조직 특성을 오른쪽의 올바른 시나리오로 드래그합니다

답:

Roadblock to achieving changes (변화를 가로막는 장애물) - "Work is decomposed into department silos, creating dependencies that prevent accelerated delivery." 업무가 부서별로 분리되어 있고, 각 부서 간의 의존성이 커서 신속한 작업 진행이 어려움.

Appetite for change by leading by example (변화를 선도하는 조직 문화)- "The scrum master tries to use agile techniques and practices wherever possible." 스크럼 마스터가 애자일 기법을 도입하고 확산시키려는 노력을 하고 있음.

Change tolerant (변화에 대한 수용력) - "Organization’s willingness to shift the way it views, reviews, and assesses employees." 조직이 직원 평가 방식이나 운영 방식을 변화시키려는 의지를 보이고 있음.

Change associated with agile (애자일과 관련된 변화)- "Decomposing work into iterative prototypes involves rework and needs change management techniques to address the hurdle of transitioning to agile." 반복적 프로토타입 개발 과정에서 추가적인 작업이 발생하며, 애자일 전환을 위한 변화 관리 기법이 필요함.

15 왼쪽의 대인 관계 스킬을 오른쪽의 올바른 시나리오로 드래그합니다

답 : 

Emotional Intelligence (감성 지능) - "Two team members are not agreeing with each other about a work item. Before the situation gets out of hand, the project manager interrupts and asks them to take a break and come back to the discussion later." 프로젝트 매니저가 감정적으로 격해질 수 있는 상황을 인식하고 중재함.

Networking (네트워킹)- "The project manager values a developer on the team who always interacts with partners and is a very good resource for making positive lasting contacts." 네트워킹은 다양한 사람들과 긍정적인 관계를 구축하는 능력.

Conflict Management (갈등 관리) - "A team member always yells and swears, making others uncomfortable. The project manager manages the group’s emotions so that others do not feel uncomfortable and asks the person to manage their emotions." 팀원 간의 갈등 상황을 프로젝트 매니저가 적극적으로 개입하여 해결하려 함.

Leadership (리더십)- "The project manager communicates the vision to stakeholders and inspires them to support the work and outcomes of the project." 프로젝트 매니저가 비전을 명확히 전달하고 이해관계자들을 동기부여하여 프로젝트를 성공적으로 이끌어감.

16. 팀은 일일 스탠드업 미팅에서 다음과 같은 장애를 보고했습니다 . 왼쪽의 각 장애물을 프로젝트 관리자가 오른쪽에서 수행해야 하는 작업으로 끌어옵니다

답:

 "I am waiting for resources from another team before I can continue on this story." - Escalate (문제 상황을 상위 관리자에게 보고 및 해결 요청)

"I finished my story but found that the acceptance criteria caused a conflict with another story."- Create or modify a story (스토리를 생성하거나 수정하기)

 

 "I had to work on something that was not on the task board." - Ask the product owner (제품 책임자에게 문의하기)

17. 애자일 프로젝트의 새로운 프로젝트 관리자는 예상되는 사항에 대한 혼란을 피하기 위해 기존 팀과 함께 일부 역할을 검토하고 있습 니다 . 왼쪽의 설명을 오른쪽의 적절한 역할로 드래그합니다 .

답:

"Discuss inter-dependencies within other projects" (다른 프로젝트와의 상호 의존성을 논의)- Scrum Master (스크럼 마스터) 

"Assign acceptance criteria and set goals" (승인 기준을 설정하고 목표를 정함)- Product Owner (제품 책임자)

"Assume leadership as needed" (필요할 때 리더십을 발휘)- Servant Leader (서번트 리더)

18. 새로운 제품 개발 프로세스에 따라 마케팅 부서는 비즈니스 및 사용자 요구 사항을 애자일 프로젝트 문서에 직접 추가하기 시작합니 다 . 왼쪽의 제품 정보를 오른쪽의 올바른 문서로 드래그합니다 .

답:

"Competitive differentiators a product can provide" (제품이 제공할 수 있는 경쟁적 차별 요소)- Product Vision (제품 비전)

• 제품 비전(Product Vision)은 제품이 달성하고자 하는 목표 및 시장에서의 차별점을 설명하는 문서임, 경쟁적 차별화 요소를 정의하는 데 중요한 역할을 함.

 "Description of how credit card data privacy is handled when a user makes a purchase" (사용자가 구매할 때 신용카드 데이터 개인정보 보호가 어떻게 처리되는지 설명)- Product Backlog (제품 백로그)

• 제품 백로그(Product Backlog)에는 개발할 기능과 비즈니스 요구 사항이 포함됨, 개인정보 보호 기능과 같은 요구 사항은 백로그에 정의되어 있으며, 개발팀이 이를 구현해야 함.

 "Confirmation that a test successfully showed that a user mistake is well handled" (사용자 실수가 잘 처리되었음을 테스트를 통해 성공적으로 확인)- Definition of Done (DoD)

• Definition of Done(DoD)은 기능이 완료되었음을 판단하는 기준을 설명하는 문서, 테스트를 통과하고 품질 기준을 충족해야 완료된 것으로 간주됨, 사용자 실수 처리 테스트가 성공적으로 수행되었다면, 해당 기능은 DoD 기준을 충족했다고 볼 수 있음.