스크럼 방법론: 역할, 이벤트 및 아티팩트

스크럼 방법론은 애자일 제품 및 소프트웨어 개발 팀의 요구에 적응하지 못한 폭포수 방법과 같은 엄격한 프로젝트 관리 접근 방식에 대한 대응으로 개발되었습니다. 스크럼 방법론을 심층적으로 살펴보겠지만 그 전에 간단한 스크럼 정의부터 시작하겠습니다.

스크럼 방법론이란 무엇입니까?

스크럼은 복잡한 제품 및 소프트웨어 개발 프로젝트에서 팀 협업을 촉진하는 프로젝트 관리 프레임워크입니다. 좋은 소식은 스크럼이 이해하기 쉽다는 것입니다. 나쁜 소식은 마스터하기가 어렵다는 것입니다.

스크럼 방법론은 프로젝트 관리에서 팀워크를 강조합니다. 책임을 강조하고 잘 정의된 목표를 향한 반복적인 진행입니다. 스크럼은 애자일 소프트웨어 개발의 일부이며 팀은 애자일을 연습합니다. 이름은 럭비 스포츠에서 따온 것입니다. 여기서 스크럼은 모든 사람이 특정 역할을 수행하지만 모두가 전략을 빠르게 채택하기 위해 노력하는 포메이션입니다.

성공적인 스크럼에 필요한 협업은 스크럼 팀이 일하는 곳마다 연결하는 클라우드 기반 작업 및 프로젝트 관리 소프트웨어인 ProjectManager에 의해 촉진됩니다. 핵심에 대한 협업을 통해 당사 플랫폼은 스크럼 팀이 스프린트 중 작업에 대한 의견을 제시하고 파일을 공유하는 등의 작업을 수행할 수 있도록 하는 실시간 데이터를 제공합니다. 오늘 무료로 시작하세요.

스크럼 프레임워크

스크럼은 가치, 역할, 이벤트 및 아티팩트로 구성된 프레임워크입니다. 이러한 요소는 팀이 작업을 더 잘 관리하는 데 도움이 되는 민첩한 프로젝트 관리 방법론을 제공하기 위해 함께 작동합니다. 스크럼 프레임워크는 단순해야 합니다. 이는 전통적인 프로젝트 관리 방법론이라기보다는 제품 및 소프트웨어 개발을 위한 프레임워크입니다.

스크럼 가치

스크럼 값이라는 용어는 실제로 스크럼 프레임워크에 적용된 애자일 값을 나타냅니다. 애자일 모범 사례로 작동하는 간단한 설명입니다. 애자일 가치는 애자일 방법론의 지침 원칙이 담긴 문서인 애자일 선언문에서 나옵니다. 그들이 무엇에 대해 빨리 설명합시다.

• 프로세스 및 도구에 대한 개인 및 상호 작용: 프로세스 및 도구는 소프트웨어 개발에서 중요하지만 개인과 개인이 이러한 프로세스 및 도구와 상호 작용하는 방식이 더 중요합니다.
• 포괄적인 문서보다 작동하는 소프트웨어: 애자일 선언이 있기 전에 소프트웨어 개발자는 문서화에 집중했습니다. 이 가치는 문서화가 중요하지만 소프트웨어 개발에 집중하는 것이 스크럼 팀의 주요 목표여야 함을 나타냅니다.
• 계약 협상보다 고객 협업: 이 가치는 고품질 제품을 만들기 위해 고객과 협업하는 것이 예전 소프트웨어 개발 시절처럼 제품 개발을 제한하는 엄격한 계약 초안을 작성하는 것보다 훨씬 더 중요하다는 것을 설명합니다.
• 계획에 따라 변경에 응답: 이 값은 Agile이 엄격한 프로젝트 계획이 아닌 반복적인 제품 개발 주기를 기반으로 변경에 원활하게 적응하는 프로젝트 관리 방법론임을 나타냅니다.

스크럼 역할

프로젝트 관리의 모든 것과 마찬가지로 스크럼 방법론에는 사람이 필요합니다. 이를 위해 여러 팀 구성원으로 구성된 스크럼 마스터, 제품 소유자 및 개발 팀의 세 가지 스크럼 역할을 정의합니다.

스크럼 마스터는 이름에서 알 수 있듯이 스크럼 방법론 전문가입니다. 그는 스크럼 팀의 모든 사람들이 프레임워크가 어떻게 작동하는지 이해하고 애자일 환경에 적응하도록 돕습니다. 그는 스크럼 회의를 이끌고 있습니다.

스크럼 제품 소유자는 제품 로그를 관리하고 스프린트 계획을 감독하며 스크럼 회의에 적극적으로 참여합니다. 어떤 의미에서 그들은 백로그 정리를 이끌고 팀워크를 향상시키기 위해 사용자 스토리의 우선 순위를 지정하기 때문에 프로젝트 관리자 역할을 합니다.

스크럼 개발 팀은 단순히 소프트웨어나 제품을 개발하는 모든 팀원으로 구성됩니다. 그들은 제품 소유자와 긴밀하게 협력하고 스크럼 마스터의 제안을 준수해야 합니다.

스크럼 이벤트

이러한 스크럼 이벤트 또는 스크럼 행사는 팀 협업을 촉진하고 제품 또는 소프트웨어 개발 수명 주기 전반에 걸쳐 스크럼 팀 구성원 간에 지속적인 커뮤니케이션 라인이 있는지 확인합니다.

스프린트 계획

팀은 제품 백로그를 사용하여 우선 순위가 가장 높은 항목부터 시작하여 이 목표를 달성하는 방법을 결정합니다. 스프린트를 계획할 때 좋은 팁은 실사를 하고 준비된 항목으로만 시작하는 것입니다. 또한 계획은 짧은 과정이므로 세부 사항에 집착하지 마십시오. 목표를 달성하기 위해 노력하기만 하면 됩니다. 계획을 협력적으로 유지하십시오. 팀은 또한 제품 소유자와 이해 관계자에게 질문해야 합니다.

일일 스크럼 회의

이것은 스크럼 팀의 모든 사람들이 하루 동안 수행할 작업에 대해 이야기하고 그들이 직면한 장애물이나 어려움을 공유하는 15분 회의입니다. 더 복잡한 주제를 탐색하기 위한 스프린트 리뷰 및 스프린트 회고와 같은 다른 회의가 있기 때문에 이 일일 스크럼 회의를 더 길게 만들 필요가 없습니다.

스프린트 리뷰

스프린트를 되돌아보고 무엇이 효과가 있었고 무엇이 효과가 없었는지 확인하고 싶을 것입니다. 그런 다음 정보를 가져와 미래의 스프린트에 적용하여 긍정적인 부분을 복제하고 부정적인 부분을 줄일 수 있습니다. 참가자들에게 감사 인사를 전하고 짧은 소개를 제공하고 토론을 위한 기본 규칙을 설정하여 스프린트 검토 프로세스를 시작합니다.

스프린트 회고

스프린트 회고 회의는 스크럼 팀이 마지막 스프린트를 되돌아보고 무엇이 잘되고 잘못되었는지 결정할 수 있는 공간을 제공합니다. 이해 관계자 및 고객 피드백도 수집하여 사용자 스토리의 우선 순위를 지정하고 제품 성능을 개선합니다.

백로그 정리

이 주기를 거치면 백로그로 돌아가 우선 순위 목록의 맨 위에 있는 다음 준비 항목을 가져옴으로써 다시 시작됩니다. 백로그 그루밍은 사전 경험을 바탕으로 작업의 우선 순위를 지정하여 스크럼 프로세스를 개선하고 가능한 한 효율적으로 작업을 계속 개선하는 것으로 구성됩니다.

스크럼 아티팩트

스크럼 방법론에서 아티팩트라는 용어는 스크럼 팀이 애자일 환경에서 제품을 개발하는 데 사용하는 핵심 개념을 나타냅니다. 모든 스크럼 팀이 필요로 하는 가장 중요한 아티팩트인 제품 백로그, 스프린트 백로그 및 제품 증분을 살펴보겠습니다.

• 제품 백로그: 제품 소유자는 수행해야 하는 작업 목록을 만들고 우선 순위에 따라 정렬합니다. 이것은 프로젝트 백로그를 구축하고 있습니다. 그들은 덜 중요하고 할당된 기간에 맞지 않는 필수 아이템이 무엇인지 결정함으로써 이를 수행합니다. 즉, 각 항목의 가치가 명확해야 합니다. 그들의 영향, 위험은 무엇이며 항목이 학습 과정에서 어떻게 도움이 될 수 있습니까?
• 스프린트 백로그: 스프린트 백로그는 스크럼 팀이 단일 스프린트에서 작업할 일련의 사용자 스토리로 간단히 정의할 수 있습니다. 가장 중요한 사용자 스토리가 항상 작업 중인 스토리이고 그 중 어느 것도 실패하지 않도록 하는 것이 중요합니다.
• 제품 증분: 제품 증분이라는 용어는 스프린트 동안 완료된 모든 제품 백로그 항목을 나타내며 완료된 모든 백로그 항목 및 사용자 스토리의 합계를 설명하는 데 사용할 수도 있습니다.

스크럼 방법론 이론은 시간이 지남에 따라 발전해 왔습니다. 스크럼 전문가들은 실제로 7개의 스크럼 아티팩트가 있다고 제안했습니다. 이 확장된 비전은 스크럼 팀의 목표를 더 자세히 정의하는 데 매우 유용할 수 있습니다.

스크럼 기록

태생

스크럼 프로세스는 1990년대 초반에 시작되었습니다. Jeff Sutherland와 Ken Schwaber는 1995년 텍사스 오스틴에서 열린 OOPSLA(객체 지향 프로그래밍, 시스템, 언어 및 응용 프로그램) 회의에서 이 프로세스를 제안했습니다. 그런 다음 "SCRUM Software"라는 출판된 논문에서 방법론을 공식화했습니다. 개발 과정.”

그러나 스크럼이라는 이름은 경영 전문가인 다케우치 히로타카와 노나카 이쿠지로가 1986년에 발표한 "신제품 개발 게임"이라는 논문에서 계승되었습니다. 그들은 프로젝트 성공을 위한 팀 협업의 중요성을 강조하는 수단으로 럭비와 관련된 스크럼이라는 단어를 사용하고 있었습니다.

이 논문은 새롭고 복잡한 프로젝트를 개발할 때 작업이 아닌 목표가 주어지는 소규모의 자기 조직화된 팀으로부터 성과를 얻는 방법을 보여주는 연구에 대해 보고했습니다. 탁월한 팀은 지시를 받은 팀이지만 해당 목표를 달성하기 위한 자체 전술을 만들 수 있는 자율성을 가지고 있습니다.

스크럼 및 소프트웨어 개발

그런 다음 스크럼 프레임워크는 적응 사례에 대한 이 연구를 소프트웨어 개발에 적용했습니다. 그 과정에서 Schwaber는 프로세스 제어 연구 엔지니어인 Babatunde A. Ogunnaike Tunde 교수를 모집하여 스크럼이 다른 방법론과 어떻게 작동하는지 알아보았습니다.

폭포수 및 기타 전통적으로 구조화된 프로세스와 같은 방법론이 스크럼 프레임워크와 일치하지 않는 것으로 확인되었습니다. Tund 교수는 경험적 접근 방식이 스크럼과 가장 잘 맞는 프로세스라고 결론지었습니다.

2001년까지 Sutherland, Schwaber 및 15명의 다른 소프트웨어 개발 리더는 Agile Software Development를 위한 선언문을 만들었습니다. 얼마 후 Agile Alliance가 설립되었고 Schwaber가 초대 회장이 되었습니다. Schwaber는 2001년 Mike Beedle과 스크럼에 대한 첫 번째 책인 Agile Software Development with Scrum을 공동 저술했습니다.

2000년대 스크럼

Scrum Alliance는 Mike Cohn, Esther Derbry와 함께 회장인 Schwaber가 2002년에 설립했습니다. 그들은 나중에 Certified ScrumMaster 프로그램을 통해 조직에 인증 부서를 추가했습니다. 2006년에 Sutherland는 Scrum, Inc.를 설립했으며 계속해서 Certified Scrum 과정을 가르치고 있습니다.

스크럼 커뮤니티의 변화는 2009년 Schwaber가 Scrum Alliance를 떠나 Professional Scrum Series를 제공하는 Scrum.org를 시작했을 때 계속되었습니다.

그 이후로 스크럼은 2010년 스크럼 가이드의 첫 번째 출판과 함께 프로젝트 관리에서 세계적인 역할을 맡았으며 2011년과 2013년에 업데이트되었습니다. 오늘날 프로젝트 관리에서 가장 많이 사용되는 애자일 프레임워크 중 하나로 알려져 있습니다.

대규모 팀과 함께 일하기 위해 성장하고 있습니다. Scrum of Scrums는 스크럼을 대규모 그룹으로 확장하는 기술 사용에 적용됩니다.

스크럼은 애자일에 어떻게 적합합니까?

스크럼은 애자일 프로세스의 일부이지만 확실히 유일한 부분은 아닙니다. 애자일은 큰 텐트지만 스크럼은 중요한 기둥입니다. 스크럼을 애자일 개발을 구현할 수 있는 프레임워크로 생각하십시오.

Agile에는 따라야 할 일련의 단계가 없으므로 스크럼은 프로젝트에 Agile을 적용하는 수단을 제공합니다. 익스트림 프로그래밍이나 기능 중심 개발과 같이 애자일 개발에 사용할 수 있는 프레임워크가 많이 있지만 스크럼의 단순성과 자율성이 장점입니다.

스크럼은 다른 애자일 관행의 진입점으로도 사용될 수 있습니다. 또한 소프트웨어를 위한 프레임워크일 뿐만 아니라 다른 많은 종류의 프로젝트에도 도움이 될 수 있습니다.

스크럼 용어집

스크럼의 프레임워크를 정의하기 전에 스크럼 환경에서 작업할 때 사용되는 몇 가지 일반적인 용어에 대한 간략한 목록이 있습니다.

번다운 차트: 번 다운 차트는 시간에 비해 많은 노력이 남아 있음을 보여줍니다.

번업 차트: 시간에 대한 측정값의 증가를 측정합니다.

일일 스크럼: 당일 작업에 대한 짧은 스크럼 회의.

완료의 정의 : 완료 의 정의(DOD)는 7개의 스크럼 아티팩트 중 하나입니다. 스크럼 팀에서 동의한 수용 기준입니다.

개발팀: 모든 스프린트와 관련된 작업을 관리합니다.

엔지니어링 표준: 프로젝트의 점진적 개발을 위한 공유 표준.

제품 백로그: 제품 백로그는 특정 순서로 수행되는 작업입니다.

제품 백로그 수정: 제품 소유자와 팀이 백로그 정리라고도 하는 제품 백로그에 세부 정보를 추가하는 경우.

제품 소유자: 제품 및 팀을 담당하는 관리자입니다.

스크럼: 복잡한 프로젝트에서 팀 협업을 위한 프레임워크.

스크럼 보드: 스크럼 보드는 스크럼 팀이 작업을 관리하는 데 도움이 됩니다.

Scrumban: Scrumban은 Scrum과 Kanban 프로젝트 관리를 결합한 하이브리드 방법론입니다.

스크럼 마스터: 스크럼 마스터 역할은 팀의 전문성을 도와주는 코치와 유사합니다.

스크럼 팀: 제품 소유자, 팀 및 스크럼 마스터. 스크럼 역할에 대해 자세히 알아보세요.

자체 조직: 프로젝트 목표 범위 내에서 팀 자율성.

스프린트(Sprint): 짧은 작업으로 다른 작업을 완료한 직후에 다음 작업을 수행합니다.

스프린트 백로그: 팀이 스프린트를 완료하는 데 필요한 것.

스프린트 목표: 스프린트 의 목적.

스프린트 계획: 스프린트 계획은 스크럼 팀이 다가오는 스프린트를 계획하는 봄 이벤트입니다.

스프린트 회고: 스프린트 의 짧은 사후 분석.

스프린트 검토: 다음 스프린트에 개선 사항을 추가하는 데 도움이 되는 스프린트에 대한 간략한 검토입니다.

이해 관계자: 일반적으로 프로젝트의 개시자인 비 팀 구성원입니다.

속도: 스프린트 동안 프로젝트의 증분으로 전환된 제품 백로그의 평균 양입니다.

ProjectManager는 스크럼 팀을 돕습니다.

스크럼 방법론에는 협업과 유연성이 필요합니다. 클라우드 기반 작업 및 프로젝트 관리 소프트웨어인 ProjectManager는 스크럼 팀을 연결하고 애자일 환경에서 작업하는 데 필요한 도구를 제공합니다. 우리의 도구는 위치, 작업 방식 또는 프로젝트에서 맡은 역할에 관계없이 모든 사람이 최신 정보를 유지하고 커뮤니케이션할 수 있도록 하는 실시간 데이터를 제공합니다.

스크럼 보드 생성 및 관리

우리의 다중 프로젝트 보기는 다른 부서가 Gantt 차트 또는 시트 보기에서 공동 작업할 수 있음을 의미합니다. 그러나 스크럼 팀은 스크럼 보드 보기를 사용하여 사용자 스토리의 백로그를 관리하고 스프린트를 계획할 때 함께 작업할 수 있습니다.

스크럼 보드는 또한 제품 소유자와 스크럼 마스터에게 진행 상황을 추적하고 잠재적인 병목 현상을 포착할 수 있는 가시성을 제공하며, 이는 리소스를 재할당하여 신속하게 해결할 수 있습니다.

실시간 대시보드로 스크럼 워크플로 추적

자기 주도적인 팀을 방해하고 싶지는 않지만 그들이 하는 일을 알아야 합니다. 실시간 대시보드는 6개의 프로젝트 지표를 추적합니다. 열등한 제품과 마찬가지로 설정이 필요하지 않습니다. 당사의 맞춤형 워크플로를 사용하면 작업을 자동으로 설정하는 트리거를 적용하여 팀이 작업에 집중할 수 있습니다. 또한 작업 승인을 통해 상태 변경을 제어할 수 있습니다.

스크럼 팀과 협업

팀이 한 지붕 아래에 있든 여러 시간대에 걸쳐 작업하든 상관없이 클라우드 기반 도구를 사용하면 함께 작업할 수 있습니다. 팀 구성원은 작업 수준에서 댓글을 달고 해당 작업에 할당되지 않은 다른 사람을 태그하여 대화에 참여시키고 이미지와 문서를 공유할 수 있습니다. 이메일 알림 및 인앱 알림은 모든 사람을 즉시 최신 상태로 유지합니다.

우리 소프트웨어는 스크럼에 이상적일 뿐만 아니라 폭포수 또는 여러 프로젝트 관리 방법의 하이브리드와 같은 보다 전통적인 방법론과도 작동할 수 있습니다. 우리의 도구를 사용하면 민첩하지 않은 조직의 다른 부서와 협업할 수 있습니다. 성공을 달성하는 데 필요한 유일한 작업 및 프로젝트 관리 도구입니다.

ProjectManager는 프레임을 선택한 방법론에 관계없이 작업의 모든 단계에서 프로젝트 관리자를 돕기 위해 고유하게 배치된 프로젝트 관리 소프트웨어입니다. 클라우드 기반이기 때문에 실시간 데이터를 수집하고 팀이 협업하는 데 도움이 되는 도구가 있어 일정과 예산 범위 내에서 모니터링 및 관리를 통해 스크럼에 필요한 자율성을 제공합니다. 이 무료 30일 평가판을 사용하여 귀하와 귀하의 팀에 어떻게 도움이 되는지 확인하십시오.