스크럼(소프트웨어 개발)

Scrum (software development)
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

Scrum(SCRUM)[1]은 프로젝트 관리를 위한 프레임워크로 처음에는 소프트웨어 개발에 중점을 두고 있지만 연구, 판매, 마케팅, 첨단 기술 [2]등 다른 분야에서 사용되고 있습니다.이것은 10명 이하의 팀원들로 구성된 팀을 위해 설계되었으며, 이들은 1개월 이내, 그리고 가장 일반적으로 2주 이내에 타임박스화된 반복 시간 내에 완료할 수 있는 목표(스프린트라고 불린다)로 분류된다.스크럼 팀은 매일의 스크럼(스탠드업 미팅의 일종)이라고 불리는 15분 이하의 타임박스 일일 미팅의 진척 상황을 평가합니다.스프린트 종료 후, 팀은 두 가지 회의를 더 개최한다. 즉, 이해관계자에게 피드백을 도출하기 위해 수행된 작업을 보여주는 스프린트 검토와 팀이 반영하고 개선할 수 있는 스프린트 소급이다.

2020 Scrum[3] Guide 기반 Scrum Agile 이벤트

이름.

스크럼이라는 용어는 럭비에서 유래한 것으로, 럭비는 선수들의 구성이다.스크럼이라는 용어는 [4]팀워크를 강조하기 때문에 이 신문의 저자들에 의해 선택되었다.소프트웨어 개발 용어 스크럼은 1986년 다케우치 히로타카와 노나카 [5][6]이쿠지로가 쓴 '신제품 개발 게임'이라는 논문에서 처음 사용되었다.이 논문은 하버드 비즈니스 리뷰 1986년 1월호에 게재되었습니다.

Scrum은 때때로 SCRUM으로 [7]모든 캐피털로 쓰여지는 것을 볼 수 있습니다.단어 자체는 약어는 아니지만, 대문자로 된 스타일은 제목에 [9][10]SCRUM을 대문자로 쓴 Ken Schwaber의[8] 초기 논문에서 나온 것 같습니다.

스크럼이라는 용어 자체의 상표는 소멸되어 왔지만,[11] 현재는 개인이 아닌 광범위한 커뮤니티가 소유한 일반 상표로 간주되고 있다.

주요 아이디어

Scrum은 복잡한 [12][13]제품을 개발, 제공 및 유지하기 위한 경량, 반복 및 증분 프레임워크입니다.이 프레임워크는 제품 개발에 대한 기존의 순차적 접근 방식에 대한 전제조건에 도전하며, 팀원들이 물리적으로 공동 배치하거나 모든 팀원들과 관련된 분야들 간의 일상적인 대면 커뮤니케이션을 장려함으로써 팀이 자기 조직화할 수 있도록 합니다.

스크럼의 주요 원칙은 고객이 원하는 범위(많은 경우 요건의 변동성[14])를 변경하고 예측할 수 없는 문제가 발생한다는 이중 인식입니다.이러한 문제에는 예측 또는 계획적인 접근법이 적합하지 않습니다.이러한 변경은 다양한 출처에서 발생하지만 스크럼에 따르면 왜 관계가 없는지를 이해하는 것은 변화를 수용하고 수용하며 분석하여 이점을 얻어야 합니다.

역사

타케우치 히로타카와 노나카 이쿠지로씨는 1986년 하버드 비즈니스 리뷰 기사 「The New Product Development Game」[15]에서 제품 개발의 맥락에서 스크럼이라는 용어를 도입했다.타케우치와 노나카는 나중에 지식 창조[16] 회사에서 "조직적 지식 창조의 한 형태이며, 특히 지속적으로, 증분적으로, 그리고 스피럴하게 혁신을 가져오는 데 능숙하다"고 주장했다.

저자들은 자동차,[15] 복사기 및 프린터 산업에 종사하는 제조업체들의 사례 연구를 바탕으로 속도와 유연성을 높이는 상용 제품 개발에 대한 새로운 접근 방식을 설명했습니다.이 모든 과정 팀은"한 단위로 끝까지 가길을 움직이며 공을 노력한다"여러 중복되는 국면을 여러 직종의 일을 하는 팀이 수행한 그들은 이 또는 럭비 전체론적 접근법을 불렀다.각각 팀의 앞쪽 interlock 그들의 머리를 dow과[15](럭비 축구에서, 스크럼 플레이를 다시 시작하는데 사용한다.n, 그리고 공을 잡으려고 시도합니다.)[17]

스크럼 프레임워크는 DuPont 연구소와 [9]델라웨어 대학의 Babatunde Ogunnaike와 함께 Schwaber의 연구에 기초했습니다.Ogunaike는 경험론에 기초하지 않은 소프트웨어와 같은 복잡한 제품을 개발하려는 시도는 초기 조건과 가정이 변화함에 따라 더 높은 위험과 실패율을 가질 수밖에 없다고 조언했다.유연성과 투명성을 갖춘 빈번한 검사와 적응을 사용하는 경험주의가 가장 적합한 접근법이다.

1990년대 초, Ken Schwaber는 그의 회사 Advanced Development Methods에서 스크럼이 [18]되는 것을 사용하였고, Jeff Sutherland, John Scumniotales 및 Jeff McKenna는 Easel Corporation에서 Scrum이라는 단어를 사용하여 유사한 접근법을 개발하였습니다.

Sutherland와 Schwaber는 아이디어를 스크럼이라는 하나의 프레임워크에 통합하기 위해 협력했습니다.스크럼을 테스트하고 지속적으로 개선하여 1995년 논문,[19] [20]2001년 신속한 변화를 위한 소프트웨어 개발 매니페스토에 대한 기여, 2002년 이후 스크럼의 전 세계적인 보급과 사용을 이끌어냈습니다.

1995년 [19]Sutherland와 Schwaber는 공동으로 Scrum 프레임워크에 대해 설명하는 논문을 텍사스 오스틴에서 열린 객체 지향 프로그래밍, 시스템, 언어 및 애플리케이션 '95(OOPSLA '95)'의 일환으로 개최된 비즈니스 객체 설계 및 구현 워크숍에서 발표했습니다.이후 몇 년 동안 Schwaber와 Sutherland는 Scrum이라고 [3]알려진 것을 개발하기 위해 이 자료를 자신들의 경험과 진화하는 모범 사례와 결합하기 위해 협력했습니다.

2001년에 Schwaber는 Mike Beedle과 협력하여 Scrum을 [21]사용한 신속한 변화를 위한 소프트웨어 개발이라는 책에서 이 방법을 설명했습니다.Scrum의 제품 개발 계획 및 관리 접근방식은 의사결정 권한을 운영 특성 및 [9]확실성 수준으로 끌어올리는 것을 포함합니다.

2002년 Schwaber는 다른 사람들과 함께 Scrum[22] Alliance를 설립하고 Certified Scrum 인증 시리즈를 설립했습니다.Schwaber는 2009년 말에 Scrum Alliance를 탈퇴하고 Scrum[23].org를 설립하여 Professional Scrum 인증 [24]시리즈를 감독하고 있습니다.

2009년 이후, The Scrum[3] Guide라고 불리는 공공 문서가 Schwaber와 Sutherland에 의해 출판되고 업데이트되었습니다.현재 버전은 2020년 11월이며, 6회 개정되었습니다.

스크럼팀

스크럼의 기본 단위는 제품 소유자, 스크럼 마스터 및 개발자로 구성된 소규모 팀입니다.이 팀은 자기관리적이고 여러 기능을 겸비하고 있으며, 한 번에 하나의 목표, 즉 제품 목표에 초점을 맞추고 있습니다.

제품 소유자

제품의 이해관계자 및 고객의 목소리(또는[25] 위원회의 요구를 대변할 수도 있음)를 대표하는 제품 소유자는 우수한 비즈니스 [26]결과를 제공할 책임이 있습니다.따라서 제품 소유자는 제품 잔량과 팀이 [25]제공하는 가치를 극대화할 책임이 있습니다.제품 소유자는 고객 중심의 결과(일반적으로 사용자 사례에만 국한되지 않음)로 제품을 정의하고, 이를 제품 백로그에 추가한 후 중요도와 [27]의존성에 따라 우선순위를 부여합니다.스크럼 팀에는 1명의 제품 소유자가 있어야 합니다(단, [28]1명의 제품 소유자가 여러 팀을 지원할 수 있습니다).이 역할과 스크럼 마스터 역할을 조합하지 않는 것이 좋습니다.제품 소유자는 제품 개발의 비즈니스 측면에 집중하고 대부분의 시간을 이해관계자 및 팀과 연락하는 데 소비해야 합니다.제품 소유자는 팀이 기술적인 솔루션에 도달하는 방법을 지시하지 않고 [29][30][31][better source needed]팀원들 간의 합의를 구합니다.이 역할은 매우 중요하며, 스크럼 팀의 비즈니스와 엔지니어(개발자)의 양쪽 모두에 대한 깊은 이해가 필요합니다.따라서 우수한 제품 소유자는 비즈니스가 필요로 하는 것을 전달하고, 그 이유를 묻고(이를 달성하기 위한 더 나은 방법이 있을 수 있기 때문에), 필요에 따라 기술 언어를 사용하여 개발자를 포함한 모든 이해관계자에게 메시지를 전달할 수 있어야 합니다.제품 소유자는 Scrum의 경험적 도구를 사용하여 매우 복잡한 작업을 관리하면서 위험을 통제하고 가치를 달성합니다.

커뮤니케이션은 제품 소유자의 핵심 책임입니다.제품 개발을 올바른 방향으로 이끌기 위해서는 우선 사항을 전달하고 팀원 및 이해관계자와 공감하는 능력이 필수적입니다.제품 소유자의 역할은 팀과 이해관계자 간의 커뮤니케이션 격차를 메워 팀의 이해관계자 및 전체 이해관계자 커뮤니티의 [32][33]팀 대표자 역할을 합니다.

이해당사자에 대한 팀의 얼굴로서, 다음은 제품 [34]소유자가 이해당사자에게 전달하는 작업 중 일부입니다.

  • 릴리스를 정의 및 공지합니다.
  • 배송 및 제품 상태를 전달합니다.
  • 거버넌스 미팅에서 진행 상황을 공유합니다.
  • 중요한 RIDA(위험, 장애, 의존관계 및 전제조건)를 이해관계자와 공유합니다.
  • 우선 순위, 범위, 자금 및 일정을 협상합니다.
  • 제품의 잔고가 눈에 띄고 투명하며 깨끗한지 확인합니다.

연관성은 제품 소유자가 가져야 할 중요한 특성입니다. 즉, 자신의 입장을 다른 사람의 입장에서 생각하는 능력입니다.제품 소유자는 다양한 배경, 직무 역할 및 목적을 가진 다양한 이해관계자와 대화하며 이러한 다양한 관점을 이해할 수 있어야 합니다.효과적이기 위해서는 제품 소유자가 청중이 필요로 하는 세부 사항의 수준을 아는 것이 현명합니다.개발자는 기대에 부응하는 제품을 만들 수 있도록 철저한 피드백과 사양을 필요로 하지만, 경영진 스폰서는 진척 상황 요약만 필요로 할 수도 있습니다.필요 이상으로 많은 정보를 제공하면 이해관계자의 관심이나 시간을 낭비할 수 있습니다.경험이 풍부한 제품 [28]소유자는 직접적인 통신 수단을 선호합니다.

제품 소유자의 효과적인 커뮤니케이션 능력도 이해관계자의 요구를 특정하고 이해관계자 간의 우선순위를 협상하며 개발자와 협업하여 요건의 효과적인 구현을 보장하는 기술에 숙달되어 있습니다.

개발자

개발자들은 [27]매 스프린트마다 가치의 증분을 구축하는 데 필요한 모든 작업을 수행한다.

개발자란[3] 시스템 또는 제품의 개발과 지원에 역할을 하는 모든 사람을 말하며,[35] 연구원, 설계자, 설계자, 데이터 전문가, 통계학자, 분석가, 엔지니어, 프로그래머 및 테스터를 포함할 수 있습니다.그러나, 일부 사람들이 '개발자'라는 용어가 그들에게 적용되지 않는다고 느낄 때 발생할 수 있는 혼란 때문에, 그들은 종종 단지 팀원으로 불린다.

그 팀은 자기 조직적이다.제품 소유자를 통하지 않는 한 팀에게 작업을 진행해서는 안 되며, 스크럼 마스터가 팀의 주의를 분산시키는 것으로부터 팀을 보호할 것으로 기대되지만, 팀은 고객 및/또는 이해관계자와 직접 대화하여 최대한의 [27]이해와 피드백의 즉시성을 얻을 수 있도록 권장됩니다.

스크럼 마스터

스크럼은 스크럼 마스터에 의해 촉진되며, 스크럼 마스터는 제품의 목표와 [36]성과물을 제공하는 팀의 능력에 대한 장애물을 제거할 책임이 있습니다.스크럼 마스터는 전통적인 팀 리더나 프로젝트 매니저가 아니라 팀과 산만한 영향 사이의 장벽으로 작용합니다.Scrum Master는 Scrum 프레임워크에 이어 Scrum 이론과 개념에 대해 팀을 지도하고 종종 주요 세션을 촉진하며 팀의 성장과 개선을 장려합니다.이 역할은 팀 퍼실리테이터 또는 서번트 리더라고도 불리며 이러한 이중적 관점을 강화합니다.

스크럼 마스터의 핵심 책임은 다음과 같습니다(이에 한정되지 않음).[37]

  • 필요한 작업을 확실하게 이해할 수 있도록 제품 소유자가 제품 잔량을 유지할 수 있도록 지원하여 팀이 지속적으로 전진할 수 있도록 합니다.
  • 주요 관계자의 의견을 받아 팀이 제품에 대한 완료 정의를 결정할 수 있도록 지원
  • 제품에[38] 고품질의 기능을 제공하기 위해 스크럼 원칙 내에서 팀을 지도합니다.
  • 주요 관계자 및 기타 조직에게 스크럼(및 경우에 따라서는 민첩한) 원칙에 대한 교육
  • 스크럼 팀이 팀 내부 또는 외부 모두에 관계없이 진행에 방해가 되는 요소를 제거 또는 회피할 수 있도록 지원
  • 팀 내 자기 조직화 및 교차 기능성 촉진
  • 정기적인 진행을 위해 팀 이벤트 진행

스크럼 마스터는 사람들과 조직이 확실성과 예측 가능성에 대한 희망을 남기고 경험적이고 희박한 사고를 채택할 수 있도록 지원합니다.

스크럼 마스터의 역할은 프로젝트 매니저와 다른 점 중 하나는 스크럼 마스터는 사람 관리 책임이 있지만 스크럼 마스터는 그렇지 않다는 것입니다.스크럼 마스터는 팀에 권한 부여와 자기 [39]조직화를 요구하기 때문에 제한된 양의 방향을 제시합니다.Scrum은 기존의 명령 및 제어 성향으로 [40]인해 문제가 발생하기 때문에 프로젝트 매니저의 역할을 공식적으로 인정하지 않습니다.

워크플로우

스프린트

스크럼 프레임워크
주요 기사: 스크럼 스프린트
해커톤§코드 스프린트와 혼동하지 마세요.
스크럼 프로세스

스프린트(반복 또는 타임박스라고도 함)는 스크럼 개발의 기본 단위이다.스프린트는 타임박스식 노력이다. 즉, 각 스프린트에 대해 사전에 합의하고 길이를 고정하며, 일반적으로 1주일에서 1개월 사이이며,[9] 가장 일반적인 것은 2주이다.

각 스프린트는 스프린트 목표가 정의된 스프린트 계획 이벤트로 시작한다.다음 스프린트의 우선순위는 밀린 업무에서 선택된다.각 스프린트는 2개의 이벤트로 끝난다.

  • 스프린트 리뷰(피드백 도출을 위해 이해관계자에게 제시)
  • 스프린트 회고전(다음 [18]스프린트를 위한 교훈과 개선사항)

Scrum은 방금 완료한 스프린트의 마지막에 가치 있고 실행 가능한 출력을 강조합니다.각 반복의 결과물을 통해 개발된 제품이 시장 [41]성공에 더 가까워질 것입니다.소프트웨어의 경우, 여기에는 제품이 완전히 통합되고 테스트 및 문서화되어 있으며 잠재적으로 릴리스가 [40]가능한 것이 포함됩니다.

스프린트 계획

스프린트가 시작될 때 스크럼 팀은 스프린트 계획 이벤트를 개최하여 다음을 수행한다.

  • 스프린트 목표에 합의합니다.제품 소유자가 설정한 우선순위에 따라 스프린트 종료까지 무엇을 제공할 것으로 예상하는지 간략하게 설명합니다.
  • 이 목표에 기여하는 제품 잔량 항목 선택
  • 스프린트 중에 어떤 항목을 수행하려고 하는지 상호 토론하고 합의하여 스프린트 잔량을 형성한다.

스프린트 계획의 최대 지속 시간은 4주 [3]스프린트의 경우 8시간이다.상세 작업이 상세하게 설명됨에 따라 일부 제품 잔량 항목이 분할되거나 단일 스프린트로 작업을 완료할 수 없다고 판단될 경우 제품 잔량 항목으로 반환될 수 있습니다.

데일리 스크럼

매일 컴퓨터실에서 스크럼을 해.이 중앙 집중식 위치는 팀이 제 시간에 출발하는 데 도움이 됩니다.

매일 스프린트 중에 개발자는 특정 [42][9]가이드라인을 사용하여 매일 스크럼(때로는 서서 진행)을 개최합니다.

모든 개발자가 준비하러 옵니다.일일 스크럼:

  • 스프린트 목표를 향한 진행 상황을 점검하는 데 초점을 맞춘다.
  • 매일 같은 시간과 장소에서 일어나야 한다
  • 제한(타임박스)은 15분으로 제한되어 있습니다.
  • 팀이 어떤 결정을 내리든
  • 개발자들만 발언해야 하지만, 다른 사람들도 포함될 수 있습니다.
  • 스크럼 마스터에 의해 촉진될 수 있다
  • 진보에 대한 장애물을 식별할 수 있다(예: 걸림돌, 위험, 문제, 지연된 의존성, 근거가 [43]없는 가정)
  • 토론은 없습니다.
  • 진행률 차트를 업데이트하는 수단이 아닙니다.

매일 스크럼을 진행하는 동안 상세한 논의를 하지 마십시오.일단 끝나면, 개별 구성원들은 종종 '브레이크아웃 세션' 또는 '애프터 파티'[44]로 알려진 문제를 상세히 논의할 수 있습니다.발견된 문제나 버그는 해결을 위해 매일 스크럼 이외의 장소에서 일괄적으로 논의해야 합니다.

팀이 이 이벤트에서 가치를 보지 못할 경우, 스크럼 마스터는 그 이유를[45] 판단하고 스크럼 [38]원칙에 대해 팀과 이해관계자에게 교육하거나, 팀에 스프린트 진행 상황을 완전히 알 수 있는 자체 방법을 설계하도록 권장할 책임이 있다.

스프린트 리뷰

스프린트 종료 시 팀은 다음과 같이 진행된다.

  • 완료된 작업을 이해관계자에게 제시한다(데모).
  • 님은, 다음과 같은 토픽으로 관계자와 제휴하고 있습니다.
    • 완료된 제품 증분에 대한 피드백 초대
    • 불완전한 작업의 영향에 대해 논의한다(계획되었는지 여부).
    • 다음 작업에 대한 제안을 받는 것(다음 작업에 대한 제안 포함)

제품 소유자는 이 이벤트를 이해 관계자와 함께 제품 잔량을 검토하고 개선할 수 있는 귀중한 기회로 간주해야 합니다.

스프린트 리뷰 가이드라인:

  • 불완전한 작업은 입증해서는 안 된다. 이해관계자에게 제공하게 될 제품 증분을 제시해야 하지만, 필요한 경우 진행 중인 작업의 확인을 요청할 수도 있다.하지만, 그 팀은 단지 무엇이 이루어졌는지 보여줄 준비가 되어 있어야 한다.
  • 권장 시간은 2주 스프린트의 경우 2시간이다(다른 스프린트 [3]주기의 경우 비례한다).

스프린트 회고전

스프린트 회고전에서 팀은 다음과 같이 말했다.

  • 과거의 전력 질주를 반성하다
  • 마지막 스프린트가 어떻게 진행되었는지 점검한다(개인, 상호작용, 프로세스, 도구, 완료의 정의).
  • 지속적인 프로세스 개선 조치를 식별하고 이에 동의합니다.

스프린트 소급 [citation needed]지침:

  • 스프린트 소급에서 고려해야 할 세 가지 영역은 다음과 같다.
    • 스프린트 중에 뭐가 잘 됐나?
    • 무엇이 잘 안 되었나요?
    • 다음 스프린트에서는 무엇을 달리 할 수 있을까요?
  • 지속 시간은 최대 3시간이며, 4주 스프린트의 경우 다른 스프린트 지속 시간에 비례한다(예: 2주 스프린트의 경우 1시간 30분).

스크럼 마스터가 이 이벤트를 촉진할 수도 있지만, 팀의 일원으로도 참가할 수 있습니다.

잔량 조정

원래 핵심 스크럼 프랙티스는 아니지만, 스크럼 가이드에 백로그 미세화(구칭 그루밍)가 추가되어 스프린트에 들어가는 제품 백로그 항목의 품질을 관리하는 방법으로 채택되었습니다.새로운 정보에 비추어 제품의 잔량 항목을 검토, 수정, 갱신, 재주문하는 진행 과정입니다.

backlog 및 backlog 내의 아이템을 변경하는 이유는 다음과 같습니다.

  • 큰 아이템은 여러 개의 작은 아이템으로 분할할 수 있습니다.
  • 수용 기준을 명확히 할 수 있다.
  • 의존관계를 특정하고 조사할 수 있다
  • 아이템은 추가 검출과 분석이 필요할 수 있습니다.
  • 우선순위가 변경되었을 수 있습니다.기대되는 수익은 다릅니다.

개선이란 스프린트 계획을 위해 개발자가 명확하고 실행할 수 있도록 항목이 적절하게 준비되고 주문되는 것을 의미한다.

잔액에는 기술 채무(설계 채무 또는 코드 채무라고도 함)도 포함될 수 있습니다.이는 소프트웨어 개발의 개념으로, 시간이 오래 걸리는 더 나은 접근방식을 사용하는 대신 지금 쉬운 솔루션을 선택함으로써 발생하는 추가 재작업에 따른 암묵적인 비용을 반영합니다.

밀린 업무 개선 시 팀 전력의[3] 최대 10%를 투자하는 것이 좋습니다.보다 성숙한 팀에서는 이를 예정된 정의된 이벤트가 아니라 자연스러운 워크플로우의 일부를 구성하는 임시 작업으로 보고 필요할 때 제품 잔량을 조정 및 조정합니다.

스프린트 취소

제품 소유자는 [3]필요에 따라 스프린트를 취소할 수 있으며 다른 사람(개발자, 스크럼 마스터 또는 경영진)의 의견을 받아 취소할 수 있습니다.예를 들어, 최근의 외부 상황은 스프린트 목표의 가치를 부정할 수 있으므로, 계속하는 것은 무의미하다.

스프린트가 비정상적으로 종료된 경우, 다음 단계는 종료 이유를 검토하는 새로운 스프린트 계획을 수행하는 것이다.

아티팩트

아티팩트는 프로젝트의 작업 관리에 사용되는 문서를 참조합니다.

제품의 잔량

주요 기사: 제품 잔량

제품 잔고는 수행해야 할 작업의 내역이며, 팀이 제품에 대해 유지하는 제품 요구 사항의 순서 목록을 포함합니다.백로그 항목의 일반적인 형식에는 사용자 사례 및 사용 [40]사례가 포함됩니다.이러한 요건에 의해 기능, 버그 수정, 기능 이외의 요건 등이 정의됩니다.제품 소유자는 위험, 비즈니스 가치, 종속성, 크기 및 필요한 날짜와 같은 고려 사항에 따라 제품 백로그 항목(PBI)의 우선순위를 부여합니다.

제품 백로그는 "필요할 때 필요한 것, 필요할 때 주문하는 것"으로 모든 사람이 볼 수 있지만 제품 백로그 항목의 관리 및 유지보수를 책임지는 제품 소유자의 동의가 있어야 변경할 수 있습니다.

제품 잔량에는 비즈니스 가치에 대한 제품 소유자의 평가가 포함되어 있습니다.또한 반올림된 피보나치 척도를 사용하여 스토리 포인트에 기술된 작업이나 복잡성에 대한 팀의 평가도 포함될 수 있습니다.이러한 견적은 제품 소유자가 타임라인을 파악하는 데 도움이 되며, 제품 잔량 항목의 주문에 영향을 미칠 수 있습니다.예를 들어, 같은 비즈니스 가치를 가지는 2개의 기능의 경우, 제품 소유자는 낮은 개발 작업(투자 수익률이 더 높기 때문에) 또는 높은 개발 작업 제공 시기를 앞당길 수 있습니다.fort(더 복잡하거나 더 위험하기 때문에 위험을 더 [46]빨리 해소하고 싶기 때문입니다).

제품 잔량 및 각 제품 잔량 항목의 비즈니스 가치는 제품 소유자의 책임입니다.각 아이템을 전달하기 위한 노력은 스토리 포인트 또는 시간으로 추정할 수 있습니다.스토리 포인트로 추정함으로써 팀은 개별 개발자의 의존도를 낮춥니다.이것은 특히 스프린트 제공 후 개발자가 다른 작업에 할당되는 동적 팀에 유용합니다.예를 들어, 사용자 스토리가 (Fibonacci 시퀀스를 사용하여) 작업 중인 개발자 수에 관계없이 5로 유지됩니다.

스토리 포인트는 타임박스 내의 노력을 정의하기 때문에 시간에 따라 변경되지 않습니다.예를 들어, 한 시간 안에 개인은 걷고, 뛰고, 오를 수 있지만, 소비되는 노력은 분명히 다릅니다.피보나치 시퀀스의 용어들 사이의 격차 진행은 팀이 신중하게 고려된 추정치를 제공하도록 장려한다.1, 2 또는 3의 추정치는 유사한 노력(1은 사소한 것)을 의미하지만, 팀이 8 또는 13(또는 그 이상)을 추정하면 제공과 예산 모두에 큰 영향을 미칠 수 있습니다.스토리 포인트를 사용하는 것의 가치는 팀이 이전 스프린트와 유사한 작업을 비교함으로써 재사용할 수 있다는 것이지만, 추정치는 해당 팀에 상대적이라는 것을 인식해야 한다.예를 들어, 한 팀이 5로 추정하면 더 높은 능력을 가진 경험이 많은 개발자로 구성된 다른 팀은 2로 추정할 수 있습니다.

모든 팀에는 제품 소유자가 있어야 하지만 대부분의 경우 제품 소유자가 여러 [28]팀과 함께 작업할 수 있습니다.제품 소유자는 제품의 가치를 극대화할 책임이 있습니다.제품 소유자는 의견을 수집하고, 많은 사람들로부터 피드백을 받고, 로비를 받지만, 최종적으로 무엇이 구축될지에 대한 최종적인 결정을 내립니다.

제품 잔량:

  • 새로운 기능, 오래된 기능 교체, 기능 삭제, 문제 수정 등 제품 수정 요청을 캡처합니다.
  • 개발자가 제품의 비즈니스 이점을 극대화하는 작업을 수행할 수 있도록 보장합니다.

일반적으로 전체 팀이 협력하여 제품 및 고객에 대한 새로운 정보가 표면화됨에 따라 제품 잔량 조정 작업을 수행하므로 나중에 스프린트가 새로운 작업에 대처할 수 있습니다.

관리

제품 잔고는 가장 간단한 형태로 작업해야 할 항목의 목록일 뿐입니다.작업 추가, 삭제 및 순서 지정 방법에 대한 규칙을 잘 수립하면 팀 전체가 [47]제품 변경 방법에 대해 더 나은 결정을 내릴 수 있습니다.

제품 소유자는 가장 빨리 필요한 항목을 기준으로 제품 잔량 항목의 우선순위를 부여합니다.스프린트 목표에 영향을 받은 개발자는 향후 스프린트를 위한 아이템을 선택하고, 이러한 아이템을 제품 백로그에서 스프린트 백로그로 이동시킨다.이것은 그들이 구축할 아이템의 리스트이다.개념적으로 스프린트 목표는 목록의 맨 위에 있는 우선순위가 높은 항목에 의해 영향을 받지만, 스프린트 내에 더 많은 작업을 수용할 수 있는 시간이 남아 있는 경우 개발자가 우선순위가 낮은 항목을 취하는 것은 드문 일이 아니다.

우선순위가 높은 항목(백로그의 맨 위)은 개발자가 작업하기에 적합한 세부사항으로 세분화해야 합니다.밀린 일이 많을수록 세부 사항은 적어집니다.Schwaber와 Beedle이 말했듯이, "우선 순위가 낮을수록, 밀린 업무 [9]항목을 거의 파악할 수 없을 때까지 세부 사항이 줄어듭니다."

팀은 밀린 업무를 처리할 때 환경 밖에서 변화가 일어난다고 가정해야 합니다. 팀은 활용할 수 있는 새로운 시장 기회, 발생하는 경쟁사의 위협 및 제품의 작동 방식을 바꿀 수 있는 고객으로부터의 피드백을 배울 수 있습니다.이러한 새로운 아이디어들은 모두 팀이 밀린 업무를 새로운 지식을 통합하도록 유도하는 경향이 있습니다.이것은 민첩한 팀의 기본적인 사고방식 중 일부입니다.세상은 변하지만 밀린 일은 [48]끝나지 않는다.

Sprint 잔량

스프린트 백로그는 개발자들이 다가오는 [49]스프린트에서 다루도록 의도된 제품 백로그의 항목 집합이다.개발자는 스프린트를 채울 수 있을 만큼 충분한 작업이 있다고 느낄 때까지 이 밀린 작업을 채우고, 과거의 성과를 사용하여 다음 스프린트를 위한 역량을 평가하며, 이를 얼마나 '노력'할 수 있는지에 대한 지침으로 사용한다.

스프린트 밀린 업무는 개발자에게 할당(또는 푸시)되지 않습니다.팀원은 밀린 업무의 우선순위, 자신의 스킬 및 능력에 따라 필요에 따라 작업을 수행합니다.이것은 개발자의 자기 조직화를 촉진한다.

스프린트 잔량은 개발자의 재산이며, 포함된 모든 추정치는 개발자가 제공한다.스크럼의 일부는 아니지만, 일부 팀은 현재 스프린트의 작업 상태를 시각화하기 위해 함께 제공되는 보드를 사용한다.ToDo, Do, Done.

증가

증가량은 스프린트 목표를 충족하는 스프린트의 잠재적으로 방출 가능한 출력이다.그것은 모든 완료된 스프린트 잔량 항목으로 구성되며, 이전의 모든 스프린트 작업과 통합된다.증분은 Scrum 팀의 Definition of Done(DoD)에 따라 완전히 작동하고 제품 소유자가 실제로 증분을 도입하여 사용하기로 결정했는지 여부에 관계없이 사용 가능한 상태여야 합니다.

내선번호

스크럼을 사용하는 데 도움이 [3]되는 다음과 같은 아티팩트 및 기술을 사용할 수 있습니다.

번다운 차트

완료된 스프린트에 대한 샘플 연소율 차트. 매일의 마지막에 남은 노력을 보여줍니다.
주요 기사:그래프 굽기

번다운 차트는 스크럼에서 자주 사용되며(스크럼의 일부가 아님) 남은 [50]작업을 보여주는 공개적으로 표시되는 차트입니다.매일 업데이트되며 참조할 수 있도록 빠른 시각화를 제공합니다.번다운 차트의 가로축은 남은 일수를 나타내고 세로축은 매일 남은 작업량을 나타냅니다.

스프린트 계획 중에 이상적인 연소 차트가 표시된다.그런 다음 스프린트 중에 개발자는 남은 작업으로 차트를 업데이트하여 차트가 매일 업데이트되고 실제와 예측이 비교됩니다.

취득값 차트와 혼동해서는 안 됩니다.

릴리스 연소 차트

주요 기사:번드업 차트
각 스프린트가 완료된 범위를 나타내는 릴리스의 샘플 연소 차트(MVP = 최소 실행 가능한 제품)

릴리스 연소 차트는 팀이 릴리스에 대한 가시성을 제공하고 진행 상황을 추적할 수 있는 방법입니다.각 스프린트가 끝날 때마다 업데이트되며 예측 범위를 제공하기 위한 진행 상황을 보여준다.방출 연소 차트의 수평 축은 방출의 스프린트를 나타내고 수직 축은 각 스프린트의 종료 시에 완료된 작업의 양을 나타낸다(일반적으로 완료된 작업의 누적 스토리 포인트를 나타낸다).진행상황은 예측범위를 나타내는 수평선을 충족하기 위해 성장하는 선으로 표시되며, 종종 주어진 출시일까지 얼마나 많은 범위를 완료할 수 있는지 또는 주어진 범위를 완료하기 위해 얼마나 많은 스프린트가 필요할지를 나타내는 지금까지의 진행상황에 기초한 예측과 함께 표시된다.

릴리스 연소 차트를 사용하면 완료된 작업량, 추가 또는 삭제한 작업량(수평 스코프 라인이 이동하는 경우) 및 남은 작업량을 쉽게 확인할 수 있습니다.

Ready의 정의(DoR)

작업 항목을 시작할 수 있을 만큼 사양과 입력이 명확하게 설정되어 있는지 여부를 결정하는 시작 기준입니다.

완료(DoD)의 정의

예를 들어, DoD는 모든 회귀 테스트가 성공적일 것을 요구한다.완료의 정의는 팀마다 다를 수 있지만 [51]팀 내에서 일관성이 있어야 합니다.

속도

주요 기사:속도(소프트웨어 개발)

마지막 스프린트에서 완료된 작업을 평가함으로써 도출된 단일 스프린트에 대한 팀의 총 역량 노력.과거 속도 데이터 수집은 팀이 역량을 이해하는 데 도움이 되는 지침이다.얼마나 많은 일을 편하게 해낼 수 있는지.

이 메트릭은 스크럼 커뮤니티에서 논란을 일으키고 있습니다.

  • 소비된 스토리 포인트가 제공되는 가치와 같지 않음: 팀은 완료된 작업을 보고 이해 관계자에게 제공되는 이점을 무시할 수 있음
  • 주의를 산만하게 하는 관행의 도입: 추정 대 실제, 분산 조사 및 재평가 정책이 발생하기 시작한다.
  • 경영진은 속도를 성능 지표로 간주하여 속도를 높이려고 합니다. 즉, 다음과 같습니다.
    • 품질 저하 - 팀은 추가된 워크로드를 포함하기 위해 "절감"을 시작합니다.
    • 사기가 저하됨 - 팀은 쾌적한 지속 가능한 속도로 일할 수 없으며 압력이 증가하면 탈진 상태가 된다.
    • 견적에 문제가 있음 - 개발자는 버퍼를 구축하고 "지표를 게임화"하기 위해 견적을 부풀려 다른 척도로 동일한 노력을 측정한다.
    • 가치 저하 - 최종 효과는 비즈니스 가치 제공에서 벗어나 초점을 전환함으로써 이해관계자의 불만을 야기하는 간섭입니다.

팀의 딜리버리 능력을 이해하는 것은 중요하지만 속도는 조정 가능한 다이얼이 아니라 팀의 지표로 간주해야 합니다.

스파이크

주요 기사: Spik (소프트웨어 개발)

개념을 연구하거나 단순한 프로토타입을 만드는 데 사용되는 타임박스 기간입니다.스파이크는 스프린트 사이에 발생하도록 계획할 수도 있고, 규모가 큰 팀의 경우 스파이크를 많은 스프린트 제공 목표 중 하나로 받아들일 수도 있다.예산 확보, 지식 확장 또는 개념 실증 작성을 위해 대규모 또는 복잡한 제품 백로그 항목을 제공하기 전에 급증하는 경우가 많습니다.스파이크의 지속 시간과 목표는 출발 전에 팀이 합의한다.스프린트 계약과는 달리, 스파이크는 실질적이고 배송 가능한 가치 있는 기능을 제공할 수도 있고 제공하지 않을 수도 있습니다.예를 들어, 스파이크의 목적은 행동 방침에 대한 결정에 성공적으로 도달하는 것일 수 있습니다.목표가 [52]달성되었을 때가 아니라 시간이 다 되면 급등은 끝난다.

트레이서 탄환

Drone Spike라고도 불리는 트레이서 총알은 현재 아키텍처, 최신 기술 세트, 생산 품질 코드를 생성하는 최신 모범 사례 세트의 스파이크입니다.이것은 기능의 매우 좁은 실장일 수 있지만, 일회용 코드는 아닙니다.이것은 생산품질이며, 나머지 반복은 이 코드를 기반으로 할 수 있습니다.탄환의 경로를 보이게 하고 정정할 수 있도록 하는 탄약으로 군사적 기원을 갖고 있다.대부분의 경우 이러한 구현은 단일 양식의 입력 필드를 백엔드에 연결하는 것과 같은 애플리케이션의 모든 계층을 통해 계층이 [53]예상대로 연결된다는 것을 증명하는 '퀵샷'입니다.

제한 사항

스크럼의 이점은 다음과 같이 [54][55]실현하기 어려울 수 있습니다.

  • 구성원이 지리적으로 분산되어 있거나 비상근인 팀:스크럼에서는 개발자는 긴밀하고 지속적인 상호작용을 해야 하며, 이상적으로는 대부분의 시간을 같은 공간에서 함께 작업해야 합니다.최근의 기술 향상으로 이러한 장벽(예: 디지털 화이트보드 상에서 협업 가능)의 영향이 감소했지만, Agile 매니페스토는 최고의 커뮤니케이션은 [56]직접 만나야 한다고 주장하고 있습니다.
  • 멤버가 매우 전문화된 스킬을 가진 팀: 스크럼에서는 개발자가 T자형 스킬을 가지고 전문 이외의 작업을 할 수 있어야 합니다.이것은 Scrum의 훌륭한 리더십에 의해 장려될 수 있다.매우 구체적인 스킬을 가진 팀원들은 잘 공헌할 수 있지만, 다른 분야에 대해 더 많이 배우고 협력할 수 있도록 장려해야 합니다.
  • 외부 의존 관계가 많은 제품:스크럼에서 제품 개발을 짧은 스프린트로 분할하려면 신중한 계획이 필요하다. 사용자 수용 테스트 또는 다른 팀과의 조정과 같은 외부 의존성은 개별 스프린트의 지연과 실패를 초래할 수 있다.
  • 성숙하거나 레거시 제품 또는 품질 관리가 규제된 제품:스크럼에서 제품 증분은 단일 스프린트에서 완전히 개발 및 테스트해야 한다. 각 릴리스에 대해 대량의 회귀 테스트 또는 안전성 테스트(예: 의료기기 또는 차량 제어)가 필요한 제품은 더 긴 폭포 방출보다 짧은 스프린트에 덜 적합하다.

사용 가능한 도구

주요 기사:Scrum 소프트웨어 비교

다른 신속한 변화를 위한 접근법과 마찬가지로 Scrum의 효과적인 채택은 사용 가능한 다양한 도구를 통해 지원할 수 있습니다(그러나 이에 의존하지 않음).

많은 기업이 스프레드시트 등의 범용 툴을 사용하여 스프린트 백로그를 구축하고 관리하고 있습니다.또한 제품 개발에 스크럼 용어를 사용하거나 스크럼을 포함한 여러 제품 개발 접근 방식을 지원하는 오픈 소스 및 독점 소프트웨어 패키지도 있습니다.

다른 조직에서는 소프트웨어 도구 없이 스크럼을 구현하고 종이, 화이트보드, 스틱 [57]노트 등의 하드카피 형식으로 아티팩트를 유지합니다.

스크럼값

Scrum은 모든 경험적 프로세스 제어와 마찬가지로 투명성, 검사 및 적응의 세 가지 축에 의해 뒷받침되는 피드백 중심의 경험적 접근법입니다.스크럼 프레임워크 내의 모든 작업은 프로세스, 워크플로우, 진행 상황 등 결과에 대한 책임자에게 보여야 합니다.이러한 것들을 가시화하기 위해 스크럼 팀은 개발 중인 제품과 팀의 작업 상태를 자주 점검해야 합니다.빈번한 검사를 통해 팀은 작업이 허용 한계를 벗어나는 경우를 발견하고 공정 또는 개발 [27]중인 제품을 조정할 수 있습니다.

이 세 가지 요소는 팀의 신뢰와 개방성을 필요로 하며, 이를 [3]통해 다음 5가지 가치의 스크럼을 실현할 수 있습니다.

  1. 대처:팀원들은 팀 목표를 달성하기 위해 개별적으로 전력 질주마다 헌신한다.
  2. 용기:팀원들은 그들이 올바른 일을 할 수 있도록 갈등과 도전을 함께 헤쳐나갈 용기가 있다는 것을 알고 있습니다.
  3. 초점: 팀원들은 팀 목표와 스프린트 밀린 일에만 집중합니다. 밀린 일 이외에는 할 일이 없습니다.
  4. 개방성:팀원 및 이해관계자는 자신의 업무와 직면한 과제에 대해 투명하게 대처하기로 합의합니다.
  5. 존중:팀원들은 기술적 능력이 있고 좋은 의도로 일하는 것을 서로를 존중합니다.

적응

스크럼은 다양한 목적을 달성하기 위해 다양한 맥락에서 사용됩니다.이러한 다양한 목적을 달성하기 위해 Scrum은 자주 맞춤 또는 개조됩니다.[58]Scrum을 채택하기 위한 일반적인 접근법은 Scrum을 다른 소프트웨어 개발 방법론과 혼합하는 것입니다. Scrum은 제품 개발 라이프 사이클 전체를 커버하는 것이 아니기 때문에 조직은 보다 포괄적인 구현을 위해 추가 프로세스를 추가할 필요가 있습니다.예를 들어, 제품 개발을 시작할 때 조직은 일반적으로 비즈니스 케이스에 대한 프로세스 지침, 요구사항 수집 및 우선순위 부여, 초기 고급 설계,[59] 예산 및 일정 예측을 추가합니다.

스크럼을 사용하는 다양한 저자와 커뮤니티에서는 스크럼을 특정 문제나 조직에 적용하거나 적용하는 방법에 대한 보다 상세한 기술도 제안하고 있습니다.많은 사람들은 이러한 방법론적 기법을 아키텍처 및 소프트웨어의 설계 패턴과 유사하게 [60][61]'패턴'이라고 부릅니다.

스크럼반

주요 기사: 스크럼반

Scrumban은 Scrum과 Kanban을 기반으로 한 소프트웨어 제작 모델입니다.Scrumban은 특히 생산 결함이나 프로그래밍 오류와 같은 빈번하고 예기치 않은 작업 항목이 있는 제품 유지보수에 적합합니다.이러한 경우, 스크럼 프레임워크의 시간 제한 스프린트는 팀과 당면한 상황에 따라 스크럼의 일상 이벤트와 다른 연습이 적용될 수 있지만, 덜 유익하다고 인식될 수 있다.작업 단계와 미완성 작업 및 결함의 동시화를 시각화하는 것은 칸반 모델에서 잘 알려져 있다.이러한 방법을 사용하여 각 작업 항목 또는 프로그래밍 오류에 대한 완료 시간을 최소화하는 한편, 각 팀 구성원이 지속적으로 [62]고용되도록 팀의 워크플로우를 지시합니다.

각 작업 단계를 설명하기 위해 같은 공간에서 작업하는 팀에서는 포스트잇이나 [63]대형 화이트보드를 사용하는 경우가 많습니다.분산형 팀의 경우 Assembla, Jira, Agilo 등의 무대 일러스트레이션 소프트웨어를 사용할 수 있습니다.

스크럼과 칸반의 큰 차이점은 스크럼 작업은 일정 시간 지속되는 스프린트로 나뉘는 반면 칸반에서는 작업의 흐름이 지속된다는 것이다.이것은, 스프린트 후에 스크럼으로 비워지는 작업 스테이지 테이블에서 볼 수 있는 반면, 칸반에서는 모든 태스크가 같은 테이블에 표시됩니다.Scrum은 다방면에 걸친 노하우를 가진 팀에 중점을 두고 있는 반면 Kanban은 전문적이고 기능적인 팀을 [62]가능하게 합니다.

스크럼 스크럼

스크럼의 스크럼은 같은 제품에 종사하는 여러 팀이 스크럼을 규모에 맞게 운용하는 기술입니다.이를 통해 소프트웨어 제공,[64] 특히 오버랩과 통합에 관한 조정 방법에 초점을 맞추어 상호의존성에 대한 진척에 대해 논의할 수 있습니다.스크럼 스크럼의 타이밍(타이밍)에 따라 각 스크럼팀의 일일 스크럼은 다른 팀의 앰배서더와 스크럼 스크럼에 참여할 멤버 1명을 앰배서더로 지정함으로써 종료된다.상황에 따라 대사는 기술 기여자가 될 수도 있고 각 팀의 [64]스크럼 마스터가 될 수도 있습니다.

스크럼의 스크럼은 단순히 진척상황의 갱신이 아니라 팀이 파악된 리스크, 장애, 의존관계 및 전제조건(RIDA)을 해결, 완화 또는 수용하기 위해 공동으로 작업하는 방법에 초점을 맞춰야 합니다.스크럼의 스크럼은 리스크 보드(해결, 소유, 수용 및 [65]완화라는 이니셜을 따서 ROAM 보드라고도 함)와 같은 자체 백로그를 통해 이러한 RIDA를 추적합니다.이것에 의해, 통상,[64] 팀간의 조정과 협업이 향상됩니다.

이 작업은 일상 스크럼과 유사하게 진행되며, 각 앰배서더는 다음 [66]4가지 질문에 답변합니다.

  • 마지막으로 만난 이후 귀사 팀이 해결한 위험, 장애, 의존성 또는 가정은 무엇입니까?
  • 귀사 팀은 다시 만나기 전에 어떤 위험, 장애, 의존성 또는 가정을 해결해야 합니까?
  • 새로운 리스크, 장애, 의존관계 또는 전제조건이 있어 팀의 속도가 느려지거나 방해가 되고 있습니까?
  • 다른 팀에 방해가 되는 새로운 리스크, 장애, 의존성 또는 가정을 도입할 예정입니까?

제프 [64]서덜랜드가 언급했듯이

원래 Scrums의 Scrum을 정의했기 때문에(Ken Schwaber는 IDX에서 함께 일하고 있었습니다), Scrums의 Scrum은 확실히 Meta Scrum이 아니라고 말할 수 있습니다.내가 사용한 스크럼은 스프린트 종료 시 모든 팀의 작업 소프트웨어를 완료 정의에 전달하거나 스프린트 중에 릴리스하는 역할을 한다.PatientKeeper는 Sprint당 4회 실전 가동에 제공되었습니다.Ancestry.com는 2주간의 스프린트당 220회 실전 가동 환경에 납품합니다.Hubspot은 하루에 100~300회 라이브 소프트웨어를 배포합니다.Scrums Master의 Scrum은 이 작업을 수행할 책임이 있습니다.Scrums의 Scrum은 운영상의 전달 메커니즘입니다.

대규모 스크럼

대규모 스크럼(LeSS)은 스크럼의 본래 목적을 잃지 않고 스케일링 규칙과 가이드라인으로 스크럼을 확장하는 제품 개발 프레임워크입니다.

프레임워크에는 두 가지 레벨이 있습니다.첫 번째 레벨은 최대 8팀으로 설계되어 있습니다.두 번째 레벨은 'LeSS Huge'로 알려져 있으며, 최대 수백 명의 개발자와 함께 개발을 위한 추가 확장 요소가 도입되어 있습니다.Scrum 확장의 시작은 표준적인 실제 원팀 Scrum을 이해하고 채택할 수 있는 것입니다.대규모 Scrum에서는 단일 팀 Scrum 요소의 목적을 검토하고 표준 Scrum [67]규칙의 제약을 유지하면서 동일한 목적에 도달하는 방법을 찾아야 합니다."

Bas Vodde와 Craig Larman은 대규모 제품 개발, 특히 통신업계와 금융업계에서 일한 경험에서 LeSS 프레임워크를 발전시켰습니다.그것은 스크럼을 가지고 무엇이 효과가 있는지 발견하기 위해 많은 다른 실험을 시도함으로써 진화했다.2013년에 실험은 LeSS 프레임워크 [68]규칙으로 통합되었다.LeSS의 목적은 조직의 복잡성을 '설명'하여 불필요한 복잡한 조직 솔루션을 해소하고 보다 심플한 방법으로 해결하는 것입니다.역할, 관리, 조직 [69]구조 감소

비판

스크럼 이벤트는 생산성을 해치고 실제 생산적인 [70][71]작업에 시간을 낭비하는 것으로 알려져 있습니다.이는 보통 행사의 목적과 목표에 [72]대한 오해로 인해 발생하기 때문에 짧은 타임박스식 토론이 아닌 지나치게 긴 회의로 진행됩니다.스크럼 관행은 애자일 매니페스토 정신으로 올바르게 지켜지지 않으면 세세한 관리의[73] 한 형태가 되어 제거하려고 했던 것과 같은 기능을 다시 도입하는 경향이 있습니다.Scrum은 또한 작업을 완료하는 데 필요한 노력을 정확하게 예측할 수 있다고 가정합니다. 그러나 이는 종종 매우 [74]예측 불가능할 수 있습니다.Scrum은 경험적 분석과 실험의 자유를 장려하기 위해 규범적[75] 관행을 의도적으로 생략합니다.스크럼은 프로젝트 관리에[citation needed] 대한 대체 접근 방식이 아니라 일종의 접근 방식이라고 인식됩니다.Scrum을 처음 시도한다고 해서 곧바로 고품질의 결과를 얻을 수 있는 것은 아닙니다.조급함은 Scrum을 짜넣고 확장할[citation needed] 기회를 빼앗습니다.Scrum에 대한 일반적인 기능상[76] 문제가 있는 접근 방식은 이제[77] 다크 스크럼[78] 및 스크림을 포함한 안티패턴으로 인식되고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
  2. ^ "Lessons learned: Using Scrum in non-technical teams". Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
  3. ^ a b c d e f g h i j Ken Schwaber; Jeff Sutherland. "The Scrum Guide". Scrum.org. Retrieved October 27, 2017.
  4. ^ "Scrum, What's in a Name? - DZone Agile". dzone.com.
  5. ^ "Archived copy" (PDF). Archived from the original (PDF) on February 9, 2021. Retrieved April 7, 2021.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  6. ^ 다케우치 히로타카와 노나카 이쿠지로(1986)의 '신상품 개발 게임'
  7. ^ "Should "SCRUM" be written in all caps?". stackoverflow.com. Retrieved January 10, 2017.
  8. ^ "Scrum.org Ken Schwaber". Retrieved February 13, 2022.
  9. ^ a b c d e f Schwaber, Ken (February 1, 2004). Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-7356-1993-7.
  10. ^ Schwaber, Ken (2004). "SCRUM Development Process" (PDF). Advanced Development Methods.
  11. ^ Johnson, Hillary Louise (January 13, 2011). "ScrumMaster vs scrum master: What do you think?". agilelearninglabs.com. Retrieved May 10, 2017.
  12. ^ "What is Scrum?". What is Scrum? An Agile Framework for Completing Complex Projects - Scrum Alliance. Scrum Alliance. Retrieved February 24, 2016.
  13. ^ Verheyen, Gunther (March 21, 2013). "Scrum: Framework, not methodology". Gunther Verheyen. Gunther Verheyen. Retrieved February 24, 2016.
  14. ^ J. Henry와 S.헨리. 소프트웨어 유지보수 프로세스와 요건의 변동성에 대한 정량적 평가.ACM Computer Science Conference의 Proc., 346-351, 1993 페이지.
  15. ^ a b c Takeuchi, Hirotaka; Nonaka, Ikujiro (January 1, 1986). "The New New Product Development Game". Harvard Business Review. Retrieved June 9, 2010. Moving the Scrum Downfield
  16. ^ The Knowledge Creating Company. Oxford University Press. 1995. p. 3. ISBN 9780199762330. Retrieved March 12, 2013.
  17. ^ "Scrum". Lexico UK English Dictionary. Oxford University Press. n.d.
  18. ^ a b Sutherland, Jeff (October 2004). "Agile Development: Lessons learned from the first Scrum". Archived from the original (PDF) on June 30, 2014. Retrieved September 26, 2008.
  19. ^ a b Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business object design and implementation: OOPSLA '95 workshop proceedings. The University of Michigan. p. 118. ISBN 978-3-540-76096-2.
  20. ^ "Manifesto for Agile Software Development". Retrieved October 17, 2019.
  21. ^ Schwaber, Ken; Beedle, Mike (2002). Agile software development with Scrum. Prentice Hall. ISBN 978-0-13-067634-4.
  22. ^ Maximini, Dominik (January 8, 2015). The Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals. Cham: Springer (published 2015). p. 26. ISBN 9783319118277. Retrieved August 25, 2016. Ken Schwaber and Jeff Sutherland presented Scrum for the first time at the OOPSLA conference in Austin, Texas, in 1995. [...] In 2001, the first book about Scrum was published. [...] One year later (2002), Ken founded the Scrum Alliance, aiming at providing worldwide Scrum training and certification.
  23. ^ "Home". Scrum.org. Retrieved January 6, 2020.
  24. ^ Partogi, Joshua (July 7, 2013). "Certified Scrum Master vs Professional Scrum Master". Lean Agile Institute. Retrieved May 10, 2017.
  25. ^ a b McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
  26. ^ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley, p. 173, ISBN 978-0-13-704329-3
  27. ^ a b c d Morris, David (2017). Scrum: an ideal framework for agile projects. In Easy Steps. pp. 178–179. ISBN 9781840787313. OCLC 951453155.
  28. ^ a b c 콘, 마이크신속한 변화를 통한 성공: Scrum을 사용한 소프트웨어 개발.어퍼 새들리버, 뉴저지주: 애디슨-웨슬리, 2010.
  29. ^ "The Scrum Guide" (PDF).
  30. ^ The Scrum guide (PDF). p. 6.
  31. ^ "The Role of the Product Owner". Scrum Alliance. Retrieved May 26, 2018.
  32. ^ Pichler, Roman (March 11, 2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. ISBN 978-0-321-68413-4.
  33. ^ Ambler, Scott. "The Product Owner Role: A Stakeholder Proxy for Agile Teams". agilemodeling.com. Retrieved July 22, 2016. [...] in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
  34. ^ "The Product Owner Role". Scrum Master Test Prep. Retrieved February 3, 2017.
  35. ^ Rad, Nader K.; Turley, Frank (2018). Agile Scrum Foundation Courseware, Second Edition. 's-Hertogenbosch, Netherlands: Van Haren. p. 26. ISBN 9789401802796.
  36. ^ 캐롤, 엔, 오코너, M. 및 에디슨, H. (2018).미국 루이지애나주 뉴올리언스, 8월 16일~18일, 미주 정보 시스템 회의(AMCIS 2018) 소프트웨어 흐름에 대한 장애 식별 및 분류
  37. ^ "Core Scrum". Scrum Alliance. Retrieved January 25, 2015.
  38. ^ a b Drongelen, Mike van; Dennis, Adam; Garabedian, Richard; Gonzalez, Alberto; Krishnaswamy, Aravind (2017). Lean Mobile App Development: Apply Lean startup methodologies to develop successful iOS and Android apps. Birmingham, UK: Packt Publishing Ltd. p. 43. ISBN 9781786467041.
  39. ^ Cobb, Charles G. (2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken, NJ: John Wiley & Sons. p. 37. ISBN 9781118991046.
  40. ^ a b c Pete Deemer; Gabrielle Benefield; Craig Larman; Bas Vodde (December 17, 2012). "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)". InfoQ.
  41. ^ Marta Dunajko. "Planning in Scrum - how to make it effective?". Neurosys.com. Retrieved August 4, 2022.
  42. ^ "What is a Daily Scrum?". Scrum.org. Retrieved January 6, 2020.
  43. ^ Little, Joe (January 17, 2011). "Impediment Management". Agile Consortium. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  44. ^ Flewelling, Paul (2018). The Agile Developer's Handbook: Get more value from your software development: get the best out of the Agile methodology. Birmingham, UK: Packt Publishing Ltd. p. 91. ISBN 9781787280205.
  45. ^ McKenna, Dave (2016). The Art of Scrum: How Scrum Masters Bind Dev Teams and Unleash Agility. Aliquippa, PA: CA Press. p. 126. ISBN 9781484222768.
  46. ^ Higgins, Tony (March 31, 2009). "Authoring Requirements in an Agile World". BA Times.
  47. ^ "The product backlog: your ultimate to-do list". Atlassian. Retrieved July 20, 2016.
  48. ^ 피클러, 로만Scrum을 통한 신속한 제품 관리: 고객이 좋아하는 제품을 만듭니다.어퍼 새들리버, 뉴저지주: 애디슨-웨슬리, 2010.[need quotation to verify]
  49. ^ Russ J. Martinelli; Dragan Z. Milosevic (January 5, 2016). Project Management ToolBox: Tools and Techniques for the Practicing Project Manager. Wiley. p. 304. ISBN 978-1-118-97320-2.
  50. ^ Charles G. Cobb (January 27, 2015). The Project Manager's Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. John Wiley & Sons. p. 378. ISBN 978-1-118-99104-6.
  51. ^ Ken Schwaber, Scrum을 통한 신속한 프로젝트 관리, 페이지 55
  52. ^ "Create a Spike Solution". Extreme Programming.
  53. ^ Sterling, Chris (October 22, 2007). "Research, Spikes, Tracer Bullets, Oh My!". Getting Agile. Retrieved October 23, 2016.
  54. ^ Turk, Dan; France, Robert; Rumpe, Bernhard (2014) [2002]. "Limitations of Agile Software Processes". Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering: 43–46. arXiv:1409.6600.
  55. ^ "Issues and Challenges in Scrum Implementation" (PDF). International Journal of Scientific & Engineering Research. 3 (8). August 2012. Retrieved December 10, 2015.
  56. ^ Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Principles behind the Agile Manifesto". Agile Alliance. Retrieved August 7, 2017.
  57. ^ Dubakov, Michael (2008). "Agile Tools. The Good, the Bad and the Ugly" (PDF). Retrieved August 30, 2010.
  58. ^ Hron, Michal; Obwegeser, Nikolaus (January 1, 2022). "Why and how is Scrum being adapted in practice: A systematic review". Journal of Systems and Software. 183: 111110. doi:10.1016/j.jss.2021.111110. ISSN 0164-1212. S2CID 240950847.
  59. ^ Hron, M.; Obwegeser, N. (January 2018). "Scrum in practice: an overview of Scrum adaptations" (PDF). Proceedings of the 2018 51st Hawaii International Conference on System Sciences (HICSS), January 3–6, 2018.
  60. ^ Bjørnvig, Gertrud; Coplien, Jim (June 21, 2008). "Scrum as Organizational Patterns". Gertrude & Cope.
  61. ^ "Scrum Pattern Community". ScrumPLoP.org. Retrieved July 22, 2016.
  62. ^ a b Kniberg, Henrik; Skarin, Mattias (December 21, 2009). "Kanban and Scrum - Making the most of both" (PDF). InfoQ. Retrieved July 22, 2016.
  63. ^ Ladas, Corey (October 27, 2007). "scrum-ban". Lean Software Engineering. Archived from the original on August 23, 2018. Retrieved September 13, 2012.
  64. ^ a b c d "Scrum of Scrums". Agile Alliance. December 17, 2015. Archived from the original on February 9, 2014. Retrieved December 17, 2013.
  65. ^ "Risk Management – How to Stop Risks from Screwing Up Your Projects!". Kelly Waters.
  66. ^ "Scrum of Scrums". Scrum Master Test Prep. Retrieved May 29, 2015.
  67. ^ Larman; scrumyear=2013. "Scaling Agile Development (Crosstalk journal, November / December 2013)" (PDF).
  68. ^ "Large-Scale Scrum (LeSS)". 2014.
  69. ^ Grgic (2015). "Descaling organisation with LeSS (Blog)".
  70. ^ Jenson, John (March 8, 2019). "Meetings: The productivity killer for developers". TandemSeven - The Experience Innovation Company. Retrieved June 5, 2020.
  71. ^ "Not all developers like agile, and here are 5 reasons why". Business Matters. December 4, 2019. Retrieved June 5, 2020.
  72. ^ "5 Dysfunctions of a Daily Scrum". Scrum.org. Retrieved July 3, 2021.
  73. ^ on, Isaak Tsalicoglou. "How to transition from Agile to micromanagement Hacker Noon". hackernoon.com. Retrieved June 5, 2020.
  74. ^ Cagle, Kurt. "The End of Agile". Forbes. Retrieved June 5, 2020.
  75. ^ James (MJ), Michael (March 29, 2021). "Things Ken Schwaber Intentionally Omits From Scrum". The Seattle Scrum Company. Retrieved July 3, 2021.
  76. ^ Derecskey, Dave (July 18, 2018). "5 Common Team Dysfunctions (and How the 5 Core Scrum Values Directly Address Them)". Medium. Retrieved July 3, 2021.
  77. ^ "Dark Scrum". ronjeffries.com. Retrieved July 3, 2021.
  78. ^ "The Scream Guide". Google Docs. Retrieved July 3, 2021.

추가 정보

외부 링크

Wikimedia Commons에는 Scrum(개발) 관련 미디어가 있습니다.