1. 방금 스크럼을 처음 도입하는 회사에 채용되었습니다. 경영진이 당신을 6개의 새로운 스크럼 팀의 스크럼 마스터로 배정했습니다. 이 팀들은 하나의 제품을 만들 예정입니다. 이 시나리오에서 당신이 추구해야 할 두 가지 조건을 선택하세요. (두 개 선택)
- 각 스크럼 팀마다 하나씩, 6명의 제품 책임자가 있어야 한다.
- 수석 제품 책임자에게 보고하는 6명의 제품 책임자가 있어야 한다.
- 제품은 하나의 제품 백로그를 가진다.
- 각 스크럼 팀은 별도의 제품 백로그를 가져야 한다.
- 오직 한 명의 제품 책임자만 있어야 한다.
2. 스크럼 팀이 9번의 스프린트 동안 제품을 작업해왔습니다. 새로운 제품 책임자가 들어와서 자신이 제품 백로그에 대한 책임이 있다는 것을 이해하고 있습니다. 하지만 그는 자신의 책임에 대해 확실하지 않습니다. 스크럼에 따르면 제품 책임자 역할의 일부인 두 가지 활동은 무엇입니까? (두 개 선택)
- 가장 가치 있는 기능이 항상 먼저 생산되도록 보장하기.
- 이해관계자와 상호작용하기.
- 스크럼 팀에게 상세한 명세서 제공하기.
- 기능을 유즈 케이스로 설명하기.
- 상세한 기능 테스트 케이스 작성하기.
3. 사용자 문서가 완료의 정의(Definition of Done)의 일부입니다. 그러나 모든 팀을 위한 기술 문서 작성자가 충분하지 않습니다. 당신의 개발자들에게는 기술 문서 작성자가 없습니다. 무엇을 해야 합니까?
- 다양한 제품 책임자들을 위해 요청에 따라 작업할 별도의 기술 문서 작성자 팀을 구성한다. 작업 순서는 선착순이다.
- 사용자 문서를 완료하지 않은 채로 두고 마지막 개발 스프린트 후까지 누적시킨다. 그 후 사용 가능한 기술 문서 작성자가 작성할 것이다.
- 스크럼 팀에 기술 문서 작성자가 올 때까지 기다린다.
- 당신의 스크럼 팀은 여전히 사용자 문서 작성에 책임이 있다. 이 경우, 스크럼 팀 구성원들이 작성할 것이다.
4. 당신은 동일한 제품 백로그에서 작업하는 4개의 스크럼 팀의 스크럼 마스터입니다. 여러 개발자들이 다가오는 2개의 스프린트에서 확인된 작업이 팀 외부의 기술 전문가의 전담 투입을 요구할 것이라고 불평하며 당신을 찾아왔습니다. 이 상황에서 스크럼 마스터가 고려해야 할 두 가지 주요 관심사는 무엇입니까? (두 개 선택)
- 안정적인 속도를 유지하려는 욕구.
- 개발자들이 스스로 해결책을 찾아내는 것의 이점.
- 모든 개발자들을 바쁘게 유지하기에 충분한 작업이 필요함.
- 개발자들이 통합된 증분을 생산할 수 있는 능력.
- 가장 가치 있는 항목을 맨 위에 배치하는 제품 책임자.
- 위험도, 더 안전한 항목이 위에 있고 더 위험한 항목이 아래에 있음.
- 항목들이 무작위로 배열됨.
- 크기, 작은 항목이 위에 있고 큰 항목이 아래에 있음.
- 스프린트가 연장되고 향후 스프린트는 이 새로운 기간을 사용한다.
- 스프린트 길이는 유지되고 스크럼 팀은 이 길이의 스프린트 내에서 실제로 무엇을 할 수 있는지 지속적으로 학습한다.
- 스프린트는 일시적으로 연장된다. 다시는 발생하지 않도록 교훈을 얻는다.
- 스크럼 프로세스와 스프린트 동안 어떻게 사용되었는지.
- 코딩 및 엔지니어링 관행.
- 스프린트 결과.
- 위의 모든 것.
- 완료의 정의에 보안을 추가한다.
- 문제가 해결될 때까지 제품 책임자에게 기능의 추가 개발을 중단하라고 말한다.
- 보안을 위한 제품 백로그 항목을 생성한다.
- 테스터들에게 확인하러 간다.
- 그 사람에게 가능한 한 빨리 팀과 문제를 공유하도록 요청한다.
- 스크럼 팀에는 개발자뿐만 아니라 비즈니스 분석가, 아키텍트, 테스터도 포함된다.
- 스크럼 팀에는 소프트웨어 증분을 제공하는 데 필요한 작업을 수행할 수 있는 교차 숙련된 개인들이 포함된다.
- 스크럼 팀의 개발자들은 팀에 속하지 않은 비즈니스 분석가, 아키텍트, 개발자 및 테스터와 긴밀히 협력한다.
- 스크럼 팀은 비즈니스 분석가, 아키텍트, 개발자 및 테스터의 별도 팀에서 끌어온 가상 팀이다.
- 스프린트에 대해 남은 총 작업의 추정치.
- 스프린트에 얼마나 많은 노력이 들어갔는지.
- 각 스크럼 팀 구성원이 얼마나 많은 시간을 작업했는지.
- 얼마나 많은 제품 백로그 항목이 남아있는지.
- 분석, 설계, 프로그래밍, 테스팅 및 문서화에 비례적인 시간.
- 스프린트에 맞출 수 있는 만큼. 남은 작업은 후속 스프린트로 이전된다.
- 모든 개발 작업과 적어도 일부 테스팅.
- 완료의 정의에 따라 선택한 모든 제품 백로그 항목에 대해 제품 책임자에게 말한 만큼.
- 스프린트에서 수행할 모든 작업의 완전한 목록이다.
- 모든 항목에는 지정된 소유자가 있다.
- 각 작업은 시간 단위로 추정된다.
- 스프린트에 대한 스크럼 팀의 계획이다.
- 제품 책임자에 의해 정렬된다.
- 프로젝트에 지출된 비용의 변화.
- 스크럼 팀이 다른 작업을 위해 해제될 수 있도록 모든 작업이 완료되는 시점.
- 제품 백로그나 개발자들에 변화가 없다면 남은 작업이 완료될 가능성이 있는 시점.
- 제품 책임자가 추가되는 새 작업과 동일한 노력의 작업을 제거하면 프로젝트가 끝날 시점.
- 비즈니스 분석가.
- 개발자들.
- 팀 관리자.
- 프로젝트 관리자.
- 제품 책임자.
15. 스프린트 끝에 스프린트 동안 작업한 제품 백로그 항목이 완료의 정의를 충족하지 못합니다. 완료되지 않은 제품 백로그 항목에 대해 어떤 두 가지 일이 발생해야 합니까? (가장 좋은 두 가지 답변 선택)
- 이해관계자가 동의하면 제품 책임자가 이를 수락하고 사용자에게 릴리스할 수 있다.
- 제품 책임자가 그것으로 무엇을 할지 결정하도록 제품 백로그에 다시 넣는다.
- 항목을 검토하고, 완료된 부분의 추정치를 속도에 추가하고 남은 작업에 대한 스토리를 생성한다.
- 이번 스프린트의 증분에 항목을 포함시키지 않는다.
- 스프린트 리뷰에서 스크럼 마스터는 "완료"된 것과 "완료되지 않은" 것을 식별한다.
- 스크럼 마스터는 개발자들에게 스크럼 회의를 타임박스 내에 유지하도록 가르친다.
- 스크럼 마스터는 팀 외부 사람들이 스크럼 팀과 상호작용하도록 돕는다.
- 스크럼 마스터는 개발자들이 작업이 필요할 때 작업을 할당한다.
- 스크럼 마스터는 스프린트 번다운 업데이트에 책임이 있다.
- 창의성 증가.
- 규칙 준수 증가.
- 추정의 정확도 증가.
- 자기 책임감 증가.
- 헌신 증가.
- 릴리스 테스팅.
- 릴리스 회고.
- 스프린트 회고.
- 스프린트 계획.
- 스프린트 테스팅.
- 스프린트 0.
- 데일리 스크럼.
- 스크럼 마스터, 또는 스크럼 마스터가 개발자들에게 하도록 할 수 있다.
- 스크럼 마스터.
- 제품 책임자.
- 스크럼 팀에서 제품 책임자를 대표하는 비즈니스 분석가.
- 각 스크럼 팀은 시스템의 한 기술 계층(예: GUI, 데이터베이스, 미들 티어, 인터페이스)만 작업한다.
- 각 스크럼 팀은 모든 기술 계층을 통해 처음부터 끝까지 기능을 개발한다.
- 그/그녀는 거기에 있을 필요가 없다.
- 기능상의 장애물에 대해 듣기 위해.
- 이해관계자의 관점을 대표하기 위해.
- 스크럼 팀 구성원으로 참여하기 위해.
- 완전한 스크럼 팀을 참여시킨다.
- 코칭 기술을 사용한다; 열린 질문과 적극적 경청과 같은.
- 외부 기술 전문가에게 결정을 내리도록 요청한다.
- 모든 팀 구성원을 회사의 인사 부서에 보내 그들의 우려를 표현하게 한다.
- 완료의 정의를 충족하는 데 필요한 모든 작업 수행
- 이해관계자들에게 매일 스프린트 진행 상황 보고
- 별도의 스프린트에서 완료할 모든 미완료 작업을 추적하고 추정하기.
- 전자 추적 도구에서 스프린트 작업을 적절히 업데이트하기.
- 아키텍트.
- 스크럼 팀.
- 스크럼 마스터.
- 주제 전문가.
- 개발자들의 관리자.
- 두 번째 스프린트의 아키텍처 변경이 수석 아키텍트의 승인을 받은 후.
- 두 번째 스프린트의 제품 백로그가 선택된 후.
- 첫 번째 스프린트 직후.
- 고객이 첫 번째 스프린트의 수용 테스트를 완료한 후.
- 사용자 스토리.
- 작업.
- 유즈 케이스.
- 테스트.
- 선택된 제품 백로그 항목의 분해인 위의 모든 것(또는 기타).
- 제품 책임자는 한 사람이다.
- 제품 책임자는 제품 백로그를 정렬하는 책임이 있다.
- 여러 사람이 스크럼 팀에서 제품 책임자 역할을 공유할 수 있다.
- 제품 책임자 역할은 위원회나 팀이 수행할 수 있다.
- 참.
- 거짓.
- 생산성이 감소할 가능성이 있다.
- 생산성이 동일하게 유지될 가능성이 있다.
- 생산성이 증가할 가능성이 있다.
30. 스크럼 마스터가 새로운 스크럼 팀에 스크럼을 소개하고 있습니다. 스크럼 팀은 스프린트 회고가 불필요하다고 결정했습니다. 스크럼 마스터는 어떤 조치를 취해야 합니까? (가장 좋은 답변 선택)
- 스크럼 팀과 고위 경영진 간의 회의를 소집한다.
- 자기 관리 팀의 결정에 따른다.
- 제품 책임자와 상의하여 상황에 대해 어떻게 생각하는지 확인한다.
- 생산적이고 유용한 스프린트 회고를 촉진하기 시작한다.
31. 개발자들이 선택한 각 제품 백로그 항목을 완전히 완료할 엔지니어링 도구와 인프라가 없는 경우 스크럼 마스터가 수행하기에 적절한 두 가지는 무엇입니까? (가장 좋은 두 가지 답변 선택)
- 시간이 지남에 따라 기술, 도구 및 인프라를 개선하도록 스크럼 팀을 코칭하고 그에 따라 완료의 정의를 조정한다.
- 상황이 개선될 때까지 제품 책임자가 부분적으로 "완료된" 증분을 수락하도록 권장한다.
- 증분을 제공하는 대신 스크럼 팀의 인프라를 구축하는 데 현재 스프린트를 다시 집중한다.
- 스크럼 팀이 스크럼을 위한 준비가 되지 않았다고 선언한다.
- 현재 상황에서 실제로 달성 가능한 완료의 정의를 스크럼 팀이 수립하도록 한다.
- 스프린트 끝에.
- 항목이 잠재적으로 릴리스될 수 있도록 남은 작업이 없을 때.
- QA가 항목이 모든 수용 기준을 통과한다고 보고할 때.
- 항목과 관련된 스프린트 백로그의 모든 작업이 완료되었을 때.
- 제품 백로그 재정렬.
- 스프린트를 위한 제품 백로그 항목 가져오기.
- 스프린트 백로그에 계획된 작업 수행.
- 속도 증가.
- 이해관계자에게 일일 진행 상황 보고.
- 각 주요 소프트웨어 엔지니어링 분야(예: QA, Dev, UX)에서 최소 한 명의 대표.
- 스프린트에서 완료된 증분을 제공하는 데 필요한 역량과 기술.
- 한 명의 리드 개발자와 8명 이하의 다른 구성원.
- 각 스프린트 끝에 무엇이 완료되었는지에 대한 완전한 투명성을 가지기 위해.
- 팀이 스프린트의 속도 목표를 달성하지 못했을 때 질책할 수 있기 위해.
- 팀이 다음 세 스프린트 동안 무엇을 제공할지 알기 위해.
- 시간이 지남에 따라 팀의 생산성을 예측하기 위해.
- 결과 행동 항목의 우선 순위 지정.
- 스크럼 팀 구성원으로 참여하고 요청받거나 필요에 따라 촉진하기.
- 개발자들의 답변을 캡처하기 위한 서기 역할.
- 토론을 요약하고 경영진에 보고하기.
- 제품 백로그 항목을 잠재적으로 릴리스 가능한 제품 기능의 증분으로 전환한다.
- 추가 도구와 환경이 필요한 전문 테스트를 제외한 모든 개발 작업을 수행한다.
- 제품 책임자가 계산한 날짜와 비용 내에서 프로젝트를 완료한다.
- 요청받거나 필요에 따라 검사 및 적응 기회를 촉진한다.
- 팀 구성원들에게 자기 관리를 코칭한다.
- 제품 책임자가 모든 스크럼 이벤트에 참석하도록 보장한다.
- 팀 갈등을 기능 라인 관리자에게 상부 보고한다.
- 개발자들의 진행 상황을 모니터링한다.
- 스크럼 팀과 함께 작업을 할당한다.
- 제품 책임자가 제품 백로그를 정렬할 시간을 더 가질 수 있도록 스프린트를 연장하라고 제안한다.
- 작업의 실현 가능한 순서인지 확실히 하기 위해 개발자들이 정렬을 수행하도록 제안한다.
- 제품 백로그 정렬의 목표가 가치를 극대화하는 것임을 이해하는 데 제품 책임자에게 도움을 제공한다.
- 사용할 정렬된 제품 백로그를 제품 책임자에게 제시한다.
- 어떤 항목이 기술적으로 가장 빨리 구현되는지 확인하기 위해 제품 책임자가 개발자들과 함께 작업하도록 권장한다.
- 참.
- 거짓.
- 개발자들이 예측한 것을 달성했다면 축하하고, 예측을 충족하지 못했다면 처벌하는 데 사용된다.
- 조직의 모든 사람이 완료된 작업을 확인할 수 있도록 스프린트 끝에 하는 데모이다.
- 스프린트 동안 개발자들의 활동을 통제하는 메커니즘이다.
- 스크럼 팀과 이해관계자들이 스프린트의 결과를 검사하고 다음에 무엇을 할지 파악하는 때이다.
- 최고 백로그 책임자.
- 제품 책임자.
- 스크럼 마스터.
- 스크럼 팀.
- 스크럼 팀이 작업이 너무 어렵다고 느낄 때.
- 스프린트 목표가 쓸모없게 될 때.
- 영업 부서에 중요한 새로운 기회가 있을 때.
- 스프린트 끝까지 모든 것이 완료되지 않을 것이 분명해질 때.
- 각 스프린트 끝에.
- 각 스프린트 시작 시.
- 스크럼 팀이 필요하다고 결정할 때만.
- 프로젝트 또는 릴리스의 마지막 스프린트 끝에.
45. 새로운 개발자가 기존 개발자들과 지속적인 갈등을 겪고 적대적인 환경을 조성하고 있습니다. 필요한 경우, 팀 구성원을 제거하는 책임은 누구에게 있습니까? (가장 좋은 답변 선택)
- 채용 관리자가 책임이 있다, 왜냐하면 그/그녀가 개발자를 고용했기 때문이다.
- 스크럼 관리자가 책임이 있다, 왜냐하면 그/그녀가 장애물을 제거하기 때문이다.
- 개발자들이 책임이 있으며, 스크럼 마스터의 도움이 필요할 수 있다.
- 제품 책임자가 책임이 있다, 왜냐하면 그/그녀가 투자수익률(ROI)을 통제하기 때문이다.
- 스프린트를 위해 선택할 제품 백로그 항목 수에 대해 개발자들을 안내한다.
- 작업이 완료되었을 때에 대한 공유된 이해를 만든다.
- 각 스크럼 이벤트의 목적, 목표 및 타임박스를 설명한다.
- 스프린트가 끝나기 전에 수행되어야 하는 작업을 설명한다.
- 투명성을 증가시킨다.
47. 스프린트 회고 동안, 개발자들이 데일리 스크럼을 화요일과 목요일에만 수행하도록 제안합니다. 스크럼 마스터에게 가장 적절한 두 가지 응답은 무엇입니까? (가장 좋은 두 가지 답변 선택)
- 요청을 고려하고 데일리 스크럼이 어떤 날에 발생해야 하는지 결정한다.
- 계획을 업데이트할 기회로서 데일리 스크럼이 왜 중요한지 팀을 코칭한다.
- 개발자들에게 투표하게 한다.
- 개발자들이 왜 이것을 원하는지 배우고 데일리 스크럼의 결과를 개선하기 위해 그들과 협력한다.
- 자기 관리 팀의 결정을 인정하고 지원한다.
- 제품 백로그 개선 중 이전 스프린트에서 생성되었어야 한다.
- 계획을 시작하기 위해 스프린트 계획 전에 설정되어야 한다.
- 스프린트 목표는 스크럼에서 필수가 아니다.
- 스프린트 동안 언제든지.
- 스프린트 계획 중에.
- 참. 결과는 그들의 참여와 가용성에 영향을 받는다.
- 거짓. 제품 책임자는 스크럼 팀의 비즈니스 분석가로 대체될 수 있다.
- 거짓. 스크럼 마스터는 스크럼 팀이 요청할 때만 필요하다.
- 참. 각각은 스크럼 팀에 100% 전념해야 한다.
- 스크럼 마스터.
- 스크럼 팀 또는 그 구성원.
- 제품 책임자.
- 이해관계자.
- 참.
- 거짓.
- 다음 스프린트를 위한 우선순위가 높은 프로세스 개선 사항 식별.
- 제품 백로그의 항목 순서.
- 팀이 협업하는 방법.
- 다음 스프린트의 항목에 대한 수용 기준 문서화.
53. 스크럼 마스터는 서로 다른 물리적 위치에 구성원이 있는 스크럼 팀과 작업하고 있습니다. 스크럼 팀은 다양한 회의실에서 만나며 데일리 스크럼 전에 물류적으로 많은 작업(예: 전화 회의 설정)을 해야 합니다. 스크럼 마스터는 어떤 조치를 취해야 합니까? (가장 좋은 답변 선택)
- 스크럼 팀이 스스로 관리하고 무엇을 할지 스스로 결정하도록 한다.
- 회의를 설정하고 스크럼 팀에게 그것이 수행되는 방법이라고 말한다.
- 스크럼 팀 구성원들에게 회의 설정을 담당하는 사람을 교대로 하도록 요청한다.
- 경영진에게 알리고 해결하도록 요청한다.
- 참.
- 거짓.
- 의사소통 방법.
- 스크럼 팀이 스프린트 계획을 수행하는 방식.
- 개발자들의 제공 능력을 향상시키는 데 필요한 기술.
- 완료의 정의.
- 위의 모든 것.
- 회의가 적절한 시간에 시작하고 끝나도록 보장함으로써.
- 개발자들을 방해하는 장애물을 제거함으로써.
- 개발자들의 결정을 촉진함으로써.
- 높은 가치의 기능을 제품 백로그에서 높게 유지함으로써.
- 7 플러스 또는 마이너스 3.
- 최소 7명.
- 9명.
- 3명에서 9명.
58. 당신은 새로 개발될 제품의 스크럼 마스터입니다. 개발에는 45명이 필요할 것입니다. 팀을 구성할 때 그룹이 생각해볼 것을 제안하는 좋은 첫 번째 질문은 무엇입니까? (가장 좋은 답변 선택)
- 모든 팀이 적절한 양의 전문 지식을 갖추도록 어떻게 확인할 것인가?
- 각 팀에 선임 및 후임 인원의 적절한 혼합은 무엇인가?
- 누가 팀 리더가 될 것인가?
- 각 팀의 주제 전문가는 누구인가?
- 스프린트 리뷰.
- 릴리스 계획.
- 스프린트 회고.
- 개선 회의.
- 데일리 스크럼.
- 개발자들에게 전문가를 추가한다.
- 기능을 부분적으로 완료하고 스프린트 리뷰에서 남은 작업을 논의한다.
- 가능하고 수용 가능한 것이 무엇인지 결정하기 위해 제품 책임자와 협력한다.
- 더 적절한 스프린트로 작업을 연기한다.
- 프로젝트 시작 시.
- 스프린트 계획 회의 중.
- 스프린트 계획 회의 전.
- 스프린트 중.
- 개발자들의 토론을 이끈다.
- 팀의 각 구성원이 3가지 질문에 모두 답했는지 확인한다.
- 각 팀 구성원이 말할 기회를 갖는지 추적한다.
- 개발자들에게 데일리 스크럼을 15분 타임박스 내에 유지하도록 가르친다.
- 위의 모든 것.
- 향후 스프린트 백로그 목록을 위한 작업으로 모든 제품 백로그 항목을 분해.
- 이전 반복에서 제공된 것을 보완하는 사용 가능한 상태의 추가 기능.
- 이전 반복에서 제공된 기능을 위한 새로운 사용자 인터페이스 디자인.
- 이전 반복에서 제공된 기능을 확인하는 자동화된 테스트 스위트.
- 향후 반복에서 기능을 제공하는 방법을 설명하는 UML 다이어그램.
64. 스크럼의 이점을 달성하기 위해서는 헌신의 가치를 제정하는 것이 중요합니다. 스크럼 팀 구성원의 헌신을 보여주는 두 가지 행동은 무엇입니까? (가장 좋은 두 가지 답변 선택)
- 항상 스프린트 예측의 항목을 제공한다.
- 다른 스크럼 팀 구성원을 돕는다.
- 최선을 다한다.
- 일일 상태 보고서를 보낸다.
- 늦게까지 일한다.
- 거짓.
- 참, 이해관계자에게 약속한 것에 따라.
- 참, 하지만 팀이 충분한 능력이 있다는 자원 관리자의 확인 후에만.
- 참.
- 거짓, 스크럼 마스터가 그것을 한다.
- 거짓, 능력과 약속은 프로젝트 관리자의 책임이다.
- 준수 문제를 담당하는 별도의 팀에 의해 다루어진다.
- 첫 번째 스프린트가 시작되기 전에 논의되고 분석되고 문서화된다.
- 제품 백로그에 추가되고 각 스프린트 동안 새로운 제품 기능 생성과 함께 다루어진다.
- 각 스프린트 동안 완료의 정의를 충족하는 일부로 다루어진다.
- 개발자들과 이해관계자.
- 제품 책임자와 개발자들.
- 스크럼 팀과 이해관계자.
- 제품 책임자와 경영진.
- 개발자들과 경영진.
- 제품 책임자와 이해관계자.
68. 참 또는 거짓: 무엇을 만들지 시작하기 위해, 스크럼은 첫 번째 스프린트를 위한 충분한 아이디어를 가진 제품 책임자, 그 아이디어를 구현할 개발자들, 프로세스를 안내하는 데 도움을 줄 스크럼 마스터 이상을 요구하지 않는다.
- 참.
- 거짓.
- 필요한 만큼.
- 월간 스프린트에 대해 2시간.
- 월간 스프린트에 대해 4시간.
- 4시간 그리고 필요에 따라 더 길게.
- 1일.
- 개발자들.
- 스크럼 마스터.
- 프로젝트 관리자.
- 제품 책임자와 상의하는 개발자들.
- 제품 책임자.
- 여러 계층(예: 데이터베이스, UI 등)에 걸쳐 기술을 기반으로 팀을 만든다.
- 제품 책임자에게 사람들을 팀에 할당하도록 요청한다.
- 개발자들에게 스스로 팀으로 나누도록 요청한다.
- 참.
- 거짓.
- 누적 비용.
- 개별 작업자 생산성.
- 시간에 따른 남은 작업.
- 고객에게 전달된 누적 비즈니스 가치.
- 스크럼 마스터가 그들을 대신해서 말한다.
- 스크럼 팀은 자기 관리하며 데일리 스크럼에서 필요한 유일한 관리이다.
- 경영진은 각 데일리 스크럼 시작 시 업데이트를 제공한다.
- 제품 책임자가 그들의 의견을 대표한다.
75. 스크럼 마스터가 공개 장애물 목록을 유지하고 있지만, 그것은 증가하고 있고 그/그녀는 장애물의 작은 부분만 해결할 수 있었습니다. 이 상황에서 가장 도움이 될 세 가지 기술은 무엇입니까? (세 개 선택)
- 스크럼 팀과 상의하기.
- 목록의 우선 순위를 정하고 순서대로 작업하기.
- 모든 프로젝트 관리자와 분류 회의를 준비하기.
- 장애물과 그 영향을 경영진에게 알리기.
- 집중.
- 존중.
- 개방성.
- 용기.
- 헌신.
- 위의 모든 것.
- 월간 스프린트에 대해 4시간.
- 월간 스프린트에 대해 8시간.
- 월간.
- 완료될 때마다.
- 제품 백로그 항목은 스토리 포인트로 추정되어야 한다.
- 추정은 스크럼 팀에 의해 이루어진다.
- 추정은 상대 단위여야 한다.
- 스크럼은 추정을 금지한다.
- 추정은 제품 책임자에 의해 이루어지지만, 스크럼 팀과 확인하는 것이 가장 좋다.
- 내부 팀 갈등 해결.
- 생산성 보고.
- 제품 책임자 선택.
- 스프린트 목표를 충족하는 데 필요한 작업 구성.
- 기존 팀이 새로운 구조로 조직하는 방법을 제안한다.
- 관리자가 개인적으로 현재 부하 직원을 새 팀으로 재배치한다.
- 관리자가 협력하여 개인을 특정 팀에 할당한다.
- 모든 개발자들을 모으고 스크럼 팀으로 자기 관리하도록 한다.
- 최고 제품 책임자가 새로운 팀 구조와 할당을 결정한다.
- 참.
- 거짓.
- 제품 책임자의 기능 관리자에게 알린다.
- 스프린트를 중지하고, 제품 책임자를 교육 과정에 보내고 다시 시작한다.
- 스프린트 회고에서 문제를 제기한다.
- 제품 책임자에게 스크럼의 가치와 점진적 제공에 대해 코칭한다.
- 대리 제품 책임자를 지명한다.
- 참.
- 거짓.
- 수용 테스트 단계 후.
- 릴리스 스프린트 전.
- 3개의 스프린트마다.
- 모든 스프린트 끝에.
- 제품 책임자가 생성하도록 요청할 때.
- 참.
- 거짓.
- 스크럼 팀 구성원으로 참여하기.
- 스크럼 팀에서 대표하는 이해관계자들에게 논의 내용을 요약하고 보고하기.
- 제품 백로그에 대한 요구사항 수집하기.
- 제품 책임자는 스프린트 회고에 참여하지 않아야 한다.
87. Marian은 제품의 새 릴리스를 위한 프로젝트를 구상하는 제품 책임자입니다. 그녀는 스프린트당 17개의 완료된 작업 단위의 지속적인 속도를 기반으로 릴리스 날짜를 예상했습니다. 처음 3개의 스프린트 동안, 개발자들이 90% 완료로 추정한 작업의 평균 속도는 13이었습니다. 개발자들은 계획을 충족해야 한다는 필요성을 느끼고 17의 속도가 그들의 능력 범위 내에 있다고 생각했습니다. 계속하기에 좋은 방법은:
- 개발자들은 스프린트당 선택된 모든 범위가 가능한 한 "완료"되도록 확인한다. 완료되지 않은 작업은 추정되고 다음 스프린트의 스프린트 백로그에 추가되므로 제품 백로그를 엉망으로 만들지 않는다.
- 마감일을 맞추기 위해 개발자들에게 충분한 사람을 추가한다.
- 검사하고 적응할 기회가 사라진다. 불투명성이 투명성을 대체했다. 예측 가능성은 제로 이하로 떨어졌다. 생산된 소프트웨어는 사용할 수 없다. 스크럼의 규칙이 존중되지 않았으므로, 수리가 가능한지 또는 더 신뢰할 수 있는 팀으로 다시 시작할지를 평가하는 것은 스크럼 마스터의 의무이다. 그렇지 않으면 스크럼 마스터는 프로젝트를 취소해야 한다.
- 개발자들은 Marian에게 남은 작업을 수행할 수 있는 충분한 릴리스 스프린트를 위한 자금을 찾도록 상기시켜야 한다.
- 1인당 2분.
- 15분.
- 4주 스프린트의 경우 15분. 더 짧은 스프린트의 경우 일반적으로 더 짧다.
- 4시간.
- 매일 같은 시간.
- 개발자들과 고객 사이의 중개자.
- 가치 최적화자.
- 요구사항 엔지니어.
- 팀 관리자.
- 제품 책임자에게 비즈니스 위험을 수용 가능한 수준으로 유지하기에 충분히 짧아야 한다.
- 개발 작업을 다른 비즈니스 이벤트와 동기화할 수 있을 만큼 충분히 짧아야 한다.
- 한 달 이하여야 한다.
- 이 모든 답변이 맞다.
- 프로그래머의 작업 확인.
- 개발자의 모든 사람이 품질에 책임이 있다.
- 품질 지표 추적.
- 버그 찾기.
- 스크럼에는 "테스터" 역할이 없다.
- 항목을 현재 스프린트에 추가하고 동일한 크기의 항목을 제거한다.
- 조정 없이 항목을 현재 스프린트에 추가한다.
- 제품 책임자에게 알려 그/그녀가 CEO와 협력할 수 있도록 한다.
- 항목을 다음 스프린트에 추가한다.
- 스크럼 팀이 개선하는 데 도움이 되는 통찰력과 자원으로 촉진한다.
- 스크럼 팀의 생산성을 모니터링한다.
- 충분히 열심히 일하지 않는 사람들을 식별하고 제거한다.
- 개발자들의 인력 수준을 지속적으로 모니터링한다.
- 그들 간의 커뮤니케이션을 모니터링하고 직접 협업을 촉진한다.
- 개발자들에게 비즈니스 요구사항과 목표 측면에서 말하도록 가르친다.
- 제품 책임자에게 스프린트 동안 사용되는 기술에 대해 가르친다.
- 그들을 위한 중개자 역할을 한다.
- 스크럼 마스터가 개발자들이 스프린트를 이해한다고 확신할 수 있을 만큼의 작업만.
- 전체 스프린트 백로그는 스프린트 계획 회의가 끝날 때까지 식별되고 추정되어야 한다.
- 개발자들이 무엇을 할 수 있는지에 대한 최선의 예측을 만들고 스프린트의 처음 며칠을 시작할 수 있을 만큼 충분히.
- 설계 및 아키텍처 영향을 이해하기에 충분한 정도만.
- 스크럼 마스터.
- 개발자들.
- 제품 책임자.
- 팀의 가장 후임 구성원.
- 개발자들.
- 팀 관리자.
- 프로젝트 관리자.
- 스크럼 팀.
- 비즈니스 분석가.
- 조직이 유사한 길이의 스프린트를 의무화했다.
- 사용할 기술에 대한 불확실성의 수준.
- 팀 구성을 변경할 수 있는 빈도.
- 이해관계자로부터 연결이 끊어질 위험.
- 다음 스프린트의 수용 테스트를 식별하기 위한 실패한 단위 테스트.
- 약간의 알려진 버그가 있는 소프트웨어 증분.
- "완료"된 작동하는 소프트웨어의 증분.
- 스크럼 마스터가 요청한 것이라면 단일 문서.
- 제품 책임자와 요구사항을 명확히 한 후 개발자들.
- 개발자들의 의견을 받은 제품 책임자.
- 아키텍트와 주제 전문가를 포함한 조직에서 가장 선임인 사람들.
- 스크럼 마스터.
- 개발자들만.
- 마지막에 도착하는 사람. 이것은 사람들이 시간을 지키도록 격려하고 타임박스 내에 머물도록 도움을 준다.
- 개발자들이 시작해야 한다고 결정하는 사람.
- 토큰을 가진 사람.
- 스크럼 마스터. 이것은 개발자들이 회의를 갖고 타임박스 내에 머물도록 보장한다.
- 마지막으로 빌드를 깬 사람.
- 팀의 최고 성과자를 위한 보너스 시스템을 도입한다.
- 스크럼 팀 구성원들이 서로를 소개하고 기술과 작업 이력에 대한 간단한 배경을 제공하도록 한다.
- 각 개발자의 개발 관리자가 직속 부하 직원을 소개하고 스크럼 팀에서의 책임을 설명하도록 한다.
- 스크럼 팀 구성원들이 호환되는 성격을 갖도록 보장한다.
- 팀이 완료의 정의가 필요하다는 것을 이해하도록 보장한다.
- 제품 책임자에게 제품 또는 프로젝트, 그 역사, 목표 및 맥락에 대해 논의하고 질문에 답하도록 요청한다.
103. 개발자들은 스프린트 끝까지 선택한 항목을 "완료"할 의도로 스프린트 백로그를 위한 제품 백로그 항목 세트를 선택합니다. 완료의 정의의 목적을 가장 잘 설명하는 세 가지 문구는 무엇입니까? (세 개 선택)
- 개발자들이 자신의 작업을 수행했는지 제어한다.
- 기술 문서에 포함되어야 할 요소에 대한 템플릿을 제공한다.
- 스프린트 리뷰에서 검사된 작업에 대한 투명성을 만든다.
- 제품 백로그 항목의 완성도를 추적한다.
- 스프린트 계획에서 예측을 만드는 데 개발자들을 안내한다.
- 증분이 릴리스 준비가 되기 위해 필요한 것을 정의한다.
- 스프린트 백로그를 검사하고 적응할 기회가 손실된다.
- 장애물이 더 느리게 제기되고 해결된다.
- 제품 책임자가 이해관계자에게 진행 상황을 정확하게 보고할 수 없다.
- 회의 전에 스크럼 보드를 업데이트하는 데 너무 많은 작업이 소비된다.
- 스크럼 마스터가 간트 차트를 제대로 업데이트할 수 있는 능력을 잃는다.
- 스프린트 백로그가 부정확해질 수 있다.
- 과학적 관리의 원칙에 부합하는 정의되고 예측 가능한 프로세스.
- 소프트웨어를 개발하는 방법을 정의하는 완전한 방법론.
- 소프트웨어 개발을 위한 모범 사례를 정의하는 요리책.
- 복잡한 환경에서 복잡한 제품이 개발되는 프레임워크.
- 경제적 부가 가치.
- 존중.
- 집중.
- 획득 가치.
- 용기.
- 가장 높은 속도를 가진 스크럼 팀이 먼저 제품 백로그 항목을 가져간다.
- 개발자들이 제품 책임자와 합의하여 작업을 가져온다.
- 제품 책임자는 각 팀에게 자체 제품 백로그를 제공해야 한다.
- 각 스크럼 팀은 동일한 수의 항목을 가져간다.
- 제품 책임자가 결정한다.
- 필요에 따라, 단기적인 생산성 감소를 고려하면서.
- 절대로, 왜냐하면 생산성을 감소시키기 때문이다.
- 필요에 따라, 생산성 변화에 대한 특별한 수당 없이.
- 공유 학습을 촉진하기 위해 매 스프린트마다.
- 프로젝트 관리자.
- 제품 책임자.
- 스크럼 마스터.
- 개발자들.
- 위의 모든 것.
- 스프린트 계획 중.
- 새로운 스프린트를 시작하기 전.
- 스프린트 회고 중.
- 새로운 프로젝트를 시작하기 전.
- 작업을 시작하기 전에 추가 개발자들을 모집한다.
- 개발자들은 제품 책임자가 인지하도록 보장하고, 스프린트를 시작하고, 진행 상황을 모니터링한다.
- 스프린트를 취소한다.
- 선택된 제품 백로그 항목을 제거하거나 변경한다.
- 개발자들은 이 스프린트 동안 초과 근무를 한다.
112. 현재 개발자들은 단일 계층(예: 프런트 엔드, 미들 티어, 백 엔드 및 인터페이스)만 다루도록 조직되어 있습니다. 이러한 컴포넌트 팀에서 기능 팀으로 이동하기로 결정할 때 고려해야 할 세 가지 사항은 무엇입니까? (세 개 선택)
- 기능 팀 없이는 스크럼을 할 수 없다.
- 이러한 종류의 이동을 할 때 생산성이 저하될 수 있다.
- 먼저 비즈니스 측의 지원을 받는 것이 도움이 된다.
- 기능 팀은 의사소통 오버헤드가 적다.
- 기능 팀을 사용하면 팀당 생산성을 계산하기가 더 쉽다.
- 제품 책임자가 새로운 작업을 식별할 때.
- 식별된 후 가능한 한 빨리.
- 스크럼 마스터가 입력할 시간이 있을 때.
- 개발자들이 승인한 후 데일리 스크럼 중에.
- 관리자에게 보고할 상태 및 진행 정보를 수집하기 위해.
- 새 항목 추가 및 번다운에 대한 진행 상황 추적을 포함하여 스프린트 백로그에 대한 변경 사항을 기록하기 위해.
- 그/그녀는 거기에 있을 필요가 없다; 그/그녀는 단지 개발자들이 데일리 스크럼을 갖도록 보장하면 된다.
- 모든 팀 구성원이 세 가지 질문에 답하도록 확인하기 위해.
115. 전통적인 방법을 사용하여 제품을 제공하는 6개 팀이 있습니다. 경영진이 스크럼을 사용하기 시작하도록 요청했습니다. 초기 프로젝트에는 소프트웨어 시스템의 계층에 대한 별도의 계획과 팀이 있었습니다. 즉, 프런트엔드용, 미들 티어용, 백엔드용, 인터페이스 및 서비스용. 이것은 컴포넌트 팀으로 알려진 것과 유사합니다. 하지만 기능별로 팀을 조직하는 것이 좋은 아이디어라고 읽었습니다. 스크럼을 시작하면서 컴포넌트 팀을 유지하는 이점은 무엇입니까?
- 새로운 팀으로 조직하는 것보다 초기 혼란이 적다. 시작하면서, 그들은 무엇이 가장 잘 작동하는지, 그리고 이를 향해 잠재적으로 재조직하는 방법을 발견할 것이다.
- 컴포넌트 팀은 일반적으로 비즈니스 가치를 제공하는 작동하는 소프트웨어 증분을 만드는 데 필요한 기술을 가지고 있다.
- 그들은 한동안 함께 일했기 때문에 새로운 기능 팀보다 더 빨리 출하 가능한 증분을 생산할 수 있을 가능성이 있다.
- 기능 팀에서 작업하는 것보다 팀 간 종속성이 적다.
- 참.
- 거짓.
- 참.
- 거짓.
- 제품 백로그 관리.
- 스프린트 마감일을 유지하고 개발자들을 궤도에 올려놓기.
- 스크럼 프레임워크가 올바르게 적용되고 있는지 확인하기 위해 스크럼 팀을 코칭.
- 스프린트 백로그에 대한 개발자들의 속도와 생산성을 향상시키기.
119. 개발자들이 제품 책임자에게 제품 백로그를 재정렬하도록 요청합니다. 팀은 외부 공급업체가 특정 소프트웨어 구성 요소를 제공하기를 기다리고 있습니다. 그 구성 요소 없이는 다음 스프린트에서 전체 팀을 차지할 충분한 작업이 없을 것입니다. 제품 책임자는 스크럼 마스터에게 도움을 요청합니다. 제품 책임자에게 줄 좋은 조언은 무엇입니까?
- 전체 팀을 바쁘게 유지하기에 충분한 작업이 없으므로 팀을 축소한다.
- 이 시간을 기술 부채와 교육에 집중할 기회로 사용하고 팀 규모를 줄이는 것을 연기한다.
- 개발자들이 구성 요소 없이도 이번 스프린트에서 작업할 수 있는 충분한 사업 가치가 있는 제품 백로그 항목이 있는지 평가하는 데 도움을 준다.
- 외부 공급업체와 협력하여 구성 요소를 조기에 제공하도록 영향을 미친다.
- 외부 권한에 대한 의존을 제거함으로써.
- 모든 스크럼 팀 구성원이 경험적 프로세스를 위한 스크럼 이벤트에 참여해야 함으로써.
- 일일 진행 상황 보고서에 기초한 점진적인 제공을 제공함으로써.
- 모든 스크럼 팀 구성원이 관리가 아니라 가치와 품질에 집중하도록 함으로써.
- 결과를 달성하기 위한 최선의 방법을 결정하는 것이 작업을 수행하는 사람들에 의해 이루어짐으로써.
- 팀 간 종속성 최소화.
- 요구사항의 명확한 정의.
- 원래 범위 예측 충족.
- 모든 팀의 모든 사람에게 충분한 작업이 있는지 확인.
- 속도 극대화.
- 이벤트는 정해진 시간에 발생해야 한다.
- 이벤트는 주어진 시간까지 발생해야 한다.
- 이벤트는 최소한의 시간이 걸려야 한다.
- 이벤트는 최대 시간을 초과할 수 없다.
- 더 엄격한 기준을 포함하도록 완료의 정의를 개선할 것이다.
- 스프린트 회고는 4시간 이상으로 증가할 것이다.
- 타임박스는 새로운 스크럼 팀에만 해당하므로 타임박스된 스프린트가 필요하지 않다.
- 스프린트 리뷰는 더 이상 필요하지 않을 것이다.
- 이제 성숙한 팀이므로 스크럼 마스터가 더 이상 필요하지 않다.
- 합리적일 때.
- 개발자들이 매 스프린트마다 완료했는지 확인하기 위해.
- 제품에 결함이 없을 때마다.
- 예외 없이.
- 개발자들의 생산성에 책임이 있으므로 스크럼 마스터.
- 모든 구성원의 정의의 공통 분모가 결과인 협력적 노력으로 스크럼 팀.
- 제품의 성공에 책임이 있으므로 제품 책임자.
- 개발 조직(개발 조직에서 사용할 수 없는 경우 개발자들).
126. 하나의 제품을 구축하기 위해 5개의 새로운 스크럼 팀이 만들어졌습니다. 스크럼 팀 중 하나의 개발자 몇 명이 스크럼 마스터에게 다른 팀과 작업을 조정하는 방법을 묻습니다. 스크럼 마스터는 무엇을 해야 합니까?
- 제품 책임자에게 스프린트 동안 너무 많은 기술적 및 개발 중복을 피하는 방식으로 제품 백로그를 정렬하는 데 리드 개발자들과 협력하도록 가르친다.
- 통합된 증분을 생성하기 위해 다른 팀과 협력하는 것이 그들의 책임임을 가르친다.
- 스프린트 계획이 끝날 때 팀에서 스프린트 작업을 수집하고 전체 스프린트에 대한 통합 계획으로 병합한다.
- 스프린트 백로그가 정렬되어 있는지 검사하기 위해 매일 5개 팀을 방문한다.
- 프로젝트의 나머지 부분에 대한 계획을 세운다.
- 후속 스프린트에 대한 요구사항을 분석, 설명 및 문서화한다.
- 적어도 하나의 기능을 개발한다.
- 완전한 아키텍처와 인프라를 분석, 설계 및 설명한다.
- 잠재적으로 릴리스 가능한 소프트웨어의 증분을 생성한다.
- 프로젝트 관리자.
- 개발자들.
- 스크럼 팀.
- 제품 책임자.
- 스크럼 마스터와 제품 책임자.
- 개발자들.
- 개발자들과 제품 책임자.
- 스크럼 팀.
- 개발자들과 스크럼 마스터.
- 스프린트 계획 회의에서.
- 데일리 스크럼 중에.
- 절대로. 모든 스프린트 백로그 항목은 각각이 개별 개발자에 의해 수행될 수 있더라도 전체 스크럼 팀이 "소유"한다.
- 팀 구성원이 더 많은 작업을 수용할 수 있을 때마다.
- 참.
- 거짓.
132. 스프린트 계획 회의에서 제품 책임자와 개발자들은 가장 높은 순서의 제품 백로그 항목에 대해 명확한 이해에 도달할 수 없었습니다. 이 때문에 개발자들은 다가오는 스프린트를 위해 얼마나 많은 제품 백로그 항목을 예측할 수 있는지 파악할 수 없었습니다. 그러나 그들은 스프린트 목표에 동의할 수 있었습니다. 스크럼 마스터가 지원해야 하는 다음 두 가지 행동은 무엇입니까? (두 개 선택)
- 스프린트를 취소한다. 전체 팀을 고급 스크럼 교육에 보내고 새로운 스프린트를 시작한다.
- 목표를 충족할 가능성이 가장 높은 제품 백로그 항목을 예측하고 가능성 있는 초기 설계 및 계획을 기반으로 스프린트 백로그를 생성한다. 스프린트 계획 회의의 타임박스가 끝나면 스프린트를 시작하고 스프린트 동안 계속 분석, 분해 및 추가 기능을 생성한다.
- 개발자들이 완전한 예측을 할 수 있도록 충분한 수의 제품 백로그 항목이 충분히 이해될 때까지 스프린트 계획 회의를 타임박스를 지나 계속한다. 그런 다음 스프린트를 시작한다.
- 다가오는 스프린트 회고에서 이것이 발생한 이유와 재발 가능성을 줄이기 위해 어떤 변경이 필요한지 논의한다.
- 모든 사람에게 먼저 제품 백로그를 분석하는 데 필요한 만큼의 시간을 갖도록 요청하고, 그런 다음 다른 스프린트 계획 회의를 다시 소집한다.
- 무엇을 할 것이고 누가 할 것인가.
- 조건이 어떻게 변했고 제품 백로그가 어떻게 진화해야 하는가.
- 무엇을 할 수 있고 어떻게 할 것인가.
- 지난 스프린트에서 무엇이 잘못되었고 이번 스프린트에서 다르게 할 것은 무엇인가.
- 누가 팀에 있고 팀 구성원의 역할은 무엇인가.
- 스프린트 회고.
- 데일리 스크럼에서 구성원들은 서 있어야 한다.
- 스프린트 번다운 차트.
- 릴리스 계획.
- 위의 모든 것.
- 프로젝트의 유효성을 판단하는 시간을 갖기 위해.
- 이해관계자와 함께 제품 증분을 검사하고 다음 단계에 대한 피드백을 수집하기 위해.
- 스프린트 동안 스크럼 팀의 활동과 프로세스를 검토하기 위해.
- 팀 정신을 구축하기 위해.
- 모든 증분이 그것들을 충족하도록 보장한다.
- 릴리스 부서가 이러한 요구사항을 이해하도록 확인하지만, 개발자들의 책임은 아니다.
- 릴리스 스프린트 전의 통합 스프린트 동안 처리한다.
- 팀의 리드 개발자에게 할당한다.
- 제품 책임자가 완료되었다고 말할 때.
- 모든 제품 백로그 항목이 완료의 정의를 충족할 때.
- 모든 작업이 완료될 때.
- 타임박스가 만료될 때.
- 참.
- 거짓.
- 참.
- 거짓.
- 고객과의 경험으로부터.
- 유용할 때 위임.
- 이해관계자들의 신뢰.
- 상업적 이해관계로부터.
- 용기.
- 집중.
- 존중.
- 경제적 부가 가치.
- 획득 가치.
- 스프린트 사이의 휴식은 30일 스프린트의 경우 1주일로 타임박스되며, 더 짧은 스프린트의 경우 일반적으로 더 적다.
- 다음 스프린트의 요구사항이 결정되고 문서화되기에 충분한 시간.
- 개발자들이 마지막 스프린트의 테스트를 완료하기에 충분한 시간.
- 없음. 새 스프린트는 이전 스프린트가 끝난 직후에 시작된다.
- 상황에 따라 위의 모든 것이 허용된다.
- 예, 하지만 작업에 종속성이 있는 스크럼 팀에만 해당된다.
- 예, 그렇지 않으면 제품 책임자(및 이해관계자)가 무엇이 완료되었는지 정확하게 검사할 수 없을 수 있다.
- 아니오, 각 스크럼 팀은 독립적이다.
- 아니오, 그것은 너무 어렵고 하드닝 스프린트에서 수행되어야 한다.
- 할 수 없다. 제품 책임자만 스프린트를 취소할 수 있다.
- 기능적 기대가 잘 이해되지 않을 때.
- 제품 책임자가 너무 자주 부재할 때.
- 스프린트를 위해 선택된 제품 백로그 항목이 달성할 수 없게 될 때.
- 기술적 종속성을 해결할 수 없을 때.
- 스프린트 백로그.
- 스프린트 목표.
- 릴리스 계획.
- 스프린트 리뷰 의사록.
- 스크럼 팀은 다음 스프린트의 스프린트 백로그에 항목을 추가할 수 있다.
- 스크럼 팀은 제품 백로그에 넣을 우선순위가 높은 프로세스 개선 사항을 적어도 하나 선택해야 한다.
- 스크럼 팀은 일이 순조롭게 진행될 때 스프린트 백로그에 프로세스 개선 사항을 추가하는 것을 거부해야 한다.
- 스크럼 마스터가 가장 중요한 프로세스 개선 사항을 선택하여 스프린트 백로그에 넣는다.
- 완전한 스크럼 팀을 의사 결정에 참여시킨다.
- 코칭 기술을 사용한다; 열린 질문과 적극적 경청과 같은.
- 외부 애자일 코치에게 권장 사항을 묻는다.
- 팀 구성원들에게 회사의 인사 부서에 문제를 제기하도록 요청한다.
- 제품 책임자를 대표하는 비즈니스 분석가.
- 제품 책임자.
- 스크럼 마스터, 또는 스크럼 마스터가 개발자들에게 하도록 할 수 있다.
- 스크럼 마스터.
- 각 스크럼 팀이 자체적으로 정의하고 사용한다. 차이점은 하드닝 스프린트 동안 논의되고 조정된다.
- 각 스크럼 팀의 스크럼 마스터가 공통 완료의 정의를 정의한다.
- 각 스크럼 팀은 자체적으로 사용하지만, 차이점이 알려지도록 다른 모든 팀에게 자신들의 정의를 명확히 해야 한다.
- 모든 스크럼 팀은 결합된 작업을 잠재적으로 릴리스 가능하게 만드는 완료의 정의를 가져야 한다.
- 각 개발자가 자체적으로 정의하고 사용한다. 차이점은 하드닝 스프린트 동안 논의되고 조정된다.
- 상황에 따라 다르다.
- 각 개발자는 자체적으로 사용하지만 차이점이 알려지도록 다른 모든 팀에게 자신들의 정의를 명확히 해야 한다.
- 모든 개발자들은 결합된 작업을 잠재적으로 릴리스 가능하게 만드는 완료의 정의를 가져야 한다.
151. 일곱 번째 스프린트 리뷰에서 이해관계자들은 실망하고 화가 났습니다. 그들은 구축 중인 제품이나 시스템이 자신들의 요구를 충족하지 못하고 그들이 기꺼이 지출할 수 있는 것보다 더 많은 비용이 들 것이라고 판단했습니다. 이로 이어질 가능성이 있는 요인은 무엇입니까? (두 개 선택)
- 프로젝트 관리 사무소(PMO)가 적절하게 참여하지 않았다.
- 제품 책임자가 이해관계자들에게 프로젝트 진행 상황을 계속 알리지 않았다.
- 이해관계자들이 스프린트 리뷰를 사용하여 진행 상황을 검사하고 평가하지 않았다.
- 이해관계자들이 개발 영역에 들어갈 수 없었다.
- 개발자들.
- 제품 책임자와 모든 이해관계자.
- 제품 책임자와 개발자들.
- 스크럼 마스터, 프로젝트 관리자 및 개발자들.
- 스프린트 리뷰에서 제품 책임자에게 알리되, 데모 전에 알린다.
- 초과 작업을 줄 다른 스크럼 팀을 찾는다.
- 스프린트에서 가능한 한 빨리 제품 책임자와 협력하여 일부 작업이나 제품 백로그 항목을 제거한다.
- 완료의 정의를 줄이고 새로운 정의에 따라 모든 제품 백로그 항목을 "완료"한다.
- 사용자.
- 스크럼 마스터.
- 제품 책임자.
- 개발자들.
- 고객.
- 데일리 스크럼을 운영한다.
- 스프린트 백로그에서 개발자들의 작업 우선순위를 정한다.
- 무엇이 작업되고 있는지 경영진에게 업데이트한다.
- 현재 스프린트의 항목에 대한 개발자들의 질문에 답한다.
- 이해관계자들과 협력한다.
- 모두가 볼 수 있도록 스크럼 보드의 별도 목록에 올린다.
- 제품 백로그에 추가하고 예상 노력에 대해 제품 책임자에게 계속 알린다.
- 스프린트가 끝나기 전에 통합 및 회귀 테스트를 실행하고 다음 스프린트의 스프린트 백로그를 위해 열린 작업을 캡처한다.
- 매 스프린트마다 작업이 처리되도록 완료의 정의에 추가한다.
- 스프린트는 어떻게 진행되고 있습니까?
- 어제 개발자들이 스프린트 목표를 충족하는 데 도움이 되도록 무엇을 했습니까?
- 왜 늦었습니까?
- 오늘 개발자들이 스프린트 목표를 충족하는 데 도움이 되도록 무엇을 할 것입니까?
- 어제 프로젝트에 몇 시간을 소비했습니까?
- 내일 무엇을 작업할 것입니까?
- 나 또는 개발자들이 스프린트 목표를 충족하는 것을 방해하는 장애물이 보입니까?
- 그러한 활동은 없다. 다음 스프린트는 현재 스프린트 직후에 시작된다.
- 제품 백로그를 개선한다.
- 현재 스프린트의 증분에 대해 품질 보증 부서와 협력한다.
- 이해관계자들과 프로젝트 계획을 업데이트한다.
- 데일리 스크럼 동안.
- 팀 구성원이 더 많은 작업을 수용할 수 있을 때마다.
- 절대로. 전체 스크럼 팀이 매 스프린트마다 가치를 창출하는 책임이 있다.
- 스프린트 계획 이벤트에서.
- 각 주요 소프트웨어 엔지니어링 분야(예: QA, Dev, UX)에서 최소 한 명의 대표.
- 스프린트에서 완료된 증분을 제공하는 데 필요한 역량과 기술.
- 한 명의 리드 개발자와 8명 이하의 다른 구성원.
- 제품과 고객에 대해 더 많이 배움에 따라 성장하고 변화할 수 있다.
- 스크럼 팀이 제품의 설계 단계를 시작할 수 있도록 충분한 정보만 제공한다.
- 스크럼 팀이 완전한 프로젝트 계획을 개발하고 유지할 수 있는 모든 예측 가능한 작업과 요구사항을 포함한다.
- 변경 관리 프로세스를 따르기 위해 기준선이 설정된다.
- 이해관계자.
- 제품 책임자.
- 스크럼 팀.
- 스크럼 마스터.
- 개발자들.
- 팀 리더가 촉진한다.
- 아침에 가장 먼저 개최된다.
- 15분 이하의 기간이다.
- 자유롭고 대화를 촉진하도록 설계되었다.
- 스크럼 마스터가 팀 구성원들에게 세 가지 질문을 하는 것으로 구성된다.
- 위치와 시간이 일정하게 유지된다.
- 스프린트 0과 같은 것은 없다.
- 제품 백로그에 삽입될 요구사항을 수집, 유도 및 분석한다.
- 이해관계자에게 날짜, 예산 및 범위를 약속하기 위한 완전한 프로젝트 계획을 만든다.
- 완료된 예측을 제공할 수 있는 능력을 갖도록 개발자들의 구성을 결정한다.
- 첫 3개의 스프린트를 채우기에 충분한 제품 백로그 항목이 정제되었는지 확인한다.
- 제품, 제품 비전 및 스크럼 프레임워크의 규칙을 이해하고, 그룹은 스스로를 팀으로 나눈다.
- 매 스프린트마다 팀을 순환시켜 지식을 전파할 수 있으므로 실제로는 중요하지 않다.
- 할당 부서에 확인하여 이전에 함께 일한 사람을 확인하고 이들을 첫 번째 팀으로 만든다.
- 기술, 연공서열 및 경험 수준의 매트릭스를 만들어 사람들을 팀에 할당한다.
- 개발자들.
- 스크럼 마스터.
- 제품 책임자.
- 프로젝트 관리자.
- 합리적일 때.
- 스크럼 팀이 작업을 완료할 때.
- 제품에 결함이 없을 때마다.
- 예외 없이 매 스프린트 후에.
- 전문가가 보안 감사를 수행하고 보안 관련 제품 백로그 항목 목록을 만들 때까지 작업을 연기한다.
- 완료의 정의에 보안 우려 사항을 추가한다.
- 모든 보안 우려 사항을 구체적으로 해결하기 위한 스프린트를 추가한다.
- 관련 부서에 작업을 위임한다.
- 스크럼 팀이 각 우려 사항에 대한 제품 백로그 항목을 생성하도록 한다.
- 최소 7명.
- 9명.
- 10명 이하.
- 7명 플러스 또는 마이너스 3명.
- 스크럼 팀이 매 스프린트 끝까지 잠재적으로 릴리스 가능한 증분을 만들 수 있는 모든 기술을 가지고 있다.
- 몇몇 개발자가 페어 프로그래밍을 하고 테스트 주도 개발을 한다.
- 스크럼 팀 내에 갈등이 없다.
- 스크럼 팀의 모든 구성원이 모든 작업을 수행할 수 있다.
- 계산되고 추정될 때, 기술 부채의 총량은 제품 책임자가 증분을 릴리스할 수 있을 때까지 정확히 얼마나 걸리는지 보여준다.
- 시스템의 현재 상태, 특히 스프린트 끝에 증분이 릴리스 가능한 상태에 대한 잘못된 가정으로 이어진다.
- 개발이 진행되고 코드가 추가됨에 따라 시스템을 안정화하기가 더 어려워지며, 이는 향후 작업이 예측할 수 없는 방식으로 느려지는 결과를 낳는다.
- 기술 부채가 있는 한 개발자들이 스프린트에서 추가 기능 개발을 할 수 없으므로 제품 책임자의 투명성을 향상시킨다.
- 개발자들이 기꺼이 하고자 하는 모든 작업.
- 통합 준비 완료.
- 완료의 정의에서 남은 작업이 없음.
- 제품 책임자가 품질로 정의하는 것.
- 최종 사용자에게 릴리스할 준비가 된 소프트웨어를 만드는 모든 작업.
- 스프린트의 길이는 스프린트 사이에 수행되는 작업에 비례해야 한다.
- 개발 노력 전반에 걸쳐 일관된 길이의 스프린트를 갖는 것이 가장 좋다.
- 스프린트 길이는 스프린트 계획 중에 결정되며, 다가오는 스프린트에서 계획된 기능을 코딩하는 데 걸리는 시간을 유지해야 하지만 테스트 시간은 포함하지 않는다.
- 스프린트 길이는 스프린트 계획 중에 결정되며, 개발자들이 다가오는 스프린트에서 수행할 작업을 제공할 수 있을 만큼 충분히 길어야 한다.
- 모든 스프린트는 1개월 이하여야 한다.
- 사용자 스토리.
- 작업.
- 유즈 케이스.
- 테스트.
- 선택된 제품 백로그 항목의 분해인 위의 모든 것(또는 기타).
- 다른 역할 없음. 개발자들은 스크럼의 3가지 책임 중 하나이다.
- 테스터.
- 비즈니스 분석가.
- 소프트웨어 아키텍트.
- 스프린트 백로그가 처음 생성될 때 모든 작업이 식별된다.
- 진행 상황의 변화를 데일리 스크럼에서 이해할 수 있다.
- 제품 책임자가 모든 사람이 무엇을 작업하고 있는지 이해할 수 있다.
- 이해관계자가 작업 수준에서 진행 상황을 모니터링할 수 있다.
- 참.
- 거짓.
- 참.
- 거짓.
- 아무도 없다.
- 개발자들.
- 제품 책임자.
- 스크럼 마스터.
- 참.
- 거짓.
- 조직과 스크럼 팀.
- 제품 책임자.
- 개발자들.
- 개발자들.
- 스크럼 팀.
- 프로젝트.
- 제품 백로그.
- 경영진이 개발자들의 작업을 더 잘 지시할 수 있을 것이다.
- 타임박스를 유지하기 위해 추가 촉진이 필요할 수 있다.
- 개발자들이 데일리 스크럼에서 작업을 재계획할 시간이 줄어들 수 있다.
- 개발자들이 데일리 스크럼 동안 덜 개방적이고 투명할 수 있다.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 전문 테스터가 합류하도록 요청하고 나중에 스프린트에 도착하면 그들이 할 테스팅을 대기열에 넣어야 한다.
- 품질을 보장하기 위해 스프린트 후에 전담 테스트 팀이 테스트할 증분을 생산해야 한다.
- 이를 해결하기 위해 스크럼 마스터의 지원이 필요할 수 있는 장애물로 제기해야 한다.
- 품질은 개발자들의 책임이며 그들은 최선을 다해 스스로 테스팅을 수행해야 한다.
- 참.
- 거짓.
- 스프린트당 한 번 수행된다.
- 스크럼 이벤트이다.
- 제품 책임자의 관심사이다.
- 제품 책임자와 개발자들이 협력하는 지속적인 프로세스이다.
- 현재 시점까지 발생한 모든 작업이다.
- 지금까지 완료된 모든 작업으로, 버그가 없는 것이다.
- 스프린트에서 수행된 모든 작업이다.
- 스프린트 동안의 완료된 작업과 이전 스프린트에서 완료된 작업의 합이다.
- 팀은 작업을 완수하는 데 필요한 모든 역량을 가지고 있다.
- 팀은 기술의 좋은 조합을 가지고 있다.
- 팀의 모든 구성원이 제품을 만드는 데 필요한 모든 기술을 가지고 있다.
- 불완전한 제품 백로그 항목이 검토되고 제품 백로그의 맨 위로 반환되었다.
- 증분이 이해관계자에게 시연되었다.
- 다음 스프린트의 가능한 제품 백로그 항목을 정의하는 수정된 제품 백로그이다.
- 모든 제품 백로그 항목의 수락(또는 거부)이다.
- 아무 문제가 없다.
- 번업 차트는 전통적인 방법에서 사용되며 번다운 차트로 대체되어야 한다.
- 참.
- 거짓.
- 예산과 합의된 일정에 따라 제품을 제공한다.
- 스크럼이 이해되도록 보장한다.
- 모든 장애물, 블로커 및 문제를 해결한다.
- 개발자들의 작업을 조정한다.
- 1.
- 4.
- 2.
- 3.
- 프로젝트 관리자.
- 제품 책임자.
- 스크럼 마스터.
- 개발자들.
- 참.
- 거짓.
- 개발자들과 제품 책임자.
- 개발자들.
- 제품 책임자.
- 이해관계자.
- 전문가가 보안 감사를 수행하고 보안 관련 제품 백로그 항목 목록을 만들 수 있을 때까지 작업을 연기한다.
- 완료의 정의에 보안 문제를 추가한다.
- 모든 보안 문제를 구체적으로 해결하기 위한 스프린트를 추가한다.
- 관련 부서에 작업을 위임한다.
- 스크럼 팀이 각 문제에 대한 제품 백로그 항목을 만들도록 한다.
- 최소 7명.
- 9명.
- 10명 이하.
- 7명 플러스 마이너스 3명.
- 스크럼 팀은 모든 스프린트 끝에 잠재적으로 출시 가능한 증분을 만들 수 있는 모든 기술을 가지고 있다.
- 개발자 중 일부가 페어 프로그래밍과 테스트 주도 개발을 한다.
- 스크럼 팀 내에 갈등이 없다.
- 스크럼 팀의 모든 구성원이 모든 작업을 수행할 수 있다.
- 계산되고 추정될 때, 총 기술 부채 양은 제품 책임자가 증분을 출시할 수 있을 때까지 정확히 얼마나 걸리는지 보여준다.
- 시스템의 현재 상태, 특히 스프린트 끝에 증분이 출시 가능하다는 것에 대한 잘못된 가정으로 이어진다.
- 개발이 진행되고 코드가 추가됨에 따라 시스템이 안정화하기 더 어려워지며, 이로 인해 향후 작업이 예측할 수 없는 방식으로 느려진다.
- 개발자들이 기술 부채가 있는 한 스프린트에서 추가 기능 개발을 할 수 없으므로 제품 책임자에 대한 투명성을 향상시킨다.
- 개발자들이 기꺼이 하려는 모든 작업.
- 통합 준비 완료.
- 완료의 정의에서 남은 작업이 없음.
- 제품 책임자가 품질로 정의하는 것.
- 최종 사용자에게 출시할 준비가 된 소프트웨어를 만들기 위한 모든 작업.
- 스프린트 기간은 스프린트 사이에 수행되는 작업에 비례해야 한다.
- 개발 노력 전반에 걸쳐 일관된 길이의 스프린트를 갖는 것이 가장 좋다.
- 스프린트 길이는 스프린트 계획 중에 결정되며, 다가오는 스프린트에서 계획된 기능을 코딩하는 데 걸리는 시간을 유지해야 하지만 테스트 시간은 포함하지 않는다.
- 스프린트 길이는 스프린트 계획 중에 결정되며, 개발자가 다가오는 스프린트에서 완료할 작업을 제공할 수 있도록 충분히 길어야 한다.
- 모든 스프린트는 1개월 이하여야 한다.
- 사용자 스토리.
- 작업.
- 유스 케이스.
- 테스트.
- 선택된 제품 백로그 항목의 분해인 위의 것들(또는 다른 것들) 중 어떤 것이든.
- 다른 역할 없음. 개발자는 스크럼의 3가지 책임 중 하나이다.
- 테스터.
- 비즈니스 분석가.
- 소프트웨어 아키텍트.
- 스프린트 백로그가 처음 만들어질 때 모든 작업이 식별될 만큼 충분히 상세해야 한다.
- 일일 스크럼에서 진행 상황의 변화를 이해할 수 있을 만큼 충분히 상세해야 한다.
- 제품 책임자가 모든 사람이 무엇을 작업하고 있는지 이해할 수 있어야 한다.
- 이해관계자가 작업 수준에서 진행 상황을 모니터링할 수 있어야 한다.
- 참.
- 거짓.
- 참.
- 거짓.
- 아무도 없다.
- 개발자들.
- 제품 책임자.
- 스크럼 마스터.
- 참.
- 거짓.
- 조직과 스크럼 팀.
- 제품 책임자.
- 개발자들.
- 개발자들을 관리한다.
- 스크럼 팀을 관리한다.
- 프로젝트를 관리한다.
- 제품 백로그를 관리한다.
- 경영진은 개발자들의 작업을 더 잘 지시할 수 있을 것이다.
- 시간 제한을 지키기 위해 추가적인 촉진이 필요할 수 있다.
- 개발자들은 일일 스크럼에서 작업을 다시 계획할 시간이 줄어들 수 있다.
- 개발자들은 일일 스크럼 중에 덜 개방적이고 투명할 수 있다.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 그들과 합류할 전문 테스터를 요청하고 그들이 나중 스프린트에 도착했을 때 테스팅을 대기열에 넣어야 한다.
- 품질을 보장하기 위해 스프린트 후에 전담 테스트 팀이 테스트할 증분을 생산해야 한다.
- 이를 스크럼 마스터의 도움이 필요할 수 있는 장애물로 제기해야 한다.
- 품질은 개발자들의 책임이며 그들은 최선을 다해 스스로 테스팅을 수행해야 한다.
- 참.
- 거짓.
- 스프린트당 한 번 수행된다.
- 스크럼 이벤트이다.
- 제품 책임자의 관심사이다.
- 제품 책임자와 개발자들이 협업하는 지속적인 프로세스이다.
- 현재 시점까지 일어난 모든 작업이다.
- 버그가 없는 지금까지 완료된 모든 작업이다.
- 스프린트에서 수행된 모든 작업이다.
- 스프린트 동안 완료된 작업과 이전 스프린트에서 완료된 작업의 합이다.
- 팀은 작업을 수행하는 데 필요한 모든 역량을 가지고 있다.
- 팀은 기술의 좋은 조합을 가지고 있다.
- 팀의 모든 구성원이 제품을 만드는 데 필요한 모든 기술을 가지고 있다.
- 불완전한 제품 백로그 항목이 검토되고 제품 백로그 상단으로 반환되었다.
- 증분이 이해관계자에게 시연되었다.
- 다음 스프린트를 위한 가능한 제품 백로그 항목을 정의하는 수정된 제품 백로그이다.
- 모든 제품 백로그 항목의 수락(또는 거부)이다.
- 아무 문제 없다.
- 번업 차트는 전통적인 방법에서 사용되며 번다운 차트로 대체되어야 한다.
- 참.
- 거짓.
- 예산 내에서 합의된 일정대로 제품을 제공한다.
- 스크럼이 이해되도록 보장한다.
- 모든 장애물, 차단 및 문제를 해결한다.
- 개발자들의 작업을 조정한다.
- 1.
- 4.
- 2.
- 3.
- 프로젝트 관리자.
- 제품 책임자.
- 스크럼 마스터.
- 개발자들.
- 참.
- 거짓.
- 개발자들과 제품 책임자.
- 개발자들.
- 제품 책임자.
- 이해관계자.
- 하루 끝에 2차 일일 스크럼을 개최해야 한다.
- 스크럼 마스터는 개발자들이 15분 시간 제한을 존중해야 하는 이유를 이해하도록 돕고 필요에 따라 그렇게 할 수 있는 방법을 찾도록 도와야 한다.
- 개발자들은 15분이 끝나면 떠나야 한다.
- 개발자들은 일일 스크럼에서 필요한 추가 시간을 가져야 한다.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 참.
- 거짓.
- 스프린트 계획 - 8시간, 일일 스크럼 - 30분, 스프린트 리뷰 - 4시간, 스프린트 회고 - 3시간.
- 스프린트 계획 - 4시간, 일일 스크럼 - 15분, 스프린트 리뷰 - 4시간, 스프린트 회고 - 4시간.
- 스프린트 계획 - 4시간, 일일 스크럼 - 15분, 스프린트 리뷰 - 8시간, 스프린트 회고 - 4시간.
- 스프린트 계획 - 8시간, 일일 스크럼 - 15분, 스프린트 리뷰 - 4시간, 스프린트 회고 - 3시간.
- 참.
- 거짓.
- 비즈니스 분석가.
- 이해관계자.
- 여전히 책임이 있는 제품 책임자의 지원을 받는 개발자들.
- 제품 책임자.
- 완료된 작업과 거의 완료에 가까운 작업을 이해관계자에게 보여주는 것이다.
- 스프린트의 결과를 검사하고 향후 적응을 결정하는 것이다.
- 프로젝트의 상태를 검토하는 것이다.
- 스프린트 동안 완료되고 완료되지 않은 것을 확인하는 것이다.
- 스크럼 마스터.
- 개발자들.
- 제품 책임자.
- 이해관계자.
- 참.
- 거짓.
- 거짓 - 첫 번째 스프린트를 시작하기 전에 완전한 제품 백로그를 만들어야 한다.
- 참 - 제품이 존재하는 한 제품 백로그도 존재한다.
- 프로젝트 동안 불확실성의 양의 진화.
- 남은 작업량을 그려서 릴리스 진행 상황의 개요.
- 프로젝트 작업에 대한 종속성, 시작 시간 및 중지 시간.
- 스프린트 끝까지 남은 작업량.
- 개발자들에게 2개 팀으로 나누도록 지시한다.
- 아무것도 하지 않는다. 개발자들은 자체 문제를 해결해야 한다.
- 개발자들에게 2개 팀으로 나누도록 지시하고, 그들이 적절한 크기를 결정해야 한다.
- 증가된 팀 규모를 잠재적 문제로 제기하고 개발자들이 이에 대해 무엇을 할지 결정하도록 돕는다.
- 개발자들에게 비즈니스 요구사항과 목표 관점에서 이야기하도록 가르친다.
- 그들 간의 커뮤니케이션을 관찰하고 직접적인 협업을 촉진한다.
- 그들을 위한 중개자로 기능한다.
- 스프린트 동안 사용되는 기술에 대해 제품 책임자에게 가르친다.