스크럼-퀵 가이드

애자일은 소프트웨어 개발 산업에서 큰 유행어 중 하나가되었습니다. 하지만 애자일 개발이란 정확히 무엇입니까? 간단히 말해, 애자일 개발은 소프트웨어 개발 팀과 프로젝트를 실행하는 다른 방법입니다.

새로운 기능을 이해하기 위해 기존 방법을 요약 해 보겠습니다. 기존 소프트웨어 개발에서 제품 요구 사항은 개발을 진행하기 전에 마무리됩니다.

폭포 모델

이 특성을 가진 가장 일반적으로 사용되는 소프트웨어 개발 모델은 다음 다이어그램에 설명 된대로 Waterfall Model입니다. 그러나 대부분의 경우 새로운 기능이 추가되고 이전 요구 사항도 변경 될 수 있습니다. Waterfall 모델은 이러한 지속적인 요구 사항 변경을 수용하도록 구성되지 않았습니다. 또한 사용자는 제품을 완전히 사용할 수있을 때까지 제품의 기능을 명확하게 알 수 없습니다.

반복적 증분 모델

반복적 인 증분 모델에서 개발은 제한된 수의 최종화되고 우선 순위가 지정된 요구 사항으로 시작됩니다. 산출물은 제품의 작업 증분입니다. 요구 사항에서 코드 개발에 이르는 일련의 활동을 반복이라고합니다. 증분의 기능과 새롭고 수정 된 보류중인 요구 사항 중 일부 또는 전부를 기반으로 다음 반복 요구 사항이 다음 번에 제공됩니다. 후속 반복의 결과는 제품의 향상된 작업 증분입니다. 이는 제품이 필요한 기능을 수행 할 때까지 반복됩니다.

사용자는 일반적으로 개발 작업에 관여하지 않으며 잘못된 기능으로 인해 통신 공백이 발생할 수 있습니다. 참여는 개발 팀에 긍정적이지만 팀의 시간을 요구하고 지연을 추가 할 수 있습니다. 또한 반복 중에 비공식적 인 요구 사항이 변경되면 혼동이 발생할 수 있으며 범위 크립이 발생할 수도 있습니다. 이러한 전제하에 애자일 개발이 시작되었습니다.

애자일 개발

애자일 개발은 팀 협업을 통해 요구 사항과 솔루션이 진화하는 반복적 인 점진적 개발을 기반으로합니다. 시간 제한이있는 반복적 접근 방식을 권장하고 변화에 대한 빠르고 유연한 대응을 장려합니다. 이것은 이론적 프레임 워크이며 개발 팀이 따라야 할 특정 관행을 지정하지 않습니다. 스크럼은 따라야 할 관행을 정의하는 특정 애자일 프로세스 프레임 워크입니다.

애자일 방법의 초기 구현에는 Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development (1997) 및 Dynamic Systems Development Method (DSDM) (1995)가 포함됩니다. 이들은 이제 총칭하여agile methodologies, 애자일 선언문이 2001 년에 출판 된 후.

애자일 선언

애자일 선언문은 2001 년 소프트웨어 개발자 팀에 의해 발표되었으며, 변화하는 요구 사항과 고객 참여를 수용하고 개발 팀에 부여해야하는 중요성을 강조했습니다.

Agile Manifesto는 다음과 같습니다.

“우리는 소프트웨어를 개발하고 다른 사람들이 그렇게하도록 도와줌으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이 작업을 통해 우리는 다음과 같은 가치를 얻었습니다.

프로세스 및 도구에 대한 개인 및 상호 작용
포괄적 인 문서에 대한 작업 소프트웨어
계약 협상을 통한 고객 협력
계획에 따라 전환에 대응

즉, 오른쪽 항목에는 가치가 있지만 왼쪽 항목에는 더 가치가 있습니다. "

… 애자일 소프트웨어 개발을위한 선언문, 저자 : Beck, Kent, et al. (2001)

Agile Manifesto 항목의 정의

왼쪽의 선언문 항목은 다음과 같이 설명 할 수 있습니다.

선언문 항목	기술
개인과 상호 작용	다음 사항에 중요성을 부여해야합니다. 팀원의 자기 조직화 및 자기 동기 부여 팀 구성원 간의 작업, 설명, 정보에 대한 지속적인 상호 작용
작업 소프트웨어	단기간에 작업 소프트웨어를 제공하면 팀에서 고객의 신뢰와 확신을 얻을 수 있습니다.
고객 협력	고객과 개발 팀의 지속적인 참여는 필요한 수정 사항에 대한 커뮤니케이션을 보장합니다.
변화에 대응	제안 된 변경 사항에 대한 빠른 응답에 초점을 맞 춥니 다. 이는 짧은 기간의 반복으로 가능합니다.

Agile Manifesto의 핵심 요소는 사람들과 협력 능력을 신뢰해야한다는 것입니다. 이러한 이유로 개발 된 특정 애자일 방법론은 프로젝트 라이프 사이클 전반에 걸쳐 팀워크와 협업을 강조함으로써 팀원의 능력을 활용합니다.

애자일의 핵심 원칙

Agile Manifesto는 다음 원칙을 기반으로합니다.

원리	기술
만족과 배달	초기 및 지속적인 작업 소프트웨어를 통한 고객 만족.
환영하는 변화	개발 후기 단계에서도 변화하는 요구 사항을 환영합니다.
자주 전달	작동하는 소프트웨어를 자주 (매월이 아닌 매주) 제공합니다.
의사 소통이 핵심	개발자와 비즈니스맨이 매일 긴밀하게 연결되도록합니다.
환경과 신뢰	동기 부여 된 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 지원을 제공하고 신뢰하십시오.
대면 커뮤니케이션	효율적이고 효과적인 의사 소통을 위해 대면 대화를 장려하십시오.
진보의 척도로서의 소프트웨어	작업 소프트웨어는 진행 상황의 주요 척도입니다.
지속 가능한 개발	개발 전반에 걸쳐 일정한 속도를 유지할 수있는 능력으로 지속 가능한 개발을 촉진합니다.
세부 사항에 대한주의	기술적 우수성과 좋은 디자인에 대한 지속적인 관심.
적은 힘	단순성이 필수적입니다.
자기 조직화 팀	변화하는 상황에 효과적으로 대처하기위한 팀의 정기적 인 관심.

애자일 방법론

DSDM (동적 시스템 개발 방법)

소프트웨어 프로젝트를위한 애자일 프레임 워크입니다. 전통적인 접근 방식을 미세 조정하는 데 사용되었습니다. DSDM의 최신 버전은 DSDM Atern이라고합니다. Atern이라는 이름은 Arctic Tern의 약자입니다. 먼 거리를 이동할 수있는 바닷새는 우선 순위 지정 및 협업과 같은 자연스러운 작업 방식 인 방법의 많은 기능을 나타냅니다.

스크럼

특히 팀 기반 개발 환경에서 작업을 관리하는 방법에 집중하는 가장 인기있는 애자일 프레임 워크입니다. Scrum은 반복 기간이 더 짧은 반복 및 증분 개발 모델을 사용합니다. 스크럼은 구현이 비교적 간단하며 빠르고 빈번한 전달에 중점을 둡니다.

익스트림 프로그래밍 (XP)

민첩한 소프트웨어 개발 유형입니다. 짧은 개발주기의 빈번한 릴리스를 권장하며 이는 생산성을 향상시키고 새로운 고객 요구 사항을 채택 할 수있는 체크 포인트를 도입하기위한 것입니다. 방법론은 전통적인 소프트웨어 엔지니어링 관행의 유익한 요소가 극한 수준으로 이동한다는 아이디어에서 그 이름을 따 왔습니다. (Extreme Programming은 사람들이 고품질 소프트웨어를보다 생산적으로 생산하도록 조직하는 소프트웨어 개발 분야입니다.) XP는 최종 제품의 품질에 상당한 차이를 만드는 새로운 접근 방식으로 분석, 개발 및 테스트 단계를 다룹니다.

테스트 주도 개발 (TDD)

매우 짧은 개발주기의 반복에 의존하는 소프트웨어 개발 프로세스입니다. 먼저 개발자가 원하는 개선 사항 또는 새로운 기능을 정의하는 자동화 된 테스트 케이스를 작성한 다음 해당 테스트를 통과하기 위해 최소한의 코드를 생성합니다. 마침내 새로운 코드를 수용 가능한 표준으로 가져옵니다.

기대다

최종 고객을위한 가치 창출 이외의 목표를 위해 자원 지출을 낭비하는 것으로 간주하여 제거 대상으로 간주하는 생산 관행입니다. 제품이나 서비스를 소비하는 고객의 관점에서 볼 때 가치라는 용어는 고객이 기꺼이 지불 할 행동이나 프로세스로 정의됩니다. Lean은 적은 작업으로 가치를 보존하는 데 중점을 둡니다.

칸반

높은 수준의 생산을 개선하고 유지하는 시스템입니다. Kanban은 조직이 재고 비용을 제어하기 위해 사용하는 전략 인 JIT (Just-In-Time)를 달성하는 한 가지 방법입니다. Kanban은 생산 시스템 전체를 운영하는 데 효과적인 도구가되었으며 개선을 촉진하는 훌륭한 방법임이 입증되었습니다.

결론

지난 10 년 동안 기업은 민첩한 관행을 통해 IT 개발 팀과 프로젝트의 성공과 성과를 극적으로 향상시킨 성공 사례가 계속해서 증가하고 있습니다. 이로 인해 애자일은 미디어 및 기술, 대기업, 심지어 정부를 포함한 다양한 산업 전반에 걸쳐 널리 채택되었습니다.

Agile Framework는 팀이 다음과 같은 이점을 누릴 수 있도록 도와줍니다.

납품 / 시장화 시간 단축
불확실성과 위험 감소
고객 가치에 초점을 맞춰 투자 수익 (ROI) 증대

이러한 다양한 애자일 방법론 중에서 스크럼은 지난 20 년 동안 전 세계적으로 매우 성공적인 것으로 입증되었습니다.

스크럼은 복잡한 제품을 개발하고 유지하기위한 프레임 워크입니다. Ken Schwaber와 Jeff Sutherland는 Scrum을 개발했습니다. 함께, 그들은 스크럼 규칙 뒤에 있습니다.

스크럼 정의

스크럼은 사람들이 복잡한 적응 문제를 해결할 수있는 프레임 워크입니다. 동시에 가장 가치있는 제품을 생산적이고 창의적으로 제공 할 수 있습니다.

스크럼은 1990 년대 초부터 복잡한 제품 개발을 관리하는 데 사용 된 프로세스 프레임 워크입니다. 스크럼은 제품을 만드는 과정이나 기술이 아닙니다. 오히려 다양한 프로세스와 기술을 사용할 수있는 프레임 워크입니다. Scrum은 제품 관리 및 개발 관행의 상대적인 효율성을 명확히하여 개선 할 수 있도록합니다.

Scrum 프레임 워크는 Scrum Teams 및 관련 역할, 이벤트, 아티팩트 및 규칙으로 구성됩니다. 프레임 워크 내의 각 구성 요소는 특정 목적을 제공하며 Scrum의 성공과 사용에 필수적입니다.

Scrum의 규칙은 이벤트, 역할 및 아티팩트를 결합하여 이들 간의 관계와 상호 작용을 제어합니다. Scrum의 규칙은이 튜토리얼 전체에서 설명됩니다.

Note-업계 전반에 걸쳐 스크럼은 문서가 없다는 것을 의미하고 스크럼 팀은 개발자로만 구성된다는 오해가 있습니다. 완전히 그렇지는 않습니다. 이후 섹션에서 이에 대한 설명을 제공합니다.

스크럼 프로세스 프레임 워크

스크럼에서 규정 된 이벤트는 규칙 성을 생성하는 데 사용됩니다. 모든 이벤트는 타임 박스 이벤트이므로 모든 이벤트는 최대 기간을 갖습니다. 이벤트는 다음 장에서 더 자세히 설명합니다.

스프린트

Scrum의 핵심은 잠재적으로 출시 가능한 제품 증분이 생성되는 2 주 또는 1 개월의 타임 박스 인 Sprint입니다. 새로운 스프린트는 이전 스프린트 종료 직후에 시작됩니다. 스프린트는 스프린트 계획, 일일 스크럼, 개발 작업, 스프린트 검토 및 스프린트 회고로 구성됩니다.

스프린트 계획에서 스프린트에서 수행 할 작업은 스크럼 팀이 공동으로 계획합니다.
데일리 스크럼 회의는 스크럼 팀이 활동을 동기화하고 그날의 계획을 세우는 15 분의 타임 박스 이벤트입니다.
Sprint Review는 증분을 검사하고 필요한 경우 제품 백 로그를 변경하기 위해 Sprint가 끝날 때 개최됩니다.
Sprint Retrospective는 Sprint Review 후 다음 Sprint Planning 이전에 발생합니다. 이 회의에서 스크럼 팀은 자체를 검사하고 후속 스프린트 동안 시행 될 개선 계획을 수립합니다.

결론

스크럼은 규칙 성을 가져 오기 위해 특정 규칙, 이벤트 및 역할을 정의하는 프로세스 프레임 워크입니다. 그러나 기본 스크럼 규칙을 위반하지 않는 한 필요에 따라 모든 조직에 적용 할 수 있습니다.

스크럼 팀은 스크럼 마스터, 제품 소유자 및 팀의 세 가지 역할로 구성됩니다.

스크럼 마스터

ScrumMaster (때로는 Scrum Master로 작성되지만 공식 용어는 "Scrum"뒤에 공백이 없음)는 스크럼 프로세스의 키퍼입니다. 그 / 그녀는-

프로세스를 원활하게 실행
생산성에 영향을 미치는 장애물 제거
중요한 회의 조직 및 촉진

제품 소유자

제품 소유자는 제품의 가치와 팀의 업무를 극대화 할 책임이 있습니다. 이것이 수행되는 방법은 조직, 스크럼 팀 및 개인에 따라 크게 다를 수 있습니다.

제품 소유자는 제품 백 로그를 관리하는 유일한 사람입니다. 제품 백 로그 관리에는 다음이 포함됩니다.

제품 백 로그 항목을 명확하게 표현합니다.
목표와 임무를 가장 잘 달성하기 위해 제품 백 로그 항목을 주문합니다.
팀이 수행하는 작업의 가치를 최적화합니다.
제품 백 로그가 모두에게 표시되고 투명하며 명확하게 표시되고 팀이 추가로 작업 할 사항을 보여줍니다.
팀이 제품 백 로그의 항목을 필요한 수준까지 이해하도록합니다.

제품 소유자는 위의 작업을 수행하거나 팀이 수행하도록 할 수 있습니다. 그러나 제품 소유자는 이러한 작업에 대해 책임을집니다.

제품 소유자는위원회가 아니라 한 사람입니다. 제품 소유자는 제품 백 로그에서위원회의 요구를 나타낼 수 있지만 제품 백 로그 항목의 우선 순위를 변경하려는 사람은 제품 소유자에게 문의해야합니다.

제품 소유자가 성공하려면 전체 조직이 자신의 결정을 존중해야합니다. 제품 소유자의 결정은 제품 백 로그의 내용과 순서에 표시됩니다. 어느 누구도 팀에게 다른 요구 사항 세트에서 작업하도록 지시 할 수 없으며 팀은 다른 사람의 말에 따라 행동 할 수 없습니다. 이것은 ScrumMaster에 의해 보장됩니다.

팀

팀은 자기 조직화 및 교차 기능입니다. 이는 팀이 적절하고 프로젝트와 관련된 분석가, 디자이너, 개발자, 테스터 등으로 구성된다는 것을 의미합니다.

업계의 일부 사람들은이 팀을 개발 팀이라고합니다. 그러나 이러한 언급은 팀이 개발자 만 가질 수 있고 다른 역할은 가질 수 없다는 논란으로 이어지고 있습니다. 오해 일 뿐이라는 것은 분명한 이해입니다. 소프트웨어 제품을 개발하려면 모든 역할이 필요하며 이것이 스크럼의 본질입니다. 팀은 협력하여 기능합니다. 교차 기능 팀은 팀의 일부가 아닌 다른 사람에게 의존하지 않고 작업을 수행하는 데 필요한 모든 역량을 갖추고 있으므로 시간과 노력을 절약 할 수 있습니다. Scrum의 팀 모델은 유연성, 창의성 및 생산성을 최적화하도록 설계되었습니다.

최적의 팀 규모는 민첩성을 유지할 수있을만큼 작으며 Sprint 내에서 중요한 작업을 완료 할 수있을만큼 큽니다. 팀 규모는 가능하면 5 명에서 9 명 사이로 유지해야합니다. 5 명 미만의 팀원이 상호 작용을 감소시키고 결과적으로 생산성 향상이 감소합니다. 9 명 이상의 회원을 보유하려면 너무 많은 조정이 필요합니다.

스크럼 팀은 정보의 원활한 흐름과 신속한 문제 해결을 위해 매일 긴밀하게 협력합니다. 스크럼 팀은 제품을 반복적이고 점진적으로 제공하여 피드백 기회를 극대화합니다. 완전한 제품의 증분 제공은 잠재적으로 유용한 작업 제품 버전을 항상 사용할 수 있도록 보장합니다.

ScrumMaster는 아래에 설명 된대로 서비스를 제공하는 훈련 된 책임자입니다.

제품 소유자에 대한 ScrumMaster 서비스

ScrumMaster는 다음을 포함하여 여러 가지 방법으로 제품 소유자에게 서비스를 제공합니다.

효과적인 제품 백 로그 관리를위한 기술 찾기.
스크럼 팀이 명확하고 간결한 제품 백 로그 항목의 필요성을 이해하도록 지원합니다.
경험적 환경에서 제품 계획을 이해합니다.
제품 소유자가 가치를 극대화하기 위해 제품 백 로그를 배열하는 방법을 알고 있는지 확인합니다.
민첩성을 이해하고 연습합니다.
필요에 따라 스크럼 이벤트를 촉진합니다.

스크럼 팀에 대한 ScrumMaster 서비스

ScrumMaster는 다음을 포함하여 여러 가지 방법으로 스크럼 팀에 서비스를 제공합니다.

스크럼 팀을 자기 조직화 및 교차 기능으로 코칭합니다.
고 부가가치 제품을 만들기 위해 스크럼 팀을 돕습니다.
스크럼 팀의 진행에 대한 장애물 제거.
요청 또는 필요에 따라 스크럼 이벤트를 촉진합니다.
스크럼이 아직 완전히 채택되고 이해되지 않은 조직 환경에서 스크럼 팀 코칭.

조직에 대한 ScrumMaster 서비스

ScrumMaster는 다음을 포함하여 여러 가지 방법으로 조직에 서비스를 제공합니다.

조직의 스크럼 채택을 이끌고지도합니다.
조직 내 스크럼 구현 계획.
직원과 이해 관계자가 스크럼 및 경험적 제품 개발을 이해하고 시행하도록 돕습니다.
스크럼 팀의 생산성을 높이는 변화를 일으 킵니다.
조직에서 스크럼 적용의 효율성을 높이기 위해 다른 스크럼 마스터와 협력합니다.

결론

스크럼 프로세스 프레임 워크는 일련의 이벤트 및 해당 아티팩트를 통해 볼 수 있습니다. 스크럼 이벤트는 타임 박스 이벤트입니다. 즉, 프로젝트에서 모든 스크럼 이벤트에는 미리 정의 된 최대 기간이 있습니다. 이러한 이벤트는 프로젝트에 관련된 모든 사람에게 프로젝트 진행 상황에 대한 투명성을 제공합니다. 스크럼의 중요한 이벤트는 다음과 같습니다.

스프린트
스프린트 계획
일일 스크럼 회의
스프린트 검토
스프린트 회고전

스프린트

Sprint 동안 작동하는 제품 Increment가 개발됩니다. 일반적으로 2 주 또는 1 개월의 기간이며이 기간은 프로젝트의 모든 스프린트에 대해 일정하게 유지됩니다. 프로젝트의 다른 스프린트에 대해 다양한 기간을 가질 수 없습니다. 새로운 스프린트는 이전 스프린트 종료 직후에 시작됩니다.

스프린트 목표는 스프린트를위한 목표 세트입니다. Increment를 구축하는 이유에 대한 지침을 팀에 제공합니다. Sprint Planning 회의 중에 생성됩니다. 스프린트의 범위가 명확 해지고 요구 사항에 대해 더 많이 알게됨에 따라 제품 소유자와 팀간에 재협상됩니다. 따라서, 각 Sprint는 그것과 연관되어 있으며, 무엇을 구축 할 것인지 정의, 설계, 구축을 안내 할 유연한 계획, 개발 작업 및 그에 따른 제품 증분을 결정합니다.

스프린트 목표가 쓸모 없게되면 스프린트를 취소해야합니다. 이는 조직이 방향을 바꾸거나 시장 또는 기술 조건이 변경되는 경우 발생할 수 있습니다. 스프린트는 제품 소유자 만 취소 할 수 있지만 다른 사람도 동일한 영향을 미칩니다.

단기간 스프린트의 특성으로 인해 스프린트 중 취소는 거의 의미가 없습니다. 스프린트 취소는 다른 스프린트로 재구성되기 위해 리소스를 소비하므로 매우 드문 경우입니다.

스프린트가 취소되고 스프린트 중에 생성 된 작업의 일부가 잠재적으로 해제 가능한 경우 제품 소유자는 일반적으로이를 수락합니다. 모든 불완전한 스프린트 백 로그 항목은 제품 백 로그에 다시 저장됩니다.

스프린트 계획

Sprint에서 수행 할 작업은 Sprint Planning Meeting에서 계획됩니다. 스프린트 계획 회의는 2 주 스프린트의 경우 최대 4 시간, 스프린트 1 개월의 경우 8 시간입니다. 회의가 진행되고 필요한 모든 참석자가 참석하고 예정된 회의의 목적을 이해하는지 확인하는 것은 스크럼 마스터의 책임입니다. 스크럼 마스터는 회의를 중재하여 토론 및 마감의 지속성을 제 시간에 모니터링합니다.

Sprint Planning은 다음 두 가지 질문에 중점을 둡니다.

Sprint Increment에서 무엇이 필요하고 전달할 수 있습니까?
Sprint 실행에 필요한 작업은 어떻게 이루어 집니까?

이 회의에 대한 입력은 다음과 같습니다.

제품 백 로그
최신 제품 증분
스프린트 중 팀의 예상 용량
팀의 과거 성과

스크럼 팀은 스프린트 중에 개발할 수있는 기능에 대해 논의합니다. 제품 소유자는 제품 백 로그 항목에 대한 설명을 제공합니다. 팀은 Sprint에서 수행 할 수있는 작업을 평가하는 데 가장 적합한 Sprint 제품 백 로그에서 항목을 선택합니다. 팀은 분석가, 디자이너, 개발자 및 테스터로 구성됩니다. 작업은 협업 방식으로 수행되므로 재 작업을 최소화합니다.

스크럼 팀은 스프린트 목표를 제시합니다. 스프린트 목표는 제품 증분을 구축하는 이유에 대한 지침을 팀에 제공하는 목표입니다. 그런 다음 팀은 Sprint 동안 선택한 기능을 작동하는 제품 증분으로 빌드하는 방법을 결정합니다. 이 Sprint에 대해 선택된 제품 백 로그 항목과이를 제공하기위한 계획을 Sprint 백 로그라고합니다.

스프린트 중 작업은 스프린트 계획 중에 추정되며 크기 및 / 또는 노력이 다양 할 수 있습니다. Sprint Planning 회의가 끝날 때까지 작업은 하루 이하의 작업으로 나뉩니다. 이는 작업 할당의 용이성을 활성화하고 완료를 추적하기위한 것입니다. 팀이 작업이 너무 많거나 적다는 것을 알게되면 선택한 제품 백 로그 항목을 제품 소유자와 재협상 할 수 있습니다.

팀은 또한 다른 사람 (스크럼 팀의 일부가 아님)을 Sprint Planning 회의에 초대하여 기술 또는 도메인 조언을 얻거나 견적을받을 수 있습니다.

일일 스크럼 회의

데일리 스크럼 회의는 팀을위한 15 분 회의로, 지난 데일리 스크럼 회의 이후의 작업을 빠르게 이해하고 다음 24 시간에 대한 계획을 수립하기 위해 매일 진행됩니다. 이 회의는 일일 스탠드 업 회의라고도합니다.

일일 스크럼 회의는 복잡성을 줄이기 위해 매일 같은 시간과 같은 장소에서 개최됩니다.

회의 중에 각 팀원은 다음과 같이 설명합니다.

그는 어제 팀이 스프린트 목표를 달성하는 데 도움이 된 무엇을 했습니까?
그는 오늘 팀이 스프린트 목표를 달성하도록 돕기 위해 무엇을 할 것입니까?
그는 자신이나 팀이 스프린트 목표를 달성하는 데 방해가되는 장애물이 있습니까?

Daily Scrum은 상태 추적 이벤트로 오인되지만 사실은 계획 이벤트입니다.

회의에 대한 입력은 팀이 스프린트 목표를 달성하기 위해 수행하는 방식이어야하며 출력은 스프린트 목표를 달성하기위한 팀의 노력을 최적화하는 새롭거나 수정 된 계획이어야합니다.

스크럼 마스터가 일일 스크럼 회의를 조정하고 회의의 목표가 충족되도록 보장하지만 회의는 팀의 책임입니다.

필요한 경우, 팀은 일일 스크럼 회의 직후에 만나 세부적인 논의를하거나 나머지 Sprint 작업을 다시 계획 할 수 있습니다.

다음은 Daily Scrum Meetings의 이점입니다.

팀 내 커뮤니케이션을 개선합니다.
Sprint에 미치는 영향을 최소화하기 위해 장애를 조기에 제거하기 위해 장애가있는 경우 식별합니다.
빠른 의사 결정을 강조하고 촉진하십시오.
팀의 지식 수준을 향상시킵니다.

스프린트 검토

Sprint Review는 모든 Sprint가 끝날 때 열립니다. 스프린트 검토 중에 릴리스되는 증분에 대한 프레젠테이션이 검토됩니다. 이 회의에서 스크럼 팀과 이해 관계자는 Sprint에서 수행 된 작업을 이해하기 위해 협력합니다. 이를 바탕으로 스프린트 중 제품 백 로그의 변경 사항을 바탕으로 참석자들은 가치를 최적화하는 데 필요한 다음 단계에 도달합니다. 따라서 Sprint Review의 목표는 피드백을 얻고 함께 진행하는 것입니다.

Sprint Review는 일반적으로 2 주 동안 2 시간 동안, 1 개월 동안 4 시간 동안 진행됩니다.

스크럼 마스터는 다음을 보장합니다.

회의가 진행됩니다.
참가자들은 목적을 이해합니다.
회의는 필요한 의제에 초점을 맞추고 필요한 기간 내에 완료됩니다.

Sprint Review에는 다음과 같은 측면이 포함됩니다.

참석자에는 제품 소유자가 초대 한 스크럼 팀과 주요 이해 관계자가 포함됩니다.
제품 소유자는 스프린트 동안 완료된 제품 백 로그 항목과 완료되지 않은 항목을 설명합니다.
팀은 Sprint 동안 잘 된 점, 발생한 문제 및 문제 해결 방법에 대해 논의합니다.
팀은 완료 한 작업을 보여주고 Increment에 대한 질문이있는 경우 답변합니다.
그런 다음 전체 그룹이 다음에 수행 할 작업에 대해 논의합니다. 따라서 Sprint Review는 후속 Sprint의 Sprint Planning에 귀중한 정보를 제공합니다.
그런 다음 스크럼 팀은 제품 증분의 다음 예상 릴리스에 대한 일정, 예산, 잠재적 기능 및 시장을 검토합니다.
Sprint Review의 결과는 업데이트 된 제품 백 로그로, 다음 스프린트에 대한 가능한 제품 백 로그 항목을 정의합니다.

스프린트 회고

Sprint Retrospective는 Sprint Review 후 다음 Sprint Planning 이전에 발생합니다. 이것은 보통 2 주간 스프린트의 경우 1 시간 회의이고 1 개월간 스프린트의 경우 3 시간 회의입니다.

Sprint Retrospective의 목적은 다음과 같습니다.

사람, 관계, 프로세스 및 도구와 관련하여 지난 Sprint에서 얻은 학습을 결합하십시오.
잘 된 주요 항목과 잠재적 인 개선 사항을 식별합니다.
제품 품질 향상을위한 개선 구현 계획 수립.

Sprint Retrospective는 Scrum 팀이 Scrum 프로세스 프레임 워크 내에서 조사하고 개선하여 다음 Sprint 결과를보다 효과적으로 만들 수있는 기회입니다.

Reference

스크럼 아티팩트는 개발중인 제품, 수행 한 활동 및 프로젝트에서 계획중인 활동을 이해하기 위해 스크럼 팀과 이해 관계자가 알아야하는 주요 정보를 제공합니다. 다음 아티팩트는 Scrum Process Framework에 정의되어 있습니다.

제품 백 로그
스프린트 백 로그
번 다운 차트
Increment

이들은 스크럼 프로젝트에서 필요한 최소 아티팩트이며 프로젝트 아티팩트는 이것으로 제한되지 않습니다.

제품 백 로그

제품 백로 그는 최종 제품의 일부로 필요한 기능의 순서가 지정된 목록이며 제품 변경 사항에 대한 단일 요구 사항 소스입니다.

제품 백 로그에는 향후 릴리스에서 제품에 적용될 변경 사항을 구성하는 모든 기능, 기능, 요구 사항, 개선 사항 및 수정 사항이 나열됩니다. 제품 백 로그 항목에는 설명, 주문, 견적 및 값의 속성이 있습니다. 이러한 항목을 일반적으로 사용자 스토리라고합니다. 제품 소유자는 내용, 가용성 및 주문을 포함하여 제품 백 로그에 대한 책임이 있습니다.

제품 백로 그는 진화하는 아티팩트입니다. 가장 초기 버전에는 처음에 알려진 가장 잘 이해 된 요구 사항 만 포함될 수 있습니다. 제품 백로 그는 제품으로 개발되고 사용 환경이 진행됩니다. 제품 백로 그는이를 효과적으로 만드는 데 필요한 사항을 통합하기 위해 지속적으로 변경됩니다. 제품이 존재하는 한 제품 백 로그도 존재합니다.

빌드중인 제품이 사용되고 가치가 증가함에 따라 제품 백로 그는 더 크고 완전한 목록이됩니다. 비즈니스 요구 사항, 시장 조건 또는 기술의 변경으로 인해 제품 백 로그가 변경되어 실시간 아티팩트가됩니다.

제품 백 로그 세분화는 제품 백 로그 항목에 세부 사항, 추정 및 우선 순위를 추가하는 것을 의미합니다. 이것은 제품 소유자와 팀이 수행하는 지속적인 프로세스입니다. 스크럼 팀은 개선 방법과시기를 결정합니다.

제품 백 로그 항목은 제품 소유자 또는 제품 소유자의 재량에 따라 언제든지 업데이트 할 수 있습니다.

순서가 높은 제품 백 로그 항목은 일반적으로 순서가 낮은 항목보다 더 명확하고 상세합니다. 보다 명확하고 세부적인 내용을 바탕으로보다 정확한 추정이 이루어집니다. 순서가 낮을수록 세부 사항이 적습니다.

다가오는 Sprint의 후보 요건이 될 수있는 제품 백 로그 항목은 이러한 항목이 Sprint 중에 개발 될 수 있도록 개선됩니다. 하나의 Sprint 내에서 팀이 개발할 수있는 제품 백 로그 항목은 Sprint 계획 회의에서 선택할 준비가 된 것으로 간주됩니다.

스프린트 백 로그

Sprint Backlog는 Sprint에 대해 선택된 제품 백 로그 항목 집합이며 제품 증분을 제공하고 Sprint 목표를 실현하기위한 계획입니다.

Sprint Backlog는 다음 증분에서 사용할 수있는 기능과 해당 기능을 작동 제품 증분으로 제공하는 데 필요한 작업에 대한 팀의 예측입니다.

스프린트 백로 그는 이해할 수 있지만 팀이 데일리 스크럼에서 추적 할 수있는 충분한 세부 정보가 포함 된 계획입니다. 팀은 스프린트 동안 스프린트 백 로그를 수정하고 스프린트 동안 스프린트 백 로그가 나타납니다. 이러한 출현은 팀이 계획을 통해 작업하고 스프린트 목표를 달성하는 데 필요한 작업에 대해 더 많이 알게 될 때 발생합니다.

새로운 작업이 필요하면 팀은이를 Sprint Backlog에 추가합니다. 작업이 수행되거나 완료되면 남은 예상 작업이 업데이트됩니다. 계획의 요소가 불필요한 것으로 간주되면 제거됩니다. 오직 팀만이 스프린트 동안 스프린트 백 로그를 변경할 수 있습니다. 스프린트 백로 그는 팀이 스프린트 중에 달성 할 계획 인 작업을 매우 눈에 잘 띄는 실시간 그림으로, 전적으로 팀에 속합니다.

증가

증분은 이전의 모든 스프린트 증분과 결합 된 스프린트 동안 완료된 모든 제품 백 로그 항목의 합계입니다. Sprint가 끝나면 새로운 Increment는 작동하는 제품이어야합니다. 즉, 사용 가능한 상태에 있어야합니다. 제품 소유자가 실제로 릴리스하기로 결정했는지 여부와 관계없이 작동 상태 여야합니다.

스크럼 팀은 증분으로 간주되는 항목에 대한 합의를 가져야합니다. 이것은 스크럼 팀에 따라 크게 다르지만 팀 구성원은 작업이 완료된다는 것이 의미하는 바를 공유해야합니다. 제품 증분에 대한 작업이 완료되는시기를 평가하는 데 사용됩니다.

동일한 이해가 팀이 스프린트 계획 중에 선택할 수있는 제품 백 로그 항목 수를 아는 데 도움이됩니다. 각 Sprint의 목적은 잠재적으로 해제 가능한 기능의 증분을 제공하는 것입니다.

Teams는 매 스프린트마다 제품 기능을 향상시킵니다. 이 증분은 사용할 수 있으므로 제품 소유자는 즉시 릴리스하도록 선택할 수 있습니다. 증분에 대한 이해가 개발 조직의 규약, 표준 또는 지침의 일부인 경우 모든 스크럼 팀은 최소한이를 따라야합니다. 개발 조직의 규칙이 아닌 경우 스크럼 팀은 제품에 적합한 Increment 정의를 정의해야합니다.

각 증분은 모든 이전 증분에 추가되며 철저한 테스트를 거쳐 모든 증분이 함께 작동하는지 확인합니다.

스크럼 팀이 성숙함에 따라 Increments의 정의가 더 높은 품질에 대한 더 엄격한 기준을 포함하도록 확장 될 것으로 예상됩니다. 모든 제품에는 수행되는 모든 작업의 표준 인 Increment 정의가 있어야합니다.

스프린트 번 다운 차트

스프린트의 어느 시점에서든 스프린트 백 로그에 남아있는 총 작업량을 합산 할 수 있습니다. 팀은 모든 일일 스크럼에 대해 남아있는 총 작업량을 추적하여 스프린트 목표 달성 가능성을 예측합니다. 스프린트 전체에서 남은 작업을 추적함으로써 팀은 진행 상황을 관리 할 수 있습니다.

Sprint Burn-Down Chart는 스크럼 팀이 소비 한 작업의 추세를 파악하는 방법입니다. 이것은 스프린트 목표를 향한 스프린트 진행 상황을 모니터링하는 데 유용한 기술임이 입증되었습니다.

제품 소유자는 최소한 모든 Sprint Review에서 남은 총 작업량을 추적합니다. 제품 소유자는이 금액을 이전 Sprint 검토에서 남은 작업량과 비교하여 목표에 대해 원하는 시간까지 예상 작업을 완료하기위한 진행 상황을 평가합니다. 이 정보는 모든 이해 관계자와 공유됩니다.

결론

스크럼의 역할, 이벤트, 아티팩트 및 규칙은 불가피합니다. Scrum의 일부만 구현 된 경우 결과는 Scrum이 아닙니다. 스크럼은 다른 기술, 방법론 및 관행과 일치하는 경우 전체적으로 구현되고 잘 작동해야합니다.

Reference

아시다시피 사용자 스토리는 일반적으로 제품 기능을 설명하는 데 사용되며 스크럼 아티팩트의 일부를 구성합니다. Product Backlog 과 Sprint Backlog.

사용자 스토리

소프트웨어 개발에서 제품 기능은 중요한 역할을합니다. 사용자가 궁극적으로 최종 제품에서 사용하기를 좋아하는 기능입니다. 일반 용어로는 요구 사항이라고합니다. 소프트웨어 개발 프로젝트의 성공은 사용자 요구 사항을 정확하고 적절하게 이해 한 다음이를 최종 제품에 구현하는 데 있습니다. 따라서 요구 사항이나 제품 기능은 개발 프로젝트 팀에 완전히 알려야합니다.

1999 년 Kent Beck은 제품 기능에 대한 사용자 스토리라는 용어를 만들었습니다. 그는 사용자 스토리가 시스템이 자신을 위해 무엇을 할 수 있는지가 아니라 자신이 원하는 것을 사용자 관점에서 설명한다고 설명했습니다. 따라서 뷰는 제품에서 사용자로 완전히 바뀌었고 사용자 스토리는 모든 Agile 프레임 워크의 요구 사항에 대한 사실상의 표준이되었습니다.

Scrum 프로젝트에서 제품 백로 그는 사용자 스토리 목록입니다. 이러한 사용자 스토리는 우선 순위가 지정되고 Sprint 계획 회의의 Sprint 백 로그에 포함됩니다.

추정치는 또한 사용자 스토리를 기반으로하며 제품의 크기는 사용자 스토리 포인트로 추정됩니다.

사용자 스토리 구조

사용자 스토리 구조는 다음과 같습니다.

A와 <사용자의 유형> ,

<작업 수행>을 원합니다 .

그래서 <나는 약간의 목표 / 이익 / 가치를 달성 할 수있다> .

ATM에서 현금을 인출하는 은행 고객의 시나리오에 대해 사용자 스토리가 어떻게 구성되는지 살펴 보겠습니다.

사용자 스토리 : 고객의 현금 인출

로 Customer,

나는 원한다 withdraw cash from an ATM,

그래서 I don't have to wait in line at the Bank

사용자 스토리 수락 기준

또한 각 사용자 스토리에는 수락 기준이 정의되어 있으므로 사용자 스토리 구현의 정확성은 수락 기준에 기반한 수락 테스트를 통과하여 확인됩니다.

다음은 사용자 스토리 고객의 현금 인출 예시에 대한 샘플 수락 기준입니다.

Acceptance Criterion 1:

Given 계정이 신용 할 수 있는지

그리고 카드는 유효합니다
그리고 디스펜서에는 현금이 들어 있습니다.

When 고객이 현금을 요구하다

Then 계좌가 인출되었는지 확인

그리고 현금이 지급되었는지 확인하십시오.
그리고 카드가 반환되었는지 확인하십시오.

Acceptance Criterion 2:

Given 계정이 초과 인출되었음을

그리고 카드는 유효합니다

When 고객이 현금을 요구하다

Then 거부 메시지가 표시되는지 확인

그리고 현금이 지급되지 않도록하십시오
그리고 카드가 반환되었는지 확인하십시오.

사용자 스토리 작성

제품 소유자는 제품 백 로그 및 사용자 스토리에 대한 책임이 있습니다. 그러나 제품 소유자 만 사용자 스토리를 작성한다는 의미는 아닙니다. 스크럼 팀의 누구나 사용자 스토리를 작성할 수 있으며 요구 사항이 개선되고 새로운 기능이 추가됨에 따라 활동을 프로젝트 전체에 분산시킬 수 있습니다.

사용자 스토리의 비 기능적 요구 사항

비 기능적 요구 사항을 사용자 스토리에도 통합 할 수 있습니다. 주어진 ATM 예에서 사용자가 365 일 24 시간 365 일 사용할 수있는 ATM은 사용 사례로 설명 할 수있는 비 기능적 요구 사항입니다.

사용자 스토리 관리

사용자 스토리는 제품 백 로그에서 관리됩니다. 사용자 스토리는 우선 순위에 따라 정렬됩니다. 가장 우선 순위가 높은 사용자 스토리는 세부 수준으로 세분화되고 가장 낮은 우선 순위 사용자 스토리는 더 낮은 세부 수준으로 유지됩니다. 모든 스프린트에 대해 가장 우선 순위가 높고 세분화 된 사용자 스토리가 스프린트 백 로그에 포함됩니다. 사용자 스토리가 제품 백 로그에 추가 될 경우 우선 순위가 먼저 결정되고 우선 순위에 따라 위치에 따라 배치됩니다. 사용자 스토리는 언제든지 우선 순위를 다시 지정할 수 있습니다. 필요한 경우 사용자 스토리를 제거 할 수도 있습니다.

사용자 스토리의 이점

사용자 스토리의 주요 이점은 사용자 중심 정의 자체에 있습니다. 이는 궁극적으로 관련 사용자 시나리오에서 제품을 사용할 사용자이기 때문입니다. 최종 사용자와 팀 구성원을 연결합니다.
사용자 스토리 자체의 구문은 사용자가 달성하고자하는 목표 나 이익 또는 가치를 포착하도록 보장합니다.
수용 기준은 사용자 스토리 자체의 일부를 구성하므로 스크럼 팀에 추가 이점이 될 것입니다.
프로젝트 실행 과정에서 사용자 스토리를 변경할 수 있습니다. 사용자 스토리의 범위가 커지면 더 작은 사용자 스토리로 분할해야합니다. 수락 기준의 조건도 변경할 수 있습니다.
각 스프린트가 끝날 때 작업 제품 증분이 사용자에게 전달되면 스크럼 팀은 스프린트 검토 회의에서 사용자로부터 피드백을받을 수 있습니다. 이를 통해 지속적으로 제품에 피드백을 통합 할 수 있습니다.

결론

Scrum의 사용자 스토리는 사용자를 Scrum 팀에 더 가깝게 만들고 마지막 순간의 놀라움을 방지합니다.

스프린트 추적은 일반적으로 번 다운 차트를 사용하여 수행됩니다. 번 다운 차트는 남은 작업 시간을 일별 시간으로 보여줍니다. 예를 들어 2 주 스프린트를 고려해 보겠습니다.

Sprint Duration: 이주

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

따라서 스프린트 시작시 남은 총 노력은 2 * 5 * 6 * 6 = 360 시간입니다.

따라서 이상적인 시나리오에서는 남은 작업에서 36 시간의 작업이 줄어들고 번 다운 차트는 다음과 같이 보입니다.

스프린트 작업이 매일 계획대로 수행되면 스크럼 진행률이 거의 이상적인 바에 맞춰집니다.

스프린트 작업이 지연되고 시간 약속이 충족되지 않으면 번 다운 차트는 다음과 같습니다.

그러나 번 다운 차트가 매일 작성되고 미끄러짐이 조기에 알려 지므로 스프린트 타임 라인을 맞추기 위해 시정 조치를 취할 수 있습니다. 타임 라인을 맞추기 위해 팀이 늘어나고 번 다운 차트가 다음과 같이 보인다고 가정합니다.

따라서 스프린트의 어느 시점에서나 스프린트에 남아있는 총 작업량을 시각화 할 수 있으며 스프린트 타임 라인을 충족 할 가능성을 개선 할 수 있습니다.

결론

번 다운 차트는 스크럼 팀이 진행 상황과 스프린트 목표를 달성하기 위해 수행해야하는 작업을 추적하는 데 도움이됩니다.

Scrum Projects에서 추정은 Sprint Planning Meeting 동안 전체 팀이 수행합니다. 추정의 목적은 우선 순위에 따라 스프린트에 대한 사용자 스토리와 스프린트의 타임 박스 동안 제공 할 팀의 능력을 고려하는 것입니다.

제품 소유자는 우선 순위가 지정된 사용자 스토리가 명확하고 추정 될 수 있으며 제품 백 로그의 시작 부분으로 이동하도록합니다.

전체적으로 스크럼 팀이 제품 증분의 제공을 담당하므로 제품 증분의 크기와이를 위해 필요한 노력을 기반으로 Sprint에 대한 사용자 스토리를 선택하는 데주의를 기울일 것입니다.

제품 증분의 크기는 사용자 스토리 포인트로 추정됩니다. 규모가 결정되면 과거 데이터, 즉 생산성이라고하는 사용자 스토리 포인트 당 노력을 통해 노력이 추정됩니다.

스크럼 추정 기법

사용자 스토리의 스크럼 추정은 각 사용자 스토리의 난이도를 기준으로합니다. 난이도를 평가하기 위해 특정 척도가 사용됩니다.

스크럼 추정에 사용되는 몇 가지 유형의 척도가 있습니다. 다음은 몇 가지 예입니다.

숫자 크기 (1 ~ 10)
티셔츠 사이즈 (XS, S, M, L, XL XXL, XXXL)
피보나치 수열 (1, 2, 3, 5, 8, 13, 21, 34 등)
개 품종 (치와와, ………, 그레이트 데인)

추정 기술은 일반적으로 전체 스크럼 팀이 스케일의 값에 익숙하고 익숙한 방식으로 선택됩니다. 가장 일반적으로 사용되고 가장 인기있는 기술은 피보나치 수열을 기반으로하는 Planning Poker입니다.

포커 기법 기획

Planning Poker Estimation Technique에서 사용자 스토리에 대한 견적은 플래닝 포커를 통해 도출됩니다. 전체 스크럼 팀이 참여하여 신속하지만 신뢰할 수있는 추정치를 산출합니다.

플래닝 포커는 한 벌의 카드로 플레이됩니다. 피보나치 수열이 사용됨에 따라 카드에는 1, 2, 3, 5, 8, 13, 21, 34 등의 숫자가 있습니다.이 숫자는 스토리 포인트를 나타냅니다. 각 견적자는 카드 한 벌을 가지고 있습니다. 카드의 숫자는 팀원 중 한 명이 카드를 들고있을 때 모든 팀원이 볼 수있을만큼 충분히 커야합니다.

팀원 중 한 명이 중재자로 선택됩니다. 중재자는 추정되는 사용자 스토리에 대한 설명을 읽습니다. 견적 자에게 질문이 있으면 제품 소유자가 대답합니다.

각 견적자는 자신의 견적을 나타내는 카드를 개인적으로 선택합니다. 모든 견적가가 선택하기 전까지는 카드가 표시되지 않습니다. 이때 모든 팀원이 각 견적을 볼 수 있도록 모든 카드를 동시에 뒤집어 들고 있습니다.

첫 번째 라운드에서는 추정치가 다를 가능성이 큽니다. 높고 낮은 추정치는 추정 이유를 설명합니다. 모든 논의는 이해를위한 것이며 개인적으로 어떤 것도 다루지 않도록주의해야합니다. 중재자는 동일하게 보장해야합니다.

팀은 몇 분 더 이야기와 추정치를 논의 할 수 있습니다.

사회자는 특정 이야기가 전개 될 때 도움이 될 토론에 대해 메모를 할 수 있습니다. 토론 후 각 견적자는 카드를 다시 선택하여 재평가합니다. 카드는 모든 사람이 추정 할 때까지 다시 한 번 비공개로 유지되며, 그 시점에서 동시에 넘겨집니다.

추정치가 스토리에 사용할 수있는 단일 추정치로 수렴 될 때까지 프로세스를 반복하십시오. 추정 라운드 수는 사용자 스토리마다 다를 수 있습니다.

포커 견적 계획의 이점

계획 포커는 세 가지 추정 방법을 결합합니다.

Expert Opinion: 전문가 의견 기반 추정 접근 방식에서 전문가는 무언가가 얼마나 오래 걸리거나 얼마나 큰지 묻습니다. 전문가는 자신의 경험이나 직감 또는 직감에 따라 견적을 제공합니다.

Expert Opinion Estimation은 일반적으로 시간이 많이 걸리지 않으며 일부 분석 방법에 비해 더 정확합니다.

Analogy: Analogy Estimation은 사용자 스토리의 비교를 사용합니다. 추정 아래의 사용자 스토리는 이전에 구현 된 유사한 사용자 스토리와 비교됩니다. 추정치는 입증 된 데이터를 기반으로하므로 정확한 결과를 얻을 수 있습니다.

Disaggregation: 분할 추정은 사용자 스토리를 더 작고 추정하기 쉬운 사용자 스토리로 분할하여 수행됩니다. Sprint에 포함될 사용자 스토리는 일반적으로 개발하는 데 2 ~ 5 일 정도 걸립니다. 따라서 더 오래 걸릴 수있는 사용자 스토리는 더 작은 사용 사례로 분할되어야합니다. 이 접근 방식은 또한 비교할만한 많은 스토리가 있음을 보장합니다.

결론

계획 포커는 즐겁지만 생산적인 추정 방법입니다. 최종 추정치가 도착하기 전에 세션이 토론을 위해 열려 있기 때문에 팀이 쉽게 합의에 도달하고 사용자 스토리 구현에 대한 광범위한 시각을 가질 수 있습니다.

스크럼 도구는 스크럼 프로젝트의 계획 및 추적을 용이하게합니다. 제품 백 로그 관리, 스프린트 백 로그, 스프린트 계획 및 추적, 번 다운 차트 표시, 일일 스크럼 회의 수행, 스크럼 회고전 수행을위한 단일 장소를 제공합니다.

다양한 유형의 스크럼 도구를 사용할 수 있습니다. 일부는 무료 (오픈 소스)이고 일부는 유료이며 일부는 증류 된 버전의 도구를받습니다. 그러나 모든 기능과 확장 성을 얻으려면 정식 버전을 구입해야합니다.

사용 가능한 스크럼 도구

다음은 현재 시장에서 사용 가능한 일부 스크럼 도구 목록입니다. 오픈 소스 도구는 별표로 표시됩니다.

Axosoft	에어 자일	애자일 조종석	Jira (GreenHopper)	섞다
스크럼 와이즈	스크럼을위한 Agilo	바나나 스크럼	쿠 나기	OnTime Now
버전 1	AgileWrap	일일 스크럼	간격	팡고 스크럼
Acunote	애자일 추적 도구 *	Digaboard *	iMeta 민첩성	중추 추적기
Agile Agenda	애자일 작업	EasyBacklog	아이스 스크럼 *	pmScrum
애자일 벤치	애자일 수프	PMT 설명	한 소프트	Prj 플래너
애자일 버디	애자일 관리자	애자일 익스프레스 *	GravityDev	프로젝트 카드
애자일 팬 *	애자일 로그	파이어 스크럼 *	지점*	양자 속삭임
빠른 스크럼	Retrospectiva *	스크럼 드	스크럼 팩토리 *	스크럼 피
Rally Dev	스크 리치 *	스크럼 대시 보드 *	스크럼 에지	스크럼 패드
Redmine 백 로그	스크럼 2 Go	스크럼 데스크	스크럼도	스크럼 트윗
스 크럼프	스크럼 시간 *	스크럼 와이즈	솔루션 팩토리 선택	태클*
도시 거북	스크럼 도구	스크럼 작품	타임 박스	톡 쏘는 오렌지 스크럼

결론

일반적으로 민첩한 스크럼은 문서 작업이 없음을 의미하지 않습니다. 스크럼 아티팩트가 정의되고 스크럼 계획 및 추적이 잘 확립되었습니다.

스크럼 도구는 스크럼 프로젝트에 관한 정보를 캡처하고 추적하는 데 유용합니다. 도구의 선택은 다른 도구에 대한 요구 사항 외에도 조직에서 요구하는 기능에 따라 다릅니다.

Scrum은 고객, 팀 구성원 및 관련 이해 당사자 간의 지속적인 협업을 지원합니다. 타임 박스 접근 방식과 제품 소유자의 지속적인 피드백을 통해 항상 필수 기능을 갖춘 작업 제품을 보장합니다. 또한 Scrum은 프로젝트의 다양한 역할에 다른 이점을 제공합니다.

고객 혜택

스프린트는 더 짧은 기간이며 모든 스프린트 계획에서 우선 순위가 지정된 사용자 스토리가 사용됩니다. 이는 모든 스프린트 제공시 고객이 요구하는 기능이 즉시 포함되도록합니다. 또한 고객이 변경 요청을 제기하면 현재 스프린트에 흡수되거나 바로 다음 스프린트에 포함됩니다. 따라서 개발 팀은 고객의 요구 사항에 매우 빠르게 응답합니다.

조직에 대한 이점

조직은 우선 순위가 지정된 사용자 스토리를 개발하는 데 필요한 노력에 집중할 수 있으므로 오버 헤드와 재 작업을 줄일 수 있습니다. 고객에 대한 스크럼의 특정 이점으로 인해 개발 팀의 효율성 향상, 고객 만족 및 이에 따른 고객 유지 및 고객 참조가 가능합니다. 그것은 조직의 시장 잠재력을 증가시킵니다.

제품 관리자의 이점

제품 관리자는 프로젝트에서 제품 소유자 역할을합니다. 제품 소유자의 책임은 고객 만족을 보장하는 것입니다. Scrum은 빠른 응답, 작업 우선 순위 지정, 변경 사항 흡수를 용이하게하기 때문에 제품 관리자는 작업이 고객 요구에 맞게 조정되었는지 쉽게 확인할 수 있으며 결과적으로 고객 만족을 보장합니다.

프로젝트 관리자의 이점

프로젝트 관리자는 프로젝트에서 스크럼 마스터 역할을합니다. Scrum의 협업 특성은 쉽고 구체적인 계획 및 추적을 용이하게합니다. 번 다운 차트를 사용하여 남은 작업을 이해하고 데일리 스크럼 회의는 프로젝트 관리자에게 항상 프로젝트 상태에 대한 인식을 제공합니다. 이러한 인식은 프로젝트를 모니터링하고 문제를 신속하게 파악하고 해결하는 데 필수적입니다.

개발팀의 이점

스프린트의 타임 박스 특성과 매 스프린트가 끝날 때마다 작동하는 제품 증분 제공으로 인해 개발 팀은 작업이 즉시 사용되는 것을보고 싶어합니다. 내장 된 팀 협업은 팀이 자신이하는 일을 즐길 수 있도록합니다. 모든 스프린트에 대한 사용자 스토리는 고객 우선 순위를 기반으로하기 때문에 팀은 또한 자신의 작업이 소중하다는 것을 이해합니다.

Scrum 인증은 Scrum Alliance에서 제공합니다. 다음 인증이 제공됩니다-

공인 ScrumMaster (CSM)
공인 스크럼 제품 소유자 (CSPO)
공인 스크럼 실무자 (CSP)
공인 스크럼 코치 (CSC)
공인 스크럼 트레이너 (CST)

공인 ScrumMaster (CSM)

공인 스크럼 마스터는 스크럼 얼라이언스의 회원이되고 스크럼 마스터의 역할을 수행하며 다른 인증을받을 수있는 기본 인증입니다. 인증에는 CSM 과정에 참석해야합니다. 그 후 응시자는 Scrum 멤버십 및 CSM 온라인 시험에 대한 세부 정보가 명시된 이메일을받습니다. 시험을 치른 후 응시자는 Certified ScrumMaster (CSM) 인증을받습니다.

공인 스크럼 제품 소유자 (CSPO)

공인 스크럼 제품 소유자는 Scrum Alliance의 회원이되고 제품 소유자 역할을 수행하며 다른 인증을받을 수있는 기본 인증입니다.

공인 스크럼 실무자 (CSP)

Certified Scrum Practitioner는 숙련 된 ScrumMaster 및 제품 소유자를위한 인증입니다. 후보자는 최소 1 년 동안 ScrumMaster 또는 제품 소유자 여야합니다. 응시자는 지정된 역할에서 수행 한 작업에 대한 자세한 설명이 포함 된 신청서를 제출해야합니다.

응시자가 필요한 기간 동안 ScrumMaster의 역할 또는 제품 소유자의 역할을 적극적으로 수행하는 경우 CSM 인증 또는 CSPO 인증 직후 CSP 인증을 획득 할 수 있습니다.

공인 스크럼 코치 (CSC)

Certified Scrum Coach는 코칭에 집중하는 사람들을위한 자격증입니다. 인증을 받으려면 응시자가 지난 5 년 동안 최소 1500 시간 동안 스크럼을 채택하고 숙달하여 스크럼 팀을지도해야합니다.

공인 스크럼 트레이너 (CST)

Certified Scrum Trainer는 CSM 또는 CSPO 수업을 가르치려는 사람들을위한 자격증입니다. 지원자는 CSM 또는 CSPO 중 하나가 있어야하며 지원하기 전에 최소 1 년 동안 CSP 여야합니다.

다음은 스크럼에 관한 몇 가지 FAQ입니다.

Question: What is the difference between Scrum and Agile Development?

Answer : Agile Development는 소프트웨어 방법론 인 반면 Scrum은 Agile을 따르는 프로세스 프레임 워크 중 하나입니다.

Question: Are Sprints and Iterations the same?

Answer: Sprints of Scrum 및 Iterations of Iterative Incremental 모델 모두 작업 제품 증분을 제공합니다. 그러나 다음과 같은 점이 다릅니다.

Sprint와 Iteration의 수명주기는 다릅니다.
스프린트는 타임 박스이지만 반복은 그렇지 않습니다.
스프린트 기간은 반복 기간에 비해 훨씬 적습니다.

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer: 스크럼 마스터는 직함이있는 사람이 맡는 역할입니다. 일반적인 관행은 프로젝트 관리자 역할을하는 사람이 스크럼 마스터 역할도 수행하는 것입니다.

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer: 아니요, 소유권이 다르기 때문입니다. 제품 소유자는 Sprint에 할당 된 사용자 스토리와 함께 제품 백 로그, 사용자 스토리의 우선 순위 지정 및 작업 제품 증분의 유효성 검사를 처리합니다.

Question: Is it that Scrum Projects need not have any Documentation?

Answer : 아니요. 다른 프로젝트와 마찬가지로 스크럼 프로젝트에는 사용자 스토리, 디자인, 테스트 케이스 등과 같은 문서가 필요합니다.

결론

Agile과 Scrum은 동일하지 않습니다. 스크럼은 Agile을 적용하는 프로세스 프레임 워크 중 하나입니다. 스크럼은 프레임 워크가 훌륭한 협업과 자기 조직화를 필요로하기 때문에 경험이 풍부한 팀원이있는 팀에게 조언됩니다. 스크럼 규칙을 엄격하게 따르지 않으면 프로젝트가 실패 할 수 있습니다. 따라서 전체 팀간에 스크럼 개념에 대한 적절한 이해가 필요합니다. 스프린트는 짧은 기간이고 타임 박스이기 때문에 스크럼 마스터가 프로젝트를 지속적으로 모니터링하더라도 작업에서 스크럼 세부 사항을 배울 시간이 없습니다.