스크럼에 대한 설명 및 시작하는 방법

스크럼은 애자일의 핵심 원칙인 지속적 개선에 중점을 두기 때문에 스크럼과 애자일이 동일하게 여겨지는 경우가 많습니다. 그러나 스크럼은 작업 수행을 위한 프레임워크이며, 애자일은 철학입니다. 애자일 철학은 빈번한 소규모 릴리스를 통한 지속적이고 점진적인 개선에 중점을 두고 있습니다. 고객에게 가치를 제공하는 방식에 대한 팀의 사고방식을 바꾸는 데에는 팀 전체의 노력이 필요하므로, 단순히 '애자일로 전환'할 수는 없습니다. 하지만 스크럼과 같은 프레임워크를 사용하면 그러한 사고방식을 갖추고 일상적인 커뮤니케이션과 작업에 애자일 원칙을 실현하는 연습을 할 수 있습니다.

애자일 및 스크럼 정의의 차이는 스크럼 가이드와 애자일 매니페스토에서 확인할 수 있습니다. 애자일 매니페스토는 다음의 네 가지 가치를 간략하게 설명합니다.

• 프로세스 및 도구보다 개인 및 상호 작용
• 종합적 설명서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협업 중시
• 계획을 따르기보다는 변화에 대응

스크럼의 정의는 경험주의 및 린 사고를 기반으로 합니다. 경험주의는 경험을 통해 지식을 얻고 관찰한 것을 기반으로 결정을 내리는 것입니다. 린 사고는 불필요한 것을 줄이고 필수 사항에 집중하는 것을 말합니다. 스크럼 프레임워크는 체험을 중시하며, 지속적으로 학습하고 변동 요인을 조정하는 것을 기반으로 합니다. 또한 프로젝트가 시작될 때 팀이 모든 내용을 알고 있지 않으며 경험을 통해 진화해 나간다고 말합니다. 스크럼은 팀이 변화하는 조건과 사용자 요구 사항에 자연스럽게 적응할 수 있도록 구성되었으며, 팀이 지속해서 학습하고 개선할 수 있도록 프로세스에 대해 우선 순위를 재지정하고 릴리스 주기가 짧습니다.

스크럼은 구조화되어 있지만 완전히 경직된 것은 아닙니다. 스크럼의 실행은 모든 조직의 요구에 맞게 사용자 지정할 수 있습니다. 스크럼 팀이 성공하기 위해 정확히 어떻게 해야 하는지에 대해서는 여러 이론이 있습니다. 하지만 Atlassian에서 10년 넘게 애자일 팀이 작업을 완료하도록 지원한 후에 어떤 프레임워크를 선택하든 그 중심에는 명확한 의사 소통, 투명성 및 지속적인 개선에 대한 노력이 있어야 한다는 점을 배웠습니다. 나머지는 사용자에게 달려 있습니다.

• 제품 백로그란 제품 소유자 또는 제품 관리자가 유지 관리해야 하는 기본 작업의 목록으로, 스프린트 백로그에 입력되는 기능, 요구 사항, 개선 사항 및 수정 사항의 동적인 목록입니다. 기본적으로 팀의 '해야 할 일' 목록입니다. 더 알게 되거나 시장이 변화함에 따라 어떤 항목이 더 이상 관련성이 없어지거나 문제가 다른 방식으로 해결될 수 있으므로, 제품 소유자는 제품 백로그를 지속적으로 다시 검토하고 우선 순위를 다시 지정하며 유지 관리합니다.
• 스프린트 백로그는 현재 스프린트 주기에서 구현하기 위해 개발 팀이 선택한 항목, 사용자 스토리 또는 버그 수정의 목록입니다. 각 스프린트 전, 팀은 스프린트 계획 회의(이 기사의 뒷부분에서 다룰 예정) 중에 제품 백로그에서 스프린트에 대해 어떤 항목에 대해 작업할 것인지 선택합니다. 스프린트 백로그는 유연할 수 있으며 스프린트 중에 변경 가능하지만, 기본 스프린트 목표(팀이 현재 스프린트에서 달성하고자 하는 것)는 바뀔 수 없습니다.
• 증분(또는 스프린트 목표)은 스프린트에서 사용할 수 있는 최종 제품입니다. Atlassian에서는 일반적으로 팀은 스프린트에서 완료된 내용을 보여주는 스프린트 종료 데모 중에 '증분'을 시연합니다. 증분은 '완료'에 대한 팀의 정의, 마일스톤, 스프린트 목표 또는 정식 버전 또는 출시된 에픽이라고도 자주 불리기 때문에, 실제로 '증분'이라는 단어를 듣게 되지는 않을 수도 있습니다. 팀에서 '완료'를 정의하는 방법 및 스프린트 목표를 정의하는 방법에 따라 달라집니다. 예를 들어, 어떤 팀은 모든 스프린트가 끝날 때 고객에게 무언가를 릴리스하기로 선택합니다. 따라서 '완료'에 대한 이 팀의 정의는 '출시'일 것입니다. 그러나 다른 유형의 팀에서는 이러한 정의가 현실적이지 않을 수 있습니다. 한 분기에 한 번만 고객에게 출시할 수 있는 서버 기반 제품에 대해 작업하는 경우를 가정해 보겠습니다. 그러한 경우에도 2주 스프린트에서 작업하도록 선택할 수 있지만, '완료'에 대한 정의는 함께 출시하려는 더 큰 버전의 일부를 마무리하는 것일 수 있습니다. 물론 소프트웨어를 릴리스하는 데 시간이 오래 걸릴수록 소프트웨어가 결과를 달성하지 못할 위험이 높아집니다.

아티팩트 내에서도 팀에서 정의하기로 선택할 수 있는 다양한 변형이 있습니다. 따라서 아티팩트를 유지하는 방법을 진화시키는 데 개방적인 태도를 유지하는 것이 중요합니다. '완료'에 대한 정의가 팀에 과도한 스트레스를 줄 수 있으며, 다시 돌아가서 새로운 정의를 선택해야 할 수도 있습니다.

다음은 스크럼 팀이 참여할 수 있는 모든 주요 세레모니의 목록입니다.

1. 백로그 구성: 백로그 그루밍이라고도 하는 이 이벤트는 제품 소유자의 책임입니다. 제품 소유자의 주요 업무는 제품 비전을 향해 제품을 유도하고 시장과 고객에 대한 최신 정보를 파악하는 것입니다. 그렇게 해서 제품 소유자는 사용자 및 개발 팀의 피드백을 사용하여 이 목록을 유지하여 이 목록을 정돈된 상태로 유지하고 언제든지 작업할 준비가 되도록 돕습니다. 양호한 백로그 유지에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

2. 스프린트 계획: 이 회의에서 전체 개발 팀이 현재 스프린트 중에 수행할 작업(범위)을 계획합니다. 이 회의는 스크럼 마스터가 주도하며 팀이 스프린트 목표를 결정합니다. 그런 다음 제품 백로그에서 특정 사용자 스토리를 스프린트에 추가합니다. 이 스토리는 항상 목표와 정렬되며 스프린트 중에 구현할 수 있도록 스크럼 팀의 합의를 거칩니다.
   
   계획 회의를 마칠 때 모든 스크럼 멤버는 스프린트에서 제공할 수 있는 사항과 증분을 달성하는 방법에 대해 명확히 알고 있어야 합니다.

3. 스프린트: 스프린트는 스크럼 팀이 함께 작업하여 증분을 완료하는 실제 기간입니다. 스프린트에서 일반적인 기간은 2주지만, 어떤 팀은 범위를 지정하는 데 1주일, 또는 중요한 증분을 제공하는 데 1달이 더 쉽다고 느낄 수 있습니다. Scrum.org의 Dave West는 작업이 복잡하고 알 수 없는 부분이 많을수록 스프린트가 짧아야 한다고 조언합니다. 하지만 실제로 이는 팀의 선택에 달려 있으며, 잘 맞지 않는다면 바꿔야 합니다. 이 기간 동안 필요에 따라 제품 소유자와 개발 팀 간에 범위를 다시 논의할 수 있습니다. 이것이 스크럼의 경험적 성격을 나타내는 가장 중요한 부분입니다.
   
   계획부터 회고에 이르는 모든 이벤트는 스프린트 중에 발생합니다. 스프린트에 대한 특정한 시간 간격이 수립되면 개발 기간 동안 일관성을 유지해야 합니다. 이를 통해 팀은 과거의 경험으로부터 배우고 그 통찰력을 이후의 스프린트에 적용할 수 있습니다.

4. 매일 스크럼 또는 스탠드업: 같은 시간(보통 아침)에 진행하는 아주 짧은 회의이며 일을 간단하게 유지하는 데 도움을 줍니다. 많은 팀에서는 15분 만에 회의를 완료하려고 하지만, 이는 가이드라인일 뿐입니다. 이 회의는 빠른 회의여야 한다는 것을 강조하여 '매일 스탠드업'이라고도 합니다. 매일 스크럼의 목표는 모든 팀원이 같은 정보를 공유하고, 스프린트 목표를 이해하고, 다음 24시간 동안의 계획을 세우는 것입니다.
   
   스탠드업은 스프린트 목표를 충족하는 데 우려 사항 또는 방해 요소에 대해 알리는 시간입니다.
   
   스탠드업을 수행하는 일반적인 방법은 스프린트 목표 달성의 맥락에서 모든 팀원이 세 가지 질문에 답하는 것입니다.
   
   • 어제 무엇을 했습니까?
   
   • 오늘 무엇을 할 계획입니까?
   • 장애물이 있습니까?
   
   하지만 이러한 회의는 어제의 자신의 일정을 읽고 다음 날 이를 반복하는 의미 없는 모임으로 빠르게 변하는 경우가 많습니다. 스탠드업의 기반이 되는 이론은, 매일 모임에 방해가 되는 잡담을 일일 회의로 전환하여 팀이 하루 중 나머지 시간 동안 작업에 집중할 수 있도록 하는 것입니다. 따라서 회의가 매일의 일정을 읽는 시간으로 바뀌면 여기에 변화를 주고 창의력을 발휘하는 것을 두려워하지 마세요.

5. Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.
   
   This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

6. 스프린트 회고: 회고란 팀이 함께 모여 스프린트, 프로젝트, 사용자 또는 관계, 도구 또는 특정 세레모니에서 효과가 있었던 부분과 잘 되지 않았던 부분을 기록하고 논의하는 단계입니다. 그 목적은 팀이 잘못 진행된 부분보다는 다음번에 개선해야 할 사항에 집중할 수 있는 장소를 만드는 것입니다.