공식 Scrum 및 Kanban 인증

Scrum 인증 시험 문제와 정답

실제 시험에 가장 가까운 예제 130문항

프로그램 Scrum Master Accredited Certification™, Scrum Product Owner Accredited Certification™, Scaled Scrum Expert Accredited Certification™, Agile Scrum Leadership (Executive) Accredited Certification™, Scrum Trainer Accredited Certification™, Agile Coach Accredited Certification™, Certified Kanban Expert (Kanban-EXP) Certification™, Certified Kanban Project Manager (Kanban-PM) Certification™, Scrum Team Member Accredited Certification™, Scrum Developer Accredited Certification™, Certified Professional In Design Thinking (CPDT) Certification™, Certified Professional In OKR (Objectives & Key Results) (CPOKR) Certification™의 시험과 매우 유사한 Scrum 인증 예제 문답을 복습하세요.

시험을 준비하세요

이 International Scrum Institute™는 는 기술·비기술 전 분야의 입문자부터 숙련자까지 지원자·강사·학습자를 돕습니다. PMI 프로젝트 관리부터 클라우드, Kubernetes 아키텍처, AI·데이터 과학과 그 사이 모든 애자일·사업 전문가를 지원합니다. 고객에게 더 잘 봉사하고 지속 가치를 만들도록 힘을 드립니다. 전문 Scrum Master를 포함한 모든 역할의 힘이 협업·문제 해결에 중요하며 회사 모두가 같은 이해로 일하게 합니다.

원하는 프로그램의 문답과 Scrum Master 시험 예제를 공부하면 어려움 없이 합격할 자신감을 갖습니다. 강좌, 교육, 자료, 모든 예제와 지원 자원은 훈련된 Scrum 전문가로서 성공적·효율적 업무를 보장합니다.

고급 Scrum 학습과 Master 문답 경험에서 효과적 시험 준비는 인증 지망자에게 필수입니다. 여러 어려움을 헤쳐야 하며 준비는 준비도를 평가하는 핵심입니다. 예제, 모의 시험지와 시뮬레이터 등 여러 자원으로 준비를 강화합니다.

이 도구들은 시험 환경을 종합적으로 보여줘 형식·구조에 익숙해지게 합니다. 예제와 모의 시험은 준비의 중요한 부분으로 Scrum의 세부 이해를 줍니다. 따라서 예제 시험·시뮬레이터를 활용하는 세심한 준비가 인증 성공에 필수입니다.

여러 시험 문제 연습은 다음을 더 잘 준비하게 한다는 보고가 있습니다.

  1. 사업의 건전성과 평판 지원,
  2. 사업 분야의 효과적 업무 촉진,
  3. 애자일 이해 강화와 Scrum Master 시험 준비 향상,
  4. 무엇보다 업계 자격을 손쉽게 높이기.

Scrum Guide 기반 강좌의 핵심 원칙·주제를 익히면 경력 전망을 높이고, 급변 시장에서 경쟁하려 애자일을 도입하는 기업에 귀중한 안내·지원을 제공할 수 있습니다.

일반 Scrum 시험 문제

문제 1 Scrum 관리 프레임워크로 어떤 소프트웨어 프로젝트를 수행할 수 있나요?

  1. 완전한 소프트웨어 패키지
  2. 고객 프로젝트
  3. 큰 시스템의 하위 시스템·구성 요소·일부
  4. 모든 유형의 소프트웨어 개발 프로젝트
  5. 해당 보기 없음

정답: 보기-4 / 모든 유형의 소프트웨어 개발 프로젝트

문제 2 애자일 선언의 기초가 아닌 것은?

  1. 과정·도구보다 개인·상호작용
  2. 포괄적 문서보다 작동하는 소프트웨어
  3. 사람보다 과정
  4. 계약 협상보다 고객 협업
  5. 계획 준수보다 변화 대응

정답: 보기-3 / 사람보다 과정

문제 3 Scrum 프레임워크가 정의하는 것은?
A) 규칙과 역할
B) 문서 지침
C) 산출물과 이벤트

  1. A
  2. B
  3. C
  4. A, B ,C
  5. A, C

정답: 보기-5 / A, C

문제 4 고객 요구는 어디에 저장하나요?

  1. Product Backlog에
  2. Sprint Backlog에
  3. 데이터베이스에
  4. Scrum 제품 요구 명세서에
  5. 어디에도 없음. Product Owner가 알고 있음

정답: 보기-1 / Product Backlog에

문제 5 다음 중 Scrum의 주요 역할은?
A) Scrum 테스터
B) Scrum 팀
C) Scrum 관리자
D) Scrum Master
E) Scrum Product Owner

  1. A, B, C, D, E
  2. B, C, D, E
  3. B, D, E
  4. A, B, D, E
  5. A, B, C, D

정답: 보기-3 / B, D, E

문제 6 다음 중 Scrum의 주요 이벤트는?
A) Sprint 계획 회의
B) Sprint 회고
C) Sprint 검토 회의
D) Sprint 중간 현황 검토 회의
E) 일일 Scrum 회의

  1. A, B, C, D, E
  2. A, B, C, D
  3. A, C, D, E
  4. A, B, C, E
  5. A, C, E

정답: 보기-4 / A, B, C, E

문제 7 프레임워크에 정의되지 않은 개념은?

  1. Scrum Master
  2. 프로젝트 관리자
  3. Scrum Product Owner
  4. 일일 Scrum
  5. Scrum 제품 번다운

정답: 보기-2 / 프로젝트 매니저

문제 8 모든 Scrum 프로젝트에서 중요한 것은?
A) 자기 조직화
B) 명확한 기업 위계
C) 의사소통
D) 지속적 개선

  1. A, B, C, D
  2. A, C, D
  3. A, D
  4. A
  5. A, B

정답: 보기-2 / A, C, D

문제 9 전통적 폭포수 모델의 단점은?
A) 최종 제품을 모두 미리 예상해야 함.
B) 초기에 정한 대로 구현해도 실제 고객에게 필요 없는 요구가 있음.
C) 각 단계가 엄격히 분리됨.

  1. A
  2. B
  3. C
  4. A, B
  5. A, B, C

정답: 보기-5 / A, B, C

문제 10 Scrum의 장점은?

  1. 세부 요구는 정말 필요할 때만 정의합니다.
  2. 특정 기능의 설계·구현·테스트를 한 단계에 모읍니다.
  3. 팀이 변화를 예상하고 환영합니다.
  4. 주어진 모든 보기
  5. 해당 보기 없음

정답: 보기-4 / 주어진 모든 보기



Scrum 인증 등록 >>



Scrum Master 인증 시험 문제

문제 11 개발 프로젝트의 Scrum Master입니다. 회고에서 John은 Product Owner Sarah가 기술적 어려움을 몰라 비현실적 스토리를 만든다며 불만을 말합니다.

효과적 대응으로 무엇을 해야 하나요?

  1. 각자 만나 걱정과 공통점을 논의합니다.
  2. 신뢰·협업을 강조하며 John에게 인내와 결정 신뢰를 권합니다.
  3. 회고에서 John·Sarah의 공개 논의를 촉진해 걱정을 다루고 협업을 돕습니다.
  4. John을 다른 Product Owner의 팀으로 옮겨 갈등을 피합니다.
  5. 책임 밖이므로 무시하고 팀이 알아서 해결하게 합니다.

정답: 보기-3 / 회고에서 John·Sarah의 공개 논의를 촉진해 걱정을 다루고 협업을 돕습니다.

문제 12 팀이 Sprint 역량을 자주 넘어 미완료 작업이 쌓입니다. 과도한 확약으로 소진되는 듯합니다.

문제 해결·성과 개선을 위해 무엇을 해야 하나요?

  1. 높은 확약을 지키도록 더 효율적으로 코칭합니다.
  2. 걱정을 전달하고 역량에 맞춰 범위를 줄이자고 합니다.
  3. 확약한 백로그를 끝내도록 더 오래 일하게 합니다.
  4. 완료 시간을 늘리려 Sprint 연장을 제안합니다.
  5. 현실적 목표를 논의하고 Product Owner와 백로그 정제를 협상합니다.

정답: 보기-5 / 현실적 목표를 논의하고 Product Owner와 백로그 정제를 협상합니다.

문제 13 팀은 고립된 작업과 부족한 교차 협업으로 소통 문제가 있습니다. 개방·투명 문화가 크게 개선할 것 같습니다.

어떻게 개방·투명 문화를 키우나요?

  1. 매일 투명하게 엄격한 보고를 요구합니다.
  2. 팀워크 워크숍으로 협업·소통을 장려합니다.
  3. 개별 면담으로 소통 문제 원인을 찾습니다.
  4. 정기 회고에서 어려움·개선책을 공개 논의하게 합니다.
  5. 리더를 정해 모든 소통을 조정하고 공유합니다.

정답: 보기-4 / 정기 회고에서 어려움·개선책을 공개 논의하게 합니다.

문제 14 Review에서 Increment가 Product Owner 수락 기준을 못 맞췄습니다. 이해관계자는 실망했지만 팀은 제약 속 최선을 다했다고 봅니다.

무엇을 권해야 하나요?

  1. 정당화하고 수용 가능하다고 설득하게 합니다.
  2. 현재 Increment를 유지하고 이해관계자 기대를 낮춥니다.
  3. 팀·Product Owner가 기준 미충족 이유를 이해하도록 논의를 촉진합니다.
  4. 사과하고 다음 Sprint에 더 높은 품질을 확약하게 합니다.
  5. 별도 회의로 수락 기준을 협상하게 합니다.

정답: 보기-3 / 팀·Product Owner가 기준 미충족 이유를 이해하도록 논의를 촉진합니다.

문제 15 Product Owner Jane이 중간에 순위를 자주 바꿔 방해·약속 미달·좌절을 낳습니다. 팀은 안정된 납품 속도를 못 낸다고 느낍니다.

어떻게 대응해야 하나요?

  1. 현재 목표를 버리더라도 새 순위를 엄격히 따르게 합니다.
  2. Jane과 만나 잦은 변경의 성과 영향을 논의합니다.
  3. 새 순위를 무시하고 초기 목표를 따르게 합니다.
  4. 초과근무로 변경과 초기 확약을 모두 충족합니다.
  5. 안정적 목표의 중요성을 서로 이해하도록 Jane·팀 논의를 돕습니다.

정답: 보기-2 / Jane과 만나 잦은 변경의 성과 영향을 논의합니다.

문제 16 Product Owner 부재로 결정·명확화를 기다려 Sprint가 늦어지며 팀이 좌절합니다.

가장 적절한 행동은?

  1. 개발자를 임시 Product Owner로 정해 대신 결정하게 합니다.
  2. 안내할 수 있을 때까지 Sprint를 멈춥니다.
  3. Product Owner와 부재 영향을 논의하고 가용성 개선을 계획합니다.
  4. 상담 없이 독립 결정해 진행하게 합니다.
  5. 더 꾸준히 참여할 사람으로 교체합니다.

정답: 보기-3 / Product Owner와 부재 영향을 논의하고 가용성 개선을 계획합니다.

문제 17 빠듯한 기한 압박과 과부하 때문에 편법을 써 제품 품질이 떨어집니다.

최선의 대응은?

  1. 더 열심히 오래 일하도록 압박합니다.
  2. 속도보다 품질을 우선하고 지연 가능성을 이해관계자에게 알립니다.
  3. 계속 편법으로 적시 납품하고 다음에 품질을 개선합니다.
  4. 기한 연장으로 품질 집중을 협상합니다.
  5. 걱정을 무시하고 압박 대응은 팀이 정하게 합니다.

정답: 보기-2 / 속도보다 품질을 우선하고 지연 가능성을 이해관계자에게 알립니다.

문제 18 팀이 빨리 끝내려 Definition of Done을 자주 건너뛰어 부채·품질 저하가 생깁니다. 목표에 필요하다고 주장합니다.

높은 품질을 위해 무엇을 권하나요?

  1. 목표 달성에 도움 되므로 계속 건너뛰게 합니다.
  2. 일부 스토리를 못 끝내도 Definition of Done을 엄격히 지킵니다.
  3. 스토리마다 팀이 정의를 정하게 해 유연성을 줍니다.
  4. 품질·양을 모두 위해 Sprint를 늘립니다.
  5. 겉으로 작동하면 무시합니다.

정답: 보기-2 / 일부 스토리를 못 끝내도 Definition of Done을 엄격히 지킵니다.

문제 19 이해관계자가 Sprint 도중 즉시 변경을 자주 요청해 집중을 깨고 목표를 어렵게 합니다.

방해를 줄이고 효과적으로 일하려면?

  1. 추가 근무로 요청과 목표를 모두 충족합니다.
  2. 급해도 다음 Sprint로 미룹니다.
  3. 정기 회의로 요구·순위를 투명하게 논의합니다.
  4. 전담 연락 담당자가 모든 요청을 처리해 집중을 지킵니다.
  5. 요청을 무시하고 초기 목표만 봅니다.

정답: 보기-4 / 전담 연락 담당자가 모든 요청을 처리해 집중을 지킵니다.

문제 20 Scrum을 막 도입한 팀은 정기 회고 가치를 이해하지 못합니다. 일부는 쓸모없는 시간 낭비라고 봅니다.

회고의 중요성을 어떻게 효과적으로 알리나요?

  1. 회고를 없애 회의 피로를 줄입니다.
  2. 회고로 과정을 개선한 다른 팀의 성공 사례를 나눕니다.
  3. 대립을 피하려 비공개 서면 의견을 요구합니다.
  4. 빈도를 줄여 더 가치 있게 느끼도록 합니다.
  5. 표준 실무이므로 걱정을 무시하고 계속합니다.

정답: 보기-2 / 회고로 과정을 개선한 다른 팀의 성공 사례를 나눕니다.



Scrum Master 인증 >>



Scrum Product Owner 인증 시험 문제

문제 21 Product Owner John의 계획 회의에서 개발팀은 스토리가 모호하다고 걱정합니다. 세부 요구 부족이 오해·지연을 낳습니다.

John은 어떻게 효과적으로 대응해야 하나요?

  1. 명확한 수락 기준의 스토리 양식을 만들어 공유해야 합니다.
  2. Scrum 원칙대로 적시에 세부 요구를 제공한다고 알려야 합니다.
  3. 업무 분석가를 배정해 각 스토리 세부 요구를 정해야 합니다.
  4. 현재대로 진행하고 질문은 Sprint 중 다루게 해야 합니다.
  5. 모든 세부 요구가 명확해질 때까지 Sprint를 미뤄야 합니다.

정답: 보기-1: 명확한 수락 기준의 스토리 양식을 만들어 공유해야 합니다.

문제 22 전자상거래 Product Owner Sarah는 마케팅팀에게 현재 백로그에 없는 새 기능 요청을 받습니다. 곧 시작할 캠페인에 핵심이라고 합니다.

Sarah는 어떻게 해야 하나요?

  1. 즉시 백로그에 넣고 다른 것보다 우선해야 합니다.
  2. 올바른 정제 과정을 거쳐 미래 Sprint에 우선순위를 정해야 한다고 알려야 합니다.
  3. 맨 아래에 넣고 기존 순위에 집중해야 합니다.
  4. 즉시 만나 현재 Sprint 순위를 협상해야 합니다.
  5. 캠페인에 핵심이므로 Sprint를 멈추고 새 기능으로 전환해야 합니다.

정답: 보기-2: 올바른 정제 과정을 거쳐 미래 Sprint에 우선순위를 정해야 한다고 알려야 합니다.

문제 23 Product Owner James는 여러 시간대의 원격 팀과 일합니다. 시차 때문에 조정·협업이 자주 어렵습니다.

James는 어떻게 협업을 개선해야 하나요?

  1. 누군가 불편해도 전원 근무 시간을 맞추도록 강제해야 합니다.
  2. 시간대별로 배정해 조정 없이 독립적으로 일하게 해야 합니다.
  3. 시차를 고려해 모두에게 합리적인 시간에 일일 스탠드업을 해야 합니다.
  4. 실시간 협업을 피하려 서면만 써야 합니다.
  5. 특정 시간대 인력을 더 고용해 근무 겹침을 늘려야 합니다.

정답: 보기-3: 시차를 고려해 모두에게 합리적인 시간에 일일 스탠드업을 해야 합니다.

문제 24 Product Owner Emily의 팀은 고객 만족을 위해 매 Sprint 더 많은 기능을 밀어붙입니다. Emily는 품질 저하·소진을 걱정합니다.

Emily는 어떻게 해야 하나요?

  1. 고객 수요·만족을 위해 더 많은 기능을 요구해야 합니다.
  2. 장기 만족을 위해 양보다 질에 집중할 중요성을 이해관계자에게 설명해야 합니다.
  3. 별도 QA팀을 배정해 질·양을 모두 달성해야 합니다.
  4. Sprint를 줄여 출시 빈도와 새 기능 수요를 충족해야 합니다.
  5. 걱정을 무시하고 사업 목표를 위해 더 많은 기능을 요구해야 합니다.

정답: 보기-2: 장기 만족을 위해 양보다 질에 집중할 중요성을 이해관계자에게 설명해야 합니다.

문제 25 Product Owner Thomas의 팀은 스토리의 사업 가치가 불명확해 일의 전체 목적·영향을 이해하기 어렵다고 자주 말합니다.

Thomas는 어떻게 대응해야 하나요?

  1. 사업 전략·장기 목표를 상세히 설명해 맥락을 알려야 합니다.
  2. 가치는 관심사가 아니니 배정 스토리만 끝내라 해야 합니다.
  3. 분석가를 고용해 스토리 가치를 상세히 설명하게 해야 합니다.
  4. 워크숍에서 공개 대화·질문으로 일의 가치를 함께 이해해야 합니다.
  5. 경영진 책임이므로 무시해야 합니다.

정답: 보기-4: 워크숍에서 공개 대화·질문으로 일의 가치를 함께 이해해야 합니다.

문제 26 Product Owner Maria는 검증·피드백에 이해관계자 참여가 많이 필요한 복잡한 프로젝트를 관리합니다. 일부가 거의 참여 못 해 지연과 개발 차질이 생깁니다.

참여·적시 피드백을 어떻게 개선하나요?

  1. 피드백 없이 진행하고 다른 작업을 우선해야 합니다.
  2. 팀 시간을 바꿔서라도 이해관계자 편한 시간에 정해야 합니다.
  3. 불참자와 소통해 적시 피드백의 성공 중요성을 강조해야 합니다.
  4. 전담 연락 담당자가 대신 참여·의견 수집하게 해야 합니다.
  5. 불참을 무시하고 의견을 필수가 아닌 선택으로 봐야 합니다.

정답: 보기-3: 불참자와 소통해 적시 피드백의 성공 중요성을 강조해야 합니다.

문제 27 Product Owner Mark는 많은 스토리·경쟁 순위의 백로그 관리가 어렵습니다. 팀이 다음 일을 못 정해 계획·실행이 늦습니다.

Mark는 어떻게 더 잘 관리·우선화해야 하나요?

  1. 단일 순위 목록으로 다음 작업 혼란·논쟁을 없애야 합니다.
  2. 전담 백로그 관리자가 정제·순위·소통을 해야 합니다.
  3. 개발팀 역량·제약을 이해하며 가용 자원에 따라 함께 순위를 정해야 합니다.
  4. 도착 순서대로 스토리를 처리해야 합니다.
  5. Scrum Master에게 백로그를 위임해 효율을 높여야 합니다.

정답: 보기-3: 개발팀 역량·제약을 이해하며 가용 자원에 따라 함께 순위를 정해야 합니다.

문제 28 웹 앱 Product Owner Jennifer에게 여러 이해관계자가 각자 최우선이라며 기능을 요청합니다. 어떻게 할지 모르겠습니다.

경쟁 요청을 어떻게 효과적으로 관리해야 하나요?

  1. 관계 유지를 위해 직급 순으로 우선해야 합니다.
  2. 모두 모아 목표·고객 요구 기반 공동 순위 틀을 만들어야 합니다.
  3. 참여 없이 개인의 사업 이해로 순위를 정해야 합니다.
  4. 가장 큰 금전 유인 제공자를 우선해야 합니다.
  5. 요청을 무시하고 백로그·Sprint 목표만 봐야 합니다.

정답: 보기-2: 모두 모아 목표·고객 요구 기반 공동 순위 틀을 만들어야 합니다.

문제 29 많은 사용자의 Product Owner Alex는 이메일·소셜·지원 등으로 요청을 자주 받습니다. 모호하고 현재 방향과 충돌하기도 합니다.

고객 요청을 어떻게 효과적으로 관리·응답해야 하나요?

  1. 별도 고객 백로그에 넣어 도착 순으로 최우선 처리해야 합니다.
  2. 명확한 처리·분류·정기 검토 과정으로 전체 전략과 정렬해야 합니다.
  3. 모호하고 성공 기여가 적으므로 무시해야 합니다.
  4. 매 Sprint 상당 부분을 요청에 써 만족·충성도를 지켜야 합니다.
  5. 고객 연락 담당자에게 맡기고 전략 결정 시간을 확보해야 합니다.

정답: 보기-2: 명확한 처리·분류·정기 검토 과정으로 전체 전략과 정렬해야 합니다.

문제 30 Product Owner Daniel의 팀은 변경을 매우 싫어하고 요구를 미리 고정하는 전통적 폭포수를 선호합니다.

어떻게 저항을 다루고 Scrum 원칙을 촉진해야 하나요?

  1. 걱정과 무관하게 엄격한 Scrum 준수를 강제해야 합니다.
  2. 조화를 위해 선호 방식을 허용하고 압박을 피해야 합니다.
  3. Scrum Master가 유연·적응·협업의 혜택을 교육하도록 권해야 합니다.
  4. 저항자를 원칙에 맞는 사람으로 바꿔 원활히 전환해야 합니다.
  5. 상급 경영진 승인으로 실무를 강제하고 저항을 눌러야 합니다.

정답: 보기-3: Scrum Master가 유연·적응·협업의 혜택을 교육하도록 권해야 합니다.



Scrum Product Owner 인증 >>



Scaled Scrum Expert 인증 시험 문제

문제 31 Scaled Scrum Expert John은 여러 국가·시간대의 큰 분산 조직 전환을 이끌며 팀 간 협업·정렬을 보장해야 합니다.

어떤 접근을 해야 하나요?

  1. 엄격한 하향 위계로 결정을 간소화합니다.
  2. 매일 전 팀 영상 회의로 동기화합니다.
  3. 명확한 채널과 글로벌 맥락 내 지역 결정권을 줍니다.
  4. 모두 같은 과정·실무를 강제합니다.
  5. 중앙 PMO가 전체 작업을 감독합니다.

정답: 보기-3 / 명확한 채널과 글로벌 맥락 내 지역 결정권을 줍니다.

문제 32 Scaled Scrum Expert Sarah는 개발 개선을 위해 도입하는 대형 금융 조직과 일합니다. 통제 상실을 두려워하는 중간 관리자가 반대합니다.

걱정을 다루고 성공적으로 전환하려면?

  1. 간섭을 막도록 중간 관리자를 제외합니다.
  2. 교육과 조직에 대한 혜택 설명으로 중간 관리자를 참여시킵니다.
  3. 엄격한 보고로 알리되 팀 활동에는 참여 못 하게 합니다.
  4. Scrum Master로 교체해 원칙과 완전히 맞춥니다.
  5. 걱정을 무시하고 참여 없이 전환합니다.

정답: 보기-2 / 교육과 조직에 대한 혜택 설명으로 중간 관리자를 참여시킵니다.

문제 33 Scaled Scrum Expert Mark는 복잡한 제품의 여러 모듈을 만드는 팀들을 조정합니다. 정보 공유가 부족하고 의존성으로 지연된다고 걱정합니다.

정보 공유·의존성에 어떻게 대응해야 하나요?

  1. 팀마다 PM을 두어 정보·의존을 통제합니다.
  2. 매일 전사 회의로 진행·의존을 논의합니다.
  3. Scrum of Scrums로 의존·장애물을 정기 논의합니다.
  4. 모든 의존을 Mark에게 승인받아야 진행하게 합니다.
  5. 복잡한 다중 팀 제품의 자연스러운 일이므로 무시합니다.

정답: 보기-3 / Scrum of Scrums로 의존·장애물을 정기 논의합니다.

문제 34 전환한 조직의 Scaled Scrum Expert Lisa에게 경영진은 즉각적 납품 개선과 빠른 결과를 기대합니다.

현실적 기대를 위해 무엇을 조언해야 하나요?

  1. 첫 Sprint에 큰 속도 향상을 약속합니다.
  2. 초기 어려움과 여러 Sprint에 걸친 점진적 개선을 설명합니다.
  3. 납품에 별 영향이 없으므로 다른 개선에 집중하자고 합니다.
  4. 지나친 목표로 압박 속 성과를 자극합니다.
  5. 기대를 무시하고 소통 없이 전환합니다.

정답: 보기-2 / 초기 어려움과 여러 Sprint에 걸친 점진적 개선을 설명합니다.

문제 35 Scaled Scrum Expert David는 대형 제품의 여러 부분을 만드는 조직에서 일합니다. 일관·품질 유지가 어렵습니다.

일관·품질을 위해 무엇을 권하나요?

  1. 모든 개발 도구·기술을 표준화합니다.
  2. 창의·혁신을 위해 팀별 도구·기술 선택을 허용합니다.
  3. 승인 없는 제품 수정을 금하는 엄격한 변경 통제를 합니다.
  4. 전통 관리로 바꿔 통제·일관성을 지킵니다.
  5. 자연스러운 일이므로 품질 걱정을 무시합니다.

정답: 보기-1 / 모든 개발 도구·기술을 표준화합니다.

문제 36 Scaled Scrum Expert Emily는 여러 대륙 팀이 Increment를 납품하는 글로벌 조직과 일합니다.

분산 팀의 효과적 조정·협업을 어떻게 촉진하나요?

  1. 같은 장소처럼 취급해 일관성을 지킵니다.
  2. 엄격한 근무 시간으로 겹침을 보장합니다.
  3. 대륙 간 조정이 복잡하므로 독립 작업을 장려합니다.
  4. 정기 영상·팀 간 계획·Scrum of Scrums로 협업·조정을 촉진합니다.
  5. 글로벌 팀을 현지 팀으로 바꿔 단순화합니다.

정답: 보기-4 / 정기 영상·팀 간 계획·Scrum of Scrums로 협업·조정을 촉진합니다.

문제 37 Scaled Scrum Expert Michael은 기존 프로젝트들을 새 틀에 통합하려는 조직의 전환을 이끕니다.

기존 프로젝트를 어떻게 원활히 통합하나요?

  1. 기존을 무시하고 새 이니셔티브만 봅니다.
  2. 모두 새 팀으로 즉시 대체합니다.
  3. 필요한 교육·지원을 주며 기존 프로젝트를 점진 전환합니다.
  4. 전환을 무시하고 기존 방식으로 관리합니다.
  5. 엄격한 중앙 통제로 기존 프로젝트를 관리합니다.

정답: 보기-3 / 필요한 교육·지원을 주며 기존 프로젝트를 점진 전환합니다.

문제 38 Scaled Scrum Expert Amy는 문화적으로 다양한 다국적 팀의 차이로 인한 협업·소통 문제를 만납니다.

어떤 개선 전략을 권하나요?

  1. 차이를 무시하고 표준 소통·협업을 강제합니다.
  2. 엄격한 규칙으로 조직 문화를 강제해 차이를 줄입니다.
  3. 문화 감수성 교육, 열린 대화와 다양성 존중을 제공합니다.
  4. 동질 팀으로 대체해 단순화합니다.
  5. Scrum에 문화는 무관하므로 원칙·실무만 봅니다.

정답: 보기-3 / 문화 감수성 교육, 열린 대화와 다양성 존중을 제공합니다.

문제 39 Scaled Scrum Expert Richard의 조직은 엄격한 위계의 역사 때문에 탈중앙·자기 조직화 전환이 어렵습니다.

성공적 탈중앙·자기 조직화로 어떻게 안내하나요?

  1. 전환기에 명확한 보고 위계·통제를 강제합니다.
  2. 탈중앙 결정을 점진 도입하고 교육·코칭과 신뢰·자기 조직화 문화를 만듭니다.
  3. 모든 관리 역할을 없애 전 수준의 자기 조직화를 장려합니다.
  4. 중앙 통제를 강제해 전환 오류를 줄입니다.
  5. 전환을 무시하고 기존 위계를 유지합니다.

정답: 보기-2 / 탈중앙 결정을 점진 도입하고 교육·코칭과 신뢰·자기 조직화 문화를 만듭니다.

문제 40 Scaled Scrum Expert Olivia의 조직은 여러 시간대에 분산되어 동기 소통·협업이 어렵습니다.

시차 문제를 어떻게 돕나요?

  1. 단일 글로벌 근무 시간으로 실시간 협업합니다.
  2. 자기 시간대에서만 일해 협업을 제한합니다.
  3. 비동기 소통·디지털 협업 도구로 시차를 수용합니다.
  4. 한 장소로 모아 시차를 없앱니다.
  5. 글로벌 조직의 자연적 차이이므로 무시합니다.

정답: 보기-3 / 비동기 소통·디지털 협업 도구로 시차를 수용합니다.



Scaled Scrum Expert 인증 >>



Agile Scrum Leadership (Executive) 인증 시험 문제

문제 41 대형 소프트웨어 회사 CEO Sarah는 Agile·Scrum 도입을 검토합니다. 팀의 어려움·저항을 걱정하며 원활하고 성공적으로 적용하려 합니다.

Agile Scrum Leader (Executive)로 무엇을 우선해야 하나요?

  1. 엄격한 규칙·과정 준수를 강제해야 합니다.
  2. 교차 기능 리더십팀으로 가치·안내를 제공해야 합니다.
  3. 작은 시범 프로젝트로 실무를 시험한 뒤 전사 확산해야 합니다.
  4. 외부 컨설턴트가 내부 참여 없이 전환을 맡게 해야 합니다.
  5. 의지를 보여주려 즉시 전사 도입해야 합니다.

정답: 보기-3: 작은 시범 프로젝트로 실무를 시험한 뒤 전사 확산해야 합니다.

문제 42 금융 회사 CIO John은 전환을 이끕니다. Scrum 팀은 다른 부서 의존성으로 늦어집니다. 병목 제거·흐름 개선을 원합니다.

의존성과 교차 협업에 어떻게 접근해야 하나요?

  1. 고립 작업으로 외부 의존을 피해야 합니다.
  2. 엄격한 과정·인계로 통제해야 합니다.
  3. 다른 부서장과 교차 기능 팀을 만들어 의존성을 함께 다뤄야 합니다.
  4. 외주로 내부 의존을 줄이고 효율을 높여야 합니다.
  5. 중앙 PMO로 전체 감독·임원 수준 해결을 해야 합니다.

정답: 보기-3: 다른 부서장과 교차 기능 팀을 만들어 의존성을 함께 다뤄야 합니다.

문제 43 기술 스타트업 제품 총괄 Laura는 빠른 혁신 제품에 전념하며 Agile·Scrum을 믿지만 참여 수준을 모릅니다.

전환에서 가장 적절한 역할은?

  1. Scrum Master로 팀·과정을 직접 관리해야 합니다.
  2. 새 코치에게 전부 위임하고 제품 전략만 봐야 합니다.
  3. 행사에 적극 참여해 통찰·지원을 주되 일을 세세히 통제하지 않아야 합니다.
  4. 상세 지침과 엄격한 준수로 이탈을 막아야 합니다.
  5. 팀을 해체하고 전통 관리로 통제를 회복해야 합니다.

정답: 보기-3: 행사에 적극 참여해 통찰·지원을 주되 일을 세세히 통제하지 않아야 합니다.

문제 44 제조 COO Mark는 애자일이 경쟁 우위와 생산 효율·대응을 높인다고 믿어 도입하려 합니다.

제조 도입의 가장 중요한 고려 요소는?

  1. 맞춤화를 최소화해 생산을 간소화해야 합니다.
  2. 엄격한 위계로 모든 생산 단위 준수를 보장해야 합니다.
  3. 여러 생산 단위의 교차 기능 팀으로 협업·흐름을 높여야 합니다.
  4. 폭포수로 바꿔 예측·안정을 지켜야 합니다.
  5. 단순화를 위해 기술·디지털을 피해야 합니다.

정답: 보기-3: 여러 생산 단위의 교차 기능 팀으로 협업·흐름을 높여야 합니다.

문제 45 의료 CEO Alex는 환자 치료·서비스 개선에 애자일을 검토하지만 전통에 익숙한 전문가 저항을 걱정합니다.

지지·신뢰를 얻을 전략은?

  1. 외부가 결정 참여 없이 강제하게 해야 합니다.
  2. 빠른 도입을 위해 의견 없는 하향식을 유지해야 합니다.
  3. 전문가를 교육·결정에 적극 참여시키고 계속 의견·피드백을 구해야 합니다.
  4. 선호·걱정과 무관하게 즉시 전면 도입해야 합니다.
  5. 기존 실무를 방해하지 않도록 미뤄야 합니다.

정답: 보기-3: 전문가를 교육·결정에 적극 참여시키고 계속 의견·피드백을 구해야 합니다.

문제 46 소매 CMO Emily는 시장에 빠르게 대응할 애자일 마케팅을 원합니다. 경쟁 우위를 믿지만 팀은 전통적 방식에 익숙합니다.

성공적 도입의 가장 효과적 접근은?

  1. 전체를 애자일 마케팅 전문가로 바꿔야 합니다.
  2. 새 부서만 애자일로 하고 나머지는 전통에 한정해야 합니다.
  3. 점진 도입·교육과 업무에서의 애자일 실험을 장려해야 합니다.
  4. 엄격한 기한·지표로 빠르게 강제해야 합니다.
  5. 더 안정·신뢰할 전통 실무를 유지해야 합니다.

정답: 보기-3: 점진 도입·교육과 업무에서의 애자일 실험을 장려해야 합니다.

문제 47 대기업 HR 총괄 David는 인재 관리·직원 개발을 위해 애자일 HR을 원합니다. 급변 환경 적응에 민첩성이 필요함을 압니다.

Agile Scrum Leader (Executive)로 성공적 도입을 위해 무엇을 해야 하나요?

  1. 기존 과정·준비와 무관하게 즉시 전면 도입해야 합니다.
  2. 전통과 독립된 별도 애자일 HR을 만들어야 합니다.
  3. HR 전문가를 교육·실험에 참여시키고 애자일 프로젝트용 교차 기능 HR팀을 만들어야 합니다.
  4. 내부 참여 없이 외부 컨설턴트가 전환을 이끌어야 합니다.
  5. 기존 과정 혼란을 피하려 전통을 유지해야 합니다.

정답: 보기-3: HR 전문가를 교육·실험에 참여시키고 애자일 프로젝트용 교차 기능 HR팀을 만들어야 합니다.

문제 48 다국적 기업 법무 총괄 Jennifer는 법률·고객 요구 대응과 효율을 위해 애자일을 검토합니다.

법무 도입의 가장 효과적 접근은?

  1. 전문가 의견 없이 즉시 도입해야 합니다.
  2. 전통과 격리된 별도 애자일 법무를 만들어야 합니다.
  3. 전문가와 협력해 교육·법무 실험을 장려해야 합니다.
  4. 내부 참여 없이 외부가 강제해야 합니다.
  5. 신뢰·통제를 위해 전통만 유지해야 합니다.

정답: 보기-3: 전문가와 협력해 교육·법무 실험을 장려해야 합니다.

문제 49 제조 CFO Richard는 불확실한 경제에서 적응을 높이려 재무 계획·예산에 애자일을 원합니다.

성공적 재무 도입의 접근은?

  1. 준비·저항과 무관하게 즉시 완전 전환해야 합니다.
  2. 전통과 독립된 별도 애자일 재무를 만들어야 합니다.
  3. 재무 전문가에게 교육·실험을 제공하고 애자일 재무 프로젝트의 교차 팀을 만들어야 합니다.
  4. 내부 없이 외부 재무 컨설턴트가 이끌어야 합니다.
  5. 과정 혼란을 피하려 전통을 유지해야 합니다.

정답: 보기-3: 재무 전문가에게 교육·실험을 제공하고 애자일 재무 프로젝트의 교차 팀을 만들어야 합니다.

문제 50 글로벌 물류 구매 총괄 Daniel은 공급업체 협업·대응·관계·비용 최적화를 위해 애자일 구매를 탐색합니다.

가장 효과적 도입법은?

  1. 전문가·공급업체 의견 없이 즉시 강제해야 합니다.
  2. 전통과 독립된 별도 애자일 구매를 만들어야 합니다.
  3. 전문가 참여·교육과 공급업체 관계의 애자일 실험을 장려해야 합니다.
  4. 내부·공급업체 없이 외부 전문가가 강제해야 합니다.
  5. 전통이 더 확립·신뢰할 만하므로 애자일을 피해야 합니다.

정답: 보기-3: 전문가 참여·교육과 공급업체 관계의 애자일 실험을 장려해야 합니다.



Scrum Leadership 인증 >>



Scrum Trainer 인증 시험 문제

문제 51 인증 Scrum Trainer로 교육합니다. John은 전통 관리, Mary는 애자일 경험이 있습니다.

John은 자기 조직화라 PM이 필요 없다고 합니다. Mary는 코칭에 Scrum Master가 핵심이라 반박합니다.

어떻게 논의를 효과적으로 다루나요?

  1. John이 맞고 PM의 자리가 없다고 설명합니다.
  2. Mary에 동의하고 코칭·촉진 역할을 강조합니다.
  3. 교육 범위 밖이므로 밖에서 해결하게 합니다.
  4. PM·Scrum Master가 성공적으로 공존하는 실제 사례를 공유합니다.
  5. 교육 중 토론으로 다양한 관점을 이해하게 합니다.

정답: 보기-4: PM·Scrum Master가 성공적으로 공존하는 실제 사례를 공유합니다.

문제 52 투명성 교육에서 Mary는 재무 정보 공유가 기밀을 침해하고 오해를 낳을까 걱정합니다.

어떻게 대응하나요?

  1. 기밀 유지를 위해 공유하지 않아야 한다고 동의합니다.
  2. 효과적 결정에 필요한 핵심 원칙이라 설명하고 팀·조직 이점 사례를 나눕니다.
  3. 관련 없을 수 있어 무시하고 넘어갑니다.
  4. 다른 의견으로 그룹 합의를 보고 관점을 바꿀 수도 있습니다.
  5. 나중에 더 조사해 조직 관련성을 판단하라 합니다.

정답: 보기-2: 효과적 결정에 필요한 핵심 원칙이라 설명하고 팀·조직 이점 사례를 나눕니다.

문제 53 교육 중 일부가 집중하지 않고 전화기를 자주 봅니다. 내용에 흥미가 부족한 듯합니다.

참여·집중을 되찾을 최선의 방법은?

  1. 나중에 따라올 것이라 보고 계속합니다.
  2. 괜찮은지, 논의·명확히 하고 싶은 게 있는지 정중히 묻습니다.
  3. 깜짝 퀴즈로 참여·주의를 확인합니다.
  4. 짧은 활력 활동·그룹 실습으로 더 몰입하는 환경을 만듭니다.
  5. 흥미는 본인 책임이므로 무시합니다.

정답: 보기-4: 짧은 활력 활동·그룹 실습으로 더 몰입하는 환경을 만듭니다.

문제 54 John은 Definition of Done이 불필요한 관료주의라며 “끝나면 끝”이 더 좋다고 합니다.

어떻게 답하나요?

  1. 동의하고 정의를 버려 단순화하라 합니다.
  2. 완료의 공통 이해·품질을 위한 Scrum 핵심이라고 설명합니다.
  3. 협상 불가이므로 무시합니다.
  4. 다른 의견을 나눠 여러 관점을 탐색합니다.
  5. 나중에 장단점 보고서를 써 판단하라 합니다.

정답: 보기-2: 완료의 공통 이해·품질을 위한 Scrum 핵심이라고 설명합니다.

문제 55 Mary는 전환이 조직의 확립된 업무·과정을 깨뜨릴까 걱정합니다.

어떻게 걱정을 다루나요?

  1. 너무 파괴적이라며 기존 유지를 권합니다.
  2. 걱정을 인정하고 적절한 교육·지원과 점진 도입으로 방해를 줄인다고 설명합니다.
  3. 확립된 틀이므로 의심 없이 도입해야 한다며 무시합니다.
  4. 다른 관점·성공담을 얻으려 동료와 상담하게 합니다.
  5. 나중에 조직에 맞는 조정을 스스로 조사하라 합니다.

정답: 보기-2: 걱정을 인정하고 적절한 교육·지원과 점진 도입으로 방해를 줄인다고 설명합니다.

문제 56 섬기는 리더십 교육에서 John은 과거의 지시·통제형 관리 원칙과 양립할지 의문입니다.

어떻게 대응하나요?

  1. 효과 없다고 동의하고 기존 원칙을 권합니다.
  2. 지시 대신 역량·지원을 주는 다른 스타일이라 설명하고 타 조직 성공담을 나눕니다.
  3. 유일한 허용 스타일이므로 적응해야 한다며 무시합니다.
  4. 외부 조사·숙련자 대화로 관점을 넓히게 합니다.
  5. 특정 프로젝트에서 직접 시험·평가하라 합니다.

정답: 보기-2: 지시 대신 역량·지원을 주는 다른 스타일이라 설명하고 타 조직 성공담을 나눕니다.

문제 57 Sarah는 매일 스탠드업이 시간 낭비라며 모든 팀에 필요한지 묻습니다.

효과·필요성에 어떻게 답하나요?

  1. 쓸모없으면 건너뛰라며 동의합니다.
  2. 투명·협업·일일 계획에 귀중한 실무라며 목적·이점을 설명합니다.
  3. 질문은 원칙 위반이라며 무시합니다.
  4. 다른 참여자 의견·경험을 토론하게 합니다.
  5. 나중에 여러 변형을 실험해 효과를 평가하게 합니다.

정답: 보기-2: 투명·협업·일일 계획에 귀중한 실무라며 목적·이점을 설명합니다.

문제 58 Mark는 Scrum이 소프트웨어에만 맞고 비기술 프로젝트에는 못 쓸지 의문입니다.

비기술 적용에 어떻게 답하나요?

  1. 소프트웨어에 한정해야 한다고 동의합니다.
  2. 여러 산업에 조정 가능하다고 설명하고 비기술 성공 사례를 나눕니다.
  3. 수정 없이 어디든 보편 적용된다며 무시합니다.
  4. 다른 이의 비기술 경험으로 관점을 넓힙니다.
  5. 나중에 사례 연구로 다재다능함을 알아보게 합니다.

정답: 보기-2: 여러 산업에 조정 가능하다고 설명하고 비기술 성공 사례를 나눕니다.

문제 59 Scrum Trainer 교육에서 경험적 통제를 강조하자 Emma는 조직에서 직관적 결정이면 충분하다며 데이터 필요성을 묻습니다.

데이터 필요성에 어떻게 답하나요?

  1. 직관이 유효하고 데이터는 불필요하다고 동의합니다.
  2. 충분한 결정·위험 감소·지속 개선의 중요성을 설명하고 실례를 나눕니다.
  3. 데이터 의문은 원칙 위반이라며 무시합니다.
  4. 다른 참여자와 장단점을 토론하게 합니다.
  5. 교육 후 조직에서 데이터 적용을 실험·평가하게 합니다.

정답: 보기-2: 충분한 결정·위험 감소·지속 개선의 중요성을 설명하고 실례를 나눕니다.

문제 60 Trainer 교육에서 James는 Review가 너무 길고 경험상 비생산적이라고 걱정합니다.

길이·효과에 어떻게 대응하나요?

  1. 동의하고 없애 시간·생산성을 개선합니다.
  2. 피드백·이해관계자 정렬의 목적·중요성과 효율화 팁을 설명합니다.
  3. 필요성 의문은 원칙 위반이라 무시합니다.
  4. 다른 이의 경험·효율 개선 제안을 나눕니다.
  5. 교육 후 조직 Review 간소화를 실험·평가하게 합니다.

정답: 보기-2: 피드백·이해관계자 정렬의 목적·중요성과 효율화 팁을 설명합니다.



Scrum Trainer 인증 >>



Agile Coach 인증 시험 문제

문제 61 XYZ Corporation 개발팀의 Agile Coach입니다. 협업 부족·변화 저항으로 적응이 어렵고 시니어 John이 특히 공개적으로 반대합니다.

긍정 변화를 위한 초기 접근은?

  1. John과 개별 면담해 걱정을 이해하고 맞춤 코칭합니다.
  2. 저항을 꾸짖고 모두처럼 따르라고 강제합니다.
  3. John을 무시하고 나머지를 코칭해 나중에 영향받길 바랍니다.
  4. 경영진이 준수를 압박하게 합니다.
  5. 즉시 제외해 진전·사기를 지킵니다.

정답: 보기-1: John과 개별 면담해 걱정을 이해하고 맞춤 코칭합니다.

문제 62 대형 전자상거래 Agile Coach로 여러 팀과 일합니다. Master Sarah는 최근 여러 Sprint의 꾸준한 속도 저하를 걱정합니다.

Sarah를 돕기 위해 무엇을 하나요?

  1. 목표 속도를 높여 빠르게 동기 부여합니다.
  2. 개인을 감시하고 기한을 엄격히 합니다.
  3. 회고로 근본 원인을 찾고 함께 해결하게 합니다.
  4. 다른 애자일 틀을 써 속도가 나아지는지 봅니다.
  5. 무시하고 알아서 높이게 합니다.

정답: 보기-3: 회고로 근본 원인을 찾고 함께 해결하게 합니다.

문제 63 금융 기관 Agile Coach입니다. 팀이 Scrum과 DevOps를 함께 적용할 방법을 몰라 지연·통합 문제가 있습니다.

원활한 통합을 위해 무엇을 하나요?

  1. Scrum을 버리고 문제를 일으키는 듯한 DevOps에만 집중합니다.
  2. Scrum을 계속하기 전 추가 DevOps 교육을 합니다.
  3. 워크숍으로 시너지를 이해하고 구현 로드맵을 만듭니다.
  4. 맥락에 안 맞을 수 있어 DevOps를 무시하고 Scrum만 합니다.
  5. 못 이해하는 사람을 숙련자로 바꿉니다.

정답: 보기-3: 워크숍으로 시너지를 이해하고 구현 로드맵을 만듭니다.

문제 64 의료 Agile Coach입니다. 원격 팀원의 시차로 소통·조정이 늦습니다.

효과적 분산 협업을 위한 전략은?

  1. 원격자가 본팀 시간에 맞추게 합니다.
  2. 시차·비동기 문제를 피하려 이메일 중심으로 합니다.
  3. 효과적 원격 도구·투명성·명확한 소통 규약으로 시차를 메웁니다.
  4. 본팀 시간대 인력을 새로 고용합니다.
  5. 불가피하므로 무시합니다.

정답: 보기-3: 효과적 원격 도구·투명성·명확한 소통 규약으로 시차를 메웁니다.

문제 65 새 모바일 앱 개발자·디자이너의 Agile Coach입니다. 설계·개발 간 반복적 오해·불일치가 재작업·지연을 낳습니다.

협업 개선에 무엇을 권하나요?

  1. 갈등·재작업을 피하려 완전 격리합니다.
  2. 공동 일일 스탠드업으로 진행·어려움·지속 정렬을 논의합니다.
  3. 문제 원인 인원을 조정 능력 좋은 사람으로 바꿉니다.
  4. 폭포수로 바꿔 설계 완료 후 개발합니다.
  5. 무시하고 팀끼리 해결하게 합니다.

정답: 보기-2: 공동 일일 스탠드업으로 진행·어려움·지속 정렬을 논의합니다.

문제 66 제조 Agile Coach입니다. 경영진은 빠듯한 기한을 위해 정확한 추정을 압박합니다. 팀은 부정확·품질 저하를 걱정합니다.

정확한 추정과 품질의 균형에 무엇을 권하나요?

  1. 부정확해도 요청 추정을 줘 기한을 지킵니다.
  2. 초기에 더 정확하고 진행하며 정밀해지는 대략적 규모(ROM) 추정을 권합니다.
  3. 압박을 무시하고 팀 판단만으로 계획·실행합니다.
  4. 기한을 늘려 품질 손상 없이 정밀 추정할 시간을 요청합니다.
  5. 요구 수준의 정밀 추정 가능자로 교체합니다.

정답: 보기-2: 초기에 더 정확하고 진행하며 정밀해지는 대략적 규모(ROM) 추정을 권합니다.

문제 67 제품팀의 Agile Coach입니다. 계획 때 과도하게 확약해 자주 미완료·이해관계자 불만이 생깁니다.

과도한 확약을 어떻게 극복하나요?

  1. 기대를 맞추려 계속 과다 확약하고 백로그를 조정합니다.
  2. 추가 근무로 모두 끝냅니다.
  3. 계획에서 솔직히 논의하고 과거 성과 기반 현실적 양을 확약합니다.
  4. 못 지키는 사람을 생산적인 사람으로 바꿉니다.
  5. 무시하고 독립 해결하게 합니다.

정답: 보기-3: 계획에서 솔직히 논의하고 과거 성과 기반 현실적 양을 확약합니다.

문제 68 개발팀은 Sprint 중 잦은 범위·기능 요청으로 집중·목표 달성이 어렵습니다. 여러분은 Agile Coach입니다.

효과적 관리 접근은?

  1. 중간 목표를 바꿔도 도착하는 대로 모두 구현합니다.
  2. 모두 기록하고 다음 Sprint에 구현해 집중을 유지합니다.
  3. 중간 논의를 피하고 초기 목표만 봅니다.
  4. Product Owner·이해관계자·팀이 평가·우선화하는 공식 변경 절차를 도입합니다.
  5. Scrum 일부가 아니므로 무시하고 초기 목표대로 갑니다.

정답: 보기-4: Product Owner·이해관계자·팀이 평가·우선화하는 공식 변경 절차를 도입합니다.

문제 69 새 팀의 Agile Coach입니다. 열정은 있지만 경험이 부족해 자기 조직화·결정이 어렵습니다.

어떤 지원 단계를 권하나요?

  1. 특정 업무·책임을 배정해 담당자가 결정하게 합니다.
  2. 매일 세부 수행·결정 지침을 줍니다.
  3. 자기 조직화·공동 결정을 장려하고 필요시 안내·지원합니다.
  4. 못 하는 사람을 숙련자로 바꿉니다.
  5. 무시하고 스스로 찾게 합니다.

정답: 보기-3: 자기 조직화·공동 결정을 장려하고 필요시 안내·지원합니다.

문제 70 수년 성공한 성숙 팀의 Agile Coach입니다. 최근 사기가 낮고 행사가 반복적·무가치하다며 참여가 줄었습니다.

활력·참여·가치를 어떻게 높이나요?

  1. 일부 행사를 건너뛰어 반복·사기를 개선합니다.
  2. 행사를 추가해 반복 걱정에 대응합니다.
  3. 기존 행사를 검토·수정해 상호작용적이고 팀에 맞게 합니다.
  4. 무관심한 사람을 열정적인 사람으로 바꿉니다.
  5. 필수이므로 걱정을 무시하고 유지합니다.

정답: 보기-3: 기존 행사를 검토·수정해 상호작용적이고 팀에 맞게 합니다.



Agile Coach 인증 >>



Kanban Expert 인증 시험 문제

문제 71 Kanban Expert로 새 도입 팀과 일합니다. WIP 제한 개념, 특히 효과적 설정·조정을 이해하기 어렵습니다.

  1. 생산성을 제한하므로 불필요하다고 설명합니다.
  2. 임의로 정하고 변경 금지라 합니다.
  3. 흐름 원칙을 가르치고 역량·제약에 따라 함께 제한을 정하게 합니다.
  4. 상담 없이 정하고 주기적으로 높여 효율을 압박합니다.
  5. 혼란을 무시하고 스스로 알아내게 합니다.

정답: 보기-3: 흐름 원칙을 가르치고 역량·제약에 따라 함께 제한을 정하게 합니다.

문제 72 마케팅팀과 일하는 Kanban Expert입니다. 리더 Sarah는 작업 유형별 완료 시간 변동이 커 예측성을 높이려 합니다.

  1. 크기·복잡성을 모두 표준화하라 합니다.
  2. 유형을 분석하고 서비스 등급으로 적절히 관리·우선화하게 합니다.
  3. 변동을 무시하고 전체 처리량만 높입니다.
  4. 한 번에 한 유형만 해 단순·예측성을 높입니다.
  5. Sarah를 무시하고 변화 없이 계속합니다.

정답: 보기-2: 유형을 분석하고 서비스 등급으로 적절히 관리·우선화하게 합니다.

문제 73 성공적으로 Kanban을 도입한 개발팀이 이해관계자·관리자의 즉각 변경 요청으로 자주 방해받습니다.

  1. 긴급해도 모두 무시하고 보드를 엄격히 따릅니다.
  2. 이해관계자 요구를 이해하고 흐름을 깨지 않으며 긴급 변경을 반영할 방법을 함께 찾습니다.
  3. 모든 긴급 요청을 즉시 처리할 별도 레인을 만듭니다.
  4. 불필요한 방해를 막도록 상호작용을 제한합니다.
  5. 없는 듯 무시하고 지연 결과를 이해관계자에게 맡깁니다.

정답: 보기-2: 이해관계자 요구를 이해하고 흐름을 깨지 않으며 긴급 변경을 반영할 방법을 함께 찾습니다.

문제 74 최근 생산 개선으로 Kanban을 도입한 제조팀을 코칭합니다. 제한은 있지만 잦은 기계 고장으로 흐름 유지가 어렵습니다.

  1. 고장을 무시하고 제한 준수만 봅니다.
  2. 제한을 없애 고장 대응을 유연하게 합니다.
  3. 고장을 추적·기록하고 데이터로 유지보수를 개선해 방해를 줄입니다.
  4. 제한을 높여 고장 중 더 많은 일을 수용해 전체 흐름을 지킵니다.
  5. 고장을 허용하지 않는 엄격한 유지보수 일정으로 연속성을 보장합니다.

정답: 보기-3: 고장을 추적·기록하고 데이터로 유지보수를 개선해 방해를 줄입니다.

문제 75 Kanban 지원팀은 보드에 오래된 항목이 늘어 걱정하며 효과적 처리를 모릅니다.

  1. 오래된 일을 무시하고 새 요청으로 응답을 개선합니다.
  2. 미해결이어도 일정 시간이 지나면 자동 종료합니다.
  3. 함께 분류·우선화하고 정기 검토·해결을 보장합니다.
  4. 적체가 모두 해결될 때까지 새 요청을 받지 않습니다.
  5. 흔한 문제이므로 조치 없이 무시합니다.

정답: 보기-3: 함께 분류·우선화하고 정기 검토·해결을 보장합니다.

문제 76 프로젝트 관리팀에 자문합니다. Kanban의 작업 의존성 가시화·관리 어려움이 기한을 해칩니다.

  1. 의존을 모두 없애 단순화합니다.
  2. 별도 보드·시각 체계로 병행 관리합니다.
  3. 명시적 정책·스윔레인으로 의존성을 보이게 표현·관리합니다.
  4. 의존은 PM 소프트웨어, 나머지는 Kanban으로 합니다.
  5. 상호의존을 무시하고 개인 작업 완료만 봅니다.

정답: 보기-3: 명시적 정책·스윔레인으로 의존성을 보이게 표현·관리합니다.

문제 77 Kanban 개발팀이 높은 우선순위 작업을 자주 가속해야 해 흐름이 깨집니다.

  1. 만족을 위해 요청될 때마다 가속합니다.
  2. 별도 긴급 레인으로 우선 처리하며 나머지 흐름은 유지합니다.
  3. WIP를 높여 가속 작업과 일반 흐름을 모두 수용합니다.
  4. 협상으로 잦은 가속을 피하고 안정시킵니다.
  5. 요청을 무시하고 지연 결과를 이해관계자에게 맡깁니다.

정답: 보기-2: 별도 긴급 레인으로 우선 처리하며 나머지 흐름은 유지합니다.

문제 78 Kanban 재무 분석팀은 큰 시간 변동 때문에 보고서 준비 시점을 예측하기 어렵습니다.

  1. 기간을 더 정확히 추정합니다.
  2. 긴급 보고서용 신속 레인을 만듭니다.
  3. 유형별 SLA로 이해관계자 기대를 명확히 합니다.
  4. 분석 과정의 효율·신뢰성을 개선해 변동을 줄입니다.
  5. 흔한 어려움이므로 무시하고 계속합니다.

정답: 보기-3: 유형별 SLA로 이해관계자 기대를 명확히 합니다.

문제 79 새 Kanban 마케팅팀에 자문합니다. 콘텐츠 제작 병목이 캠페인 출시를 늦춥니다.

  1. 콘텐츠를 과정에서 빼 따로 관리합니다.
  2. 하류가 준비되면 콘텐츠를 요청하는 풀 체계로 병목 영향을 줄입니다.
  3. 콘텐츠 WIP를 높여 생산을 가속·해결합니다.
  4. 외주로 병목을 완전히 없앱니다.
  5. 흔하므로 무시하고 알아서 하게 합니다.

정답: 보기-2: 하류가 준비되면 콘텐츠를 요청하는 풀 체계로 병목 영향을 줄입니다.

문제 80 Kanban 서비스팀을 코칭합니다. 새 요청이 언제든 들어와 작업을 자주 끊습니다.

  1. 응답이 길어져도 새 요청을 무시하고 초기대로 합니다.
  2. 별도 레인에서 처리해 일반 흐름을 지킵니다.
  3. WIP를 조정해 방해를 수용하고 신속 응답합니다.
  4. 특정 시간에 새 요청을 처리하고 나머지는 기존 일에 집중합니다.
  5. 과정 변경 없이 원하는 대로 처리하게 합니다.

정답: 보기-4: 특정 시간에 새 요청을 처리하고 나머지는 기존 일에 집중합니다.



Kanban Expert 인증 >>



Kanban Project Manager 인증 시험 문제

문제 81 새 제품을 개발하는 “TechPros”의 Kanban Project Manager입니다. 최근 몇 주 꾸준히 WIP를 넘어 흐름 유지가 어렵습니다.

효과적 대응은?

  1. 따라잡으려 일시적으로 제한을 무시합니다.
  2. 제한을 낮춰 부담·통제를 회복합니다.
  3. 초과자에게 엄격한 불이익으로 규율을 강제합니다.
  4. 회고로 초과 근본 원인을 이해하고 해법을 함께 찾습니다.
  5. 리더가 세세히 통제해 준수시킵니다.

정답: 보기-4: 회고로 초과 근본 원인을 이해하고 해법을 함께 찾습니다.

문제 82 “AgileCrafters”는 병·개인 사정의 잦은 결근으로 흐름 중단·리드타임 증가를 겪습니다.

결근 영향을 줄이고 안정시키려면?

  1. 모든 결근에 진단서를 요구해 유효성을 확인합니다.
  2. 예정 없는 휴가를 엄격히 벌합니다.
  3. 돌아와 추가 근무로 보충하게 합니다.
  4. 보드에 결근 영향을 가시화하고 부하 균형·흐름 유지법을 함께 찾습니다.
  5. 자주 빠지는 사람을 바꿉니다.

정답: 보기-4: 보드에 결근 영향을 가시화하고 부하 균형·흐름 유지법을 함께 찾습니다.

문제 83 중요 프로젝트 개발팀의 Kanban Project Manager입니다. 개발자·테스터·디자이너 오해가 최근 생산성을 낮춥니다.

소통·협업을 어떻게 개선하나요?

  1. 엄격한 위계로 채널·결정권을 명확히 합니다.
  2. 전담자가 모든 소통·정확한 전달을 감독합니다.
  3. 문서 중심으로 오해를 줄입니다.
  4. 정기 교차 기능 회의·워크숍으로 이해·협업을 높입니다.
  5. 소통이 어려운 사람을 교체합니다.

정답: 보기-4: 정기 교차 기능 회의·워크숍으로 이해·협업을 높입니다.

문제 84 우선 마케팅 캠페인의 Kanban 관리자입니다. 계속 범위·요구가 바뀌어 지연·예측 불가가 생깁니다.

문제 대응·안정을 위해 무엇을 하나요?

  1. 변경·추가를 거절해 초기 계획을 지킵니다.
  2. 모든 변경에 고위 승인을 요구합니다.
  3. 초과근무로 변경·초기 일정을 맞춥니다.
  4. 모든 변경을 보드에 표시·우선화하고 팀과 흐름을 조정합니다.
  5. 변경 관리를 못 하는 사람을 바꿉니다.

정답: 보기-4: 모든 변경을 보드에 표시·우선화하고 팀과 흐름을 조정합니다.

문제 85 IT 인프라 팀의 Kanban Project Manager입니다. 업그레이드 같은 계획 개선과 서버 중단 같은 비계획 사고의 균형이 어려워 압도됩니다.

계획·비계획 균형을 어떻게 돕나요?

  1. 기한을 위해 계획을 사고보다 우선합니다.
  2. 계획 시간에 사고 처리를 금합니다.
  3. 초과근무로 둘 다 관리합니다.
  4. 둘 다 보드에 표시해 부하를 조정하고 필요시 긴급을 우선합니다.
  5. 둘 다 관리 못 하는 사람을 바꿉니다.

정답: 보기-4: 둘 다 보드에 표시해 부하를 조정하고 필요시 긴급을 우선합니다.

문제 86 새 제품의 “InnovateTech” 팀은 동기·참여 저하로 생산성·품질이 떨어집니다.

동기·참여를 어떻게 높이나요?

  1. 엄격한 평가를 금전 인센티브와 연결합니다.
  2. 추가 업무로 항상 바쁘게 합니다.
  3. 팀원끼리 경쟁하게 합니다.
  4. 정기 개인 면담으로 걱정을 이해하고 역량·개인 성장 기회를 줍니다.
  5. 동기·참여가 낮은 사람을 바꿉니다.

정답: 보기-4: 정기 개인 면담으로 걱정을 이해하고 역량·개인 성장 기회를 줍니다.

문제 87 “AgileBuilders”는 여러 이해관계자의 잦은 범위 요청으로 집중·안정된 흐름 유지가 어렵습니다.

변경 대응·안정에 무엇을 권하나요?

  1. 모두 거절해 초기 계획·일정을 지킵니다.
  2. 목표·우선순위 영향을 평가하는 공식 변경 절차를 도입합니다.
  3. 영향과 무관하게 모두 수용해 만족시킵니다.
  4. 보드에 표시하고 적절히 우선화·반영하며 안정을 지킵니다.
  5. 변경 관리가 어려운 사람을 바꿉니다.

정답: 보기-2: 목표·우선순위 영향을 평가하는 공식 변경 절차를 도입합니다.

문제 88 “TechSprinters”는 작고 빠른 일과 크고 오래 걸리는 일의 불균형으로 예측·리드타임이 나빠집니다.

크기 균형·예측성을 위해 무엇을 하나요?

  1. 작은 일을 우선해 크기를 일정하게 합니다.
  2. 일정 크기 이상은 금합니다.
  3. 더 오래 일해 큰 일을 끝냅니다.
  4. 크기를 보드에 표시하고 적절한 처리·예측성 정책을 함께 정합니다.
  5. 여러 크기를 못 다루는 사람을 바꿉니다.

정답: 보기-4: 크기를 보드에 표시하고 적절한 처리·예측성 정책을 함께 정합니다.

문제 89 “CodeCrafters”의 새 Alice는 Kanban·분야 경험이 적습니다. 팀은 지식 부족이 흐름·성과를 늦춘다고 걱정합니다.

원활히 통합하려면 어떻게 하나요?

  1. 추가 업무로 학습·통합을 가속합니다.
  2. 팀 내 멘토가 밀접히 안내하고 학습을 돕습니다.
  3. 혼자 따라잡아 속도·지식을 맞추게 합니다.
  4. 진행·작업을 표시하고 맞춤 교육·온보딩으로 지원합니다.
  5. 숙련자로 교체해 속도를 유지합니다.

정답: 보기-2: 팀 내 멘토가 밀접히 안내하고 학습을 돕습니다.

문제 90 출시 전 품질을 담당하는 “QualityMasters”는 잦은 갈등·이견으로 협업·사기가 나빠집니다.

갈등에 대응하고 조화롭게 하려면?

  1. 엄격한 규칙으로 이견·갈등을 금합니다.
  2. 팀워크 활동으로 유대·협력을 장려합니다.
  3. 논의를 피하고 개인 작업만 해 갈등을 줄입니다.
  4. 공개 논의·회고로 갈등과 팀 역학 개선책을 함께 찾습니다.
  5. 갈등 당사자를 바꿔 조화를 만듭니다.

정답: 보기-4: 공개 논의·회고로 갈등과 팀 역학 개선책을 함께 찾습니다.



Kanban Project Manager 인증 >>



Scrum Team Member 인증 시험 문제

문제 91 Scrum 개발자입니다. 계획에서 Product Owner가 모호한 요구·수락 기준의 스토리를 제시해 기대대로 완료할지 걱정합니다.

Scrum Team Member의 가장 적절한 행동은?

  1. 계획 회의에서 Product Owner에게 명확화를 요청합니다.
  2. 건너뛰고 다음에 요구가 명확하면 합니다.
  3. 지연을 피하려 질문 없이 최선을 다합니다.
  4. 요구 부족으로 Master에게 제거를 요청합니다.
  5. 모호한 요구를 불평하고 거절합니다.

정답: 보기-1: 계획 회의에서 Product Owner에게 명확화를 요청합니다.

문제 92 Sarah가 항상 많은 일을 맡아 야간·주말에도 목표를 위해 일합니다. 소진과 협업 영향이 있습니다.

팀원으로 무엇을 하나요?

  1. 헌신을 인정하고 계속하게 합니다.
  2. 개인적으로 안녕을 걱정하며 더 균등한 분담을 제안합니다.
  3. 개인 선택이며 성공에 좋으므로 무시합니다.
  4. Master에게 과로를 막도록 보고합니다.
  5. 지속 가능 속도·장기 과로 피해를 팀 회의로 논의합니다.

정답: 보기-2: 개인적으로 안녕을 걱정하며 더 균등한 분담을 제안합니다.

문제 93 Review가 지루·비생산적이라 참여가 줄었습니다. Product Owner 발표는 길고 팀 의견을 잘 받지 않습니다.

효과·참여를 어떻게 개선하나요?

  1. 다음 회고에서 불평하고 형식 변경을 요구합니다.
  2. 의견이 무시되므로 조용히 빠져 자기 일에 집중합니다.
  3. 진행에 자원하고 상호작용 요소로 참여·협업을 높입니다.
  4. 회의에서 Product Owner 발표 방식을 따지고 더 흥미로운 내용을 요구합니다.
  5. Master에게 개인적으로 팀 걱정을 다뤄달라 합니다.

정답: 보기-3: 진행에 자원하고 상호작용 요소로 참여·협업을 높입니다.

문제 94 여러 Sprint 목표를 계속 놓쳐 팀이 낙담·과부하입니다. Master가 “Scrumban”을 제안합니다.

팀원으로 무엇을 하나요?

  1. 틀보다 실행을 고쳐야 하므로 반대합니다.
  2. 새 아이디어일 수 있어 수용·지원합니다.
  3. Master와 이유를 이해하고 기존 Scrum 내 다른 해결책을 논의합니다.
  4. 한 Sprint Scrum을 쉬고 비구조적으로 일해 성과를 봅니다.
  5. 팀 상담 없이 바꾸는 결정을 Product Owner에게 불평합니다.

정답: 보기-3: Master와 이유를 이해하고 기존 Scrum 내 다른 해결책을 논의합니다.

문제 95 여러 이해관계자의 경쟁 요구로 Product Owner가 균형을 못 잡고 요청마다 백로그를 바꿉니다.

목표 집중을 어떻게 돕나요?

  1. 만족·지지를 위해 계속 수용하게 합니다.
  2. 중요도와 무관하게 모든 요청을 무시합니다.
  3. 잦은 변경 영향을 팀과 논의하고 투명한 순위 설정을 돕습니다.
  4. Master에게 무능을 불평하고 교체를 제안합니다.
  5. 계획 확정 후 백로그 변경을 엄격히 금하게 합니다.

정답: 보기-3: 잦은 변경 영향을 팀과 논의하고 투명한 순위 설정을 돕습니다.

문제 96 포인트를 써도 복잡성·노력 추정이 부정확해 지연·뜻밖 문제가 생깁니다.

팀원으로 정확성을 어떻게 높이나요?

  1. 연습으로 좋아지니 현재대로 합니다.
  2. 시간 단위로 바꿔 추정·추적합니다.
  3. 애자일 추정 교육으로 함께 더 잘 배우자고 합니다.
  4. 더 직관·정확한 티셔츠 크기를 강제합니다.
  5. 복잡·혼란이 불필요하므로 추정을 없애달라 합니다.

정답: 보기-3: 애자일 추정 교육으로 함께 더 잘 배우자고 합니다.

문제 97 Scrum 팀은 Sprint 도중 범위가 자주 변경되어 업무에 차질을 겪고 Sprint 목표를 달성하기 어려워지고 있습니다. Product Owner는 Sprint 도중 사용자 스토리를 자주 추가하거나 삭제합니다.

Scrum 팀원으로서 이 문제를 해결하고 안정적인 Sprint를 유지하려면 어떻게 해야 합니까?

  1. Product Owner의 행동이 팀 업무를 방해하고 Sprint 목표에 영향을 주므로 팀에서 제외해 달라고 요청합니다.
  2. Product Owner와 문제를 논의하고 Sprint가 시작되면 Sprint 백로그를 변경하지 않겠다고 약속하도록 제안합니다.
  3. Product Owner가 원하는 것을 제공하지 못하더라도 범위 변경을 무시하고 원래 Sprint 백로그 작업을 계속합니다.
  4. Scrum Master에게 Product Owner의 행동에 대해 불만을 제기하고 Sprint 도중 범위 변경을 막도록 개입해 달라고 요청합니다.
  5. 원래 Sprint 백로그에 없는 사용자 스토리 작업을 모두 거부하고 Product Owner에게 변경은 허용되지 않는다고 말합니다.

정답: 보기-2: Product Owner와 문제를 논의하고 Sprint가 시작되면 Sprint 백로그를 변경하지 않겠다고 약속하도록 제안합니다.

문제 98 Scrum 팀은 외부 의존성이 많은 프로젝트를 진행하며, 이러한 의존성으로 인한 지연과 장애 요인을 자주 겪습니다. 이는 팀의 Sprint 목표 달성 능력에 영향을 주고 있습니다.

Scrum 팀원으로서 외부 의존성을 더 효과적으로 관리하고 팀에 미치는 영향을 줄이려면 어떤 조치를 취할 수 있습니까?

  1. 지연의 책임을 외부 팀에 돌리고 우리 팀의 요구를 충족하려면 그들이 더 잘 일해야 한다고 주장합니다.
  2. Scrum Master와 회의를 요청하여 문제를 논의하고 외부 팀과 더 적극적으로 소통하는 등의 해결책을 모색합니다.
  3. 외부 의존성은 팀의 통제 밖이며 효과적으로 관리할 수 없으므로 외부 의존성이 있는 사용자 스토리 작업을 모두 거부합니다.
  4. 외부 의존성과 관계없이 사용자 스토리를 개별적으로 작업하기 시작하고 의존성이 해결되면 통합하자고 제안합니다.
  5. Product Owner에게 외부 의존성에 대해 불만을 제기하고 외부 요인과 무관한 사용자 스토리를 제공하라고 요구합니다.

정답: 보기-2: Scrum Master와 회의를 요청하여 문제를 논의하고 외부 팀과 더 적극적으로 소통하는 등의 해결책을 모색합니다.

문제 99 Scrum 팀은 여러 Sprint 동안 함께 일해 왔으며, 팀원들이 Sprint 회고에서 건설적인 피드백과 대립을 자주 피한다는 것을 발견했습니다. 해결할 문제가 있어도 팀은 Sprint의 긍정적인 측면에 집중하려 합니다.

Scrum 팀원으로서 Sprint 회고에서 개방적이고 솔직한 피드백 문화를 장려하려면 어떻게 할 수 있습니까?

  1. 조화로운 업무 환경을 유지하도록 팀원들에게 Sprint의 긍정적인 측면에 계속 집중하라고 권장합니다.
  2. 회고에서 문제를 공개적으로 논의하고 건설적인 피드백을 제공하며 솔선수범하여 다른 팀원들에게 모범을 보입니다.
  3. Scrum Master와 따로 이야기하고 팀 내 부정적인 분위기를 피하도록 회고에서는 긍정적인 측면만 논의한다는 엄격한 규칙을 시행해 달라고 요청합니다.
  4. 팀이 회고 중 공개적인 논의를 불편해하므로 회고 외에 추가 회의를 잡아 문제를 다루고 피드백을 제공합니다.
  5. 팀원들에게 회고 중 우려와 문제를 공개적으로 표현하도록 권장하고 개선을 위한 안전한 공간임을 강조합니다.

정답: 보기-5: 팀원들에게 회고 중 우려와 문제를 공개적으로 표현하도록 권장하고 개선을 위한 안전한 공간임을 강조합니다.

문제 100 Scrum 팀은 같은 장소에서 일하던 방식에서 서로 다른 장소와 시간대에서 일하는 분산 팀으로 전환하고 있습니다. 이 전환으로 의사소통과 협업에 어려움이 생겼습니다.

Scrum 팀원으로서 분산 Scrum 팀 내 협업과 의사소통을 개선하려면 어떤 조치를 취할 수 있습니까?

  1. 원격 협업의 어려움을 피하도록 업무를 독립적으로 수행하고 필요할 때만 소통하겠다고 요청합니다.
  2. 화상 회의와 인스턴트 메시지 등 실시간 상호작용과 협업을 돕는 다양한 의사소통 도구와 채널의 사용을 지지합니다.
  3. 원격 팀원 간 협업의 필요성을 최소화하도록 업무 범위를 제한하고 개인의 기여에 집중하자고 제안합니다.
  4. 분산 팀에서 일하기를 거부하고 원격 근무의 어려움을 피하도록 같은 장소에서 일하는 팀으로 옮겨 달라고 요구합니다.
  5. 매일 스탠드업 회의에 적극적으로 참여하고 팀원들에게 정기적으로 진행 상황을 알리며 원격 동료들과 협업하고 지식을 공유할 기회를 적극적으로 찾습니다.

정답: 보기-2: 화상 회의와 인스턴트 메시지 등 실시간 상호작용과 협업을 돕는 다양한 의사소통 도구와 채널의 사용을 지지합니다.



Scrum Team Member 자격증 >>



Scrum Developer 인증 시험 문제

문제 101 Jill은 소프트웨어 개발 팀의 Scrum Developer입니다. 현재 Sprint에서 팀은 외부 시스템과의 통합이 필요한 복잡한 기능을 개발하고 있습니다. 통합을 돕는 특정 라이브러리가 필요하다는 사실을 알게 됩니다. Jill은 사용 경험이 있는 인기 오픈 소스 라이브러리를 제안하지만, 동료 Mark는 회사가 라이선스를 보유한 독점 라이브러리를 선호합니다.

이 상황에서 Jill은 어떻게 해야 합니까?

  1. 이미 사용할 수 있으므로 Mark의 선호에 따라 독점 라이브러리를 사용합니다.
  2. 시간을 절약하고 비용 효율적일 수 있으므로 자신에게 익숙한 오픈 소스 라이브러리의 사용을 고집합니다.
  3. 각 라이브러리의 장단점을 팀과 논의하고 프로젝트의 필요에 따라 공동으로 결정합니다.
  4. Product Owner에게 문제를 전달하고 교착 상태를 해결할 최종 결정을 요청합니다.
  5. 팀 내 갈등을 피하도록 당장은 라이브러리 문제를 무시하고 다른 작업에 집중합니다.

정답: 보기-3 / 각 라이브러리의 장단점을 팀과 논의하고 프로젝트의 필요에 따라 공동으로 결정합니다.

문제 102 Scrum 팀은 모바일 애플리케이션 개발 프로젝트를 진행하고 있습니다. Sprint 계획 회의에서 Product Owner인 Brian은 다음 릴리스에 매우 중요하다고 생각하는 새 기능을 제시합니다. 팀은 이 기능이 Sprint에서 사용 가능한 역량 대부분을 차지할 것으로 추정합니다.

하지만 Scrum Developer인 Sarah는 Sprint 내에 이 기능을 구현하는 데 따르는 기술적 복잡성과 위험을 우려합니다. 릴리스가 지연되고 제품의 전반적인 품질에 영향을 줄 수 있다고 생각합니다.

이 상황에서 Sarah는 어떻게 해야 합니까?

  1. Product Owner의 요청에 따라 즉시 기능을 수락하고 제공을 약속합니다.
  2. 팀에 우려를 표현하고 이후 Sprint에서 처리할 수 있도록 기능을 더 작고 관리 가능한 부분으로 나누자고 제안합니다.
  3. Product Owner에게 Sprint 내 구현이 기술적으로 불가능하므로 해당 기능을 범위에서 제외해야 한다고 알립니다.
  4. 요청대로 기능을 개발하되 팀이나 Product Owner에게 알리지 않고 다음 Sprint까지 미룰 계획을 몰래 세웁니다.
  5. 팀을 참여시키지 않고 Scrum Master가 Product Owner와 협상하여 문제를 해결하도록 설득합니다.

정답: 보기-2 / 팀에 우려를 표현하고 이후 Sprint에서 처리할 수 있도록 기능을 더 작고 관리 가능한 부분으로 나누자고 제안합니다.

문제 103 Scrum 팀은 전자 상거래 웹사이트의 웹 개발 프로젝트를 진행하고 있습니다. Sprint 리뷰에서 이해관계자들은 새 기능이 제공된 디자인 명세와 일치하지 않는다는 점을 발견합니다. 이들은 실망하며 프로젝트 지연을 우려합니다.

Scrum Developer로서 이 상황에 어떻게 대응해야 합니까?

  1. 디자인 명세가 항상 실용적인 것은 아니며 개발 과정에서 조정이 필요할 수 있다고 설명하며 팀을 옹호합니다.
  2. 문제를 인정하고 팀과 상의하지 않은 채 다음 Sprint에서 디자인의 차이를 수정하겠다고 제안합니다.
  3. 이해관계자들과 회의를 잡아 우려를 이해하고 팀과 함께 디자인 문제를 해결할 계획을 세웁니다.
  4. 명확하고 정확한 명세를 제공하지 않은 디자인 팀을 비난하며 개발 팀의 책임을 돌립니다.
  5. 디자인 명세는 충분하며 이해관계자의 기대가 비현실적이라고 생각하여 피드백을 무시합니다.

정답: 보기-3 / 이해관계자들과 회의를 잡아 우려를 이해하고 팀과 함께 디자인 문제를 해결할 계획을 세웁니다.

문제 104 Scrum 팀은 마감이 촉박한 프로젝트를 진행하며, Product Owner인 Lisa는 사용자 스토리를 마지막 순간에 자주 변경해 달라고 요구합니다. 이 변경으로 팀의 업무 흐름이 방해받아 원래 Sprint 계획을 따라가기 어려워지고 있습니다.

Scrum Developer로서 Lisa의 잦은 사용자 스토리 변경을 어떻게 처리해야 합니까?

  1. Sprint 목표를 놓치더라도 Lisa의 모든 변경을 이의 없이 수용합니다.
  2. Lisa의 요청과 관계없이 변경을 모두 거부하고 원래 사용자 스토리를 고수합니다.
  3. Lisa와 회의를 잡아 변경이 팀의 Sprint 목표 달성 능력에 미치는 영향을 논의하고 절충안을 제안합니다.
  4. 개발 팀이 방해받지 않고 업무에 집중하도록 Scrum Master에게 알리고 Lisa의 요청을 처리하게 합니다.
  5. 팀 내 갈등을 피하도록 팀이나 Scrum Master에게 알리지 않고 Lisa의 변경을 몰래 작업합니다.

정답: 보기-3 / Lisa와 회의를 잡아 변경이 팀의 Sprint 목표 달성 능력에 미치는 영향을 논의하고 절충안을 제안합니다.

문제 105 Scrum 팀은 새 모바일 앱 개발 프로젝트를 진행하고 있습니다. Sprint 계획 회의에서 Product Owner인 Robert는 요구사항과 인수 기준이 모호한 사용자 스토리를 제공합니다. 그는 개발을 진행해야 하며 세부 사항은 나중에 정하면 된다고 주장합니다.

Scrum Developer로서 이 상황을 어떻게 처리해야 합니까?

  1. Sprint 중에 세부 사항이 명확해질 것이라 믿고 Product Owner의 지시대로 개발을 시작합니다.
  2. 명확한 요구사항과 인수 기준 없이는 개발을 시작하지 않겠다고 하며 작업 시작 전 정의의 중요성을 강조합니다.
  3. 팀 회의를 열어 Product Owner와 문제를 논의하고 개발 시작 전에 요구사항을 명확히 해야 한다고 주장합니다.
  4. 개발을 시작하되 Scrum Master에게 불명확한 점을 알리고 문제는 나중에 해결하도록 둡니다.
  5. Product Owner나 팀과 상의하지 않고 가정을 세워 사용자 스토리를 적극적으로 작업하고 빠르게 완료합니다.

정답: 보기-3 / 팀 회의를 열어 Product Owner와 문제를 논의하고 개발 시작 전에 요구사항을 명확히 해야 한다고 주장합니다.

문제 106 Scrum 팀은 새 소프트웨어 제품을 개발하고 있습니다. Sprint 계획 회의에서 Product Owner인 Emma는 즉시 해결해야 하는 중대한 버그 수정을 제시합니다. 이 버그는 운영 환경에 영향을 주며 고객 만족도에 미치는 영향이 큽니다.

Scrum Developer로서 이 상황에 어떻게 대응해야 합니까?

  1. 예측 가능성을 유지하도록 Sprint 백로그를 따르며 버그 수정을 다음 Sprint로 미루고 계획된 작업을 계속합니다.
  2. 고객 만족도에 미치는 영향이 크므로 버그 수정을 수락하고 즉시 작업하여 문제를 해결합니다.
  3. Scrum Master에게 문제를 전달하고 버그 수정을 우선해야 할지 결정하도록 합니다.
  4. 원래 Sprint는 계획대로 진행하면서 버그를 해결할 별도의 긴급 Sprint를 만들자고 제안합니다.
  5. Sprint 도중 Scrum 팀의 작업을 방해해서는 안 된다고 생각하여 버그 수정 요청을 무시합니다.

정답: 보기-2 / 고객 만족도에 미치는 영향이 크므로 버그 수정을 수락하고 즉시 작업하여 문제를 해결합니다.

문제 107 Scrum 팀은 프로젝트를 진행하며 개발 팀원들은 팀 개발 프로세스의 개선 가능성을 발견했습니다. 이러한 개선으로 효율성과 제품 품질이 높아질 수 있지만 구현에는 시간과 노력이 필요합니다.

Scrum Developer로서 이 상황에 어떻게 접근해야 합니까?

  1. 개선 아이디어를 팀과 공유하되 Scrum 원칙상 Sprint 도중 변경은 허용되지 않는다고 강조합니다.
  2. 팀의 성공에 꼭 필요한 개선이므로 현재 Sprint를 방해하더라도 즉시 변경을 적용합니다.
  3. 개선 아이디어를 다음 Sprint를 위해 기록하고 다음 Sprint 회고에서 팀과 논의합니다.
  4. 변경은 불필요한 복잡성을 초래할 수 있으므로 개선 아이디어를 무시하고 현재 프로세스를 계속 따릅니다.
  5. 개발 팀을 참여시키지 않고 Scrum Master가 이러한 개선의 구현을 처리하도록 제안합니다.

정답: 보기-3 / 개선 아이디어를 다음 Sprint를 위해 기록하고 다음 Sprint 회고에서 팀과 논의합니다.

문제 108 Scrum 팀은 기존 소프트웨어 제품에 복잡한 기능을 추가하는 프로젝트를 진행하고 있습니다. Sprint 도중 정해진 기간 안에 모든 사용자 스토리를 완료하지 못할 수 있다는 점이 분명해집니다. 팀은 Sprint 목표에 미칠 영향을 우려합니다.

Scrum Developer로서 이 상황에서 어떤 조치를 취해야 합니까?

  1. 원래 약속을 지키기 위해 Sprint 기간을 넘기더라도 모든 사용자 스토리 작업을 계속합니다.
  2. Product Owner와 문제를 논의하고 팀이 Sprint 목표를 달성하도록 일부 사용자 스토리를 제외하는 방안을 협상합니다.
  3. Scrum Master와 Product Owner에게 예상 문제를 알리고 진행 방법에 대한 지침을 기다립니다.
  4. 팀이나 Product Owner와 상의하지 않고 Sprint 내 모든 사용자 스토리를 완료하기 위해 초과 근무하기로 결정합니다.
  5. 팀 내 갈등을 피하도록 문제를 무시하고 각 팀원이 대처 방법을 개별적으로 결정하게 합니다.

정답: 보기-3 / Scrum Master와 Product Owner에게 예상 문제를 알리고 진행 방법에 대한 지침을 기다립니다.

문제 109 Scrum 팀은 타사 서비스와의 통합이 필요한 프로젝트를 진행하고 있습니다. 여러 기술적 문제와 지연으로 통합 과정에 어려움이 있습니다. Scrum Master는 통합을 성공적으로 완료하도록 현재 Sprint를 연장하자고 제안합니다.

Scrum Developer로서 이 제안에 어떻게 대응해야 합니까?

  1. 팀의 계획에 차질이 생기더라도 Sprint를 연장하여 통합을 성공시키자는 Scrum Master의 제안에 동의합니다.
  2. 팀은 원래 Sprint 기간 내에 계획한 작업을 완료해야 한다고 주장하며 Sprint 연장 제안을 거절합니다.
  3. Scrum Master 및 팀과 회의를 잡아 통합의 어려움을 논의하고 Sprint 연장의 실행 가능성을 평가합니다.
  4. 팀이 과로하게 되더라도 통합을 성공시키기 위해 팀이나 Scrum Master와 상의하지 않고 Sprint를 연장합니다.
  5. 팀 내 갈등을 피하도록 통합 문제를 무시하고 원래 Sprint 계획을 따릅니다.

정답: 보기-3 / Scrum Master 및 팀과 회의를 잡아 통합의 어려움을 논의하고 Sprint 연장의 실행 가능성을 평가합니다.

문제 110 Scrum 팀은 기존 제품의 새 기능을 개발하는 프로젝트를 진행하고 있습니다. Sprint 도중 Product Owner인 David는 이해관계자에게서 새 정보를 받습니다. 이 정보로 인해 Sprint 백로그의 사용자 스토리 하나를 크게 변경해야 합니다. 이 변경은 팀의 Sprint 목표 달성 능력에 영향을 줄 가능성이 큽니다.

Scrum Developer로서 이 상황을 어떻게 처리해야 합니까?

  1. 이해관계자의 요청을 충족하기 위해 Sprint 목표를 놓치더라도 변경을 즉시 수용합니다.
  2. Sprint에 차질을 주므로 이후 Sprint에서 다뤄야 한다고 주장하며 사용자 스토리의 변경을 모두 거부합니다.
  3. 제안된 변경을 팀과 논의하고 Sprint에 미치는 영향을 분석하며 최선의 행동 방침을 함께 결정합니다.
  4. 이해관계자의 요청을 빠르게 충족하는 데 필요하다고 생각하여 팀에 알리지 않고 변경을 구현합니다.
  5. 팀이 Sprint에 집중하도록 팀을 참여시키지 않고 Scrum Master가 변경 요청을 처리하자고 제안합니다.

정답: 보기-3 / 제안된 변경을 팀과 논의하고 Sprint에 미치는 영향을 분석하며 최선의 행동 방침을 함께 결정합니다.



Scrum Developer 자격증 >>



Design Thinking 인증 시험 문제

문제 111 디자인 씽킹은 공감, 창의성, 반복적인 과정을 포함하는 인간 중심의 문제 해결 접근법입니다. 다음 상황을 살펴보세요.

당신은 모바일 뱅킹 앱의 사용자 경험을 개선하는 프로젝트에서 팀과 함께 일하는 Design Thinking Professional입니다. 공감 단계에서 팀은 여러 사용자를 인터뷰합니다. 그중 Sarah는 앱의 탐색 방식과 불명확한 거래 내역에 대한 불만을 표현합니다. 이러한 인터뷰에서 유용한 통찰을 얻습니다.

디자인 씽킹 과정에서 다음으로 어떤 조치를 취해야 합니까?

  1. 앱의 탐색 방식과 거래 내역을 개선할 아이디어를 도출하는 브레인스토밍을 진행합니다.
  2. 사용자 인터뷰에서 얻은 통찰을 바탕으로 개선된 앱의 프로토타입을 만듭니다.
  3. 사용자 인터뷰의 결과를 이해관계자 및 개발 팀과 공유하는 발표를 준비합니다.
  4. 아이디어 도출 단계로 넘어가기 전에 사용자 인터뷰를 더 진행하여 추가 데이터를 수집합니다.
  5. 다기능 팀을 구성하여 사용자 피드백에 따른 앱 변경을 즉시 구현하기 시작합니다.

정답: 보기-1: 앱의 탐색 방식과 거래 내역을 개선할 아이디어를 도출하는 브레인스토밍을 진행합니다.

문제 112 디자인 씽킹의 핵심 원칙 중 하나는 “프로토타입 제작과 테스트”입니다. 다음 상황을 살펴보세요.

팀은 새로운 친환경 물병을 디자인하는 프로젝트를 진행하고 있습니다. 사용자 인터뷰 후 여러 디자인 아이디어가 나왔습니다. 팀은 아이디어를 테스트하기 위해 프로토타입을 만들기로 합니다. 테스트 중 사용자가 물병을 쉽게 열고 확실히 닫는 데 어려움을 겪는다는 사실을 발견합니다.

프로토타입 제작과 테스트 단계에서 이 문제를 해결하려면 팀은 어떻게 해야 합니까?

  1. 나중에 해결할 수 있는 사소한 문제이므로 무시하고 기존 프로토타입으로 진행합니다.
  2. 테스트를 중단하고 물병 뚜껑 구조를 다시 설계하여 문제를 해결할 새 프로토타입을 만듭니다.
  3. 문제가 중대한지 일회성인지 확인하기 위해 테스트를 계속하고 데이터를 더 수집합니다.
  4. 현재 디자인에 문제가 너무 많은 것 같으므로 완전히 다른 디자인 아이디어로 전환합니다.
  5. 사용자에게 문제를 공유하고 해결책을 제안해 달라고 한 뒤 그 아이디어를 즉시 구현합니다.

정답: 보기-2: 테스트를 중단하고 물병 뚜껑 구조를 다시 설계하여 문제를 해결할 새 프로토타입을 만듭니다.

문제 113 디자인 씽킹에는 다양한 분야의 구성원으로 이루어진 다기능 팀이 참여하는 경우가 많습니다. 다음 상황을 상상해 보세요.

당신은 소매 회사의 온라인 쇼핑 경험을 개선하는 디자인 씽킹 팀을 이끌고 있습니다. 팀에는 디자이너, 개발자, 마케팅 담당자, 고객 서비스 담당자가 있습니다. 아이디어 도출 단계에서 제안된 기능의 구현 가능성을 놓고 디자이너와 개발자 사이에 갈등이 생깁니다.

Design Thinking Professional로서 이 갈등을 효과적으로 해결하려면 어떻게 해야 합니까?

  1. 디자이너가 사용자 경험을 책임지므로 그들의 아이디어를 우선해야 한다며 디자이너 편을 듭니다.
  2. 디자이너와 개발자가 서로 다른 해결책을 독립적으로 작업하도록 팀을 별도의 그룹으로 나눕니다.
  3. 디자이너와 개발자의 협력적인 논의를 촉진하여 절충안을 모색하고 사용자 경험과 기술적 실현 가능성의 균형을 맞추는 해결책을 찾습니다.
  4. 추가 갈등을 피하도록 디자이너와 개발자 모두에게서 의사결정 권한을 회수하고 직접 최종 결정을 내립니다.
  5. 사용자 만족에 필수적이므로 원래 디자인을 유지하고 개발자가 구현 방법을 알아내게 합니다.

정답: 보기-3: 디자이너와 개발자의 협력적인 논의를 촉진하여 절충안을 모색하고 사용자 경험과 기술적 실현 가능성의 균형을 맞추는 해결책을 찾습니다.

문제 114 디자인 씽킹은 사용자 요구와 감정을 이해하는 것이 중요한 “공감” 단계에서 시작하는 경우가 많습니다. 다음 상황을 살펴보세요.

당신은 모바일 뱅킹 앱의 초기 이용 경험을 개선하는 디자인 씽킹 팀의 일원입니다. 사용자 인터뷰에서 John이라는 사용자는 앱의 가입 절차와 명확한 안내의 부족에 대한 불만을 표현합니다.

“공감” 단계에서 John의 우려를 효과적으로 해결하려면 팀은 어떻게 해야 합니까?

  1. 다른 사용자들은 가입 절차에 문제가 없다고 가정하고 John의 피드백을 개인적인 사례로 여겨 무시합니다.
  2. 재설계에 시간이 많이 걸릴 수 있으므로 John의 피드백을 기록한 뒤 기존 초기 이용 절차를 유지합니다.
  3. John과 더 깊이 대화하여 가입 절차에서 겪는 불만과 불편 사항을 자세히 파악합니다.
  4. John의 우려를 해결하는 것이 매우 중요하므로 피드백을 바탕으로 전체 초기 이용 절차를 즉시 다시 설계합니다.
  5. 계획된 초기 이용 개선을 계속하고 이후 앱의 반복 개발에서 John의 우려를 다루는 방안을 고려합니다.

정답: 보기-3: John과 더 깊이 대화하여 가입 절차에서 겪는 불만과 불편 사항을 자세히 파악합니다.

문제 115 디자인 씽킹은 공감과 사용자 요구 이해의 중요성을 강조합니다. 다음 상황을 살펴보세요.

당신은 소매 회사의 쇼핑 경험을 개선하는 디자인 씽킹 팀을 이끌고 있습니다. 사용자 인터뷰에서 Lisa는 더 지속 가능한 쇼핑 경험을 원한다고 말합니다. 그녀는 친환경 포장과 제품 조달의 중요성을 강조합니다.

Lisa의 우려를 다루고 디자인 과정에 지속 가능성을 반영하려면 팀은 어떻게 해야 합니까?

  1. 대부분의 쇼핑객에게 지속 가능성은 큰 관심사가 아니며 비용이 증가할 수 있으므로 Lisa의 피드백을 무시합니다.
  2. 지속 가능성을 부차적으로 고려하되 디자인 과정에서 편의성과 가격 접근성 등의 다른 요인을 우선합니다.
  3. Lisa와 더 논의하여 그녀가 가장 중요하게 생각하는 지속 가능성의 구체적인 측면을 이해하고 쇼핑 경험에 반영할 방법을 모색합니다.
  4. 쇼핑객의 편의성과 가격 접근성을 희생하더라도 지속 가능성을 우선하도록 쇼핑 경험 전체를 개편합니다.
  5. 현재 일정과 목표에 차질을 줄 수 있으므로 기존 디자인 계획을 유지하고 지속 가능성 문제는 별도 프로젝트에서 다룹니다.

정답: 보기-3: Lisa와 더 논의하여 그녀가 가장 중요하게 생각하는 지속 가능성의 구체적인 측면을 이해하고 쇼핑 경험에 반영할 방법을 모색합니다.

문제 116 디자인 씽킹은 반복적인 프로토타입 제작과 테스트를 장려합니다. 다음 상황을 상상해 보세요.

당신은 비영리 단체의 새 디지털 플랫폼을 설계하는 디자인 씽킹 팀의 일원입니다. 초기 프로토타입을 만든 후 여러 참가자와 사용자 테스트를 진행합니다. 피드백을 통해 일부 사용자가 플랫폼의 탐색 방식을 혼란스러워한다는 사실을 알게 됩니다.

이 시점에서 팀이 취할 가장 적절한 조치는 무엇입니까?

  1. 피드백을 개인적인 선호의 결과로 여겨 무시하고 기존 탐색 디자인을 유지합니다.
  2. 피드백을 바탕으로 탐색 방식을 수정하고 추가 사용자 테스트를 위한 새 프로토타입을 만듭니다.
  3. 탐색 방식을 변경하기 전에 더 다양한 의견을 수집하도록 추가 사용자를 대상으로 테스트를 계속합니다.
  4. 탐색 디자인에 대한 팀원들의 의견을 토대로 최선의 행동 방침을 정하도록 전체 팀원을 대상으로 설문조사를 합니다.
  5. 혼란스럽다고 느낀 사용자의 우려를 해결하기 위해 완전히 다른 탐색 디자인을 적용합니다.

정답: 보기-2: 피드백을 바탕으로 탐색 방식을 수정하고 추가 사용자 테스트를 위한 새 프로토타입을 만듭니다.

문제 117 디자인 씽킹에는 협업과 여러 분야가 참여하는 팀이 필요한 경우가 많습니다. 다음 상황을 살펴보세요.

당신은 대도시의 대중교통 체계를 재설계하는 디자인 씽킹 팀을 이끌고 있습니다. 팀에는 도시 계획가, 소프트웨어 개발자, 교통 전문가가 있습니다. 아이디어 도출 단계에서 효율성, 지속 가능성, 사용자 경험 등 우선순위가 서로 다른 팀원 간에 갈등이 생깁니다.

Design Thinking Professional로서 이 갈등을 효과적으로 관리하려면 어떻게 해야 합니까?

  1. 도시 설계 전문성을 다른 고려 사항보다 우선해야 한다며 도시 계획가 편을 듭니다.
  2. 프로젝트의 각 측면에 최선의 해결책이 나올 수 있으므로 각 팀원이 협업 없이 자신의 우선순위를 독립적으로 추구하도록 합니다.
  3. 팀 내 협력적인 논의를 촉진하여 다양한 우선순위의 균형을 맞추고 효율성, 지속 가능성, 사용자 경험 사이의 절충을 고려하는 해결책을 찾습니다.
  4. 갈등을 빠르게 해결하고 프로젝트가 순조롭게 진행되도록 프로젝트의 통제권을 가져와 직접 최종 결정을 내립니다.
  5. 교통 체계가 단절되더라도 효율성, 지속 가능성, 사용자 경험을 위한 별도의 해결책을 구현합니다.

정답: 보기-3: 팀 내 협력적인 논의를 촉진하여 다양한 우선순위의 균형을 맞추고 효율성, 지속 가능성, 사용자 경험 사이의 절충을 고려하는 해결책을 찾습니다.

문제 118 디자인 씽킹은 사용자에 대한 공감에서 시작하는 경우가 많습니다. 다음 상황을 살펴보세요.

당신은 의료 서비스 제공자를 위한 모바일 앱을 개선하는 팀을 이끄는 Design Thinking Professional입니다. 사용자 인터뷰에서 의료 전문가 Michael은 앱의 보안과 개인정보 보호 기능을 우려하며, 이러한 문제가 앱 사용의 큰 장벽이라고 강조합니다.

디자인 과정의 초기 단계에서 Michael의 우려를 효과적으로 해결하려면 팀은 어떻게 해야 합니까?

  1. 대부분의 의료 전문가에게 보안과 개인정보 보호는 최우선 사항이 아니라고 가정하고 Michael의 피드백을 무시합니다.
  2. 보안과 개인정보 보호 문제를 해결하는 데 시간이 너무 많이 걸릴 수 있으므로 Michael의 피드백을 기록하되 기존 디자인 계획을 유지합니다.
  3. Michael과 더 논의하여 그가 가장 중요하게 생각하는 보안 및 개인정보 보호의 구체적인 측면을 이해하고 앱 디자인에 반영할 방법을 모색합니다.
  4. 원래 디자인이 크게 달라지더라도 Michael의 피드백에 따라 앱의 보안 및 개인정보 보호 기능을 완전히 다시 설계합니다.
  5. 지연을 피하도록 현재 디자인 계획을 유지하고 이후 앱 업데이트에서 보안 및 개인정보 보호 문제를 다루는 방안을 고려합니다.

정답: 보기-3: Michael과 더 논의하여 그가 가장 중요하게 생각하는 보안 및 개인정보 보호의 구체적인 측면을 이해하고 앱 디자인에 반영할 방법을 모색합니다.

문제 119 디자인 씽킹은 문제 해결에 대한 총체적인 접근을 장려합니다. 다음 상황을 살펴보세요.

당신은 전자 상거래 플랫폼의 쇼핑 경험을 개선하는 디자인 씽킹 팀의 일원입니다. 팀은 사용자 인터뷰를 진행하여 모바일 앱의 탐색 방식과 결제 절차 양쪽에서 문제를 발견했습니다. 사용자들은 두 영역의 복잡성에 불만을 표현했습니다.

디자인 과정에서 이 문제들을 효과적으로 해결하려면 팀은 어떻게 해야 합니까?

  1. 결제 절차는 별도 문제이므로 무시하고 모바일 앱의 탐색 방식 개선에만 집중합니다.
  2. 쇼핑 경험을 총체적으로 개선하도록 모바일 앱의 탐색 방식과 결제 절차를 동시에 수정합니다.
  3. 더 빠른 결과를 위해 탐색 방식과 결제 절차의 디자인 Sprint를 별도로 진행하여 각각의 문제를 독립적으로 해결합니다.
  4. 현재 프로젝트 일정 내에 해결하기에는 너무 복잡할 수 있으므로 결제 절차 관련 피드백을 무시합니다.
  5. 쇼핑 경험을 빠르게 개선하는 것이 중요하므로 탐색 관련 우려는 다루지 않고 새 결제 절차를 만듭니다.

정답: 보기-2: 쇼핑 경험을 총체적으로 개선하도록 모바일 앱의 탐색 방식과 결제 절차를 동시에 수정합니다.

문제 120 디자인 씽킹은 반복적인 프로토타입 제작과 테스트의 중요성을 강조합니다. 다음 상황을 살펴보세요.

당신은 혁신적인 스마트 홈 기기를 만드는 디자인 씽킹 팀의 일원입니다. 초기 프로토타입을 만든 후 여러 참가자와 사용자 테스트를 진행합니다. 피드백을 통해 사용자들이 기기의 인터페이스를 혼란스러워하며 필수 기능 일부가 빠져 있다는 사실을 알게 됩니다.

이 시점에서 팀이 취할 가장 적절한 조치는 무엇입니까?

  1. 사용자가 시간이 지나면 인터페이스에 적응할 것이라고 가정하고 피드백을 무시한 채 기존 프로토타입으로 진행합니다.
  2. 사용자 피드백을 바탕으로 기기 인터페이스를 수정하고 빠진 기능을 추가한 뒤 추가 테스트를 위한 새 프로토타입을 만듭니다.
  3. 추가 사용자를 대상으로 테스트를 계속하며 데이터를 더 수집하여 문제가 일관되게 나타나는지 개별 사례인지 확인합니다.
  4. 큰 변경 없이 단순화로 사용자의 우려를 해결할 수 있다고 가정하고 기기 인터페이스를 더 단순하게 만듭니다.
  5. 현재 프로토타입에 수정하기 어려울 만큼 문제가 많은 것 같으므로 스마트 홈 기기에 완전히 다른 디자인을 적용합니다.

정답: 보기-2: 사용자 피드백을 바탕으로 기기 인터페이스를 수정하고 빠진 기능을 추가한 뒤 추가 테스트를 위한 새 프로토타입을 만듭니다.



Design Thinking 자격증 >>



OKR(목표와 핵심 결과) 인증 시험 문제

문제 121 XYZ Corp의 제품 관리자 John은 팀에 OKR을 도입하려 합니다. “고객 만족도 개선”이라는 목표에 효과적인 핵심 결과를 정의하기가 어렵습니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 이번 분기에 제공하는 제품 기능 수를 늘립니다.
  2. 분기별 고객 만족도 설문조사를 실시하고 10점 만점에 평균 8점 이상을 달성합니다.
  3. 팀의 정시 납품률을 95%로 높입니다.
  4. 다음 분기에 제품 백로그 항목의 100%를 완료합니다.
  5. 매주 팀 회의를 열어 고객 피드백과 우려를 논의합니다.

정답: 보기-2: 분기별 고객 만족도 설문조사를 실시하고 10점 만점에 평균 8점 이상을 달성합니다.

문제 122 스타트업의 마케팅 책임자 Sara는 팀의 노력을 회사의 전략적 목표에 맞추기 위해 OKR을 도입하려 합니다. 목표 중 하나는 “브랜드 인지도 향상”입니다. 이 목표의 진척을 측정하기에 적절한 핵심 결과는 무엇입니까?

  1. 두 달 안에 회사의 새 로고를 만듭니다.
  2. 분기 내에 회사 공식 소셜 미디어 채널의 신규 팔로워 10,000명을 확보합니다.
  3. 협업을 강화하도록 마케팅 부서의 팀 단합 행사를 엽니다.
  4. 분기 동안 모든 마케팅 캠페인을 정해진 일정에 완료합니다.
  5. 회사 웹사이트를 시각적으로 더 매력적으로 재설계합니다.

정답: 보기-2: 분기 내에 회사 공식 소셜 미디어 채널의 신규 팔로워 10,000명을 확보합니다.

문제 123 소프트웨어 개발 회사의 팀장 Mark는 팀의 OKR을 설정하려 합니다. 목표 중 하나는 “코드 품질 향상”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. Sprint 기간 내에 배정된 모든 작업을 완료합니다.
  2. 분기 말까지 보고된 버그 수를 50% 줄입니다.
  3. 매일 스탠드업 회의를 열어 프로젝트 진행 상황과 어려움을 논의합니다.
  4. 품질과 관계없이 다음 Sprint 내에 모든 백로그 항목을 완료합니다.
  5. 분기 동안 두 주마다 새 제품 기능을 출시합니다.

정답: 보기-2: 분기 말까지 보고된 버그 수를 50% 줄입니다.

문제 124 기술 스타트업의 CEO Lucy는 회사 전체의 OKR을 설정하고자 합니다. 목표 중 하나는 “지속 가능한 성장 달성”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 다음 분기 내에 새 직원 20명을 채용합니다.
  2. 연말까지 월간 반복 매출(MRR)을 20% 늘립니다.
  3. 사기와 협업을 높이도록 전사 야유회를 엽니다.
  4. 더 많은 고객을 확보하도록 다음 주에 새 마케팅 캠페인을 시작합니다.
  5. 분기 내에 미처리 행정 업무를 모두 완료합니다.

정답: 보기-2: 연말까지 월간 반복 매출(MRR)을 20% 늘립니다.

문제 125 고객 지원 부서의 팀장 Sarah는 팀에 OKR을 도입하고 있습니다. 목표 중 하나는 “고객 만족도 개선”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 고객 불만의 100%를 접수 후 한 시간 내에 해결합니다.
  2. 다음 분기 내에 고객 문의 응답 시간을 50% 줄입니다.
  3. 사기와 팀워크를 높이도록 매주 팀 단합 활동을 진행합니다.
  4. 보고와 문서 작성을 포함한 모든 행정 업무를 주중에 완료합니다.
  5. 다음 달 안에 새 문의 티켓 관리 시스템을 도입합니다.

정답: 보기-2: 다음 분기 내에 고객 문의 응답 시간을 50% 줄입니다.

문제 126 제품 관리자 James는 개발 팀에 OKR을 도입하고 있습니다. 목표 중 하나는 “사용자 경험 향상”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 다음 분기 내에 새 제품 기능 세 가지를 출시합니다.
  2. 다음 달 안에 일일 사용자 상호작용 수를 10% 늘립니다.
  3. 팀 내 협업을 개선하도록 매주 팀 단합 모임을 진행합니다.
  4. 품질과 관계없이 다음 Sprint 내에 사용자 인터페이스 디자인 작업을 모두 완료합니다.
  5. 개선 의견을 수집하도록 두 주마다 사용자 피드백 모임을 진행합니다.

정답: 보기-5: 개선 의견을 수집하도록 두 주마다 사용자 피드백 모임을 진행합니다.

문제 127 마케팅 이사 Anna는 마케팅 팀의 OKR을 설정하고 있습니다. 목표 중 하나는 “브랜드 참여도 향상”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 분기 동안 모든 마케팅 캠페인을 정해진 일정에 완료합니다.
  2. 연말까지 소셜 미디어 팔로워 수를 10% 늘립니다.
  3. 협업과 사기를 높이도록 매달 외부 장소에서 팀 단합 행사를 엽니다.
  4. 분기 내에 두 주마다 새 제품 기능을 출시합니다.
  5. 브랜드 참여도를 개선할 피드백을 수집하도록 매주 고객 설문조사를 실시합니다.

정답: 보기-2: 연말까지 소셜 미디어 팔로워 수를 10% 늘립니다.

문제 128 개발 팀을 이끄는 David는 다음 분기의 OKR을 설정하고 있습니다. 목표 중 하나는 “제품 품질 향상”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 분기 내에 매달 제품의 새 버전을 출시합니다.
  2. 분기 말까지 고객이 보고하는 중대한 버그 수를 영으로 줄입니다.
  3. 매일 스탠드업 회의를 열어 프로젝트 진행 상황과 어려움을 논의합니다.
  4. 품질과 관계없이 Sprint 기간 내에 배정된 모든 작업을 완료합니다.
  5. 다음 달 안에 새 프로젝트 관리 도구를 도입합니다.

정답: 보기-2: 분기 말까지 고객이 보고하는 중대한 버그 수를 영으로 줄입니다.

문제 129 고객 지원 관리자 Catherine은 지원 팀에 OKR을 도입하고 있습니다. 목표 중 하나는 “응답 시간 개선”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 보고와 문서 작성을 포함한 모든 행정 업무를 주중에 완료합니다.
  2. 다음 분기 내에 고객 문의 평균 응답 시간을 30% 줄입니다.
  3. 협업과 팀 사기를 높이도록 매주 팀 단합 모임을 진행합니다.
  4. 고객 불만의 100%를 접수 후 한 시간 내에 해결합니다.
  5. 다음 달 안에 새 문의 티켓 관리 시스템을 도입합니다.

정답: 보기-2: 다음 분기 내에 고객 문의 평균 응답 시간을 30% 줄입니다.

문제 130 제품 관리자 Michael은 제품 개발 팀에 OKR을 도입하고 있습니다. 목표 중 하나는 “사용자 참여도 향상”입니다. 이 목표의 진척을 측정하기에 가장 적합한 핵심 결과는 무엇입니까?

  1. 품질과 관계없이 Sprint 기간 내에 모든 제품 개발 작업을 완료합니다.
  2. 연말까지 사용자가 제품을 이용하는 평균 시간을 20% 늘립니다.
  3. 협업과 팀 사기를 높이도록 매달 팀 단합 행사를 엽니다.
  4. 분기 내에 매달 제품의 새 버전을 출시합니다.
  5. 사용자 참여도를 개선할 피드백을 수집하도록 매주 사용자 설문조사를 실시합니다.

정답: 보기-2: 연말까지 사용자가 제품을 이용하는 평균 시간을 20% 늘립니다.



OKR 목표 및 핵심 결과 자격증 >>