프로그램 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의 세부 이해를 줍니다. 따라서 예제 시험·시뮬레이터를 활용하는 세심한 준비가 인증 성공에 필수입니다.
여러 시험 문제 연습은 다음을 더 잘 준비하게 한다는 보고가 있습니다.
사업의 건전성과 평판 지원,
사업 분야의 효과적 업무 촉진,
애자일 이해 강화와 Scrum Master 시험 준비 향상,
무엇보다 업계 자격을 손쉽게 높이기.
Scrum Guide 기반 강좌의 핵심 원칙·주제를 익히면 경력 전망을 높이고, 급변 시장에서 경쟁하려 애자일을 도입하는 기업에 귀중한 안내·지원을 제공할 수 있습니다.
일반 Scrum 시험 문제
문제 1 Scrum 관리 프레임워크로 어떤 소프트웨어 프로젝트를 수행할 수 있나요?
완전한 소프트웨어 패키지
고객 프로젝트
큰 시스템의 하위 시스템·구성 요소·일부
모든 유형의 소프트웨어 개발 프로젝트
해당 보기 없음
정답: 보기-4 / 모든 유형의 소프트웨어 개발 프로젝트
문제 2 애자일 선언의 기초가 아닌 것은?
과정·도구보다 개인·상호작용
포괄적 문서보다 작동하는 소프트웨어
사람보다 과정
계약 협상보다 고객 협업
계획 준수보다 변화 대응
정답: 보기-3 / 사람보다 과정
문제 3 Scrum 프레임워크가 정의하는 것은?
A) 규칙과 역할
B) 문서 지침
C) 산출물과 이벤트
A
B
C
A, B ,C
A, C
정답: 보기-5 / A, C
문제 4 고객 요구는 어디에 저장하나요?
Product Backlog에
Sprint Backlog에
데이터베이스에
Scrum 제품 요구 명세서에
어디에도 없음. Product Owner가 알고 있음
정답: 보기-1 / Product Backlog에
문제 5 다음 중 Scrum의 주요 역할은?
A) Scrum 테스터
B) Scrum 팀
C) Scrum 관리자
D) Scrum Master
E) Scrum Product Owner
A, B, C, D, E
B, C, D, E
B, D, E
A, B, D, E
A, B, C, D
정답: 보기-3 / B, D, E
문제 6 다음 중 Scrum의 주요 이벤트는?
A) Sprint 계획 회의
B) Sprint 회고
C) Sprint 검토 회의
D) Sprint 중간 현황 검토 회의
E) 일일 Scrum 회의
A, B, C, D, E
A, B, C, D
A, C, D, E
A, B, C, E
A, C, E
정답: 보기-4 / A, B, C, E
문제 7 프레임워크에 정의되지 않은 개념은?
Scrum Master
프로젝트 관리자
Scrum Product Owner
일일 Scrum
Scrum 제품 번다운
정답: 보기-2 / 프로젝트 매니저
문제 8 모든 Scrum 프로젝트에서 중요한 것은?
A) 자기 조직화
B) 명확한 기업 위계
C) 의사소통
D) 지속적 개선
A, B, C, D
A, C, D
A, D
A
A, B
정답: 보기-2 / A, C, D
문제 9 전통적 폭포수 모델의 단점은?
A) 최종 제품을 모두 미리 예상해야 함.
B) 초기에 정한 대로 구현해도 실제 고객에게 필요 없는 요구가 있음.
C) 각 단계가 엄격히 분리됨.
문제 101 Jill은 소프트웨어 개발 팀의 Scrum Developer입니다. 현재 Sprint에서 팀은 외부 시스템과의 통합이 필요한 복잡한 기능을 개발하고 있습니다. 통합을 돕는 특정 라이브러리가 필요하다는 사실을 알게 됩니다. Jill은 사용 경험이 있는 인기 오픈 소스 라이브러리를 제안하지만, 동료 Mark는 회사가 라이선스를 보유한 독점 라이브러리를 선호합니다.
이 상황에서 Jill은 어떻게 해야 합니까?
이미 사용할 수 있으므로 Mark의 선호에 따라 독점 라이브러리를 사용합니다.
시간을 절약하고 비용 효율적일 수 있으므로 자신에게 익숙한 오픈 소스 라이브러리의 사용을 고집합니다.
각 라이브러리의 장단점을 팀과 논의하고 프로젝트의 필요에 따라 공동으로 결정합니다.
Product Owner에게 문제를 전달하고 교착 상태를 해결할 최종 결정을 요청합니다.
팀 내 갈등을 피하도록 당장은 라이브러리 문제를 무시하고 다른 작업에 집중합니다.
정답: 보기-3 / 각 라이브러리의 장단점을 팀과 논의하고 프로젝트의 필요에 따라 공동으로 결정합니다.
문제 102 Scrum 팀은 모바일 애플리케이션 개발 프로젝트를 진행하고 있습니다. Sprint 계획 회의에서 Product Owner인 Brian은 다음 릴리스에 매우 중요하다고 생각하는 새 기능을 제시합니다. 팀은 이 기능이 Sprint에서 사용 가능한 역량 대부분을 차지할 것으로 추정합니다.
하지만 Scrum Developer인 Sarah는 Sprint 내에 이 기능을 구현하는 데 따르는 기술적 복잡성과 위험을 우려합니다. 릴리스가 지연되고 제품의 전반적인 품질에 영향을 줄 수 있다고 생각합니다.
이 상황에서 Sarah는 어떻게 해야 합니까?
Product Owner의 요청에 따라 즉시 기능을 수락하고 제공을 약속합니다.
팀에 우려를 표현하고 이후 Sprint에서 처리할 수 있도록 기능을 더 작고 관리 가능한 부분으로 나누자고 제안합니다.
Product Owner에게 Sprint 내 구현이 기술적으로 불가능하므로 해당 기능을 범위에서 제외해야 한다고 알립니다.
요청대로 기능을 개발하되 팀이나 Product Owner에게 알리지 않고 다음 Sprint까지 미룰 계획을 몰래 세웁니다.
팀을 참여시키지 않고 Scrum Master가 Product Owner와 협상하여 문제를 해결하도록 설득합니다.
정답: 보기-2 / 팀에 우려를 표현하고 이후 Sprint에서 처리할 수 있도록 기능을 더 작고 관리 가능한 부분으로 나누자고 제안합니다.
문제 103 Scrum 팀은 전자 상거래 웹사이트의 웹 개발 프로젝트를 진행하고 있습니다. Sprint 리뷰에서 이해관계자들은 새 기능이 제공된 디자인 명세와 일치하지 않는다는 점을 발견합니다. 이들은 실망하며 프로젝트 지연을 우려합니다.
Scrum Developer로서 이 상황에 어떻게 대응해야 합니까?
디자인 명세가 항상 실용적인 것은 아니며 개발 과정에서 조정이 필요할 수 있다고 설명하며 팀을 옹호합니다.
문제를 인정하고 팀과 상의하지 않은 채 다음 Sprint에서 디자인의 차이를 수정하겠다고 제안합니다.
이해관계자들과 회의를 잡아 우려를 이해하고 팀과 함께 디자인 문제를 해결할 계획을 세웁니다.
명확하고 정확한 명세를 제공하지 않은 디자인 팀을 비난하며 개발 팀의 책임을 돌립니다.
디자인 명세는 충분하며 이해관계자의 기대가 비현실적이라고 생각하여 피드백을 무시합니다.
정답: 보기-3 / 이해관계자들과 회의를 잡아 우려를 이해하고 팀과 함께 디자인 문제를 해결할 계획을 세웁니다.
문제 104 Scrum 팀은 마감이 촉박한 프로젝트를 진행하며, Product Owner인 Lisa는 사용자 스토리를 마지막 순간에 자주 변경해 달라고 요구합니다. 이 변경으로 팀의 업무 흐름이 방해받아 원래 Sprint 계획을 따라가기 어려워지고 있습니다.
Scrum Developer로서 Lisa의 잦은 사용자 스토리 변경을 어떻게 처리해야 합니까?
Sprint 목표를 놓치더라도 Lisa의 모든 변경을 이의 없이 수용합니다.
Lisa의 요청과 관계없이 변경을 모두 거부하고 원래 사용자 스토리를 고수합니다.
Lisa와 회의를 잡아 변경이 팀의 Sprint 목표 달성 능력에 미치는 영향을 논의하고 절충안을 제안합니다.
개발 팀이 방해받지 않고 업무에 집중하도록 Scrum Master에게 알리고 Lisa의 요청을 처리하게 합니다.
팀 내 갈등을 피하도록 팀이나 Scrum Master에게 알리지 않고 Lisa의 변경을 몰래 작업합니다.
정답: 보기-3 / Lisa와 회의를 잡아 변경이 팀의 Sprint 목표 달성 능력에 미치는 영향을 논의하고 절충안을 제안합니다.
문제 105 Scrum 팀은 새 모바일 앱 개발 프로젝트를 진행하고 있습니다. Sprint 계획 회의에서 Product Owner인 Robert는 요구사항과 인수 기준이 모호한 사용자 스토리를 제공합니다. 그는 개발을 진행해야 하며 세부 사항은 나중에 정하면 된다고 주장합니다.
Scrum Developer로서 이 상황을 어떻게 처리해야 합니까?
Sprint 중에 세부 사항이 명확해질 것이라 믿고 Product Owner의 지시대로 개발을 시작합니다.
명확한 요구사항과 인수 기준 없이는 개발을 시작하지 않겠다고 하며 작업 시작 전 정의의 중요성을 강조합니다.
팀 회의를 열어 Product Owner와 문제를 논의하고 개발 시작 전에 요구사항을 명확히 해야 한다고 주장합니다.
개발을 시작하되 Scrum Master에게 불명확한 점을 알리고 문제는 나중에 해결하도록 둡니다.
Product Owner나 팀과 상의하지 않고 가정을 세워 사용자 스토리를 적극적으로 작업하고 빠르게 완료합니다.
정답: 보기-3 / 팀 회의를 열어 Product Owner와 문제를 논의하고 개발 시작 전에 요구사항을 명확히 해야 한다고 주장합니다.
문제 106 Scrum 팀은 새 소프트웨어 제품을 개발하고 있습니다. Sprint 계획 회의에서 Product Owner인 Emma는 즉시 해결해야 하는 중대한 버그 수정을 제시합니다. 이 버그는 운영 환경에 영향을 주며 고객 만족도에 미치는 영향이 큽니다.
Scrum Developer로서 이 상황에 어떻게 대응해야 합니까?
예측 가능성을 유지하도록 Sprint 백로그를 따르며 버그 수정을 다음 Sprint로 미루고 계획된 작업을 계속합니다.
고객 만족도에 미치는 영향이 크므로 버그 수정을 수락하고 즉시 작업하여 문제를 해결합니다.
Scrum Master에게 문제를 전달하고 버그 수정을 우선해야 할지 결정하도록 합니다.
원래 Sprint는 계획대로 진행하면서 버그를 해결할 별도의 긴급 Sprint를 만들자고 제안합니다.
Sprint 도중 Scrum 팀의 작업을 방해해서는 안 된다고 생각하여 버그 수정 요청을 무시합니다.
정답: 보기-2 / 고객 만족도에 미치는 영향이 크므로 버그 수정을 수락하고 즉시 작업하여 문제를 해결합니다.
문제 107 Scrum 팀은 프로젝트를 진행하며 개발 팀원들은 팀 개발 프로세스의 개선 가능성을 발견했습니다. 이러한 개선으로 효율성과 제품 품질이 높아질 수 있지만 구현에는 시간과 노력이 필요합니다.
Scrum Developer로서 이 상황에 어떻게 접근해야 합니까?
개선 아이디어를 팀과 공유하되 Scrum 원칙상 Sprint 도중 변경은 허용되지 않는다고 강조합니다.
팀의 성공에 꼭 필요한 개선이므로 현재 Sprint를 방해하더라도 즉시 변경을 적용합니다.
개선 아이디어를 다음 Sprint를 위해 기록하고 다음 Sprint 회고에서 팀과 논의합니다.
변경은 불필요한 복잡성을 초래할 수 있으므로 개선 아이디어를 무시하고 현재 프로세스를 계속 따릅니다.
개발 팀을 참여시키지 않고 Scrum Master가 이러한 개선의 구현을 처리하도록 제안합니다.
정답: 보기-3 / 개선 아이디어를 다음 Sprint를 위해 기록하고 다음 Sprint 회고에서 팀과 논의합니다.
문제 108 Scrum 팀은 기존 소프트웨어 제품에 복잡한 기능을 추가하는 프로젝트를 진행하고 있습니다. Sprint 도중 정해진 기간 안에 모든 사용자 스토리를 완료하지 못할 수 있다는 점이 분명해집니다. 팀은 Sprint 목표에 미칠 영향을 우려합니다.
Scrum Developer로서 이 상황에서 어떤 조치를 취해야 합니까?
원래 약속을 지키기 위해 Sprint 기간을 넘기더라도 모든 사용자 스토리 작업을 계속합니다.
Product Owner와 문제를 논의하고 팀이 Sprint 목표를 달성하도록 일부 사용자 스토리를 제외하는 방안을 협상합니다.
Scrum Master와 Product Owner에게 예상 문제를 알리고 진행 방법에 대한 지침을 기다립니다.
팀이나 Product Owner와 상의하지 않고 Sprint 내 모든 사용자 스토리를 완료하기 위해 초과 근무하기로 결정합니다.
팀 내 갈등을 피하도록 문제를 무시하고 각 팀원이 대처 방법을 개별적으로 결정하게 합니다.
정답: 보기-3 / Scrum Master와 Product Owner에게 예상 문제를 알리고 진행 방법에 대한 지침을 기다립니다.
문제 109 Scrum 팀은 타사 서비스와의 통합이 필요한 프로젝트를 진행하고 있습니다. 여러 기술적 문제와 지연으로 통합 과정에 어려움이 있습니다. Scrum Master는 통합을 성공적으로 완료하도록 현재 Sprint를 연장하자고 제안합니다.
Scrum Developer로서 이 제안에 어떻게 대응해야 합니까?
팀의 계획에 차질이 생기더라도 Sprint를 연장하여 통합을 성공시키자는 Scrum Master의 제안에 동의합니다.
팀은 원래 Sprint 기간 내에 계획한 작업을 완료해야 한다고 주장하며 Sprint 연장 제안을 거절합니다.
Scrum Master 및 팀과 회의를 잡아 통합의 어려움을 논의하고 Sprint 연장의 실행 가능성을 평가합니다.
팀이 과로하게 되더라도 통합을 성공시키기 위해 팀이나 Scrum Master와 상의하지 않고 Sprint를 연장합니다.
팀 내 갈등을 피하도록 통합 문제를 무시하고 원래 Sprint 계획을 따릅니다.
정답: 보기-3 / Scrum Master 및 팀과 회의를 잡아 통합의 어려움을 논의하고 Sprint 연장의 실행 가능성을 평가합니다.
문제 110 Scrum 팀은 기존 제품의 새 기능을 개발하는 프로젝트를 진행하고 있습니다. Sprint 도중 Product Owner인 David는 이해관계자에게서 새 정보를 받습니다. 이 정보로 인해 Sprint 백로그의 사용자 스토리 하나를 크게 변경해야 합니다. 이 변경은 팀의 Sprint 목표 달성 능력에 영향을 줄 가능성이 큽니다.
Scrum Developer로서 이 상황을 어떻게 처리해야 합니까?
이해관계자의 요청을 충족하기 위해 Sprint 목표를 놓치더라도 변경을 즉시 수용합니다.
Sprint에 차질을 주므로 이후 Sprint에서 다뤄야 한다고 주장하며 사용자 스토리의 변경을 모두 거부합니다.
제안된 변경을 팀과 논의하고 Sprint에 미치는 영향을 분석하며 최선의 행동 방침을 함께 결정합니다.
이해관계자의 요청을 빠르게 충족하는 데 필요하다고 생각하여 팀에 알리지 않고 변경을 구현합니다.
팀이 Sprint에 집중하도록 팀을 참여시키지 않고 Scrum Master가 변경 요청을 처리하자고 제안합니다.
정답: 보기-3 / 제안된 변경을 팀과 논의하고 Sprint에 미치는 영향을 분석하며 최선의 행동 방침을 함께 결정합니다.
문제 111 디자인 씽킹은 공감, 창의성, 반복적인 과정을 포함하는 인간 중심의 문제 해결 접근법입니다. 다음 상황을 살펴보세요.
당신은 모바일 뱅킹 앱의 사용자 경험을 개선하는 프로젝트에서 팀과 함께 일하는 Design Thinking Professional입니다. 공감 단계에서 팀은 여러 사용자를 인터뷰합니다. 그중 Sarah는 앱의 탐색 방식과 불명확한 거래 내역에 대한 불만을 표현합니다. 이러한 인터뷰에서 유용한 통찰을 얻습니다.
디자인 씽킹 과정에서 다음으로 어떤 조치를 취해야 합니까?
앱의 탐색 방식과 거래 내역을 개선할 아이디어를 도출하는 브레인스토밍을 진행합니다.
사용자 인터뷰에서 얻은 통찰을 바탕으로 개선된 앱의 프로토타입을 만듭니다.
사용자 인터뷰의 결과를 이해관계자 및 개발 팀과 공유하는 발표를 준비합니다.
아이디어 도출 단계로 넘어가기 전에 사용자 인터뷰를 더 진행하여 추가 데이터를 수집합니다.
다기능 팀을 구성하여 사용자 피드백에 따른 앱 변경을 즉시 구현하기 시작합니다.
정답: 보기-1: 앱의 탐색 방식과 거래 내역을 개선할 아이디어를 도출하는 브레인스토밍을 진행합니다.
문제 112 디자인 씽킹의 핵심 원칙 중 하나는 “프로토타입 제작과 테스트”입니다. 다음 상황을 살펴보세요.
팀은 새로운 친환경 물병을 디자인하는 프로젝트를 진행하고 있습니다. 사용자 인터뷰 후 여러 디자인 아이디어가 나왔습니다. 팀은 아이디어를 테스트하기 위해 프로토타입을 만들기로 합니다. 테스트 중 사용자가 물병을 쉽게 열고 확실히 닫는 데 어려움을 겪는다는 사실을 발견합니다.
프로토타입 제작과 테스트 단계에서 이 문제를 해결하려면 팀은 어떻게 해야 합니까?
나중에 해결할 수 있는 사소한 문제이므로 무시하고 기존 프로토타입으로 진행합니다.
테스트를 중단하고 물병 뚜껑 구조를 다시 설계하여 문제를 해결할 새 프로토타입을 만듭니다.
문제가 중대한지 일회성인지 확인하기 위해 테스트를 계속하고 데이터를 더 수집합니다.
현재 디자인에 문제가 너무 많은 것 같으므로 완전히 다른 디자인 아이디어로 전환합니다.
사용자에게 문제를 공유하고 해결책을 제안해 달라고 한 뒤 그 아이디어를 즉시 구현합니다.
정답: 보기-2: 테스트를 중단하고 물병 뚜껑 구조를 다시 설계하여 문제를 해결할 새 프로토타입을 만듭니다.
문제 113 디자인 씽킹에는 다양한 분야의 구성원으로 이루어진 다기능 팀이 참여하는 경우가 많습니다. 다음 상황을 상상해 보세요.
당신은 소매 회사의 온라인 쇼핑 경험을 개선하는 디자인 씽킹 팀을 이끌고 있습니다. 팀에는 디자이너, 개발자, 마케팅 담당자, 고객 서비스 담당자가 있습니다. 아이디어 도출 단계에서 제안된 기능의 구현 가능성을 놓고 디자이너와 개발자 사이에 갈등이 생깁니다.
Design Thinking Professional로서 이 갈등을 효과적으로 해결하려면 어떻게 해야 합니까?
디자이너가 사용자 경험을 책임지므로 그들의 아이디어를 우선해야 한다며 디자이너 편을 듭니다.
디자이너와 개발자가 서로 다른 해결책을 독립적으로 작업하도록 팀을 별도의 그룹으로 나눕니다.
디자이너와 개발자의 협력적인 논의를 촉진하여 절충안을 모색하고 사용자 경험과 기술적 실현 가능성의 균형을 맞추는 해결책을 찾습니다.
추가 갈등을 피하도록 디자이너와 개발자 모두에게서 의사결정 권한을 회수하고 직접 최종 결정을 내립니다.
사용자 만족에 필수적이므로 원래 디자인을 유지하고 개발자가 구현 방법을 알아내게 합니다.
정답: 보기-3: 디자이너와 개발자의 협력적인 논의를 촉진하여 절충안을 모색하고 사용자 경험과 기술적 실현 가능성의 균형을 맞추는 해결책을 찾습니다.
문제 114 디자인 씽킹은 사용자 요구와 감정을 이해하는 것이 중요한 “공감” 단계에서 시작하는 경우가 많습니다. 다음 상황을 살펴보세요.
당신은 모바일 뱅킹 앱의 초기 이용 경험을 개선하는 디자인 씽킹 팀의 일원입니다. 사용자 인터뷰에서 John이라는 사용자는 앱의 가입 절차와 명확한 안내의 부족에 대한 불만을 표현합니다.
“공감” 단계에서 John의 우려를 효과적으로 해결하려면 팀은 어떻게 해야 합니까?
다른 사용자들은 가입 절차에 문제가 없다고 가정하고 John의 피드백을 개인적인 사례로 여겨 무시합니다.
재설계에 시간이 많이 걸릴 수 있으므로 John의 피드백을 기록한 뒤 기존 초기 이용 절차를 유지합니다.
John과 더 깊이 대화하여 가입 절차에서 겪는 불만과 불편 사항을 자세히 파악합니다.
John의 우려를 해결하는 것이 매우 중요하므로 피드백을 바탕으로 전체 초기 이용 절차를 즉시 다시 설계합니다.
계획된 초기 이용 개선을 계속하고 이후 앱의 반복 개발에서 John의 우려를 다루는 방안을 고려합니다.
정답: 보기-3: John과 더 깊이 대화하여 가입 절차에서 겪는 불만과 불편 사항을 자세히 파악합니다.
문제 115 디자인 씽킹은 공감과 사용자 요구 이해의 중요성을 강조합니다. 다음 상황을 살펴보세요.
당신은 소매 회사의 쇼핑 경험을 개선하는 디자인 씽킹 팀을 이끌고 있습니다. 사용자 인터뷰에서 Lisa는 더 지속 가능한 쇼핑 경험을 원한다고 말합니다. 그녀는 친환경 포장과 제품 조달의 중요성을 강조합니다.
Lisa의 우려를 다루고 디자인 과정에 지속 가능성을 반영하려면 팀은 어떻게 해야 합니까?
대부분의 쇼핑객에게 지속 가능성은 큰 관심사가 아니며 비용이 증가할 수 있으므로 Lisa의 피드백을 무시합니다.
지속 가능성을 부차적으로 고려하되 디자인 과정에서 편의성과 가격 접근성 등의 다른 요인을 우선합니다.
Lisa와 더 논의하여 그녀가 가장 중요하게 생각하는 지속 가능성의 구체적인 측면을 이해하고 쇼핑 경험에 반영할 방법을 모색합니다.
쇼핑객의 편의성과 가격 접근성을 희생하더라도 지속 가능성을 우선하도록 쇼핑 경험 전체를 개편합니다.
현재 일정과 목표에 차질을 줄 수 있으므로 기존 디자인 계획을 유지하고 지속 가능성 문제는 별도 프로젝트에서 다룹니다.
정답: 보기-3: Lisa와 더 논의하여 그녀가 가장 중요하게 생각하는 지속 가능성의 구체적인 측면을 이해하고 쇼핑 경험에 반영할 방법을 모색합니다.
문제 116 디자인 씽킹은 반복적인 프로토타입 제작과 테스트를 장려합니다. 다음 상황을 상상해 보세요.
당신은 비영리 단체의 새 디지털 플랫폼을 설계하는 디자인 씽킹 팀의 일원입니다. 초기 프로토타입을 만든 후 여러 참가자와 사용자 테스트를 진행합니다. 피드백을 통해 일부 사용자가 플랫폼의 탐색 방식을 혼란스러워한다는 사실을 알게 됩니다.
이 시점에서 팀이 취할 가장 적절한 조치는 무엇입니까?
피드백을 개인적인 선호의 결과로 여겨 무시하고 기존 탐색 디자인을 유지합니다.
피드백을 바탕으로 탐색 방식을 수정하고 추가 사용자 테스트를 위한 새 프로토타입을 만듭니다.
탐색 방식을 변경하기 전에 더 다양한 의견을 수집하도록 추가 사용자를 대상으로 테스트를 계속합니다.
탐색 디자인에 대한 팀원들의 의견을 토대로 최선의 행동 방침을 정하도록 전체 팀원을 대상으로 설문조사를 합니다.
혼란스럽다고 느낀 사용자의 우려를 해결하기 위해 완전히 다른 탐색 디자인을 적용합니다.
정답: 보기-2: 피드백을 바탕으로 탐색 방식을 수정하고 추가 사용자 테스트를 위한 새 프로토타입을 만듭니다.
문제 117 디자인 씽킹에는 협업과 여러 분야가 참여하는 팀이 필요한 경우가 많습니다. 다음 상황을 살펴보세요.
당신은 대도시의 대중교통 체계를 재설계하는 디자인 씽킹 팀을 이끌고 있습니다. 팀에는 도시 계획가, 소프트웨어 개발자, 교통 전문가가 있습니다. 아이디어 도출 단계에서 효율성, 지속 가능성, 사용자 경험 등 우선순위가 서로 다른 팀원 간에 갈등이 생깁니다.
Design Thinking Professional로서 이 갈등을 효과적으로 관리하려면 어떻게 해야 합니까?
도시 설계 전문성을 다른 고려 사항보다 우선해야 한다며 도시 계획가 편을 듭니다.
프로젝트의 각 측면에 최선의 해결책이 나올 수 있으므로 각 팀원이 협업 없이 자신의 우선순위를 독립적으로 추구하도록 합니다.
팀 내 협력적인 논의를 촉진하여 다양한 우선순위의 균형을 맞추고 효율성, 지속 가능성, 사용자 경험 사이의 절충을 고려하는 해결책을 찾습니다.
갈등을 빠르게 해결하고 프로젝트가 순조롭게 진행되도록 프로젝트의 통제권을 가져와 직접 최종 결정을 내립니다.
교통 체계가 단절되더라도 효율성, 지속 가능성, 사용자 경험을 위한 별도의 해결책을 구현합니다.
정답: 보기-3: 팀 내 협력적인 논의를 촉진하여 다양한 우선순위의 균형을 맞추고 효율성, 지속 가능성, 사용자 경험 사이의 절충을 고려하는 해결책을 찾습니다.
문제 118 디자인 씽킹은 사용자에 대한 공감에서 시작하는 경우가 많습니다. 다음 상황을 살펴보세요.
당신은 의료 서비스 제공자를 위한 모바일 앱을 개선하는 팀을 이끄는 Design Thinking Professional입니다. 사용자 인터뷰에서 의료 전문가 Michael은 앱의 보안과 개인정보 보호 기능을 우려하며, 이러한 문제가 앱 사용의 큰 장벽이라고 강조합니다.
디자인 과정의 초기 단계에서 Michael의 우려를 효과적으로 해결하려면 팀은 어떻게 해야 합니까?
대부분의 의료 전문가에게 보안과 개인정보 보호는 최우선 사항이 아니라고 가정하고 Michael의 피드백을 무시합니다.
보안과 개인정보 보호 문제를 해결하는 데 시간이 너무 많이 걸릴 수 있으므로 Michael의 피드백을 기록하되 기존 디자인 계획을 유지합니다.
Michael과 더 논의하여 그가 가장 중요하게 생각하는 보안 및 개인정보 보호의 구체적인 측면을 이해하고 앱 디자인에 반영할 방법을 모색합니다.
원래 디자인이 크게 달라지더라도 Michael의 피드백에 따라 앱의 보안 및 개인정보 보호 기능을 완전히 다시 설계합니다.
지연을 피하도록 현재 디자인 계획을 유지하고 이후 앱 업데이트에서 보안 및 개인정보 보호 문제를 다루는 방안을 고려합니다.
정답: 보기-3: Michael과 더 논의하여 그가 가장 중요하게 생각하는 보안 및 개인정보 보호의 구체적인 측면을 이해하고 앱 디자인에 반영할 방법을 모색합니다.
문제 119 디자인 씽킹은 문제 해결에 대한 총체적인 접근을 장려합니다. 다음 상황을 살펴보세요.
당신은 전자 상거래 플랫폼의 쇼핑 경험을 개선하는 디자인 씽킹 팀의 일원입니다. 팀은 사용자 인터뷰를 진행하여 모바일 앱의 탐색 방식과 결제 절차 양쪽에서 문제를 발견했습니다. 사용자들은 두 영역의 복잡성에 불만을 표현했습니다.
디자인 과정에서 이 문제들을 효과적으로 해결하려면 팀은 어떻게 해야 합니까?
결제 절차는 별도 문제이므로 무시하고 모바일 앱의 탐색 방식 개선에만 집중합니다.
쇼핑 경험을 총체적으로 개선하도록 모바일 앱의 탐색 방식과 결제 절차를 동시에 수정합니다.
더 빠른 결과를 위해 탐색 방식과 결제 절차의 디자인 Sprint를 별도로 진행하여 각각의 문제를 독립적으로 해결합니다.
현재 프로젝트 일정 내에 해결하기에는 너무 복잡할 수 있으므로 결제 절차 관련 피드백을 무시합니다.
쇼핑 경험을 빠르게 개선하는 것이 중요하므로 탐색 관련 우려는 다루지 않고 새 결제 절차를 만듭니다.
정답: 보기-2: 쇼핑 경험을 총체적으로 개선하도록 모바일 앱의 탐색 방식과 결제 절차를 동시에 수정합니다.
문제 120 디자인 씽킹은 반복적인 프로토타입 제작과 테스트의 중요성을 강조합니다. 다음 상황을 살펴보세요.
당신은 혁신적인 스마트 홈 기기를 만드는 디자인 씽킹 팀의 일원입니다. 초기 프로토타입을 만든 후 여러 참가자와 사용자 테스트를 진행합니다. 피드백을 통해 사용자들이 기기의 인터페이스를 혼란스러워하며 필수 기능 일부가 빠져 있다는 사실을 알게 됩니다.
이 시점에서 팀이 취할 가장 적절한 조치는 무엇입니까?
사용자가 시간이 지나면 인터페이스에 적응할 것이라고 가정하고 피드백을 무시한 채 기존 프로토타입으로 진행합니다.
사용자 피드백을 바탕으로 기기 인터페이스를 수정하고 빠진 기능을 추가한 뒤 추가 테스트를 위한 새 프로토타입을 만듭니다.
추가 사용자를 대상으로 테스트를 계속하며 데이터를 더 수집하여 문제가 일관되게 나타나는지 개별 사례인지 확인합니다.
큰 변경 없이 단순화로 사용자의 우려를 해결할 수 있다고 가정하고 기기 인터페이스를 더 단순하게 만듭니다.
현재 프로토타입에 수정하기 어려울 만큼 문제가 많은 것 같으므로 스마트 홈 기기에 완전히 다른 디자인을 적용합니다.
정답: 보기-2: 사용자 피드백을 바탕으로 기기 인터페이스를 수정하고 빠진 기능을 추가한 뒤 추가 테스트를 위한 새 프로토타입을 만듭니다.