수동 소득 아이디어 2023
스프린트 회고전이란 무엇입니까?
회고는 애자일 소프트웨어 개발에서 스크럼 프레임워크의 검사 및 적응 메커니즘의 기초를 형성합니다. 스프린트 회고는 마지막 스프린트의 프로세스를 살펴보고 스크럼 팀이 프로세스, 즉 제품, 백로그(개념) 및 제공 가능한 소프트웨어 간의 실제 작업을 분석하고 경험에서 배울 수 있도록 하는 데 사용됩니다. 다른 스크럼 이벤트(예: 스프린트 계획)와 마찬가지로 “타임박스” 이벤트이며 일반적으로 2주 스프린트 동안 2시간 동안 지속됩니다. 스크럼 팀이 학습한 내용을 기반으로 개선하기 위해 다음 스프린트에서 구현하는 구체적인 조치를 식별하는 역할을 합니다. 스프린트 회고의 결과는 프로세스 개선입니다.
따라서 회고는 팀이 더 나아지고 협력을 최적화하는 데 도움이 됩니다. 당신은 변화의 촉매제입니다. 그들은 개선으로 이어지는 조치를 만들어 스크럼 팀에서 변경 프로세스를 추진합니다. 프로세스를 보면 팀 자체에 영향을 미치는 문제가 먼저 해결됩니다. 그러나 중기적으로는 전체 조직에 영향을 미치는 팀 간 변경 프로세스 및 변경도 시작됩니다.
따라서 스프린트 회고 회의는 스크럼의 중심 이벤트 중 하나이며 투명성, 검토 및 조정(3가지 스크럼 기둥)을 통해 개발 프로세스의 지속적인 개선에 초점을 맞추는 반면, 스프린트 검토는 제품 개선을 목표로 합니다.
반복적이고 증분적인 접근 방식을 통해 Scrum은 두 가지 수준에서 지속적인 개선 프로세스(CIP)를 설정합니다. 개발될 제품 자체(즉, WHAT 관련)와 개발 프로세스(HOW)에 대한 것입니다.
Sprint Retrospective의 목적은 개발 프로세스에서 품질과 효율성을 높이는 방법을 식별하고 계획하는 것입니다. 따라서 스크럼 프레임워크는 팀이 스크럼 프로세스를 지속적으로 개선하도록 지원합니다.
스프린트 회고전에는 무엇이 포함되나요?
각 스프린트가 끝날 때 스크럼 팀은 개인, 상호 작용, 프로세스, 도구 및 완료의 정의 측면에서 스프린트가 어떻게 진행되었는지 검토합니다.
효율성을 개선하는 데 가장 유용한 변경 사항을 식별하고 제품 백로그에 포함하거나 적시에 구현하기 위해 스프린트 백로그에 포함하여 구현을 자율적으로 결정합니다.
제품의 지속적인 개선과 귀중한 소프트웨어의 조기 및 지속적인 제공을 통해 사용자를 만족시키는 원칙은 개발 프로세스의 지속적인 개선 없이는 생각할 수 없습니다.
핵심은 팀 수준에서 학습하는 것입니다. 회고는 이러한 학습 과정을 적극적으로 지원합니다.
좋은 회고를 수행하는 스크럼 팀은 단 몇 번의 스프린트 과정에서 매우 크게 향상되어 많은 영역에서 볼 수 있습니다.
- 생산성 향상: 팀은 프로세스에서 기능 장애 요소와 병목 현상을 식별하고 회고를 통해 제거합니다.
- 향상된 품질: 팀은 소모품의 내부 및 외부 품질이 자신과 고객의 기대를 충족하지 못하는 이유를 논의하고 분석합니다. 회고는 그들이 품질을 개선하고 미래의 기술적 부채를 피하기 위한 올바른 조치를 취하는 데 도움이 됩니다.
- 실력 향상: 스크럼 팀은 지속적으로 성과와 기술을 개선하도록 권장됩니다. 회고는 팀의 집단적 창의성을 통해 약점을 지적하고 더 나은 솔루션을 찾음으로써 그들을 지원합니다.
- 향상된 협업: 회고는 스크럼 팀과 그 이상에서 협업을 개선하여 보다 효율적이고 생산적으로 만드는 데 도움이 됩니다. 연습은 특히 이 분야에 큰 잠재력이 있음을 보여줍니다.
- 처리량 증가: 정기적인 회고를 수행하는 스크럼 팀은 더 효율적일 뿐만 아니라 더 효과적입니다. 이것은 “처리량”, 즉 새로운 요구 사항을 실행 가능한 소프트웨어로 변환하는 팀의 능력을 증가시킵니다.
이러한 명백한 결과 외에도 효과적인 회고를 수행하는 스크럼 팀이 작업을 더 즐기고 동기 부여 수준이 훨씬 더 높다는 것을 보여줍니다. 그럼에도 불구하고 “바로 가기”와 최적이 아닌 구현이 실제로 관찰될 수 있습니다.
Sprint Retrospective에서 발생하는 4가지 일반적인 실수
1. 선택적 이벤트인 스프린트 회고전
스크럼 팀 또는 이해 관계자는 회고의 가치를 충분히 이해하고 내면화하지 않았습니다. 예를 들어 스프린트 목표를 달성하는 데 더 많은 시간을 갖기 위해 개별 사례에서 회고가 생략되거나 연기됩니다. 때로는 상당히 단축되기도 합니다. 이렇게 가정된 지름길은 위험한 줄타기입니다. 왜냐하면 일단 받아들여지면 회고는 일반적으로 종종 의문을 갖기 때문입니다.
개발할 제품의 가치에 기여하는 의사 소통, 최소한의 도구 또는 도구 사용 측면에서 팀에서 개선 할 것이 없다는 것은 대담하고 완전히 비현실적인 논문입니다. 또한 이러한 행동은 경험주의 및 지속적인 개선과 같은 기본 원칙과 완전히 접촉합니다.
따라서 회고의 가치가 조직에서 충분히 이해되고 있는지 확인하고 수행할 공간과 시간을 만드십시오.
2. 스프린트마다 성촉의 날
Sprint Retrospective는 무엇이 잘되고 무엇이 잘못되었는지에 대한 사실 기반 분석을 위한 이벤트일 뿐만 아니라 집단적 창의성과 상호 영감을 위한 공간이기도 합니다. 개선방안을 마련하는 것입니다. 그러나 이것은 또한 관행, 구조 또는 위치가 영구적으로 동일하게 유지되어서는 안 된다는 것을 의미합니다. 형식의 변화를 통해 자극을 만드는 것이 중요하다. 그렇지 않으면 팀 구성원 간의 수동성이 증가하거나 심지어 지루함을 느낄 위험이 있습니다. 결국 회고전을 시간낭비로 보는 결과를 낳는다.
3. 심리적 안정감 부족
회고는 각 팀원이 두려움과 외부 영향 없이 문제를 제기하고 적절한 존중을 가지고 피드백을 제공할 수 있는 안전한 장소여야 합니다. 팀원 개개인이 대화를 주도하여 다른 사람들을 위협한다면 회고는 심리적 안정을 제공하지 못할 것입니다. 이로 인해 개별 참가자가 회고에서 물러나 수동적이 되는 경우가 많습니다.
스크럼 팀 구성원 간에 계층 구조가 있을 때 특히 까다로워집니다. 예를 들어, 같은 스크럼 팀의 시니어 개발자나 스크럼 팀 외부의 상사에게 보고하는 주니어 개발자는 회고전으로 가는 길을 주장합니다. 회고는 지속적인 직원 평가 이벤트가 아닙니다. 이러한 시나리오에서 스크럼 마스터는 특히 어려움을 겪습니다.
최악의 경우 회고전은 상호 손가락질과 손가락질로 변질됩니다. 더군다나 팀원 개개인이 레트로에 대한 정보를 제공하거나 외부인에게 프로토콜을 공개한다면 레트로는 심리적 안전지대가 될 수 없다. Vegas 규칙이 여기에 적용됩니다. 말한 내용은 회고전 참가자 사이에 있습니다. 결과 및 계획된 개선 조치는 제품 백로그를 통해 투명하게 공개됩니다.
모든 사람이 자신의 생각을 자유롭게 표현할 기회를 갖고 자신의 의견을 경청하도록 합니다. 존중하는 협력이 있고 “비난 게임”이 없으며 팀의 자율성이 보존되는 것도 중요합니다.
4. 적응 없음, 구현 없음
팀은 이전 회고에서 계획된 개선 상태를 검토하지 않습니다. 가치 있는 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키기 위해 팀이 자율적인 결정을 내린다고 주장하는 경우 이는 상대방의 그에 상응하는 자기 헌신과 개인적 책임을 의미합니다. 팀이 계획된 개선 활동을 따르지 않아 “검사”가 수행되지 않으면 CIP 프로세스 수립에 실패한 것입니다.
또 다른 시나리오는 개발 프로세스에서 개선 가능성이 확인되었지만 구현 팀의 어느 누구도 지속적인 문제에 대해 책임이 있다고 보고하지 않은 경우입니다. 일반적으로 이로 인해 다음 구현이 부적절하거나 완전히 무시됩니다. 이러한 작업은 스크럼과 “애자일”이 실제로 작동하지 않는다는 인식에 기여합니다.
따라서 회고의 맥락에서도 지속적인 개선의 기본 원칙으로 지름길을 택하지 않도록 하십시오. 이런 맥락에서 우리는 슈하리 콘셉트를 언급한다.
