메뉴

Agile 및 Scrum 용어 : Agile / Scrum 개념에 대한 용어집

  • 메인
  • 다른
  • Agile 및 Scrum 용어 : Agile / Scrum 개념에 대한 용어집

agile scrum terminology

문제를 제거하기 위해 도구를 사용해보십시오

이것은 모든 중요한 Agile / Scrum 용어에 대한 포괄적 인 가이드이며 Agile 및 Scrum 개념의 올인원 용어집입니다.

우리 모두 알고 있듯이 Agile은 소개가 필요하지 않습니다. 전 세계적으로 사용되고있는 소프트웨어 개발 프레임 워크입니다.

이 문서는 손끝에 있어야하는 모든 애자일 / 스크럼 개념에 대한 포괄적 인 가이드입니다.

애자일 스크럼

학습 내용 :

애자일 선언

Agile 방법론은 Agile Manifesto를 기반으로합니다. 선언문에 대한 자세한 내용은 애자일 소프트웨어 개발을위한 선언문 .

애자일 선언문의 핵심 내용은 다음과 같이 줄일 수 있습니다. :

  • 개인 간 의사 소통은 프로세스 바인딩에 효과적입니다.
  • 작동하는 제품은 기존의 단계별 문서보다 낫습니다.
  • 클라이언트 / 비즈니스 소유자의 참여가 중요하므로 지속적인 피드백 루프도 마찬가지입니다.
  • 변화는 불가피합니다. 따라서 팀은 그들을 포용하고 환영해야합니다.

애자일 프로세스가 이러한 선언을하더라도이를 달성하기위한 정확한 구체적인 단계를 제공하지 않음을 알 수 있습니다. 팀이 최선을 다할 수 있도록 완전한 자유와 자율성을 부여합니다.

시간이 지남에 따라 자유형은 일반적인 관행으로 발전했습니다. 그중 가장 유명한 것은 스크럼입니다.

그것으로 우리의 정의를 시작합시다.

스크럼이란?

Scrum은 Ken Schwaber와 Jeff Sutherland가 개발 한 개발 모델로 1990 년대부터 사용되었습니다.

작업은 더 작은 요구 사항 (스토리, 서사 및 작업)으로 나뉘고 긴밀한 팀이 소규모 분할로 구축하고 제공합니다. 피드백을 자주 구하고 잦은 짧은 릴리스의 형태로 제품을 개선합니다.

스크럼의 기둥

스크럼의 기둥은 아래에서 자세히 설명합니다.

  • 투명도 : 팀은 무슨 일이 일어나고 있는지 알고 있으며 서로를 공유하고 돕는 데 열려 있습니다. 의사 소통은 매일 일어 서서 비공식적 인 사람 대 사람 상호 작용을 통해 자유롭게 흐릅니다.
  • 검사 : 작업에 대한 빈번하고 종교적인 검사는 Scrum의 성공의 열쇠입니다. 팀은 간단하고 신뢰할 수있는 방법으로 식별, 진단, 문제 해결, 수정하고 정상으로 돌아갈 수 있습니다.
  • 적응 : 스크럼은 그들이하는 일이 옳다고 가정하지 않습니다. 다음과 같은 형태의 정기 체크 포인트가 있습니다. 스프린트 계획, 일일 스크럼, 스프린트 검토 / 회고 회의 팀이 검토하고 적응할 수있는 곳입니다.

스크럼 팀

스크럼 팀 일반적으로 작고 (5-9) 일반적으로 교차 기능을합니다. 그들은 스크럼 마스터 , 개발자, 테스터 (모든 애자일 팀 구성원을 작업 분야에 관계없이 개발자로 지칭하는 것이 일반적입니다).

다른 기술 팀원과 가장 중요한 것은 제품 소유자 또는 후원자입니다. 애자일은 모든 베팅을 팀에 맡깁니다. 따라서 자체 구성 A 팀은 매우 중요하며 성공적인 민첩한 구현을위한 전제 조건입니다.

스크럼 팀

스크럼에서의 역할

다음은 스크럼의 다양한 역할입니다.

  • 제품 소유자 : 제품 소유자가 백 로그를 소유합니다. 그는 제품과 제품의 모양을 담당합니다. 제품 백 로그를 유지하고 전반적인 제품 비전을 가지고 팀의 목표를 추진하는 것이 제품 소유자의 주요 책임입니다.
  • 개발팀 : 개발 팀에는 제한된 역할이 없습니다. 그들은 부서 간 업무를 수행하고 목표를 달성하기위한 최선의 접근 방식을 선택해야합니다.
  • 스크럼 마스터 : 스크럼이 올바른 방식으로 구현되도록하는 것이 스크럼 마스터의 임무입니다. 스크럼 마스터는 서번트 리더 팀 전체를 위해.

스크럼 행사

애자일은 추적을 유지하고 성공하기 위해 몇 가지 습관에 의존합니다.

그들 중 일부는 아래에 언급되어 있습니다.

# 1) 매일 스크럼 회의 : 각 팀 구성원이 다음 사항에 대해 이야기하는 일반적인 15 분 짧은 모임입니다.

  • 어제 무엇을 했습니까?
  • 오늘은 무엇을 계획하고 있습니까?
  • 도중에 장애물이 있습니까?

이 회의 형식은 완료된 작업, 남은 작업 및 필요한 경우 팀이 서로를 도울 수있는 방법을 이해하는 데 매우 효과적입니다.

스크럼 마스터는이 회의를 촉진하지만 스크럼 마스터의 이익이나 상태 수집 장소를위한 것은 아닙니다. 팀이 그날의 작업을 정복하는 별도의 방법으로 가기 전에 함께 상호 작용하고 함께 모일 수있는 기회입니다.

# 2) 스프린트 : Sprint는 타임 박스 반복입니다 (종종 한 번 3 주이지만 더 길거나 짧을 수 있음). 이는 반복적 인 프로세스이며 개발 및 제공의 버스트로 볼 수 있습니다.

# 3) 스프린트 계획 : 스프린트 계획의 목적은 제품 백 로그 스토리 세트를 배송 가능한 제품의 증분으로 전환하는 방법을 계획하는 것입니다.

전체 형식은 2 부분 상황과 같을 수 있습니다.

  • 전반전 – 팀은 완료하기로 약속 한 항목을 선택합니다.
  • 후반 – 제품 소유자는 질문이 있습니다.

팀은 그것을 구축하는 방법을 결정합니다. 따라서 작업이 생성되고 할당되어 결과적으로 스프린트 백 로그.

# 4) 스프린트 검토 / 데모 : 스프린트 후 팀과 이해 관계자가 만나 완성 된 작업을 선보일 수 있습니다.

완료된 작업은 계획된 항목과 비교되며 구현되지 않은 기능은 생략됩니다. 이 회의의 기간은 4 시간을 넘지 않습니다.

# 5) 스프린트 회고 : 이 회의는 스크럼 마스터 PO를 포함한 전체 팀이 참석합니다.

팀은 프로세스 개선 아이디어에 초점을 맞춰 최근 Sprint에 대해 논의하고 다음 Sprint의 생산성을 높이기 위해 변경할 수있는 사항을 결정합니다.

일반적으로 이 회의는 2 시간 이상 걸리지 않습니다.

=> 권장 읽기 – 애자일 회고 회의

애자일 추정 기초

다음은 애자일 추정 기본 사항입니다.

입력

  • 제품 백 로그 및 스프린트 백 로그.
  • 과거 데이터, 유사한 작업에 대한 이전 추정치와 실제 노력 값이 사용되었습니다.

예상 참가자

  • 응용 프로그램에 익숙한 팀 구성원.
  • 응용 프로그램과 다른 시스템의 통합을 이해하는 팀 구성원.
  • 프로젝트 완료에 필요한 다양한 기술을 나타냅니다.
  • 구축, 배포 및 QA 팀 대표.

Epic / Feature / Idea에 대한 정의

  • 이들은 대규모 사용자 스토리이며 일반적으로 단일 반복으로 구현하기에는 너무 큽니다.
  • 아이디어 / 에픽 –> 스토리 –> 작업 (하나의 아이디어는 여러 스토리를 가질 수 있습니다. 하나의 스토리는 여러 작업을 가질 수 있습니다. 스토리 범위는 하나의 스프린트로 제한됩니다. 스토리를 완료하려면 모든 작업을 닫아야합니다)

# 1) 스토리 포인트 추정 기법 : 스토리 포인트는 팀에게 스토리가 얼마나 복잡한 지 알려주는 숫자입니다.

대부분의 경우 피보나치 시리즈 또는 티셔츠 크기가 사용됩니다. 일반적으로 하나의 스토리 포인트는 한 사람의 하루 작업에 해당하는 것으로 간주됩니다.

그러나 비율은 작업의 한 단위를 완료하는 데 걸린 평균 시간의 실제 데이터를 기반으로 매 반복 후에 수정됩니다.

관련된 단계는 다음과 같습니다.

  • 매우 큰 요구 사항을 작은 작업으로 나누십시오.
  • 최소 2 명의 견적 가로 구성된 팀을 선택하십시오. 스크럼 마스터 , 제품 소유자 및 다른 사람들이 참여할 수 있습니다.
  • 각 견적자는 사용자 스토리 (작업)에 대해 자신의 스토리 포인트를 비공개로 할당하고 동일한 내용을 게시합니다.
  • 요구 사항에 대한 스토리 포인트는 유사한 작업의 크기에 대한 과거 지식을 기반으로 평가자가 할당합니다.
  • 추정치는 약간 다를 것으로 예상됩니다.
  • 추정치가 크게 다를 경우 높고 낮은 추정자가 추정치를 설명합니다.
  • 그 후, 모든 추정자가 동일한 수로 수렴 할 때까지 동일한 프로세스를 따라 한 번 더 추정을 수행합니다.

# 2) 기획 포커 : 이 흥미롭고 재미있는 기술이 여기에 설명되어 있습니다. Planning Poker로 애자일 추정 프로세스를 쉽게 만드는 방법

노트 :애자일 추정을위한 다른 많은 기술이 있지만이 두 가지가 가장 두드러진 기술입니다.

스크럼 아티팩트

가장 중요한 스크럼 아티팩트는 제품 백 로그 및 스프린트 백 로그입니다. . 이것은 전체 스프린트 목표를 모니터링하는 데 도움이되는 것들입니다.

# 1) 제품 백 로그 :

  • 제품 / 프로젝트에 대해 유지 관리되는 '요구 사항'의 정렬 된 목록입니다.
  • 목록에는 버그 및 작동하지 않는 항목도 포함될 수 있습니다.
  • 제품 소유자는 PBL에서 우선 순위를 설정할 책임이 있습니다.
  • 제품 소유자는 제품 백 로그를 관리 할 책임이 있습니다.

# 2) 스프린트 백 로그 :

  • 에 대한 할 일 목록 (백 로그 항목이라고도 함) 스프린트.
  • 스크럼 팀 유지 관리를 담당합니다 ..
  • 스프린트 중에 팀원들은 새로운 정보가 나오면 스프린트 백 로그를 업데이트해야합니다.
  • 항목 중 하나라도 불완전하거나 부분적으로 완료된 경우 표준 스크럼의 정의에 따라 해당 항목은 다시 제품 백 로그.

# 3) 번 다운 차트 :

소프트웨어 테스트에서 사용자 수용 테스트는 무엇입니까
  • 스프린트에서 완료된 작업과 남은 작업을 보여주는 공개적으로 표시되는 차트입니다.
  • 매일 완료되는 실제 작업을 보여줍니다.
  • 에 의해 유지 스크럼 마스터 매일.
  • 두 가지 유형이 있습니다. ‘번 다운 차트 출시’및‘스프린트 번 다운 차트’.

번 다운 차트

완료의 정의

완료의 정의 스크럼 팀마다 다릅니다. 간단히 말해서 DoD는 팀이 사용 가능한 도구를 통해 목표를 달성 할시기를 알려주는 방법입니다. PO와 팀 간의 계약입니다.

DoD 충족은 백 로그의 모든 스토리가 이해 관계자의 요구 사항에 따라 개발되었음을 의미합니다. 스토리는 비 기술적이거나 여러 작업을 포함 할 수 있습니다.

백 로그 구체화 (그루밍)

백 로그 개선 핵심 스크럼 관행은 아니지만 스프린트에 들어가는 백 로그 항목의 품질을 관리하는 방법으로 채택되었습니다.

제품 백 로그 항목을 검토하고 스프린트 계획 활동을 통해 스프린트에 진입하면 팀이 명확하고 실행할 수 있도록 적절한 우선 순위가 지정되고 준비되었는지 확인하는 지속적인 노력입니다.

폭포와의 빠른 비교

매개 변수기민한폭포
고객 만족 빠른 배송으로 고객 만족배송이 늦어 고객이 확신하지 못함
작동하는 소프트웨어 제공 잦은 배송몇 달에 한 번
늦은 변경 다가오는 봄으로 빠르게 범위를 지정할 수 있습니다.구현하기 어려움
통신 일상 커뮤니케이션프로젝트 관리자와 회의 검토
의존 비즈니스맨과 개발자 – 테스터 간의 긴밀한 커뮤니케이션 및 협력.프로젝트 관리자가 프로젝트를 주도합니다.

제품 백 로그

위로 올라가면 PBI가 생성되고 깊이 있습니다.

  • 디- 충분히 상세 함
  • IS- 응급 이다
  • IS- 예상
  • 피- 우선 순위

그리고 그들은 팀에 더 상세합니다.

제품 백 로그

스크럼 마스터가 적응해야하는 사항 :

  • 장애 제거
  • 촉진
  • 멘토링 및 교육
  • 코칭

이것들은 스크럼 마스터 수행해야 할 때 스크럼 새로 구현되었습니다. 그러나 시간이 지남에 따라 팀이 스크럼에 익숙해지면 (자체 조직화 됨) 스크럼 마스터는 수행해야 할 작업, 즉 '관찰'이 있습니다.

스크럼 팀 구축

팀을 구성하는 동안 스크럼 마스터 포밍, 스토밍, 규범 및 공연과 같은 도전에 직면 할 수 있습니다.

  • 형성- 팀에 관계가없는 곳.
  • 스토밍 팀원 사이의 경계가 밝아지는 곳.
  • 규범 팀에 좋은 관계가 형성되었을 때.
  • 실행할 수 있는- 팀워크 만있는 마지막 단계입니다.

보시다시피 마지막 단계는 팀이 실제로 스크럼 팀 . 그러나이 전환 과정에서 어느 단계에서나 약간의 중단이 발생하면 팀이 처음으로 돌아갑니다.

결론

이 튜토리얼이 모든 중요한 내용을 간략하게 설명했으면합니다. 애자일 및 스크럼 용어 . 이 튜토리얼 시리즈를 참조하십시오 애자일 방법론에 대한 완벽한 가이드 Agile / Scrum 개념에 대한 자세한 내용은

행복한 민첩성!

추천 도서

^