로그인
로그인

PMP-16 스크럼 애자일 연습

이 마인드맵은, Xisai PMP 마인드맵을 기반으로, 확장하다. 이 장은 다음과 같습니다: PMP-16 스크럼 애자일 연습 동시에 관련 지식 포인트가 포함된 PMP 시험 문제도 있습니다. 지식포인트부터 해당 시험문제까지, 지식 포인트에 대한 이해와 기억을 깊게 할 수 있습니다!

2023-05-30 17:36:54에 편집됨

슈퍼직장인

최근 작업 더 많은 작업 보기>>

PMP-16 스크럼 애자일 연습

슈퍼직장인

최근 작업 더 많은 작업 보기>>

추천 사항
개요

PMP-19 민첩한 변화
- 2
슈퍼직장인
PMP-18 기타 애자일 관행
- 3
슈퍼직장인
민첩한 채택 및 실천 지원 프레임워크 템플릿
- 1
WSR38pNH
프로젝트 변경 통제 프로세스 평가 프레임워크 템플릿
- 2
WSR38pNH

PMP-16 스크럼 애자일 연습

스크럼 애자일 연습

세 개의 기둥

투명성, 검사, 적응

투명도

프로세스의 주요 링크는 관련 사람들에게 명백하며 동시에 이해관계자가 이러한 링크에 대해 통일된 이해를 갖도록 보장합니다.

보다

스크럼 사용자는 스크럼 아티팩트와 스프린트 목표 달성을 향한 진행 상황을 자주 검토해야 하며 검토 빈도는 다음에 맞게 조정되어야 합니다.

프로세스의 중대한 편차가 즉시 감지되는지 확인

적응하다

검사 결과 하나 이상의 측면이 허용 가능한 범위에서 벗어나 허용되지 않는 제품이 되는 것으로 밝혀지면 프로세스 또는 절차 내용을 조정해야 합니다.

추가 편차를 줄이려면 가능한 한 빨리 조정을 수행해야 합니다.

세 글자

1. 제품 소유자

1. 대변인, 조타수, 수락자

2. 도킹

고객과의 소통(이니시에이터), 니즈 수집, 상위 고객 육성(이니시에이터)

3. PO 책임

제품에 집중

제품 개발 방향 안내

4. 만들다

제품 백로그(또는 팀과 함께 생성)

5. 종류

비즈니스 가치를 기준으로 작업 우선순위 지정(팀원 위)

6. 모니터링 요구 사항

실제 상황에 따라 청소, 요구 사항 변경 및 정렬

7. 피드백에 참여하세요

프로젝트에 참여하고 자주 적시에 피드백 제공

"완성된 사용자 스토리" 식별

2. 애자일 코치

촉매제, 늙은 암탉, 방어자

핵심 포인트 1: 섬기는 리더십

역할 포지셔닝은 보조적이고, 하인과 같으며, 서비스 지향적입니다.

포인트 2: 프로모션 효과

팀 내외의 협력과 의사소통을 장려하고 다른 사람을 대신하여 결정을 내리지 않습니다.

포인트 3: 개입

1. 도움을 요청했을 때

2. 팀이 애자일을 위반하는 경우

3. Agile 도구를 사용하는 방법을 모릅니다.

4. 갈등을 스스로 해결하는 것은 효과적이지 않습니다.

핵심 포인트 4: 조직의 장애물 제거

제품 개발 방향과 개발 방법을 방해하지 않습니다.

핵심 포인트 5: 다른 사람들이 기여할 수 있는 길을 열어주세요

팀이 문제를 해결하고 민첩한 관행의 효과를 보장할 수 있도록 지원 및 지원을 제공합니다.

3. 자기 조직화 팀

1. 자기조직화, 일반화, 투명한 의사소통

자기 조직화 특성

2. 성과와 자기관리에 집중하라

자기 주장의 과제, 건설적인 대결, 민첩한 코칭에 대한 헌신 없음

3. 인원수

3-9명의 플레이어, 플러스 또는 마이너스 2개 변경

PO와 SM은 인원수에 포함되지 않습니다.

인원이 많을 경우 팀이 나누어질 수 있습니다.

4. 풀 타임

하나의 프로젝트에 집중하다

5. 전문가

병목 현상을 줄이고, 효율성을 개선하고, 사일로/사일로를 줄이는 데 도움이 됩니다.

6. 팀원 교체

일반적으로 팀이 구성된 후에는 직원을 임의로 변경하거나 추가하거나 제거하지 않습니다.

교체가 필요한 경우, 더 나은 시간은 두 번의 반복 사이입니다.

7. 오피스 스타일

중앙 집중식 사무실 선호

정의: 팀이 함께 일하는 지리적 위치를 나타냅니다.

가상오피스와는 다르게

이점

대면 커뮤니케이션

침투적 의사소통 촉진

정의: 함께 일하는 팀원 간의 정보 흐름 무의식적으로 공유

정보는 무의식적으로 공유됩니다.

일반적으로 직접적인 주의 없이 정보를 얻음으로써 정보 전송 비용을 줄이고 미묘하게 통신합니다.

글로벌, 분산된 팀

1. 가상 수단, 어항 창 및 원격 페어링을 사용할 수 있습니다.

1. 어항 창문

팀을 여러 위치로 이동함으로써 장기 화상회의 링크 구축 및 어항창 생성

매일 작업을 시작할 때 링크를 열고 하루가 끝나면 링크를 닫습니다.

2. 원격 페어링

음성 및 비디오 링크를 포함한 화면을 공유하기 위해 가상 회의 도구를 사용하여 원격 페어링을 설정합니다.

이는 모두 분산된 팀에서 사용할 수 있는 커뮤니케이션 기술 및 방법입니다.

2. 의사소통을 돕기 위해 온라인 협업 도구(비디오, 광고판)를 사용하십시오.

CAVES 및 공공 장소에 대한 공통 원칙

동굴

거래를 위해 예약된 개인 공간으로 격리되고 조용한 환경이 필요합니다.

공용 공간공통

공공영역은 소통과 협업이 자주 일어나는 공공공간이다.

8. 팀빌딩의 5단계

형태

팀원의 역할과 책임을 명확히 한다.

지령

충격

갈등을 낳다

영향/코치 유형

사양

문제를 해결하고 협력하려고 노력하십시오.

참여

성숙한

성숙한 단위처럼 질서있게 운영하고 효율적으로 업무를 완수한다.

권한 부여

해산

프로젝트가 종료되고 팀이 해산됩니다.

터크먼의 사다리 이론

1. 형성 단계

리소스를 늘리고, 새로운 구성원이 팀에 합류하고, 서로를 알아가세요.

2. 충격 단계

서로 다른(반대되는) 의견, 갈등, 분쟁 및 불일치

3. 표준화 단계

함께 일하고, 업무 요구에 따라 일하는 습관과 행동을 조정하고, 신뢰를 배우기 시작하세요.

4. 성숙한 단계

효율적으로 협력하고 문제를 해결하세요.

5. 용해 단계

팀을 해체하고 사람들을 석방하라

9. 제너럴리스트 전문가를 양성하는 방법, 제너럴리스트 전문가가 되는 방법

1. 지식 공유

2. 크로스 트레이닝, 스킬 트레이닝

3. 페어 프로그래밍

4. 요약

성공적인 애자일 팀의 역할

제품 소유자

1. 제품 개발 방향 안내

2. 제품 백로그 생성 및 유지 관리

3. 비즈니스 가치에 따라 작업 순서 지정

4. 피드백을 제공하다

팀 진행자

1. 민첩한 프로세스를 준수하는지 확인

2. 팀을 지도하고 코치하며 팀의 장애물을 제거합니다.

다기능 팀 구성원

1. 필요한 모든 기술을 갖춘 일반 전문가

2. 잠재적으로 출시 가능한 제품을 정기적으로 제공

3. 핵심 책임

단시간에 작업을 전달

세 가지 유물

1. 제품 백로그

딥 모델

제품 백로그 정리

반복 0

제품 백로그에 대한 준비 정의(DoR) 생성

준비의 정의

사용자 요구사항을 중심으로 한 팀의 체크리스트입니다. 여기에는 팀이 시작하는 데 필요한 모든 정보가 포함됩니다.

체크리스트

인용 품질 관리

체크리스트

다음 스프린트에서 사용자 스토리를 백로그에서 개발로 이동하기 위해 충족해야 하는 조건인 Ready의 정의

준비가 정의된 상태의 사용자 스토리 스토리가 즉시 실행 가능해야 함을 의미합니다.

그래서 준비된 상태 이는 세분성 세분화가 적절하다는 것을 의미합니다.

DoR 및 DoD

DoR(준비의 정의)

준비의 정의

정의

작업이나 기능을 시작하기 위해 충족해야 하는 일련의 조건이나 기준을 나타냅니다.

효과

DoR은 구현이 시작되기 전에 팀이 작업 또는 기능에 대해 명확하게 이해하고 합의하도록 돕습니다.

DoR에는 다음이 포함될 수 있습니다.

1. 업무 또는 기능

설명이 명확하고 구체적이며 상세합니다.

2. 타당성 조사 및 위험 평가

완전한

3. 필요한 자원(인력, 시간, 예산 등)

할당된

4. 프로젝트 요구 사항, 목표 및 승인 기준

명확히하다

5. 모든 관련 이해관계자가 업무 및 기능에 대해 논의했습니다.

합의에 도달

DoD(완료의 정의)

완료의 정의

정의

작업이나 기능이 완료된 것으로 간주되기 전에 충족해야 하는 일련의 조건이나 기준을 나타냅니다.

효과

DoD는 팀이 예상되는 품질과 표준에 따라 작업이나 기능을 완료하도록 돕습니다.

DoD에는 다음이 포함될 수 있습니다.

1. 코드가 작성되었으며 코드 리뷰를 통과했습니다.

2. 기능이 모든 예정된 테스트를 통과했습니다.

단위 테스트

통합 테스트

성능 시험

3. 문서가 완성되고 업데이트되었습니다.

사용자 매뉴얼

기술 문서

4. 작업 또는 기능과 관련된 문제 및 결함

해결됨

자연

모든 작업의 정렬된 목록, 가치 지향

종류

1. 가치 리스크를 고려하세요

지연 비용: 작업 지연의 반대 가치를 이해하고, 팀이 먼저 완료할 작업을 결정하는 데 도움이 될 수 있습니다.

2. 비용, 종속성, 정치 등도 고려될 수 있습니다.

개선 및 빗질

진보적인 디테일

콘텐츠

기능적 내용

기능적이지 않은 콘텐츠

기술 부채, 위험 대응, 운영 및 유지 관리 작업 등은 비기능 사용자 스토리로 백로그에 포함됩니다.

성능 요건

제품의 주요 작동 및 성능 요구 사항

우주 왕복선 무게

웹사이트 로드

성능 요구 사항은 단일 기능에 국한되지 않으므로 단일 기능의 승인 테스트에 포함되어서는 안 됩니다.

성능 요구사항에는 제품이 성능 지표를 통과하는지 확인하기 위한 전반적인 승인 테스트가 있어야 합니다.

위험

위험은 발생할 경우 프로젝트에 영향을 미칠 수 있는 불확실한 사건입니다.

Agile에서 부정적인 위험은 반가치와 동일합니다.

가치는 돈을 절약하는 것이고, 위험은 돈을 쓰는 것이다

위험이 발생하면 이를 처리하는 데 시간과 자원을 투자해야 합니다.

이는 또한 프로젝트의 이익을 위협할 것입니다.

기민한

이는 비즈니스 가치와 위험 동인의 조합입니다.

가능한 한 빨리 위험 회피 및 이전 조치를 계획하십시오.

민첩한 프로젝트는 초기 단계에서 계속해서 반복하고 높은 위험을 처리합니다.

높은 위험을 조기에 노출시키십시오

이러한 방식으로 위험 대응 비용이 상대적으로 낮아지고, 이후 단계에서 비효율적인 작업 입력이 발생할 가능성이 줄어듭니다.

소규모 위험 기반 실험

스파이크(Spike)라고 불리는 리스크 관리 기술이다.

책임이 있는

주로 PO에서 생성하고 유지 관리함

심층 모델

상세한, 적절한, 추정 가능한, 긴급한, 우선순위가 지정된

나뉘다

너무 큰 사용자 스토리는 분할해야 함

반복 중에 완료될 수 있는지 확인하기 위해

다른

기능 중심 개발 모델(FDD)

1. 이 모델에는 제품 소유자 역할이 없습니다.

2. FDD의 주요 인물

1. 주요 개발자

2. 클래스 소유자

3. 기능팀

2. 할 일 목록을 반복하세요

자연

이 반복에서 완료해야 하는 목표와 작업 항목

특정 작업을 명확히 하세요.

팀에서 자체적으로 논의하고 접수합니다.

시간

반복 기획 회의에서 생성됨

원칙적으로

반복 프로세스 중에 반복 할 일 목록은 일반적으로 마음대로 변경되지 않습니다.

먼저 반복 작업이 성공적으로 완료되었는지 확인합니다.

조정

사용자 스토리가 이미 명백히 유효하지 않은 경우

또는 현재 상황이 긴급하여 이를 처리하지 못하면 전체 반복이 위태로워질 수 있습니다.

반복 백로그를 조정할 수 있습니다.

3. 배송 가능한 제품 증가

배송 가능한 제품 증분은 반복에서 실제로 완료된 사용자 스토리입니다.

잠재적인 패키지 제품 기능 증가

배송 가능한 제품 증가분, 배송된 값

변화에 더 효과적으로 대응할 수 있도록 가능한 한 빨리 가치를 제공하세요.

다섯 가지 이벤트

회의

1. 반복과 스프린트

반복 시간 상자

팀 역량 및 프로젝트 특성과 일치해야 함

한번 결정되면 마음대로 조정되지 않습니다.

요구 사항이 자주 변경되고 고객이 더 높은 검토 빈도를 요구하는 경우

전체 반복 시간 상자를 단축할 수 있습니다.

8843

2. 반복 및 스프린트 계획 회의

PDCA-P

무엇을 합니까

스프린트 계획 회의

1. 반복 작업과 목표를 결정하는 것입니다.

반복 대상

PO가 스프린트 동안 달성하고 달성하고자 하는 것

팀은 완료를 위해 노력할 수 있습니다.

반복 백로그(스프린트 백로그)

2. 어떻게 이루어지는지 토론해 보세요

3. 출력 반복 백로그

4. 회의의 기본 내용

1. 일반적으로 PO에서는 제품 백로그(product backlog)를 설명하고 스토리를 구체화하며, 팀에서는 이를 평가하고 반복 백로그(sprint backlog)를 제시합니다.

2. 사용자 스토리를 작업으로 분할하여 시간 추정

3. 팀원 각자의 도메인 업무(과제)

4. 스프린트 백로그 업데이트

누가 참여하는가

1. PO, 개발팀, 애자일 코치

PO는 제품 백로그를 설명하고 스토리를 다듬습니다.

반복 백로그를 평가하고 도출하는 팀

2. 관련 당사자가 팀 계획 및 수요 목표 변경을 이해하고 싶은 경우 스프린트 계획 회의에 초대될 수 있음

관계자는 이해할 수 있다

팀 상황

상품상황

얼마나 오래

타임박스 2X

1개월 반복 주기, 스프린트 계획 회의 시간 상자는 월 8시간입니다.

2시간/주

주요 요점

3. 일일 스탠드업 미팅

PDCA-D

무엇을 합니까

1. 목적

프로젝트 상태 정보 이해(진행 상황 추적)

팀의 개별 상태를 이해하세요.

합의 정보

정보 격차 해소

문제, 장애물, 위험 식별

2. 일일 스탠드업 회의는 애자일 원칙을 뒷받침하는 가장 중요한 초석 중 하나이며 마음대로 취소할 수 없습니다.

정보를 동기화하여 업무 가시성 및 정보 공유 제공

키워드: 반복 중에 중단되지 않음

여는 방법

1. 일일 스탠드업 회의는 팀이 직접 주최하고 토론을 통해 시간과 장소를 결정합니다.

2. 회의에는 개발팀과 애자일 코치가 모두 참석하며, 상황에 따라 PO가 초청되며, 관련 당사자도 초청됩니다.

개발팀과 애자일 코치들이 모두 회의에 참석했습니다.

3. 타임박스는 보통 15분

기타 사유(문화적 환경 등)가 회의의 효율성에 영향을 미치므로 시간을 적절하게 연장할 수 있으나 일반적으로 20분을 넘지 않습니다.

인원이 너무 많으면 팀을 나눠서 하는 것도 고려해 보세요

4. 모두가 차례대로 질문에 답합니다.

1. 지난 스탠드업 미팅 이후 나는 무엇을 성취했는가?

2. 지금부터 다음 스탠드업까지 무엇을 달성할 계획인가요?

3. 나의 장벽(위험 또는 문제)은 무엇입니까?

방송국 회의는 정보를 동기화하고 문제를 제기할 뿐 해결하지는 않습니다.

문제 해결은 일일 스탠드업 회의 후 개별적으로 조정 가능

안티패턴

1. 현황보고회가 아님

2. 문제를 발견하기만 하고 해결하지는 않는다

스탠드업 미팅 후 특별토론을 통해 문제 해결 가능

현재 반복 목표에 영향을 미치지 않고 전체 프로세스와 관련된 경우 회의를 검토하여 개선 사항을 논의할 수 있습니다.

테스트 포인트

4. 반복검토회의

PDCA-C

무엇을 합니까

반복 검토 회의에서: 1.PO 식별 "완료", 2. 완성된 사용자 스토리를 고객이 수락하고 피드백을 제공합니다.

스프린트 반복 중에 달성된 내용을 설명하세요.

완성된 작품을 보여주세요

원칙적으로 제품 소유자가 참석해야 합니다.

논의하다

다음번엔 기대됨

변화의 크기

유행 분석

완료되지 않았거나 승인되지 않은 사용자 스토리는 제품 백로그로 돌아가기 전에 협상하고 전달해야 합니다.

누가 참여하는가

제품 소유자, 주요 고객, 애자일 코치, 개발팀

얼마나 오래

1개월 반복 주기, 회의 시간 상자는 4시간입니다.

4시간/월

1시간/주

반복 검토 회의에서는 주로 작업 완료에 대해 설명하고 "완료" 기능을 시연합니다.

테스트 포인트

5. 반복검토회의

PDCA-A

무엇을 합니까

자신을 성찰하고 그 과정에 주의를 기울이십시오. 대책의 실효성 검토, 원인파악 및 개선방안 제시

잘 된 점과 잠재적인 개선이 필요한 부분에 대해 토론하세요.

팀이 프로세스를 조정하는 데 도움이 되는 경험과 교훈을 요약합니다.

목적

1. 이전 스프린트의 사람, 관계, 프로세스, 도구의 상황을 검토합니다.

2. 잘 진행된 주요 영역과 잠재적으로 개선이 필요한 영역을 식별하고 순위를 매깁니다.

3. 스크럼 팀의 작업 방식을 개선하기 위한 계획 개발

누가 참여하는가

1. 일반적으로 팀 구성원, 민첩한 코치

민첩한 코치가 회의를 보장합니다.

긍정적이고 생산적이다

2. PO는 상황에 따라 다름

3. 이해관계자들이 참여하도록 초대됩니다.

얼마나 오래

Iteration 검토 후 및 다음 Iteration 계획 전

한 달 반복 주기, 일반적으로 3시간

스크럼 5가지 값

헌신, 집중, 개방성, 존중, 용기

약속하다

약속

목표에 헌신하려는 의지

집중하다

약속한 일에 전념하십시오.

1. 팀원은 정규직으로 이 프로젝트에 집중하고 있습니다.

2. 팀원이 프로젝트에 집중할 수 있도록 장애물을 제거하세요.

3. 이번 반복에서는 반복 할 일 목록에 중점을 두고 필요한 경우가 아니면 교체하지 마세요.

열려 있는

개방 상태

팀 내의 모든 정보는 누구에게나 공개됩니다.

존경

모든 사람은 자신만의 고유한 가치관과 경험을 가지고 있습니다.

용기

감히 약속하고, 약속을 이행하고, 감히 거절하십시오

다른

스크럼은 제품 개발 관리를 위한 단일 팀 프로세스 프레임워크입니다.

프레임워크에는 스크럼 역할, 이벤트, 아티팩트 및 규칙이 포함되어 있으며 반복적 접근 방식을 사용하여 작업 결과물을 제공합니다.

스크럼은 1개월 이하의 기간 동안 실행됩니다.