유래

스크럼은 일본에서부터 사용하기 시작한 제품 개발 프로세스의 한 유형을 가리키는 용어다. 이 용어는 노나카 이쿠지로와 타케우치 히로타카가 생산성에서 경쟁자들을 압도하는 일부 기업들의 제품 개발을 설명하기 위해 1987년에 처음으로 사용하기 시작했다. 스크럼은 럭비에서 공이 경기장 바깥으로 나가서 플레이를 다시 시작할 때 취하는 전술 대형을 말한다. 스크럼이 배제하려고 하는 제품 개발 프로세스와 럭비 경기 사이의 유사성 때문에 우리는 스크럼이라는 이름에 반해 버렸다. 둘 다 현실 적응적이고, 기민하며, 자기 조직적이다. 쉴 틈이 별로 없다.

(중략)

스크럼은 비즈니스 요구를 충족시키는 소프트웨어를 개발하는 데 초점을 맞추기 위해서 복잡함을 제거하는 관리 및 제어 프로세스이다. 스크럼은 기존의 엔지니어링 실천법, 개발 방법론 혹은 표준들을 아우르고 포괄한다. 또한 스크럼은 익스트림 프로그래밍(Extreme Programming)의 실천방법으로 사용한다. 경영진과 팀은 요구사항과 기술들을 놓치는 것 없이 잘 갈무리하여 작동하는 소프트웨어를 전달할 수 있다. 스크럼은 1개월 안에 돌아가는 기능을 만들수 있게 한다.

스크럼은 주로 팀 수준의 사안들을 다룬다. 스크럼은 사람들이 효과적으로 협업할 수 있게 해주며, 또한 그렇게 함으로써 복잡하고 정교한 제품을 생산할 수 있게 해준다. 즉, 스크럼은 협력을 촉진함으로써 모든 관련자의 성취감을 충족시키는 것을 목적으로 하는 일종의 사회 공학이다. 경영진의 적극적인 보살핌과 후원 속에서 개발팀이 자율적으로 일을 추진할 때 협력이 발생한다. 스크럼을 사용하면, 팀은 점진적 그리고 경험적으로 제품을 개발하게 된다. 개발팀은 사전에 수립된 프로젝트 계획보다는 자신의 지식과 경험을 따르게 된다. 결국 스크럼을 적용한 거의 대부분의 프로젝트에서 생산성이 급격하게 증가한다.

스크럼의 창안자인 우리들은 스크럼을 전통적인 방법론과 프로세스에 대한 효과적인 대안으로 사용하면서 진화시켜 왔다. 우리는 여러분이 우리의 생각을 이해하고, 우리의 경험을 공유하며, 우리가 맛보았던 성공을 여러분이 속한 조직에서 재현할 수 있도록 하기 위해서 이 책을 썼다. 1

스크럼의 기본 원칙

스크럼의 기본 원칙 중 하나는 '가능한 것을 하라(the art of the possible)'이다. 다시 말해서, 스크럼은 불가능한 것들에 매달리지 말고 가능한 것부터 생각하라고 가르친다. 개발팀에게 최대 허용 시간(time box)을 주고, 그 안에서 제품을 만들어 내라고 요구하는 것이다. 무엇이 가능한지 그리고 주어진 자원들로 문제를 어떻게 해결할 수 있을지에 초점을 맞추는 것이 중요하다. 2

요약

스크럼?

  • 복잡한 문제를 점진적으로 해결하기 위한 팀 관리 방법.
  • "스크럼"은 럭비 팀이 함께 전진하는 모습에서 따온 단어.
  • 스프린트 단위로 진행해 나가며, 매 스프린트마다 점진적으로 제품을 배포한다.

스크럼 팀의 구성

  • 인원 구성
    • 스크럼 마스터: 1명
    • 프로덕트 오너: 1명
    • 개발자: 여러명 (4~8명이 적절)
  • 스크럼 팀에는 하위 팀이 없다.
  • 스크럼 팀 하나가 스프린트를 완료하기 위한 모든 기술을 갖고 있어야 한다.
  • 스크럼 팀은 하나의 목표에 동시에 집중하는 전문가들의 모임이다.

각 멤버의 역할

  • 개발자
    • 매 스프린트마다 사용 가능한 기능을 점진적으로 만들어 배포한다.
  • 프로덕트 오너(PO)
    • 프로덕트 가치를 극대화하는 책임을 갖는다.
      • 프로덕트의 목표를 세운다.
    • 백로그를 관리한다.
      • 백로그 아이템을 만든다.
      • 백로그 우선순위를 정한다.
      • 백로그를 이해하기 쉽게 설명한다.
  • 스크럼 마스터
    • 팀과 조직이 스크럼 방법론을 이해하고 실천할 수 있게 돕는다.

스프린트: 스크럼 진행 방법

스크럼의 작업 흐름 요약3

  • 스프린트 계획
    • PO: 다음 스프린트 목표를 제안한다.
    • 다같이: 다음 스프린트 목표를 정의한다. 목표를 못 세우면 안된다.
    • 다같이: 다음 스프린트의 완료 기준을 정의한다.
    • 개발자들: 다음 스프린트를 어떻게 완료할 것인지를 계획한다.
  • 일일 스크럼
    • 주로 개발자들만 참여하는 15분짜리 회의.
    • 매일 같은 시각에 같은 장소에서 한다.
    • 팀 의사소통 향상, 장애물 식별, 신속한 의사 결정을 목표로 한다.
    • 별도로 다른 회의를 할 필요성을 줄이기 위해서 한다.
  • 스프린트 리뷰
    • 몇몇 사람이 발표만 하고 끝나면 안된다!
    • 스프린트 결과를 점검한다.
    • 이해관계자들에게 결과물과 프로덕트 진척도를 보여준다.
    • 다음에 무엇을 할 것인지를 논의한다.
    • 필요하다면 백로그를 수정한다.
  • 스프린트 회고
    • 품질과 효율 향상을 위한 방법을 계획한다.
    • 각자 역할별로 지난 스프린트가 어떻게 진행됐나 점검한다.
    • 팀이 잘못된 방향으로 나아간 근본 원인을 찾는다.
    • 스프린트에서 잘 해낸 것에 대해서도 논의한다.
    • 효율을 향상시키기 위한 방법을 찾고, 그 중 가장 영향이 클 것 같은 개선책을 고려해서 다음 스프린트에서 해보는 방향으로 논의한다.
    • 스프린트 회고를 하면 스프린트가 끝난다.

From: 스크럼 가이드

스크럼의 정의

스크럼은 사람과 팀, 조직이 복잡한 문제에 대해 적응할 수 있는 해법Adaptive solutions을 활용하여 가치를 창출하도록 도와주는 경량Lightweight 프레임워크이다.

간단히 말해서 스크럼은 스크럼 마스터가 다음과 같은 환경을 조성하는 것이다:

  1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
  2. 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분Increment of value으로 만들어 낸다.
    • (*증가분은 스크럼 팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미한다. - 번역자)
  3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
  4. 반복한다. 4

스프린트

스프린트를 진행하게 되면 적어도 한 달에 한 번은 프로덕트 목표 대비 진척을 점검하고 조정을 할 수 있기 때문에 프로젝트 진척에 대한 예측 정확도를 높일 수 있다. 스프린트 기간을 너무 길게 잡으면, 스프린트 목표가 효력이 없어지거나 복잡도가 늘어나고 리스크가 높아질 수 있다. 더 짧은 스프린트 기간일수록 더 많은 학습 기회를 가질 수 있고, 짧은 기간 동안 수행하는 비용과 노력으로 리스크를 한정시킬 수 있다. 각 스프린트는 짧은 프로젝트와 같이 여겨질 수 있다.

진척을 예측하는 데에는 [[/jargon/burndown-chart]]{번 다운Burn-downs차트}, 번 업Burn-ups차트, 누적 흐름도Cumulative flows와 같은 다양한 방식이 있다. 이러한 방식이 유용하기는 하지만, 경험주의의 중요성을 대체하지는 못한다. 복잡한 환경에서는 어떤 일이 일어날지 알 수가 없다. 단지 지금까지 무엇이 발생했는지를 토대로 앞으로의 결정을 내릴 수 있다.

스프린트 목표가 효력이 없게 되면, 스프린트를 취소할 수있다. 오직 프로덕트 오너만이 스프린트를 취소할 결정권을 갖는다. 5

데일리 스크럼

데일리 스크럼의 목적은 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것이다.

데일리 스크럼은 스크럼 팀의 개발자들만 참여하는 15 분 길이의 이벤트이다. 복잡성을 줄이기 위해 같은 시각에 같은 장소에서 스프린트 기간의 모든 근무일 마다 수행한다. 만약 프로덕트 오너나 스크럼 마스터도 스프린트 백로그 아이템을 맡아 활동적으로 업무를 하고 있다면 개발자들의 일원으로 데일리 스크럼에 참여할 수 있다.

개발자들이 실행하는 데일리 스크럼이 스프린트 목표 대비 진척과 다음 근무일에 실행할 수 있는 계획을 만드는 것에 초점을 두는 한, 개발자들은 어떤 방식이나 기법으로도 데일리 스크럼을 진행할 수 있다. 이로써 일에 집중하고 자율관리 팀으로서의 능력을 향상시킨다.

데일리 스크럼은 팀의 소통을 향상시키고 팀이 가지고 있는 장애물을 식별하며 신속한 의사 결정을 촉진하여 별도로 다른 미팅을 할 필요성을 줄여준다.

개발자들이 계획 변경에대한 논의를반드시 데일리 스크럼에서만 해야 하는 것은 아니다. 아무 때나 자주 만나서 더 상세하게 남은 스프린트의 업무를 조정하거나 다시 계획하는 논의를 진행하면 된다. 6

개발팀 크기

최적의 개발팀 크기는 민첩하게 대응할 수 있도록 충분히 작고, 한 스프린트 안에서 의미 있는 작업을 끝낼 수 있을 정도로 충분히 커야 합니다. 3 명 미만의 개발팀은 서로 간의 교류가 적기 때문에 결과적으로 적은 생산성을 얻게 됩니다. 작은 규모의 개발팀은 팀 내부에 필요한 기술 역량이 없을 수 있으므로 스프린트를 수행하는 동안 기술적인 제약이 발생하여 출시할 수 있는 기능이 포함된 제품 증분을 배포하지 못할 수도 있습니다. 9 명 이상의 개발팀은 너무 많은 상호 협조를 요구합니다. 큰 규모의 개발팀은 경험적 프로세스를 활용하기에는 너무 복잡합니다. 제품 책임자와 스크럼 마스터는 그들이 스프린트 백로그 작업에 참여하지 않는 이상 개발팀 인원수에 포함되지 않습니다. 7

스프린트 백로그

스프린트 백로그는 스프린트 목표(왜), 스프린트를 위해 선택된 프로덕트 백로그 아이템들의 모음(무엇을), 증가분을 전달하기 위한 실행할 수 있는 계획(어떻게)으로 구성되어 있다.

스프린트 백로그는 개발자들에 의한 개발자들을 위한 계획이다. 매우 가시적이며, 개발자들이 스프린트 목표를 달성하기 위해 스프린트 동안 완수하기로 계획한 업무를 실시간으로 보여주는 그림이다. 따라서 스프린트 백로그는 스프린트 기간 동안 더 알게 된 것만큼 업데이트 된다. 스프린트 백로그는 데일리 스크럼 때 진척을 확인할 수 있을 만큼 세부 내용이 충분해야 한다. 8

From: 애자일 조직은 이렇게 일합니다

스크럼이 뭐야?

스크럼은 가볍지만 체계적이고 잘 짜여진 팀 워크플로Workflow 관리 방식이다. 스크럼은 특정 기술 실천법을 강요하지 않는다. 팀에서 일을 어떻게 다뤄야 하는지 정의하고, 팀이 사용하는 특정 역할과 업무 조정에 필요한 방법을 규정한다. 9

스크럼 기초

스크럼은 일련의 규칙을 담고 있는 이벤트(회의나 행사라고도 함), 역할, 산출물로 요약된다.

스크럼은 개념적으로 스크럼에서 요구사항을 담당하는 프로덕트 오너Product Owner, PO가 만든 '제품 백로그'Product Backlog로 시작한다. 제품 백로그는 스크럼팀이 전달해야 하는 요구사항, 진행 중인 요구사항, 피처, 기능, 스토리, 개선사항 및 수정사항의 묶음이다. 제품 백로그는 가능한 모든 요구사항의 완벽한 리스트를 제공하는 대신 가장 중요하고 가장 시급하며 가장 ROI가 높은 요구사항에 초점을 둔다.

스크럼팀은 1~4주의 반복적인 시간 주기인 '스프린트'Sprint 안에서 작업을 수행한다. 보통 1~3주 스프린트가 가장 잘 작동한다. 스프린트가 길어질수록 리스크가 증가하고 개선 기회는 제한된다. 2주 스프린트가 가장 일반적이다. 10

스크럼 프로젝트의 작업 흐름

스크럼의 작업 흐름 요약

3

애자일팀은 블랙박스여야 한다

스크럼의 애자일 실천법은 스크럼팀을 명시적으로 '블랙박스'로 취급한다. 만약 당신이 조직의 리더라면 팀의 투입과 산출은 볼 수 있지만, 팀 내부 업무에 대해서는 크게 신경 쓰지 말아야 한다.

스크럼에서 이러한 아이디어는 팀이 각 스프린트를 시작할 때 정해진 양의 작업(스프린트 목표)을 수행한다고 말함으로써 구현된다. 팀은 스프린트가 끝날 때까지 무슨 일이 있어도 작업을 완수할 것을 약속한다. 그런 다음, 팀은 스프린트 기간 동안 블랙박스로 취급된다. 아무도 내부를 들여다볼 수 없고, 누구도 스프린트 중에 일감을 더 넣을 수 없다. 스프린트가 끝나면 팀은 처음에 약속했던 기능을 전달한다. 스프린트가 짧기 때문에 관리자는 팀이 약속을 지켰는지 확인하기 위해 기다릴 필요가 없다.

팀을 블랙박스로 표현한 건 다소 과장되었지만 그 본질이 중요하다. 관리자나 다른 리더들과 나눈 수백 건의 대화에 따르면, 팀을 블랙박스로 취급하면 보다 건강하고 효과적인 관리가 가능하다. 관리자가 세부 기술이나 프로세스를 검토해선 안 된다. 그들은 팀이 명확한 방향성을 갖도록 하는 데에 초점을 두어야 하며, 팀이 그 방향을 수행하는 책임을 지도록 해야 한다. 팀이 목표를 향해서 어떻게 갈 건지 매 순간 내리는 결정이나 저지르는 실수를 모두 알 필요 없다. 세부사항에 지나치게 신경 쓰는 일은 실수를 문책하지 않고 팀의 자율도를 극대화하는 등의 여 러 핵심 원칙에 반대되는 행위이다.

리더가 '블랙박스'에서 관심 가져야 하는 일은 장애물 제거, 스프린트 도중 운영 중단 막기, 갈등 해결을 통한 팀 코칭, 프로젝트 간 우선순위 충돌 해결, 자기 계발 지원, 새로운 팀원 채용, 조직 관료주의 간소화, 팀의 경험을 되돌아봄으로써 배우는 일 장려하기 등이다. 11

완료 정의 만들고 사용하기

완료 정의Definition of Done, DoD가 명확해야 한 항목에 대한 QA 작업을 다른 모든 작업과 밀접하게 맞물리도록 수행할 수 있어서 결함 삽입과 감지 사이의 간격을 최소화하는 데 도움이 된다. 좋은 DoD는 설계, 코드, 테스트, 문서화 및 요구사항 구현과 관련된 기타 모든 작업에 대한 완료 기준을 포함한다. 완료 기준은 참 혹은 거짓이라는 용어를 사용하여 명시하는 게 이상적이다. 그림 11-2는 DoD의 예이다.

  • 코드 리뷰 통과
  • 정적 코드 분석 통과
  • 에러 없이 단위 테스트 통과
  • 단위 테스트를 통해 70% 상태 커버
  • 시스템과 통합 테스트 완료
  • 오류 없이 자동화된 비기능 테스트 완료
  • 에러와 경고 없이 빌드
  • 문서화된 모든 공용 API 12

From: HARD CODE

에릭 브레히너의 마이크로소프트 사내 칼럼으로, 2006년 3월 1일 작성된 글이다.

스크럼은 약어인가?

미신 #7: 스크럼은 약어다

스크럼은 가장 널리 알려지고 가장 많이 적용되는 애자일 기법의 하나지만 약어는 아니다. 스크럼은 럭비 용어로, 팀이 공을 되찾으려고 팔짱 끼고 전진하는 모습을 가리킨다. 스크럼팀이 매일 여는 간단 회의(Standup meeting)도 스크럼이라고 부른다. 마이크로소프트에서는 스크럼과 유사한 기법을 10여년 전부터, 그러니까 용어가 생기기 훨씬 전부터 사용해 왔다. 스크럼은 가장 단순한 애자일 기법 중 하나며, 많은 마이크로소프트 팀이 이미 사용하는 방식과 가장 유사하다. 13

에릭 브레히너가 말하는 스크럼

마지막으로 소개할 기법은 스크럼으로, 가장 오해를 많이 받는 기법이다. 익스트림 프로그래밍과 스크럼을 혼동하는 사람도 있고(실제로 익스트림 프로그래밍은 스크럼을 사용하지 않는다) 애자일과 스크럼을 동일하게 취급하는 사람도 있다(도대체 왜?). 이 중에서도 가장 혼란스러운 점이라면 스크럼이 사용하는 이상한 용어들이다. 스크럼 마스터(Scrum Master), 백로그(backlog), 번다운(burn-down), 스프린트(sprint), 심지어 닭과 돼지라는 용어도 나온다. 관리자들이 겁먹고 달아날 만하다. 큰 실수다.
(중략) 13

  • 스크럼: 매일 모여서서 진행하는 간단한 회의
  • 스크럼 마스터: 기능팀 조직자
  • 백로그: 기능 목록 혹은 작업 항목 목록
  • 번다운: 남은 업무를 표시하는 그래프
  • 스프린트: 작은 중간목표
  • 닭과 돼지: 기업 농장에 사는 동물들

  • 스크럼에서 일일 간단 회의는 아주 체계적이며 유용한 자료를 수집한다. 스크럼 마스터(팀 조직자)는 각 팀원에게 어제 회의 이후로 진행한 업무와 (걸린 시간과) 내일 회의까지 진행할 업무와 (남은 업무량과) 업무 장애 요소를 묻는다.

  • 스크럼에서 수집하는 자료는 스프레드시트나 데이터베이스에 저장한다. 스프레드시트 기능을 이용하면 업무에 걸리는 시간, 완료 날짜, 진행 중인 업무, 계획 변경 등 다양한 프로젝트 사안을 분석하기 쉽다. 스크럼 기법에서 가장 많이 사용하는 그래프는 시간 대비 남은 작업량을 보여주는 번다운 차트다.

  • 스크럼 마스터는 팀에서 독립적인 위치에 선다. 아예 팀 소속이 아니면 더욱 좋지만 현실적으로 쉽지 않다. 스크럼 마스터는 회의를 짧고 간단하게 이끌어야 한다.

  • 기능 목록이나 기능 일정은 제품 백로그, 작업 항목 목록이나 작업 일정은 스프린트 백로그라고 부른다. 두 목록을 분리함으로써 관리층은 제품에 넣을 기능(제품 백로그)에, 기능팀은 닥친 업무(스프린트 백로그)에 집중할 수 있다. 스크럼 마스터는 보통 일주일에 한 번씩 관리층과 만나서 (예를 들어, 주간 책임자 회의에서) 경과와 상태를 보고한다.

  • 작은 중간목표를 뜻하는 스프린트는 기간을 고정한다. 스프린트는 지정한 일 수가 지나면 끝나는데, 대략 30일 정도가 보통이다.

  • 스프린트가 끝날 때마다 기능팀은 관리층과 만나 업무 진행 상태를 검토하고(꽤 괜찮은 변화라고 생각하지 않는가?), 잘한 점과 개선할 점을 토론하고(제품을 출시하고 나서 사후분석을 수행할 때까지 일 년 아니 10년을 기다리는 방식보다 훨씬 낫지 않은가?), 다음 스프린트에 주력할 작업 항목을 다시 예측한다(계획과 예측값이 변했다고? 그럴 리가!).

일일, 주간, 월간 피드백 메커니즘을 둠으로써 스크럼팀은 변화하는 환경에서도 효율성과 탄력성을 잃지 않는다. 또한 핵심 자료를 수집함으로써 스크럼팀과 관리층은 프로젝트 진행 상태와 업무 장애 요인을 사전에 파악한다. 관리층이 소유하는 기능 목록과 기능팀이 소유하는 작업 항목 목록을 분리함으로써 스크럼팀은 방향을 잃지 않고 업무에 집중한다. 이런 방식으로 스크럼은 팀 구성원 각자와 관리층 모두에게 책임을 부여한다. 13

강요하면 안 된다

에릭 브레히너는 강요하면 안 된다고 강조한다.

관리자들이 팀에게 특정 방법론을 강요하는 경우를 내 주변에서 많이 봤다. 스크럼처럼 인기 있는 기법일지라도 강요는 반드시 역효과를 낸다. 관리자는 제안하고, 보조하고, 장려하는 역할에 서야 한다. 절대로 강요해서는 안 된다. 13

From: Kanban and Scrum - Making the Most of Both

  • Split your organization into small, cross-functional, self-organizing teams.
  • Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
  • Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
  • Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
  • Optimize the process by having a retrospective after each iteration.
  • 조직을 작게 쪼갠다.
    • 기능적으로 직교하도록 쪼갠다.
    • 스스로 운영할 수 있도록 쪼갠다.
  • 업무를 작은 일들의 목록으로 쪼갠다.
    • 배포 가능한 단위로 쪼갠다.
    • 목록은 우선순위에 따라 정렬한다.
    • 각 업무 항목에 대해 상대적인 노력의 양을 추정한다.
  • 시간을 쪼갠다.
    • 시간을 짧고 고정된 단위의 이터레이션(1~4 주 정도)으로 쪼갠다.
    • 각 이터레이션마다 출시 가능한 코드가 나와야 하고, 시연도 가능해야 한다.
  • 릴리즈 계획을 최적화한다. 그리고 고객과 함께 검토하여 일의 우선순위를 업데이트한다.
    • 매 이터레이션마다 배포된 결과를 검토하면서 얻은 깨달음을 활용하도록 한다.
  • 매 이터레이션마다 회고를 하여 업무 프로세스를 최적화한다.

So instead of a large group spending a long time building a big thing, we have a small team spending a short time building a small thing. But integrating regularly to see the whole.

  • 우리는 커다란 그룹에서 오랜 시간을 사용하여 커다란 결과를 만드는 것보다, 작은 팀으로 짧은 시간 동안 작은 결과를 만들어 내도록 한다.
  • 단, 항상 전체를 조망할 수 있도록 주기적으로 결과를 전체에 통합한다.

From: 데브옵스 핸드북

대부분의 최신 소프트웨어 개발 방법론은 빅뱅 방식(예를 들어, 폭포수 모델) 대신, 짧고 반복적인 개발 주기를 규정하고 있다. 일반적으로, 배포 주기가 길어질수록 결과가 나빠진다. 예를 들어 스크럼 방법론에서 스프린트(sprint)는 시간이 표시된 개발 완료 주기(일반적으로, 1개월이나 그 이하)로, 여기에서 "완료(Done)"란 "작동하고, 잠재적으로 출시 가능한 코드"가 있는 경우로 정의된다.14

참고문헌

  • HARD CODE / 박재호 역 / 에이콘출판사 / 발행 2009년 06월 30일 / 원제 : I. M. Wright's Hard Code
  • Kanban vs Scrum - How to make the most of both (PDF)
  • 스크럼 가이드 2017년 11월
  • 스크럼 가이드 2020년 11월
  • 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  • 스크럼 / 켄 슈와버, 마이크 비들 공저 / 박일, 김기웅 공역 / 인사이트(insight) / 초판 1쇄 발행: 2008년 10월 03일 / 원제 : Agile Software Development with Scrum
  • 애자일 조직은 이렇게 일합니다 / 스티브 매코널 저/백미진 역 / 인사이트(insight) / 초판 1쇄 발행 2022년 06월 29일 / 원제: More Effective Agile

주석

  1. 스크럼. 1장. 2쪽. ↩

  2. 스크럼. 2장. 42쪽. ↩

  3. 애자일 조직은 이렇게 일합니다. 4장. 44쪽. ↩ ↩2

  4. 스크럼 가이드 2020년 11월. 5쪽. ↩

  5. 스크럼 가이드 2020년 11월. 11쪽. ↩

  6. 스크럼 가이드 2020년 11월. 13쪽. ↩

  7. 스크럼 가이드 2017년 11월. 9쪽. ↩

  8. 스크럼 가이드 2020년 11월. 16쪽. ↩

  9. 애자일 조직은 이렇게 일합니다. 4장. 42쪽. ↩

  10. 애자일 조직은 이렇게 일합니다. 4장. 43쪽. ↩

  11. 애자일 조직은 이렇게 일합니다. 5장. 80쪽. ↩

  12. 애자일 조직은 이렇게 일합니다. 11장. 175쪽. ↩

  13. HARD CODE. 2장. ↩ ↩2 ↩3 ↩4

  14. 데브옵스 핸드북. 168쪽. ↩