해시넷
"스크럼"의 두 판 사이의 차이
(새 문서: '''스크럼'''(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트...) |
|||
| 1번째 줄: | 1번째 줄: | ||
| − | '''스크럼'''(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다. | + | '''스크럼'''(scrum)은 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 뜻하는 럭비 용어로, 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.<ref name=“위키피디아”>〈[https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4) 스크럼(애자일 개발 프로세스)]〉, 《위키피디아》</ref> |
| + | |||
| + | ==개요== | ||
| + | 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다. 스크럼은 30일을 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 일반적인 권장기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주 정도의 유연성을 가진다. 주기가 너무 짧으면 개발 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로, 적용해보면서 필요시 조율하는 것이 좋다. 스크럼 과정을 통해 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해나가게 된다. 보통, 각 작업은 4시간에서 16시간 정도를 소요하도록 정한다. 물론, 작업을 정하고 할당하는 것은 팀 내에서 자율적으로 진행된다. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여긴다. 다만 다른 프로세스들에 비해 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 있다.<ref name=“위키피디아”></ref> 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크 기법 이다. 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여, 복잡하고 정교한 제품을 생산하도록 한다.<ref name=“스크럼”>민현기, 〈[https://medium.com/dtevangelist/scrum-dfc6523a3604 애자일 Scrum(스크럼) 이해하기]〉, 《미디엄》, 2019-01-26</ref> | ||
| + | |||
| + | ==특징== | ||
| + | 특정 언어나 방법론에 의존적이지 않고, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법이다. 스크럼은 다음과 같은 특성을 가진다. 솔루션에 포함할 기능/ 개선점에 대한 우선순위를 부여한다. 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과와 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 날마다 15분 정도 회의를 가지고, 항상 팀 단위라 생각해야 한다. 이때 주의할 것은 보고하는 자리가 아니라 공유하는 자리라는 것이다. 이 프로젝트와 관련되어 한 일, 또는 이슈 들을 공유해야 한다. 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지해야한다.<ref name=“위키피디아”></ref> | ||
| + | |||
| + | ==역사== | ||
| + | 스크럼 방법론을 창조한 것은 제프 서덜랜드와 켄 슈와버이지만, 스크럼이랑 용어가 처음 등장한 것은 노나카 이쿠지로와 타케우치 히로타카가 하버드 비드니스 리뷰에 발표된 ‘새로운 신제품 개발 방식’이었다. 이 글에 큰 영감을 받은 서덜랜드와 슈와버가 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다. 노나카와 타케우치가 왜 럭비용어인 스크럼을 사용했는지에 대한 언급은 없지만, 스크럼의 핵심인 주도적인 팀 수행을 묘사하기 위해 사용한 것으로 추측된다. 생산성과 혁신을 나타내는 제조업체의 특성을 바탕으로 기업이 팀 안에서 서로 공을 주고 받으며 하나가 되어 필드를 나아가는 럭비팀처럼 일체적 방법론을 사용한다고 비유하였다.<ref name=“뉴스”>양민경, 〈[https://hrbulletin.net/organizational-culture/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0%E2%91%A0-%EC%8A%A4%ED%81%AC%EB%9F%BCscrum/ 애자일 방법론⓵: 스크럼(scrum)]〉, 《뉴스레터》, 2018-06-19</ref> | ||
| + | |||
| + | |||
| + | ==진행순서== | ||
| + | ===제퓸 백로그 작성=== | ||
| + | 제퓸 책임자가 사용자 스토리를 기반으로 제품 백로그(product backlog)를 작성한다. 제품 백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다. 우선순위를 가지며, 위에 있을수록 우선순위가 높고 상세화 되어 있다. 사용자 스토리란 고객이나 개발자 모두 이해할 수 있도록 고객이 작성하는 것이다. 카드(card), 대화(communication), 테스트(test) 세 가지를 이용하여 작성한다. | ||
| + | *카드: 고객의 요구 사항을 문서화하기 보다는 표현하기 위한 것으로 대화의 매개체 역할을 한다. 누가, 왜, 무었을에 대한 정보가 다 포함되어 있어야 한다. | ||
| + | * 대화: 카드 내용의 세부사항을 구체화시킴으로서 인수 기준이 정해지고, 이해의 공유를 촉진시킨다. | ||
| + | *테스트(Confirmation): 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다. 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다. | ||
| + | |||
| + | ===스프린트 계획 회의=== | ||
| + | 제품 책임자, 스크럼 마스터, 개발팀이 참여하며 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다. 스프린트 계획 파트 1과 스프린트 계획 파트 2로 나뉘는데, 스프린트 계획파트 1에서는 스프린트 동안 무엇을 할지 우선순위가 높은 아이템들을 검토하고 스프린트 목표를 정한다. 스프린트 계획 파트 2에서는 스프린트 계획 파트 1에서 결정한 무엇을 어떻게 실행할 지에 대해 정한다. 스프린트 계획 회의가 끝날 때쯤, 개발팀은 각 스프린트가 끝날 때 마다 어떤 결과물을 내놓을 것인지 대한 현실적인 목표를 정하는데 이것을 스프린트 약속이라고 한다. | ||
| + | |||
| + | ===스프린트 백로그 작성=== | ||
| + | 제품 백로그에서 결정된 우선 순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다. 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다. 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(scrum board)라고 한다. | ||
| + | |||
| + | ===일일 스크럼 미팅=== | ||
| + | 일일 스크럼 미팅은 개발원들이 늘어지는 것을 막기 방지하기 위해 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다. 매일 정해진 시간에 정해진 장소에 모여서 15분~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애요인 등을 공유하며, 문제가 있을 경우 미팅 후 바로 해결한다. 일일 스크럼 미팅을 지속적으로 할 경우 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방할 수 있다. 개발 팀원들은 매일 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번 다운 차트를 통해 진척도를 추적한다. | ||
| + | |||
| + | ===실행 가능한 제품 개발=== | ||
| + | 각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것이다. 매 스프린트의 결과로ㅆ 나오는 산출물을 잠재적으로 출시 가능한 제품 증분이라고 부른다. | ||
| + | |||
| + | ===스프린트 리뷰=== | ||
| + | 스프린트가 종료되었을 때 개발 팀이 스프린트 동안 개발한 증분의 기능을 고객을 포함한 이해관리자들에게 보여주고 피드백을 받는 과정을 말한다. 고객은 자신이 요청한 요구사항이 해당 스프린트 동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다. 스프린트의 한주당 스프린트 리뷰시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다. | ||
| + | |||
| + | ===스프린트 회고=== | ||
| + | 스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로ㅆ 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다. 스프린트 회고 과정에서 스크럼 마스터는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator) 역할을 할 수 있다. 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다. | ||
| + | |||
| + | ===다음 스프린트 시작=== | ||
| + | 스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다. 스프린트가 회고가 끝나면 휴식 기간 없이 바로 다음 스프린트를 진행한다.<ref name=“스크럼진행과정”>황선영, 〈[https://medium.com/pocs/%EC%8A%A4%ED%81%AC%EB%9F%BC%EC%9D%98-%EC%A7%84%ED%96%89-%EA%B3%BC%EC%A0%95-b6faa13e0e8c 스크럼의 진행 과정]〉, 《미디엄》, 2019-07-17</ref> | ||
| + | |||
| + | ==역할== | ||
| + | *제품 책임자(Product Owner): 약자로 PO라고도 하며, 제품 백로그를 관리, 작성하고 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영하는 일을 한다. 요구사항에 우선순위를 매기고 각 스프린트마다 우선순위를 관리, 조정한다. | ||
| + | *스크럼마스터(servant leader): 일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행 중 문제가 생겼을 EO 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야 한다. | ||
| + | *개발팀: 스크럼 팀(scrum team)이라고도 부르며 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명 정도로 이루어진다. 따로 리더가 정해져있지 않으며, 팀원들이 자기 조직화되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.<ref name=“스크럼진행과정”></ref> | ||
| + | |||
| + | ==추구 가치== | ||
| + | *용기: 팀원 간 갈등과 도전을 위한 용기를 가져야 한다. 해당 기능이 이해가 안 되거나 문제가 있는 경우 일을 더 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득시킬 용기가 있어야 한다. | ||
| + | *집중: 한 번에 하나씩 일을 마무리하고, 업무에 집중할 수 있도록 불필요한 회의 참석은 지양해야하며, 주기적인 반복 작업은 제거하거나 자동화 해야 한다. | ||
| + | *헌신/책임: 팀의 목표 달성을 위해 개개인이 공약한 목표를 달성하도록 팀에 헌신하고, 필요한 모든 권한을 부여해야 한다. 개인보다 팀과 공동 목표 달성이 우선이고, 가치 있는 소프트웨어를 개발할 수 있도록 최대한의 지원과 권한이 필요하다. | ||
| + | *존중: 개개인별로 장단점이 있을 것이고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을 것이다. 팀원 서로를 존중할 필요가 있다. | ||
| + | *투명성/개방성: 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다. 제품백로그, 스크럼회의 ,스프린트 리뷰 등을 통해 공유되어야 하며, 자신에게 불리해도 숨기지 않고 도움을 청해야 한다.<ref name=“스크럼”></ref> | ||
| + | |||
| + | ==주요 용어== | ||
| + | *제품 백로그: 개발할 제품의 요구사항인 사용자 스토리의 집합이며, 우선순위로 관리한다. | ||
| + | *사용자 스토리: | ||
| + | *완료 기준(Definition of Done), 인수 기준(Acceptance Criteria): 사용자 스토리를 완료시키기 위한 조건 명세다. | ||
| + | *스프린트: 계획, 개발, 리뷰 작업 등 최소 단위의 주기다. 보통 1~4주 단위에서 선택할 수 있다. | ||
| + | *잠재적 출시 가능 제품, 최소 실행 가능 제품: 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품이다. | ||
| + | *스프린트 계획 회의: 스프린트 목표와 스프린트 백로그를 계획하는 회의다. | ||
| + | *스프린트 백로그: 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록이다. | ||
| + | *칸반 보드: 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판이다. | ||
| + | *일일 스크럼 회의: 매일 어제 한 일, 오늘 할 일, 해결해야 할 장애 또는 문제 요소를 공유하는 회의로 매일 15분 정도 수행한다. 장애 요소는 화이트 보도에 적어놓고 지속적으로 해결한다. | ||
| + | *스프린트 리뷰: 스프린트 마지막 날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토하는 과정이다. | ||
| + | *스프린트 회고: 스프린트 마지막 날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선하는 것이다. | ||
| + | |||
| + | {{각주}} | ||
| + | |||
| + | ==참고자료== | ||
| + | *〈[https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4) 스크럼(애자일 개발 프로세스)]〉, 《위키피디아》 | ||
| + | *민현기, 〈[https://medium.com/dtevangelist/scrum-dfc6523a3604 애자일 Scrum(스크럼) 이해하기]〉, 《미디엄》, 2019-01-26 | ||
| + | *양민경, 〈[https://hrbulletin.net/organizational-culture/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0%E2%91%A0-%EC%8A%A4%ED%81%AC%EB%9F%BCscrum/ 애자일 방법론⓵: 스크럼(scrum)]〉, 《뉴스레터》, 2018-06-19 | ||
| + | *황선영, 〈[https://medium.com/pocs/%EC%8A%A4%ED%81%AC%EB%9F%BC%EC%9D%98-%EC%A7%84%ED%96%89-%EA%B3%BC%EC%A0%95-b6faa13e0e8c 스크럼의 진행 과정]〉, 《미디엄》, 2019-07-17 | ||
| + | |||
| + | ==같이 보기== | ||
| + | * [[애자일]] | ||
| + | * [[스프린트]] | ||
| + | * [[프레임워크]] | ||
| + | * [[방법론]] | ||
| + | |||
| + | {{프로그래밍|토막글}} | ||
2021년 1월 13일 (수) 16:56 판
스크럼(scrum)은 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 뜻하는 럭비 용어로, 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중 하나이다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.[1]
목차
개요
특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발 뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다. 스크럼은 30일을 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 일반적인 권장기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주 정도의 유연성을 가진다. 주기가 너무 짧으면 개발 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로, 적용해보면서 필요시 조율하는 것이 좋다. 스크럼 과정을 통해 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해나가게 된다. 보통, 각 작업은 4시간에서 16시간 정도를 소요하도록 정한다. 물론, 작업을 정하고 할당하는 것은 팀 내에서 자율적으로 진행된다. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여긴다. 다만 다른 프로세스들에 비해 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 있다.[1] 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크 기법 이다. 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여, 복잡하고 정교한 제품을 생산하도록 한다.[2]
특징
특정 언어나 방법론에 의존적이지 않고, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법이다. 스크럼은 다음과 같은 특성을 가진다. 솔루션에 포함할 기능/ 개선점에 대한 우선순위를 부여한다. 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과와 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 날마다 15분 정도 회의를 가지고, 항상 팀 단위라 생각해야 한다. 이때 주의할 것은 보고하는 자리가 아니라 공유하는 자리라는 것이다. 이 프로젝트와 관련되어 한 일, 또는 이슈 들을 공유해야 한다. 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지해야한다.[1]
역사
스크럼 방법론을 창조한 것은 제프 서덜랜드와 켄 슈와버이지만, 스크럼이랑 용어가 처음 등장한 것은 노나카 이쿠지로와 타케우치 히로타카가 하버드 비드니스 리뷰에 발표된 ‘새로운 신제품 개발 방식’이었다. 이 글에 큰 영감을 받은 서덜랜드와 슈와버가 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다. 노나카와 타케우치가 왜 럭비용어인 스크럼을 사용했는지에 대한 언급은 없지만, 스크럼의 핵심인 주도적인 팀 수행을 묘사하기 위해 사용한 것으로 추측된다. 생산성과 혁신을 나타내는 제조업체의 특성을 바탕으로 기업이 팀 안에서 서로 공을 주고 받으며 하나가 되어 필드를 나아가는 럭비팀처럼 일체적 방법론을 사용한다고 비유하였다.[3]
진행순서
제퓸 백로그 작성
제퓸 책임자가 사용자 스토리를 기반으로 제품 백로그(product backlog)를 작성한다. 제품 백로그는 이해 관계자로부터 추출된 제품이 제공해야 하는 기능이나 개발할 제품에 대한 요구사항 목록을 말한다. 우선순위를 가지며, 위에 있을수록 우선순위가 높고 상세화 되어 있다. 사용자 스토리란 고객이나 개발자 모두 이해할 수 있도록 고객이 작성하는 것이다. 카드(card), 대화(communication), 테스트(test) 세 가지를 이용하여 작성한다.
- 카드: 고객의 요구 사항을 문서화하기 보다는 표현하기 위한 것으로 대화의 매개체 역할을 한다. 누가, 왜, 무었을에 대한 정보가 다 포함되어 있어야 한다.
- 대화: 카드 내용의 세부사항을 구체화시킴으로서 인수 기준이 정해지고, 이해의 공유를 촉진시킨다.
- 테스트(Confirmation): 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다. 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다.
스프린트 계획 회의
제품 책임자, 스크럼 마스터, 개발팀이 참여하며 제품 백로그를 기반으로 스프린트 목표와 스프린트 백로그를 계획하는 회의이다. 스프린트 계획 파트 1과 스프린트 계획 파트 2로 나뉘는데, 스프린트 계획파트 1에서는 스프린트 동안 무엇을 할지 우선순위가 높은 아이템들을 검토하고 스프린트 목표를 정한다. 스프린트 계획 파트 2에서는 스프린트 계획 파트 1에서 결정한 무엇을 어떻게 실행할 지에 대해 정한다. 스프린트 계획 회의가 끝날 때쯤, 개발팀은 각 스프린트가 끝날 때 마다 어떤 결과물을 내놓을 것인지 대한 현실적인 목표를 정하는데 이것을 스프린트 약속이라고 한다.
스프린트 백로그 작성
제품 백로그에서 결정된 우선 순위를 기반으로 스프린트 동안 해야 하는 일에 대한 리스트를 스프린트 백로그라고 한다. 스프린트 목표를 구현 가능하도록 각각의 요구사항을 task 단위로 나누어 개발자들이 나눠서 작업을 수행한다. 많은 팀들이 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이것을 스크럼 보드(scrum board)라고 한다.
일일 스크럼 미팅
일일 스크럼 미팅은 개발원들이 늘어지는 것을 막기 방지하기 위해 늘어지는 것을 방지하기 위해 스탠드업 미팅 형식으로 진행된다. 매일 정해진 시간에 정해진 장소에 모여서 15분~20분 동안 간단하고 빠르게 진행한다. 어제 했던 일과 오늘 할 일, 수행 중 문제점이나 장애요인 등을 공유하며, 문제가 있을 경우 미팅 후 바로 해결한다. 일일 스크럼 미팅을 지속적으로 할 경우 프로젝트 후반부에 문제점이 갑자기 발생하는 것을 예방할 수 있다. 개발 팀원들은 매일 스프린트 백로그에 있는 현재 작업을 완료하기 위해 작업이 얼마나 남았는지 번 다운 차트를 통해 진척도를 추적한다.
실행 가능한 제품 개발
각 스프린트마다 목표는 실행 가능한 제품을 만들어서 배포하는 것이다. 매 스프린트의 결과로ㅆ 나오는 산출물을 잠재적으로 출시 가능한 제품 증분이라고 부른다.
스프린트 리뷰
스프린트가 종료되었을 때 개발 팀이 스프린트 동안 개발한 증분의 기능을 고객을 포함한 이해관리자들에게 보여주고 피드백을 받는 과정을 말한다. 고객은 자신이 요청한 요구사항이 해당 스프린트 동안 제품이 잘 반영되었는지 평가한 후 피드백을 하면 프로덕트 오너는 고객의 피드백이나 여러 사항들을 정리하여 다음 스프린트에 반영되도록 제품 백로그를 다시 갱신한다. 스프린트의 한주당 스프린트 리뷰시간은 한 시간으로 제약되어 있으며 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 한다.
스프린트 회고
스프린트 리뷰 후 프로젝트를 진행하면서 좋았던 점이나 문제점, 미진한 점 등을 도출함으로ㅆ 다음 스프린트를 보다 더 나은 방향으로 개선할 수 있도록 하는 과정을 말한다. 스프린트 회고 과정에서 스크럼 마스터는 중재 및 조정 역할을 하는 퍼실리테이터(facilitator) 역할을 할 수 있다. 스프린트 회고 과정을 통해 이미 정해진 프로세스로만 프로젝트를 수행하는 것이 아니라 프로세스가 끊임없이 개선되도록 하여 변화하고 있는 환경에 더 능동적으로 적응할 수 있도록 한다.
다음 스프린트 시작
스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다. 스프린트가 회고가 끝나면 휴식 기간 없이 바로 다음 스프린트를 진행한다.[4]
역할
- 제품 책임자(Product Owner): 약자로 PO라고도 하며, 제품 백로그를 관리, 작성하고 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영하는 일을 한다. 요구사항에 우선순위를 매기고 각 스프린트마다 우선순위를 관리, 조정한다.
- 스크럼마스터(servant leader): 일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행 중 문제가 생겼을 EO 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야 한다.
- 개발팀: 스크럼 팀(scrum team)이라고도 부르며 고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명 정도로 이루어진다. 따로 리더가 정해져있지 않으며, 팀원들이 자기 조직화되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.[4]
추구 가치
- 용기: 팀원 간 갈등과 도전을 위한 용기를 가져야 한다. 해당 기능이 이해가 안 되거나 문제가 있는 경우 일을 더 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득시킬 용기가 있어야 한다.
- 집중: 한 번에 하나씩 일을 마무리하고, 업무에 집중할 수 있도록 불필요한 회의 참석은 지양해야하며, 주기적인 반복 작업은 제거하거나 자동화 해야 한다.
- 헌신/책임: 팀의 목표 달성을 위해 개개인이 공약한 목표를 달성하도록 팀에 헌신하고, 필요한 모든 권한을 부여해야 한다. 개인보다 팀과 공동 목표 달성이 우선이고, 가치 있는 소프트웨어를 개발할 수 있도록 최대한의 지원과 권한이 필요하다.
- 존중: 개개인별로 장단점이 있을 것이고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을 것이다. 팀원 서로를 존중할 필요가 있다.
- 투명성/개방성: 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다. 제품백로그, 스크럼회의 ,스프린트 리뷰 등을 통해 공유되어야 하며, 자신에게 불리해도 숨기지 않고 도움을 청해야 한다.[2]
주요 용어
- 제품 백로그: 개발할 제품의 요구사항인 사용자 스토리의 집합이며, 우선순위로 관리한다.
- 사용자 스토리:
- 완료 기준(Definition of Done), 인수 기준(Acceptance Criteria): 사용자 스토리를 완료시키기 위한 조건 명세다.
- 스프린트: 계획, 개발, 리뷰 작업 등 최소 단위의 주기다. 보통 1~4주 단위에서 선택할 수 있다.
- 잠재적 출시 가능 제품, 최소 실행 가능 제품: 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품이다.
- 스프린트 계획 회의: 스프린트 목표와 스프린트 백로그를 계획하는 회의다.
- 스프린트 백로그: 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록이다.
- 칸반 보드: 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판이다.
- 일일 스크럼 회의: 매일 어제 한 일, 오늘 할 일, 해결해야 할 장애 또는 문제 요소를 공유하는 회의로 매일 15분 정도 수행한다. 장애 요소는 화이트 보도에 적어놓고 지속적으로 해결한다.
- 스프린트 리뷰: 스프린트 마지막 날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토하는 과정이다.
- 스프린트 회고: 스프린트 마지막 날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선하는 것이다.
각주
- ↑ 1.0 1.1 1.2 〈스크럼(애자일 개발 프로세스)〉, 《위키피디아》
- ↑ 2.0 2.1 민현기, 〈애자일 Scrum(스크럼) 이해하기〉, 《미디엄》, 2019-01-26
- ↑ 양민경, 〈애자일 방법론⓵: 스크럼(scrum)〉, 《뉴스레터》, 2018-06-19
- ↑ 4.0 4.1 황선영, 〈스크럼의 진행 과정〉, 《미디엄》, 2019-07-17
참고자료
- 〈스크럼(애자일 개발 프로세스)〉, 《위키피디아》
- 민현기, 〈애자일 Scrum(스크럼) 이해하기〉, 《미디엄》, 2019-01-26
- 양민경, 〈애자일 방법론⓵: 스크럼(scrum)〉, 《뉴스레터》, 2018-06-19
- 황선영, 〈스크럼의 진행 과정〉, 《미디엄》, 2019-07-17
같이 보기
