애자일 스크럼 방법론을 사용하는 사람은 누구입니까?
스크럼은 소프트웨어 개발 팀에서 널리 사용됩니다. 사실, 가장 인기 있는 애자일 방법론. 에 따르면 12년차 State of Agile 신고소프트웨어 팀의 70%는 스크럼 또는 스크럼 하이브리드를 사용합니다. 그러나 스크럼은 IT 및 마케팅을 포함한 다른 비즈니스 부서로 확산되어 복잡성과 모호성 속에서 프로젝트를 진행해야 합니다. 리더십 팀 또한 스크럼을 기반으로 애자일 관리 관행을 구축하고 있으며, 종종 스크럼을 린 및 칸반(애자일 프로젝트 관리의 하위 그룹) 관행과 결합합니다.
애자일 프로젝트 관리와 관련하여 스크럼이란 무엇입니까?
스크럼은 애자일의 하위 그룹입니다.
- 애자일은 그룹의 일상적인 상호작용과 활동을 설명하는 일련의 가치와 원칙입니다. 애자일 자체는 규범적이거나 구체적이지 않습니다.
- 스크럼 방법론은 애자일의 가치와 원칙을 따르지만, 특히 특정 소프트웨어 개발 관행과 관련하여 추가적인 정의와 사양을 포함합니다.
스크럼 방법론을 통해 어떤 이점을 얻을 수 있나요?
애자일 스크럼을 도입한 조직은 다음과 같은 경험을 했습니다.
- 높은 생산성
- 더 나은 품질의 제품
- 출시 시간 단축
- 이해관계자 만족도 향상
- 더 나은 팀 역학
- 더 행복한 직원
스크럼 프로젝트 관리의 특별한 점은 무엇일까요?
스크럼은 정보를 투명하게 공개하여 작업의 복잡성을 해결합니다. 이를 통해 사람들은 예측된 상황이 아닌 현재 상황을 기반으로 검토하고 적응할 수 있습니다. 이를 통해 팀은 폭포수 개발 프로세스의 일반적인 함정, 즉 끊임없이 변화하는 요구 사항으로 인한 혼란, 시간, 자원, 비용의 과소평가, 소프트웨어 품질 저하, 부정확한 진행 상황 보고 등을 해결할 수 있습니다. 스크럼 개발에는 제공되는 내용이 기대에 부합하는지 확인하기 위해 일반적인 용어와 표준의 투명성이 필수적입니다. 빈번한 검토는 진행 상황을 확인하고, 조기에 차이점을 발견하여 신속하게 조정할 수 있도록 합니다. 검토 및 적응을 위한 가장 일반적인 스크럼 이벤트는 다음과 같습니다. 스프린트 계획, 일일 스크럼 또는 "스탠드업", 스프린트 검토 및 스프린트 회고(아래 "스크럼 이벤트" 섹션 참조).
스크럼 방법론은 다른 애자일 접근 방식과 어떻게 비교됩니까?
대부분의 기업은 조직의 나머지 부분으로 "확장"하기 전에 개별 팀을 먼저 애자일로 전환합니다. 애자일 확장은 쉽지 않기 때문에 최근 다음과 같은 새로운 프레임워크가 등장했습니다. 확장된 Agile 프레임워크® 그리고 규율 있게 민첩한 전달 (DAD) 이러한 인기로 인해 스크럼은 많은 애자일 애플리케이션 수명 주기 관리(Agile ALM) 이니셔티브의 중요한 부분이 되었습니다.
애자일 스크럼 개발의 구성 요소는 무엇입니까?
스크럼 방법론은 팀 역할, 이벤트(의식), 아티팩트, 규칙으로 정의됩니다.
스크럼 팀
스크럼 팀은 일반적으로 7명(±2명)으로 구성되며, 업무를 위임하거나 문제 해결 방법을 결정하는 팀 리더는 없습니다. 팀은 하나의 단위로서 문제를 어떻게 처리할지 결정합니다. 스크럼 팀의 각 구성원은 솔루션의 필수적인 부분이며, 처음부터 끝까지 제품을 이끌어갈 것으로 기대됩니다. 스크럼 팀에는 세 가지 주요 역할이 있습니다.
제품 소유자
제품 소유자는 프로젝트의 핵심 이해관계자로, 일반적으로 내부 또는 외부 고객, 또는 고객 대변인 역할을 합니다. 팀이 개발 중인 제품의 전반적인 사명과 비전을 전달하는 제품 소유자는 단 한 명입니다. 제품 소유자는 궁극적으로 제품 백로그를 관리하고 완료된 작업 단위를 승인할 책임을 갖습니다.
스크럼 마스터
스크럼 마스터는 제품 소유자, 개발팀, 그리고 조직을 섬기는 리더입니다. 팀에 대한 계층적 권한은 없지만, 오히려 촉진자 역할을 하는 스크럼 마스터는 팀이 스크럼 이론, 관행, 그리고 규칙을 준수하도록 보장합니다. 스크럼 마스터는 팀이 최고 수준의 성과를 낼 수 있도록 가능한 모든 조치를 취함으로써 팀을 보호합니다. 여기에는 장애물 제거, 회의 진행, 그리고 제품 소유자가 백로그를 정리하도록 돕는 것이 포함될 수 있습니다.
개발팀
개발팀은 각 스프린트 완료 시 배포 가능한 증분을 제공할 수 있는 모든 기술을 갖춘, 자기 조직화되고 교차 기능적인 그룹입니다. 스크럼은 "개발자"라는 용어의 정의를 프로그래머를 넘어 배포되는 증분 생성에 참여하는 모든 사람을 포함하도록 확장합니다. 개발팀에는 직책이 없으며, 스크럼 마스터를 포함하여 누구도 개발팀에 제품 백로그 항목을 잠재적으로 배포 가능한 증분으로 전환하는 방법을 지시하지 않습니다.
스크럼 이벤트(세레모니)
스프린트
스프린트는 특정 작업을 완료하고 검토를 위해 준비하는 기간이 정해진 기간입니다. 스프린트는 보통 2~4주 동안 진행되지만, 짧게는 1주일 정도로 단축될 수도 있습니다.
스프린트 계획
스프린트 계획 팀 회의는 어떤 제품 백로그 항목을 전달할지, 어떻게 작업을 완료할지를 결정하는 시간이 정해진 이벤트입니다.
일일 스탠드업
일일 스탠드업은 짧은 커뮤니케이션 회의(15분 이내)로, 각 팀원이 마지막 스탠드업 이후의 진행 상황, 다음 회의 전까지 계획된 작업, 진행을 방해하는 장애물 등을 빠르고 투명하게 공유합니다.
스프린트 리뷰
스프린트 검토는 팀이 스프린트 기간 동안 완료된 작업을 발표하는 "쇼앤텔(show-and-tell)" 또는 시연 행사입니다. 제품 책임자는 미리 정의된 승인 기준에 따라 작업을 확인하고 작업을 승인하거나 거부합니다. 이해관계자 또는 고객은 제공된 증분이 비즈니스 요구를 충족하는지 확인하기 위해 피드백을 제공합니다.
회고록
회고(retrospective)는 스프린트의 마지막 팀 회의로, 무엇이 잘 되었고 무엇이 잘못되었는지, 그리고 다음 스프린트에서 팀이 어떻게 개선할 수 있는지 파악하는 자리입니다. 팀과 스크럼 마스터가 함께 참여하는 회고는 팀이 전반적인 성과에 집중하고 프로세스의 지속적인 개선 전략을 수립할 수 있는 중요한 기회입니다.
스크럼 아티팩트
제품 백 로그
제품 백로그는 시스템, 프로젝트 또는 제품에 대한 모든 요구 사항을 요약한 가장 중요한 단일 문서입니다. 제품 백로그는 각 작업 항목으로 구성된 할 일 목록으로 볼 수 있으며, 각 항목은 비즈니스 가치를 지닌 결과물을 생성합니다. 백로그 항목은 제품 담당자가 비즈니스 가치를 기준으로 정렬합니다.
S인쇄 백로그
스프린트 백로그는 스프린트에서 완료해야 하는 제품 백로그에서 가져온 구체적인 항목 목록입니다.
증가
증분은 마지막 소프트웨어 릴리스 이후 완료된 모든 제품 백로그 항목의 합계입니다. 증분 출시 시점은 제품 소유자가 결정하지만, 증분에 포함된 모든 항목이 출시될 준비가 되었는지 확인하는 것은 팀의 책임입니다. 이는 잠재적으로 출시 가능한 증분(PSI)이라고도 합니다.
스크럼 규칙
애자일 스크럼의 규칙은 전적으로 팀에 달려 있으며, 팀 프로세스에 가장 적합한 방식으로 관리되어야 합니다. 최고의 애자일 코치는 팀에게 위에 나열된 기본 스크럼 이벤트부터 시작하여 팀의 고유한 요구에 따라 검토하고 조정하여 팀의 협업 방식을 지속적으로 개선하도록 안내할 것입니다.
스크럼 연습
시작하기
에 스크럼을 시작하다개별 스크럼 팀이 제품 백로그와 각 스프린트별 스프린트 백로그 항목의 진행 상황을 관리하기 위해 화이트보드, 스티키 노트, 스프레드시트와 같은 간단한 스크럼 도구를 사용하는 것은 드문 일이 아닙니다. 애자일 방식을 조직의 다른 부서로 확장하는 것은 의심할 여지 없이 더 복잡합니다. 조직 내에서 스크럼을 사용하거나 지리적으로 분산된 팀이 많을수록 화이트보드, 스티키 노트, 스프레드시트와 같은 간단한 도구는 점점 더 복잡해집니다.
애자일을 다음 단계로 끌어올리다
Digital.ai Agility, 이전 VersionOne은 스크럼과 같은 애자일 관행을 확장하는 과제를 해결합니다. 올인원 애자일 프로젝트 관리 플랫폼 개별 팀뿐만 아니라 확장 가능한 애자일 프레임워크를 도입한 분산 기업에서도 사용할 수 있습니다. Digital.ai Agility 팀, 프로그램 및 포트폴리오 수준의 이해 관계자가 계획, 추적 및 보고할 수 있는 중앙 집중식 환경입니다. 소프트웨어 제공 위치에 관계없이.
