스크럼이란?

스크럼 (Scrum)

팀이 협업하고 영향력이 큰 업무를 수행하는 데 도움이 되는 애자일 프레임워크
복잡한 제품을 개발, 배포하고 유지하기 위함
스크럼 프레임워크는 팀이 반복과 지속적인 개선에 집중할 수 있도록 가치, 역할, 지침의 청사진을 제공

 

스크럼의 역사

1986년

• Hirotaka Takeuchi와 Ikujiro Nonaka가 기고한 Harvard Business 리뷰 기사 The New Product Development Game에서 처음 소개
• 럭비에서 스크럼이라는 이름을 따옴
• "럭비에서와 같이 팀에서 공을 패스하고 이를 단위로 필드 위를 이동하는 것" 이라고 설명함

 

 

1995년

• Ken Schwaber와 Jeff Sutherland가 애자일 선언문 및 스크럼 개발 프로세스를 출가, 더욱 체계적으로 정리되어 발전
• Schwaber와 Sutherland의 스크럼은 소프트웨어 개발의 워터폴 모델을 부분적으로 거부하는 것이라고도 말할 수 있음
• 워터폴 모델에서 프로젝트는 순차적 단계로 세분화되어 각 단계의 결과물이 완성되면 그다음 단계로 진행
• Schwaber와 Sutherland는 소프트웨어 개발자가 고객을 위한 최고의 제품을 구축하기 위해 환경에 지속적으로 대응하고 적응할 수 있는 더 유연하고 반복적인 접근 방식이 효과적이라고 생각
• 최초 발간 이후, 정기적으로 업데이트되는 Scrum Guide를 발행
• "팀이 자신의 업무 스킬이 얼마나 효과적인지를 확인하고 팀이 지속적으로 발전하고 개선하도록 한다"

 

 

 

스크럼 진행

스크럼 프레임워크가 지속적인 개선 시스템에 의존한다는 것을 알아야 함
스크럼에서 스프린트를 시작할 때 아무것도 알지 못할 수도 있음
스프린트 프로세스 중 얻은 정보를 토대로 필요에 따라 프로세스와 요구사항을 조정할 수 있음

 

 

1. 백로그를 정리

• 스크럼 스프린트를 시작하기 위해 제품 백로그에서 가져올 업무를 파악해야함
• 더 좋은 스크럼 스프린트를 진행하기 위해 제품 백로그를 명확하게 문서화 시켜야함
  • 정보 수집을 하기 위해 프로젝트 관리 툴을 사용

 

2. 스프린트 플래닝 세션을 가짐

• 스크럼 스프린트를 시작하기 전 중점을 둘 곳을 정함

 

3. 스크럼 스프린트를 시작

• 스프린트 기간 동안 팀이 스프린트 플래닝 세션에서 정리한 제품 백로그의 항목을 수정함

 

4. 일일 스크럼 스탠드업 미팅을 수행

 

5. 스프린트 리뷰시에 업무 내용을 보고

• 스프린트 리뷰에서 스크럼 팀은 이해관계자의 승인, 확인을 위해 완료된 업무를 보고
  • 완료의 예
    
    • 제품 출시 준비 완료
    • 제품 테스트 후 베타 환경에서 출시 준비 완료
    • 제품이 수락 테스트를 거친 후 모든 사용자에게 출시 가능

 

6. 스프린트 회고에서 공유하고 반영

• 스프린트가 끝난 후 진행 결과와 앞으로의 개선점을 논의
• 스크럼은 지속적인 개선 프로세스에 중점

 

 

 

스크럼 역할

제품 소유자

• 제품 백로그를 담당자
• 사용자의 니즈를 파악하고 팀과 기타 관계자에게 사용자의 경험을 전달하는 것에 중점
• 궁극적으로 출시할 준비가 되었는지 판단

 

스크럼 마스터

• 다양한 스크럼 이벤트를 실행하는 사람
• 스크럼 프로젝트 매니저 또는 진행자
• 일일 스탠드업 미팅을 주도
• 스프린트 플래닝, 리뷰, 회고 미팅을 주최

 

스크럼 팀

• 스프린트를 수행하는 모든 사람
• 지속적인 개선을 위해 자기 주도적이고 협력적이어야 함

 

 

 

스크럼 원칙

1. 경험적 프로세스 관리 
   • 스크럼 팀은 투명성, 점검, 적응을 중시
2. 자기 주도적
   • 스크럼 팀에는 역할과 규칙이 있지만, 모든 스크럼 멤버가 자신의 작업과 업무를 소유
   • 스크럼에서는 책임을 공유하는 것이 팀을 더 창의적이고 역동적으로 만들어준다고 믿음
3. 협업
   • 스크럼 스프린트를 수행할 때와 그 이후에 팀이 협력하면 최상의 결과를 얻을 수 있음
4. 가치 기반 우선순위 지정
   • 스크럼 스프린트의 목표는 최고의 비즈니스 가치를 제공하는 것
   • 스크럼 프로세스를 시작할 때부터 업무 우선순위를 지정해야 함
5. 타임박싱
   • 스크럼 프로세스에는 스프린트 자체, 일일 스탠드업, 회고와 같은 다양한 시간 기반 활동 존재
   • 스크럼은 지속적인 개선이라는 신념을 토대로 하므로 다음 작업으로 나아가고 향후 업무를 개선하기 위해 업무 시간을 정하는 것이 중요
6. 반복적 개발
   • 스크럼에서 첫 번째 제품은 완벽하지 않음
   • 반복해서 개발함으로써 팀은 고객 니즈에 가장 부합하고, 가치 기반 우선순위에 따라 제품과 결과물을 수정할 수 있음

 

 

스크럼 가치

• 약속
  • 스크럼 팀은 하나이며, 팀 멤버들은 서로를 신뢰해야 함
  • 스크럼 팀 멤버들은 이 기간 동안 스프린트에 전념할 것을 약속하고, 최상의 솔루션을 찾기 위해 지속적으로 개선하는 데 전념해야 함
• 용기
  • 스크럼 중에 팀은 정확한 해답이 없는 어려운 문제에 직면할 수 있음
  • 스크럼 팀은 최선의 솔루션에 도달하기 위해 열린 마음을 가지고 어려운 질문을 던지고 솔직하게 답하는 용기를 가져야 함
• 집중
  • 스크럼 팀은 스크럼 스프린트를 수행할 때 제품 백로그에서 업무를 수행
  • 스크럼 팀은 스프린트가 끝날 때까지 결과물을 완료하기 위해 백로그에서 선택한 업무에 집중
• 오픈 마인드
  • 스크럼 중 모든 것이 완벽하게 진행되지는 않을 것
  • 스크럼 팀 멤버들은 개인적으로 배울 수 있고 제품이나 프로세스를 개선하는 데 도움이 되는 새로운 아이디어와 기회에 열려있어야 함
• 존중
  • 협업은 스크럼의 핵심
  • 팀의 협업을 지원하기 위해 팀 멤버들은 다른 멤버, 스크럼 마스터, 스크럼 프로세스를 존중해야 함

 

 

스크럼 장점

• 스크럼은 코드나 새로운 기능과 같은 전형적인 ‘제품’이든, 마케팅 캠페인이나 크리에이티브 자산과 같은 좀 더 색다른 스크럼 ‘제품’이든 상관없이 무언가를 자주 개발하고 출시해야 하는 팀에 가장 효과적
• 스크럼 프레임워크를 따르는 팀은 민첩성과 유연성을 갖출 수 있음
• 팀워크를 강화하고 목표를 보다 효과적으로 달성하는 데 도움
• 제품 백로그에서 작업을 가져오기 때문에 항상 자신이 무엇을 수행하는지 정확히 알 수 있음
• 모든 구성원이 ‘완료’의 의미를 알기 때문에 목표가 무엇인지 명확하게 파악할 수 있음

 

 

스크럼 단점 및 한계점

• 스크럼 프로세스에서는 변화를 수용하고 권장하기 때문에 범위 변동으로 인한 어려움을 겪을 수 있음
• 변경사항이 너무 많거나 제각기 다른 피드백이 많으면 계속 반복하여 수정한다고 하여도 성과 달성을 못 할 수 있음
• 스크럼 팀은 예정된 스프린트 플래닝, 리뷰 등 많은 미팅이 있을 수 밖에 없음
• 제품, 엔지니어링 또는 소프트웨어 개발 팀이 아니라면 도입하기 어려울 수 있음