스크럼 소개

스크럼의 역사

1970년 Winston Royce의 "대형 소프트웨어 시스템 개발 관리" 보고서가 발표된 이후 많은 사람들이 Waterfall 개발 모델의 단점을 제거할 수 있는 방법론을 찾으려고 노력했습니다. "폭포"에 대한 대안은 지금 논의할 스크럼 방법이었습니다.

스크럼은 1986년 Takeuchi와 Nonaki의 저서 The New Rules for New Product Development에서 이름을 얻었습니다. 이 문서는 목표를 달성하는 가장 효과적인 방법은 개발자에게 명확한 행동 계획을 제공하는 것이라고 주장합니다.

1995년에는 Sutherland와 Schweiber의 "Scrum을 사용한 소프트웨어 개발"이라는 또 다른 가이드가 등장했습니다. 이후 이 간행물은 여러 번 업데이트되었습니다. 이제 이 방법 개발의 주요 가이드로 간주됩니다. 스크럼 가이드의 현재 버전에는 2020년에 업데이트된 정보가 포함되어 있습니다.

스크럼 가이드의 주요 조항은 프로젝트 관리 템플릿이 개발자가 합의된 시간 프레임(스프린트) 내에 완제품을 제공한다는 사실을 기반으로 해야 한다고 제안합니다. Scrum의 성공적인 구현을 위해서는 역할, 이벤트, 규칙 및 아티팩트와 같은 여러 요소로 구성된 구조를 사용하는 것이 좋습니다.

스크럼에서의 역할

Scrum에는 세 가지 역할이 있으며 모두 Scrum 팀을 구성합니다.

소프트웨어 제품의 고객만이 비즈니스에 대한 가치를 완전히 이해하고 있기 때문에 프로젝트에서 가장 중요한 사람입니다. 고객은 미래 제품의 사용자 요구 사항을 개발자에게 설명하지만 개발 프로세스의 기술적인 부분은 책임지지 않습니다. 고객은 또한 제품에서 특정 요소나 기능을 만들 때 우선 순위를 결정합니다.

개발자는 응용 범위에 따라 교차 기능이 달라지는 기술 작업의 구현을 맡습니다. 개발자는 스프린트 백로그 생성, 코드 작성, 스프린트 목표에 맞게 프로젝트 조정 및 기타 작업으로 바쁩니다.

스크럼 마스터는 스크럼 팀의 진행자입니다. 고객과 개발자에게 도움을 제공합니다. 간단히 말해서, 스크럼 마스터는 프로젝트에 참여하지 않은 사람들과 코드를 작성하는 사람들 사이에서 바쁘게 소통합니다. 때로는 같은 대기업의 서로 다른 코더 팀이 이러한 팀의 스크럼 마스터 총회에서 의사 소통하고 조정합니다.

스크럼의 이벤트

스크럼 이벤트에는 5가지 유형이 있습니다.

스프린트는 스크럼의 가장 중요한 부분입니다. 여기에는 스프린트 계획, 일일 스탠드업(일일 스크럼), 스프린트 검토 및 회고가 포함됩니다.

스프린트 계획. Scrum 팀의 모든 구성원은 미래의 스프린트에 대한 계획을 세우는 데 참여합니다. 제품 아이디어가 제시되고 각 팀원이 이에 대해 생각하는 의견을 표현할 수 있습니다. 그런 다음 회의에서 우선 순위가 결정되고 기한이 발표됩니다.

일일 스크럼은 15분 이상 지속되지 않는 일일 짧은 스크럼 이벤트입니다. 일반적으로 오늘 또는 내일의 인코더 작업을 계획하기 위해 수행됩니다. Daily Scrum에서는 현재 문제에 대해 토론할 수 있습니다. 프로젝트에 참여하는 모든 개발자는 이러한 워크샵에 참여해야 합니다. 스크럼 마스터의 존재는 허용되지만 필수는 아닙니다.

스프린트 검토(데모) - 스프린트 중에 생성된 결과를 표시합니다. 일반적으로 이 이벤트는 최종 단계에서 발생합니다. 모든 관심있는 사람들이 그것에 참여합니다.

스프린트 회고전 - 스프린트 결과에 대한 토론. 팀원들은 각자에게 부여된 업무를 어떻게 처리하고 향후 업무 성과를 어떻게 개선할 것인지에 대해 의견을 나눕니다.

또한 백로그 정제(Backlog Refinement)가 때때로 수행됩니다. 백로그 항목, 다음 스프린트 준비 및 현재 작업의 우선 순위에 대해 논의합니다.

유물

스크럼 아티팩트는 프로젝트 또는 스프린트 종료 시 발생하는 작업입니다. 제품 백로그, 스프린트 백로그 및 증분의 세 가지 아티팩트가 있습니다. 각각은 사용자에게 소프트웨어를 적시에 제공하는 데 필요합니다. 보조 아티팩트(번다운 차트 등)도 있습니다.

스프린트 아티팩트에 포함된 구성 요소:

제품 백로그 - 인터페이스 및 백엔드 기능.

스프린트 백로그는 반복 중에 수행해야 하는 작업 목록입니다. 스프린트가 시작되기 전에 합의됩니다.

증분 - 스프린트 중에 생성된 소프트웨어 백로그 항목의 총 수와 이전에 이루어진 증분 값입니다. 완료된 새 증가분은 스프린트가 끝나기 전에 표시되어야 합니다. 이는 스크럼 팀의 요구 사항을 충족하는 작업 버전이 있음을 의미합니다.

제품 백로그 항목 - 스프린트 반복 중에 완료되어야 합니다. 일반적으로 요소는 여러 개의 작은 작업으로 나뉩니다.

스프린트 목표는 완료해야 하는 작업입니다(백로그 항목 또는 기타 작업 생성).

스프린트 번다운은 스프린트가 끝나기 전에 남은 작업입니다. 번다운 차트는 오름차순 또는 내림차순입니다. 그것은 모두 팀원이 일하는 동안 직면하는 어려움에 달려 있습니다. 진행 상황의 지표가 아니라 문제를 해결하는 방법과 인센티브일 뿐입니다.

제품 릴리스/제품 번다운 차트는 다음 스프린트가 끝나기 전에 스크럼 마스터가 그린 차트입니다. 가로축은 스프린트, 세로축은 남은 작업량입니다.

스크럼 프레임워크 규칙

역할, 이벤트 및 아티팩트가 스크럼의 기본이지만 이 외에도 다른 규칙이 있습니다. 그들 모두는 작업 프로세스의 효율성을 향상시킵니다. 다음은 이러한 규칙 목록입니다.

• 스크럼 팀에는 소프트웨어 고객, 스크럼 마스터 및 개발자가 포함됩니다.
• 모든 스프린트는 길이가 같아야 합니다.
• 한 스프린트를 완료하면 즉시 새 스프린트 작업이 시작됩니다.
• 스프린트는 항상 계획에서 시작됩니다.
• 팀원들은 업무 시작 시 아침 스크럼을 갖습니다.
• 각 스프린트는 각 스프린트 중에 검토됩니다. 이것은 팀과 이해 관계자 간의 의사 소통을 향상시킵니다.
• 스프린트 중에는 스프린트 백로그를 변경하지 않는 것이 좋습니다.

스크럼의 한계

명백한 장점과 함께 Scrum에는 다음과 같은 단점도 있습니다.

• 스크럼은 종종 공통된 기한이 없기 때문에 수행되는 작업량의 감소로 이어집니다.
• 프로젝트 참여자들의 참여도가 낮거나 협력을 꺼리는 경우 결과에 실패할 가능성이 상당히 높습니다.
• 스크럼 구조는 대규모 팀에서 사용하기 어렵지만 여전히 가능합니다. LeSS, SAFe, Nexus 등의 확장 프레임워크가 있습니다.
• 프로젝트 중간에 한 명 이상의 팀원이 팀에서 이탈해도 프로젝트에 큰 영향을 미치지 않습니다.