스크럼

스크럼(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이다. 애자일 소프트웨어 개발 중 하나로서, 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 뜻하는 럭비 용어에서 유래되었다. 소프트웨어 개발 프로젝트를 위해 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트나 프로그램 관리에서도 적용될 수 있다.

개요

특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크다. 스크럼은 30일을 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다. 일반적인 권장 기간은 30일이지만, 스크럼 적응도 및 진행 상황에 따라 1주~4주 정도의 유연성을 가진다. 주기가 너무 짧으면 개발 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로, 적용해보면서 조율이 필요한 경우 조율하는 것이 좋다. 스크럼 과정을 통해 개발 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해나가게 된다. 보통, 각 작업은 4시간에서 16시간 정도를 소요하도록 정한다. 물론, 작업을 정하고 할당하는 것은 팀 내에서 자율적으로 진행된다. 애자일 프로세스는 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화를 중요하게 여긴다. 다만 다른 프로세스들에 비해 무질서해 보이기 때문에 전통적인 프로세스 개선과 마찰이 있다. 비즈니스 요구를 충족시키는 데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크 기법이다. 사람들이 효과적으로 성취감을 충족하며 협업할 수 있게 하여, 복잡하고 정교한 제품을 생산하도록 한다.

역사

스크럼 방법론을 창조한 것은 제프 서덜랜드와 켄 슈와버이지만, 스크럼이랑 용어가 처음 등장한 것은 노나카 이쿠지로와 타케우치 히로타카가 하버드 비즈니스 리뷰에 발표된 ‘새로운 신제품 개발 방식’이었다. 이 글에 큰 영감을 받은 서덜랜드와 슈와버가 스크럼의 개념을 실천 기법으로 개발, 발전시키게 된다. 노나카와 타케우치가 왜 럭비 용어인 스크럼을 사용했는지에 대한 언급은 없지만, 스크럼의 핵심인 주도적인 팀 수행을 묘사하기 위해 사용한 것으로 추측된다. 생산성과 혁신을 나타내는 제조업체의 특성을 바탕으로 기업이 팀 안에서 서로 공을 주고받으며 하나가 되어 필드를 나아가는 럭비팀처럼 일체적 방법론을 사용한다고 비유하였다.

특징

특정 언어나 방법론에 의존적이지 않고, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용범위의 개발 기법이다. 스크럼은 다음과 같은 특성을 가진다. 솔루션에 포함할 기능이나 개선점에 대한 우선순위를 부여한다. 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과와 적용할 기능이나 개선에 대한 목록을 제공해야 한다. 날마다 15분 정도 회의를 가지고, 항상 팀 단위라 생각해야 한다. 이때 주의할 것은 보고하는 자리가 아니라 공유하는 자리라는 것이다. 이 프로젝트와 관련되어 한 일, 또는 이슈들을 공유해야 한다. 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지해야 한다.

장점

스프린트마다 생산되는 실행 가능한 제품들을 통해 사용자와 충분히 의견을 나눌 수 있고, 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능하다. 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다. 다른 개발 방법론들에 비해 단순하고 실천 지향적이다. 스크럼마스터는 개발 팀원들이 목표달성에 집중할 수 있도록 팀의 문제를 해결한다. 프로젝트 진행 현황을 볼 수 있어, 신속하게 목표와 결과를 추정할 수 있고, 목표에 맞게 변화를 시도할 수 있다.

단점

스프린트가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 한다. 그런데 이 작업이 많아지면 그만큼 작업 시간이 더 필요하다. 일일 스크럼 회의를 15분 정도로 제한해 두었는데, 15분 안에 회의를 끝내기는 어렵다. 회의가 길어지게 될 경우 작업 시간이 늦어지고 이로 인해 작업하는데 상당히 방해를 받을 수도 있다. 또한 매일매일 회의를 해야 한다는 부담이 있을 수 있다. 투입 인원수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어렵다. 또한 스크럼은 프로젝트의 관리를 중점으로 하기 때문에 스프린트 수행 후 검토 희의를 하지만 프로세스 품질을 평가하지 않아 품질 관련 활동이 미약하고, 따라서 품질의 정도를 알 수 없다. 검사를 있다 하더라도 부실한 품질평가가 이루어진다.

진행순서

제품 백로그 작성

제품 책임자가 사용자 스토리를 기반으로 제품 백로그를 작성한다. 제품 백로그는 사용자 중심의 기능들을 우선순위를 매겨 나열한 리스트이다. 이때 사용자 스토리는 사용자의 관점에서 작성이 되어야 한다. 제품 백로그는 제품 수명 기간 동안 계속 존재하고 개선되면서 해당 제품의 로드맵 역할을 하기 때문이다. 어떤 관점에서 보든, 제품 백로그에는 팀이 해야 하는 모든 것이 우선순위에 따라 기록된 것이 한 눈에 명확히 드러나야 한다. 하나의 제품에 대해서는 오직 하나의 제품 백로그만이 존재한다. 이 말은 제품 책임자는 팀을 포함해서 이해관계자들의 관심사를 전반적으로 반영해서 우선 순위를 결정해야 한다는 것을 뜻한다. 위에 있을수록 우선순위가 높고 상세화되어 있다. 제품 백로그에는 다양한 아이템들이 포함되는데 모든 사용자들은 장바구니에 책을 담을 수 있다와 같은 우선적으로 고객을 위한 새로운 기능이 포함된다. 뿐만 아니라 해당 시스템을 C++ 기반에서 자바 기반으로 변환한다와 같은 개발에 대한 발전 목표나 테스트 속도를 향상시킨다와 같은 팀에서의 개선 목표, 신용카드 인증 속도를 향상하기 위한 해결책을 조사한다와 같은 연구 업무 또는 결함이 많지 않다면 스크립트 오류를 처리하는 명령어를 진단하고 고친다와 같이 발견된 결함을 포함시킬 수도 있다. 결함이 많은 시스템의 경우는 보통 별도의 결함 추적 시스템을 가진다. 제품 백로그에 들어갈 아이템들은 어떤 방식으로든 분명하고 계속 유지될 수 있도록 표현된다. 많이 오해하고 있는 것과는 달리 제품 백로그는 사용자 스토리가 아니라 단지 아이템만 담는다. 이러한 아이템들은 사용자 스토리, 유스케이스 또는 팀이 유용하다고 생각하는 요구사항 작성 방법으로 표현될 수 있다. 어떤 방식을 활용하든, 대부분의 아이템들은 고객에게 가치를 전달하는 것에 초점이 맞춰져야 한다. 좋은 제품 백로그는 다음과 같은 특징을 갖는다. 먼저 최우선 순위의 아이템은 낮은 우선순위의 아이템보다 먼저 진행되기 때문에 더 상세하고 세밀하게 기술되어 있어야 한다. 팀은 제품 책임자에게 제품 백로그의 각 아이템에 해당하는 일의 양과 기술적인 위험성에 대한 추정치를 제공해야 한다. 제품 책임자와 다른 사업적인 이해관계자들은 제품 요구사항의 가치에 대한 정보를 다양한 이해관계자들에게 전달해야 한다. 이 정보에는 수익이나 비용 절감, 사업적인 리스크, 중요성이 포함될 수 있다. 더불어 학습한 내용이나 변동되는 것들에 맞추어 제품 백로그는 자주 개선된다. 매 스프린트마다 우선순위에 따라 아이템들이 추가되고 제거되고 수정되며 쪼개지고 변경된다. 그러므로 고객의 니즈 변화, 새로운 아이디어, 경쟁사의 움직임, 기술적인 걸림돌 등을 반영하기 위해서 제품 책임자는 계속해서 제품을 업데이트 해야 한다. 마지막으로 제품 백로그의 최우선 순위 아이템부터 1에서 N까지의 순서로 우선순위가 매겨져야 한다. 최우선 순위의 아이템들은 적은 비용으로 큰 가치를 내는 것이어야 한다. 또 다른 방식으로는 큰 위험을 포함하고 있는 아이템의 우선순위를 높게 잡는 방법이 있다.

적용하기에 불명확할 경우, 전반적인 경영 성과를 바탕으로 접근할 수 있다. 이런 경우는 성과에 관련된 여러 개의 아이템들이 한 번에 전달돼야 가치를 만드는 경우가 해당되며 이런 경우 제품 책임자는 최소기능제품에 대해서 다음 번에 만들 증분을 정의한다. 일의 양을 추정하는데 흔히 쓰이는 기술 중 하나는 일의 양, 복잡성, 불확실성 등을 고려해서 스토리 포인트나 단순히 포인트 단위로 상대적인 크기를 추정하는 것이다. 이러한 방법들은 단지 제안일 뿐이다. 스크럼에서는 제품 백로그의 아이템들을 표현하거나 우선순위를 매기는 방법에 대해서 정의하지 않고 추정 기술이나 추정 단위에 대해서도 고려하지 않는다. 스크럼에는 매 스프린트마다 일이 얼마나 끝났는지를 추적하는 기술이 있다. 평균값을 속도라고 하며, 속도는 제품 백로그의 아이템을 추정할 때와 같은 단위를 사용한다. 제품 백로그의 아이템들은 완료를 위해 필요한 일의 양에 따라서 변할 수도 있다. 제품 백로그를 개선하기 위한 워크샵이나 스프린트 계획 회의 때 큰 아이템을 작게 쪼개거나 작은 아이템을 통합한다. 다가오는 스프린트의 제품 백로그 아이템들은 팀이 이 아이템들에 대해서 이해할 수 있을 만큼 충분히 세분화되어서 스프린트 계획 때 팀이 유의미한 예측을 할 수 있어야 한다. 이런 세분화된 크기를 실행가능한 크기라고 한다. 시간과 비용이 많이 드는 주요한 기술 개선사항의 경우는 제품 백로그에 포함되어야 한다. 왜냐하면 이런 개선사항은 사업 투자가 될 수도 있고, 궁극적으로 이 투자를 할지는 사업 지향적인 제품 책임자가 결정할 것이기 때문이다. 참고로 스크럼에서, 팀에게는 스프린트 동안 제품 백로그에 있는 아이템 중 몇 개를 할지를 정할 수 있는 독자적인 권한이 있다. 그러므로 팀원들은 가벼운 기술적 개선사항에 대해서는 만약 그런 개선사항들이 사업을 진행하면서 필요한 정상적인 것들이고 개발자들이 일을 제대로 하기 위해서 필요한 것이라면 독자적으로 맡아서 처리할 수 있다. 물론 그렇긴 하더라도 매 스프린트마다 팀은 대부분의 시간을 내부의 기술적인 업무 보다는 제품 책임자가 정한 목표를 위해서 쓴다. 스크럼에 대한 오해 중 하나는 스크럼을 하면 구체적인 명세서를 쓰지 않아도 된다는 것이다. 실제로 얼만큼의 세부적인 내용들이 필요한지는 팀이 결정하는 것이고, 이런 결정은 백로그 아이템마다 팀의 이해도같은 요인들에 따라 다르다. 백로그에는 무엇이 중요한지를 최소한으로 명시해야 한다. 즉, 모든 세부사항을 기록하기 보다는 해당 아이템을 이해하는데 필수적으로 필요한 것이 무엇인지 명확하게 기록하고 팀, 제품 책임자 그리고 이해관계자들과의 대화를 통해 이를 늘려나가야 한다. 우선순위가 낮은 제품 백로그의 아이템은 한동안 진행되지 않을 것이고 대체로 크기가 크며 상세화가 덜 되어있다. 반면 우선순위가 높은 제품 백로그의 아이템은 빠른 시일 내에 진행될 예정이며 더 상세화가 되어있다. 한편 사용자 스토리란 고객이나 개발자 모두 이해할 수 있도록 고객이 작성하는 것이다. 카드, 대화, 테스트 세 가지를 이용하여 작성한다.

• 카드 : 고객의 요구 사항을 문서화하기보다는 표현하기 위한 것으로 대화의 매개체 역할을 한다. 누가, 왜, 무엇을에 대한 정보가 다 포함되어 있어야 한다.
• 대화 : 카드 내용의 세부사항을 구체화시킴으로서 인수 기준이 정해지고, 이해의 공유를 촉진시킨다.
• 테스트 : 대화에서 논의한 인수 기준을 통해 스토리의 완료 여부를 판단한다. 인수 기준이 만족되었는지 여부를 확인하기 위해 긍정적인 테스트와 부정적인 테스트를 모두 사용해야 한다.

완료 기준

공식적으로 매 스프린트의 산출물은 잠재적으로 출시 가능한 제품 증분이라고 부른다. 첫 번째 스프린트를 시작하기 전에 제품 책임자, 팀, 스크럼 마스터는 제품 백로그의 아이템이 잠재적으로 출시 가능하기 위해서 필요한 모든 것에 대해 검토해야 한다. 제품을 출시하기 위해 필요한 모든 활동은 잠재적으로 출시 가능이라는 말의 정의에 포함되어야 하며 그렇기 때문에 스프린트 동안 끝나야 한다. 안타깝게도 팀이 스크럼을 적용하기 시작하면 종종 매 스프린트마다 잠재적으로 출시 가능한 제품을 전달하고자 하는 목표를 이루지 못한다. 이런 일은 팀이 자동화가 덜 되었거나 충분하게 다기능적이지 않기 때문이다. 시간이 지나면 팀은 더 나아져서 매 스프린트마다 잠재적으로 출시 가능한 제품 증분을 전달할 수 있을 것이다. 그러나 시작을 위해서는 현재의 역량에 대한 기준을 만들 필요가 있다. 이 기준들이 완료 기준으로 기록된다. 스프린트가 시작하기 전에 제품 책임자와 팀은 완료 기준에 대해서 합의를 볼 필요가 있다. 이 활동은 잠재적으로 출시 가능한 제품 증분을 만들기 위한 활동의 일부이다. 팀은 이 완료기준에 맞추어 스프린트의 업무를 계획한다. 좋은 제품 책임자는 항상 완료기준이 가능하면 잠재적으로 출시할 수 있을 수준에 가깝게 잡혀서 개발이 투명해지고 지연되는 경우가 줄어들며 리스크가 감소하기를 원한다. 만약 완료기준이 잠재적으로 출시 가능한 정도가 아니라면 리스크와 지연이 발생하게 될 릴리즈를 하게 될 때까지 계속 작업이 지연될 것이다. 이런 지연된 작업을 때론 완료되지 않은 작업이라고 부른다. 스크럼 팀은 끊임없는 개선을 해야 하고 이런 개선 사항들이 완료 기준을 늘리는데 반영된다.

스프린트 계획 회의

스프린트 계획 회의는 매 스프린트를 시작할 때 진행되며, 2개의 회의로 나뉘어 진행되는데 첫 번째 회의를 스프린트 계획 파트1이라고 한다. 스프린트 계획 파트1에서는 제품 책임자와 팀이 제품 백로그 중 제품 책임자가 이번 스프린트에서 진행되길 원하는 우선순위가 높은 아이템들을 검토한다. 대체로 이 아이템들은 지난 스프린트에서 제품 백로그 개선을 하는 동안 잘 분석되었기 때문에 이 회의에서는 간단히 질문에 대해서 다시 한 번 명확히 하는 작업만 진행된다. 제품 책임자와 팀은 제품 백로그의 우선순위가 높은 아이템들의 목표와 내용에 대해서 정의하며, 이런 우선순위를 통해 팀원들은 제품 책임자의 생각을 알게 된다. 파트1은 제품 책임자가 무엇을 원하고 왜 그것이 필요한지에 초점이 맞춰져 있다. 회의 후반부에 제품 책임자는 자리를 떠나도 되지만 2단계 회의에는 참여 할 수 있어야 한다. 파트1에서 팀과 제품 책임자는 스프린트 목표를 정한다. 이것은 스프린트의 목표를 담은 요약된 문장이며 여기서의 목표는 이상적으로는 짜임새가 있는 주제를 담고 있어야 한다. 팀은 또한 실제로 어떤 결과물을 만들어 낼 수 있을지를 고려해서 스프린트 목표의 범위를 유연하게 정할 수 있다. 왜냐하면 팀은 스프린트의 시간적 제약 때문에 몇몇 아이템을 제외해야 함에도 불구하고 해당 스프린트의 목표에 맞는 실질적이고 완성된 무언가를 내놓아야 하기 때문이다. 그렇다면 스프린트에 진행되는 각 아이템의 규모는 전체 스프린트에 비해서 현저히 작게 쪼개져야 한다. 일반적인 지침으로는 각각의 아이템들은 스프린트 기간의 1/4 이내에 완수될 수 있을 정도의 크기로 추정하는 것이 좋다.

스프린트 계획 파트2에서는 팀이 하기로 결정한 아이템을 어떻게 수행할 지에 대해서 초점을 맞춘다. 팀은 제품 백로그의 우선순위가 높은 것부터 순차적으로 해당 스프린트가 끝날 때까지 할 수 있는 아이템의 수를 예측한다. 이것이 스크럼에서 핵심이다. 스크럼에서는 완수해야 할 작업을 제품 책임자가 팀에 할당하는 것이 아니라, 팀이 스스로 할 수 있는 작업의 양을 결정하는 것을 중요시한다. 팀이 나름대로 분석과 계획을 한 것을 토대로 작업의 양이 예측되기 때문에 그 결과를 더욱 신뢰할 수 있다. 제품 책임자는 팀이 얼마나 많은 양의 작업을 할지 결정하지는 않지만, 팀이 하기로 한 아이템들이 제품 백로그에서 우선순위가 높은 것부터, 즉 가장 중요하다고 생각하는 것부터 뽑아져 나왔다는 것을 알 수 있다. 팀은 우선순위가 아래에 있는 제품에 대해서도 영향력을 행사할 수 있다. 이는 보통 팀과 제품 책임자 둘 다 현재 우선순위가 아래에 있는 아이템이 더 위에 있는 것이 적절하다고 생각하는 경우이다. 스프린트 계획 회의는 작업을 완수하기 위한 진지한 예측 작업이고 팀은 여기에 신중하게 임한다. 이런 이유로 때때로 회의가 몇 시간씩 진행되기도 하는데, 스프린트 계획 회의는 2주 단위의 스프린트를 기준으로 4시간을 넘지 않도록 해야 한다. 파트1, 파트2 모두 같은 시간제한을 적용하여 2주 단위의 스프린트를 기준으로 각 파트가 2시간을 넘지 않도록 해야 한다. 스크럼은 스프린트 계획 파트2를 정확히 어떻게 해야 하는지에 대해서 정의하지는 않는다. 어떤 팀은 스프린트에 진행 할 목표치를 정하는데 이전 스프린트의 속도를 사용하기도 하고, 어떤 팀은 그들의 수용능력을 처음으로 계산해보기 위해서 더 세분화된 방법을 사용하기도 한다. 수용능력을 활용하는 방식으로 목표치를 정하고자 한다면, 팀은 스프린트 파트2를 진행하면서 각 팀원들이 스프린트와 관련된 업무를 수행하는데 얼만큼의 시간을 쓸지를 추정한다. 스프린트와 관련된 업무를 수행하는데 쓸 시간이라는 것은 회의를 참석하거나 메일을 보내거나 휴식하는 시간은 제외한 개념이다. 대부분의 사람들의 경우는 하루에 4~6시간 정도를 여기에 쓸 수 있으며 이것을 이번 스프린트에 대한 수용능력으로 생각할 수 있다. 수용능력이 정해지고 나면 해당 기간 동안 제품 백로그에 있는 아이템 중 몇 개를 할지, 또 어떻게 이것들을 완수할 것인지를 생각해 보아야 한다. 이 과정은 보통 화이트보드로 디자인에 대한 토론을 하면서 시작된다. 팀원들이 전반적인 디자인에 대해서 이해하고 나면 제품 백로그에 있는 아이템들을 작업으로 세분화한다. 제품 백로그에 있는 아이템을 가져오기 전에 팀원들은 지난번 스프린트의 회고 때 나온 개선 목표를 위한 작업을 만드는데 집중할 수도 있다. 그러고 나면 팀은 제품 백로그에서 제품 책임자가 가장 우선순위를 높게 설정해놓은 아이템을 골라서 ‘충분’할 때까지 세분화 시키는 작업을 한다. 각 아이템에 대해서 세분화된 작업들을 리스트에 포함시킬 수도 있고 제품 백로그의 아이템을 완료하는데 걸리는 시간이 2시간 정도로 규모가 작다면 그대로 포함시킬 수도 있다.

스프린트 백로그 작성

스프린트 동안 해야 하는 일에 대한 이리스트를 스프린트 백로그라고 한다. 스프린트 계획 회의가 끝날 쯤에, 팀은 스프린트가 끝날 때 어떤 결과물을 내놓을 것인지에 대한 현실적인 목표를 정한다. 일반적으로 이것을 스프린트 약속이라고 하는데 이는 팀이 목표를 달성하기 위해서 최선을 다할 것을 약속하는 것을 의미한다. 안타깝게도 이 단어는 때론 열심히 한다는 의미가 아니라 피로 쓴 맹세라는 오해를 받는다. 이런 오해가 생기지 않도록 스프린트의 목표를 제품 책임자에게 전달할 때는 예측이라는 단어로 표현한다. 스크럼은 가령 테스트만 하는 테스터와 같이 직책에 맞는 일만 하기 보다는 여러 기술을 가지기를 권장한다. 즉, 팀원들은 일이 있는 곳으로 가서 할 수 있는한 도와준다. 만약 테스트 업무가 많다면 모든 팀원들이 도와줄 것이다. 이 말이 모든 사람이 제너럴리스트가 되어야 한다는 의미는 아니다. 물론 어떤 사람들은 특별히 테스트나 다른 기술이 있겠지만 팀원들은 함께 일하고 새로운 기술을 서로 배워야한다. 결과적으로 사람들은 스프린트 계획에서 업무를 만들거나 추정할 때 최선을 다 할 수 있는 모든 일에 자원할 필요가 없으며 그런 것이 적절하지도 않다. 그보다는 새로운 업무를 고를 때는 한 번에 하나의 업무에만 자원하고, 업무를 고를 때는 학습이라는 목적을 고려하는 것이 더 좋다. 이런 이유로 스프린트 계획 단계에서 업무를 할당하는 것이 아니라, 스프린트가 진행되는 동안 필요에 따라 업무를 할당한다. 존은 특정한 업무를 할 때 앞서 말한 것들은 거의 하지 못한다. 왜냐하면 다른 사람을 가르치는 것은 너무 시간이 오래 걸리거나 불가능하기 때문이다. 아마도 존은 팀에서 그림을 그리는 예술적인 기술을 가진 유일한 사람일 것이다. 다른 팀원들은 만약 직장에서의 수명이 이 업무에 달려있다면 막대기 같은 사람을 그리지는 못할 것이다. 만약 이런 일이 흔히 일어난다면 뭔가 잘못된 것이다. 이런 일이 일어나는 경우에는, 계획되어있는 존이 완료해야만 하는 그림을 그리는 작업 전체가 짧은 스프린트 동안 가능한지에 대해서 생각해봐야 한다. 많은 팀들은 벽 크기의 업무 보드 형식의 스프린트 백로그를 만드는데 이는 보통 스크럼 보드라고 불린다. 이 보드에 있는 포스트잇에 적힌 작업들은 스프린트 기간 동안 할 일, 작업 중, 완료라고 적힌 열 사이를 이동한다.

스크럼의 기본적인 하나의 특징은 팀이 스프린트의 목표를 한 번 설정하면, 모든 추가사항이나 변경사항들은 다음 스프린트까지 미뤄져야 한다는 것이다. 이 말은 만일 제품 책임자가 스프린트 중에 팀이 했으면 하는 새로운 아이템을 결정해도 다음 스프린트가 시작할 때 까지는 바꿀 수 없다는 뜻이다. 만약 외부 상황에 의해서 우선순위가 많이 바뀌거나 이 일을 계속 했을 경우 팀이 시간을 낭비하는 꼴이 된다면 제품 책임자나 팀은 스프린트를 중단할 수 있다. 팀이 스프린트를 중단하면 새로운 스프린트 계획 회의를 통해서 새로운 스프린트를 시작한다. 보통 이런 일이 일어나는 것을 막는 것이 좋다. 왜냐하면 이런 경우 제품 책임자와 팀이 사기가 하락해서 극단적인 결정에 의지하도록 하기 때문이다. 스프린트 동안 목표가 바뀌지 않도록 팀을 보호하는 것은 강력하고 긍정적인 영향을 준다. 첫 번째로, 팀은 목표가 바뀌지 않을 것임을 확실하게 알고 일을 하기 때문에 확실하게 완료하는데 초점을 더 둘 수 있다. 두 번째로 제품 책임자는 스프린트에 자신이 제품 백로그에 우선순위를 매기고 팀에게 준 아이템들에 대해서 제대로 생각해 보게 된다. 이런 스크럼의 규칙들을 따르면서 제품 책임자는 두 가지를 얻는다. 첫 번째로 제품 책임자는 팀이 실질적이고 분명한 일들을 끝내기 위해서 최선을 다 한다는 것을 알게 된 것에 확신할 수 있다. 시간이 지나면서 팀은 실질적인 예측으로 일을 고르고 끝내는데 꽤 능숙해 질 수 있다. 두 번째로 제품 책임자는 다음 스프린트가 시작하기 전에는 어떤 변경이든 제품 백로그에 반영할 수 있다. 이런 측면에서 일을 추가하거나, 빼거나, 수정하거나, 우선순위를 다시 정하는 것이 모두 가능하고 수용된다. 제품 책임자는 현재 스프린트가 진행되는 동안 개발 중인 아이템에 대해서는 변경을 할 수 없지만 원하는 변경사항을 반영하기 위해서 한 스프린트 기간 이하만 기다리면 된다. 방향의 변화, 요구사항의 변화, 평범한 마음가짐의 변화 같은 변화를 둘러싼 오명은 사라졌고 이런 이유들로 제품 책임자들은 보통 스크럼에 대해서 누구 못지않게 열정적이다.

데일리 스크럼 미팅

스프린트가 시작되면 팀은 하나의 스크럼의 주요 활동을 하게 되는데 이것이 데일리 스크럼이다. 데일리 스크럼은 매일 정해진 시간에 15분 이하로 하는 짧은 회의이다. 모든 팀원은 여기에 참석해야 한다. 간단하게 덧붙이자면 이 회의는 모두가 서서 진행하기를 권장한다. 이 회의에서 팀원들은 각자가 한 업무에 대해서 서로 맞추고 장애 요소에 대해서 말한다. 데일리 스크럼에서 각 팀원들은 한 명씩 세 가지를 다른 팀원들에게 말한다. 1) 지난 회의 이후로 무엇을 완료했는가? 2) 다음 회의 전에 무엇을 완료할 것인가? 3) 이것을 하는데 장애 요소는 무엇인가? 참고로 데일리 스크럼은 관리자에게 상태를 보고하는 회의가 아니다. 이 회의는 자율적인 조직이 무엇이 진행되고 있는지에 대해서 서로 공유하고 협력하는 시간이다. 누군가가 장애 요소에 대해서 말하면 스크럼 마스터는 팀원들이 그것을 해결하도록 도와주는 역할을 한다. 데일리 스크럼 동안은 깊이가 얕거나 없는 토론만 하며 그 주제는 세 가지 질문에 대한 답과 관련된 것이다. 만약 논의가 필요하다면 데일리 스크럼이 끝난 후 바로 이어서 한 개 이상의 유사한 회의를 하며, 스크럼의 누구도 꼭 참여할 필요는 없다. 이런 연이은 회의를 하는 경우는 흔히 있으며 여기서 일부 또는 전체 팀원들은 데일리 스크럼 때 들은 정보에 대한 조정을 한다. 다른 말로 하면 이것은 또 다른 검토과 조정의 반복이다. 팀이 스크럼을 처음 한다면 일반적으로 관리자나 또는 권한이 있다고 여겨지는 사람들이 데일리 스크럼에 들어오지 않기를 권장한다. 이런 위험한 행동을 통해 팀은 감시당하고 있다고 생각하게 되어서 매일 비현실적인 기대치에 대한 주요 진척도를 보고해야 한다는 압박을 느끼게 된다. 또한 팀은 문제점을 보고하는 것에 대해서 억제를 당한다고 느끼며 팀이 스스로 잘 관리하지 못하고 세부사항까지 관리를 받게 된다. 이해관계자들은 팀의 회의에 따라가기 보다는 팀의 진척을 느리게 하는 장애 요소들을 제거해 주는 것이 더 유익할 것이다.

진척도 추적

스크럼에서 팀은 스스로 관리한다. 팀은 이를 성공적으로 하기 위해서 어떻게 스스로 관리를 하는지를 알아야 한다. 매일 팀원들은 스프린트 백로그에 있는 현재의 작업을 완료하기 위해서 작업이 얼마나 남았는지를 새로 추정한다. 또한 누군가는 종종 팀 전체로서 남은 작업을 더해서 스프린트 번다운 차트에 표시한다. 이 차트는 매일 팀이 완료할 작업이 얼마나 남았는지에 대한 새 추정치를 보여준다. 이상적으로 이 차트는 스프린트의 마지막 날에 남은 작업이 0이 되는 방향의 감소 그래프이다. 그러므로 이것은 소멸 차트라고 불린다. 제품 개발의 현실에서는 이 그래프가 좋게 나타나는 경우도 있지만 보통은 그렇지 않다. 중요한 것은 이 차트는 팀이 목표를 향해서 어느 정도 나아갔는지를 보여준다는 것이다. 즉, 팀이 과거에 얼마의 시간을 썼는지가 아니라 팀을 목표에서 떼어놓는 일들이 앞으로 얼마나 남았는가를 보여준다. 만약 번다운 차트의 그래프가 스프린트가 끝날 때 완료가 될 방향으로 가고 있지 않다면 팀은 계속 지속 가능한 속도를 유지하면서 일의 범위를 줄인다던가 또는 더 효율적으로 일할 방향을 찾아서 조정해야 한다. 스프레드시트를 이용해서 스프린트 번다운 차트를 만들고 보여줄 수 있지만 많은 팀들은 업무 공간의 벽에 종이를 붙이고 펜으로 적는 것이 더 효율적이라는 것을 알고 있다. 이런 기술이 많이 필요하지 않은 고감도의 해결책이 보통 컴퓨터 차트보다 빠르고 간단하며 시각적으로 더 좋다.

제품 백로그 개선

많이 알려지진 않았지만 가치 있는 스크럼의 가이드라인 중 하나는 매 스프린트의 일정 부분은 팀 전체가 미래의 스프린트들을 위해서 제품 백로그를 개선하는데 써야 한다는 것이다. 여기에는 세부적인 요구사항 분석, 큰 아이템을 작은 아이템으로 쪼개는 것, 새로운 아이템에 대한 추정을 하는 것, 현재의 아이템들을 다시 추정하는 것을 포함된다. 스크럼에서는 어떻게 일을 해야 하는지에 대해서는 언급하지 않지만 자주 사용되는 기법 중 하나로는 스프린트의 중반이나 끝에 집중적인 워크샵을 가져서 팀과 제품 책임자 그리고 다른 이해관계자들이 방해 받지 않고 이 개선업무에 집중할 수 있도록 하는 것이 있다. 이런 개선활동은 현재 스프린트의 아이템을 위한 것이 아니다. 이 활동은 대개 한 두 스프린트 다음이 될 미래의 아이템을 위한 것이다. 이런 활동을 통해서 스프린트 계획은 상대적으로 간단해진다. 왜냐하면 제품 책임자와 스크럼 팀은 명확하고 분석이 잘 되었으며 신중하게 추정된 아이템들에 대한 계획을 하기 때문이다. 스프린트 계획에서 중요한 질문이나 발견, 혼란이 있거나 완성이 덜 된 느낌이 든다는 것은 이 개선 워크샵이 끝나지 않았거나 잘 되지 않았다는 신호이다. 이렇게 되면 계획 업무가 스프린트 자체로 번져나가게 되며, 이는 일반적으로 바람직하지 않다.

스프린트 리뷰

스프린트가 끝나면 스프린트 리뷰를 하며 여기서 사람들은 스프린트를 검토한다. 이 회의의 참가자는 제품 책임자, 팀원, 스크럼마스터 그리고 추가적으로 고객, 사용자, 이해관계자, 전문가, 경영진 그리고 관심이 있는 누구나가 될 수 있다. 2주 길이의 스프린트는 최대 2시간 이내에 끝낸다. 참가하는 누구나 자유롭게 질문할 수 있고 의견을 줄 수 있다. 리뷰는 종종 데모라는 잘못된 꼬리표를 달기도 하지만 이는 이 회의의 진정한 의도를 모르는 것이다. 스크럼의 중요한 개념은 검토와 조정이다. 반복되는 주기 안에서 무엇이 진행되고 있는지 보고 배우며 피드백에 기반해서 발전시켜 나간다. 스프린트 리뷰는 제품을 위해서 검토하고 조정하는 활동이다. 이때 제품 책임자는 제품과 팀에 대해서 상황이 어떤지 배운. 또한 이 때 팀도 제품 책임자와 시장에 대해서 어떻게 되어가고 있는지 배운다. 따라서 리뷰에서 중요한 요소는 팀과 제품 책임자간의 상황에 대해서 배우고, 조언을 구하는 등의 깊이 있는 대화이다. 리뷰는 분명 팀이 스프린트 동안 만든 실제로 동작하는 소프트웨어를 사용하는 것을 포함하지만 리뷰의 초점이 대화를 하는 것 보다는 단지 제품을 보는 것에만 집중된다면 균형이 맞지 않다. 스프린트 리뷰에서 “살아있는 소프트웨어”라는 것은 팀이 제시하는 프레젠테이션이 아니며 또한 슬라이드웨어를 쓰지 않는다. 리뷰를 하는 방에는 사람들이 동작하는 소프트웨어를 검토하고 사용해 볼 수 있도록 한 대 이상의 컴퓨터를 둔다. 리뷰에서는 팀이 수동적으로 데모를 하는 것 보다는 실제 사용자와 제품 책임자가 소프트웨어를 전달받아서 소통할 수 있는 활동적인 활동을 더 권장한다. 스프린트 리뷰를 준비하는데 30분을 넘지 않도록 해야 하며 그렇지 않다면 무언가 잘못된 것이다.

스프린트 회고

스프린트 리뷰는 제품에 대해서 검토하고 조정하는 것을 포함한다. 리뷰 후에 연이어 하는 스프린트 회고는 프로세스와 환경에 대해서 검토하고 조정하는 것을 포함한다. 이것은 팀이 어떤 것이 효과가 있고 어떤 것이 효과가 없는지 토론하고 무엇을 바꿀지에 대해서 합의하기 위한 자리이다. 때로 스크럼마스터는 회고에서 퍼실리테이터 역할을 할 수 있다. 하지만 회고를 위해서 중립적인 외부 퍼실리테이터를 찾는 것이 더 나을 수도 있다. 스크럼마스터가 각자의 회고를 퍼실리테이팅 해주는 것은 좋은 접근방식이며 이것을 통해서 팀원들은 서로 소통할 수 있다. 많은 팀들이 회고를 단지 문제에만 집중해서 진행하는데, 이것은 잘못되었다. 이런 방식은 사람들이 회고를 다소 우울하고 부정적인 활동이라고 생각하게 만든다. 이런 방법 대신 매 회고가 긍정적인 부분 또는 강점에 또한 집중할 수 있도록 해야 한다. Appreciative Inquiry 사이트에 있는 여러 책들을 통해서 더 자세한 팁들을 얻을 수 있다. 항상 같은 분석 기법을 쓰는 회고는 지루해질 수 있다. 그러므로 시간이 지나면서 다양한 기법들을 소개해야 한다.

다음 스프린트 시작

스프린트 리뷰 후 제품 책임자는 새로운 시각으로 새로운 아이템을 추가하고 더 이상 쓸모 없는 부분은 제거하며 현재 있는 것들을 수정하고 제품 백로그를 업데이트한다. 스프린트 사이에는 휴식 시간이 없다. 팀들은 보통 어느 날 오후에 스프린트 회고를 하고 바로 다음날 아침에 스프린트 계획을 한다. 애자일 개발의 한 가지 원칙은 지속 가능한 속도이며 탐은 합리적인 수준으로 적절히 일해야 이 주기를 계속 이어나갈 수 있다. 생산성은 팀의 실천방식이 발전하고 팀의 생산성에 방해가 되는 요소들을 제거해 가며 계속해서 오르는 것이지, 잔업이나 품질에 대해서 타협하며 오르는 것이 아니다. 스프린트는 제품 책임자가 제품을 출시할 준비가 되었다고 판단할 때까지 계속된다. 완벽한 스크럼에서 제품은 매 스프린트가 끝날 때 마다 잠재적으로 출시가 가능한 상태이다. 이는 테스트나 문서화 같은 마무리 작업이 필요하지 않다는 뜻이다. 이 말이 함축하고 있는 것은 매 스프린트마다 모든 것이 완벽하게 끝나야 한다는 것이다. 즉, 리뷰가 끝난 후 즉시 실제로 출시 가능하거나 배포할 수 있어야 한다. 그러나 많은 조직들은 개발 방법, 툴, 인프라가 약하고 이런 완벽한 스크럼은 할 수 없으며 그렇기 때문에 남은 일을 처리하기 위해서 릴리즈 스프린트가 필요하다. 릴리즈 스프린트가 필요할 때, 이것은 필요악이며 조직은 실천방식의 개선을 통해서 더 이상 릴리즈 스프린트가 필요 없도록 해야 한다.

릴리즈 관리

새로운 제품의 경우나 현재의 제품에 단지 스크럼만 적용하는 경우, 첫 번째 스프린트 전에 제품 백로그 개선을 시작할 필요가 있으며, 여기서 제품 책임자와 팀은 적절한 스크럼 제품 백로그를 만든다. 이 작업은 며칠이 걸릴 수도 있고 한 주가 걸릴 수도 있으며 워크샵을 하게 될 수도 있다. 이 워크샵은 때론 초기 제품 백로그 제작 또는 릴리즈 계획라고 불린다. 그리고 세부적인 요구사항 분석이나 첫 번째 릴리즈 때 확인할 모든 아이템에 대한 추정도 필요하다. 놀랍게도 스크럼에서 확실히 정해진 제품 백로그가 있는 제품의 경우는 다음 릴리즈를 위한 어떤 특별하거나 큰 릴리즈 계획이 필요 없다. 냐하면 제품 책임자와 팀은 매 스프린트마다 5 ~ 10% 정도의 시간을 제품 백로그 개선에 써야 하고 계속해서 추후를 위해 준비해야 하기 때문이다. 이런 지속적인 제품 개발 방식에서는 기존의 순차적인 수명 주기를 따르는 개발에서 볼 수 있었던 준비-실행-종료 단계의 극단적으로 끊어지는 단계에 대한 준비가 필요 없다. 최초의 제품 백로그 개선 워크샵과 매 스프린트의 백로그 개선을 하는 동안, 팀과 제품 책임자는 릴리즈 계획도 세우고 학습한 것을 바탕으로 추정치와 우선순위도 개선도 할 것이다. 어떤 릴리즈는 데이터가 중심이 된다. 스크럼은 매 스프린트마다 잠재적으로 출시 가능한 코드를 만드는 것을 강조하기 때문에 제품 책임자는 중간 릴리즈를 하기로 할 수도 있고, 고객이 완료된 작업에 대한 수혜를 더 빨리 받을 수 있게 할 수도 있다. 사람들은 다가오는 모든 일들을 알 수 없기 때문에, 계획을 세우고 개선하는 것을 통해서 릴리즈에 대한 큰 방향성을 제시하고 어떻게 결정들의 균형을 맞출지를 명확히 하는 것이 핵심이다. 대부분의 제품 책임자들은 한 번의 릴리즈만 하는 방식을 선택한다. 계약이 있는 개발과 같이 고정된 가격, 고정된 날짜, 고정된 제품과 같은 투입이 있는 경우는 예상치 못한 것이나 변화에 대응할 수 있도록 여유를 둬야 한다. 이런 점에서 스크럼은 다른 접근방식과 다르지 않다.

역할

제품 책임자

제품 책임자는 투자 수익률을 최대화 해야 할 책임이 있다. 그러기 위해서 제품 책임자는 기능을 식별하고 이것을 반영해서 리스트의 우선순위를 짜고, 다음 스프린트에 어떤 것이 리스트의 가장 위에 와야 하는지 결정하고, 지속적으로 리스트의 우선순위를 다시 짜고 개선한다. 제품이 상업적인 경우, 제품 책임자는 제품의 손익에 대한 책임이 있다. 내부적으로 활용되는 제품의 경우는 제품 책임자에게 제품이 상업적일 때와 같은 투자 수익률에 대한 책임은 없다. 그러나 각 스프린트마다 가장 높은 가치를 주는 아이템을 선택해야 한다는 면에서는 투자 수익률을 최대화 하는 책임이 여전히 있다. 실제로는 ‘가치’라는 단어는 불분명하다. 그리고 우선순위를 매기는 일은 주요 고객을 만족시키고자 하고, 전략적인 목적에 맞추며, 리스크에 대처하고, 개선하기 위한 활동 등의 영향을 받을 수도 있다. 어떤 경우는 제품 책임자와 고객이 같은 사람이다. 이런 경우는 내부적으로 활용되는 제품의 경우 흔히 나타난다. 다른 경우로는 고객이 다양한 니즈를 가진 수 백만의 사람일 수도 있다. 이런 경우 제품 책임자의 역할은 많은 제품 조직들에서의 제품 관리자나 제품 마케팅 관리자의 역할과 비슷하다. 하지만, 제품 책임자는 어쨌던 기존의 제품 관리자와는 다르다. 왜냐하면 제품 책임자는 프로젝트 관리자에게 개발에 대한 결정권을 위임하는 것이 아니라 적극적으로 자주 팀과 소통하고, 모든 이해관계자들과 함께 일하고 매 스프린트의 결과를 검토하며 우선순위를 정하기 때문이다. 중요한 것은, 스크럼에서 최종 권한을 가진 제품 책임자는 오직 한 사람이며, 제품 책임자는 업무의 가치에 대한 책임이 있다는 것이다. 제품 책임자가 혼자 일 할 필요가 없더라도 한 사람이어야 한다.

스크럼 마스터

스크럼마스터는 제품 그룹이 사업적인 가치를 만들기 위해서 스크럼을 배우고 적용하는 것을 돕는다. 스크럼마스터는 팀과 제품 책임자 그리고 조직이 성공할 수 있기 위해서 가능하다면 어떤 것이든 돕는다. 스크럼마스터는 팀원들의 관리자가 아니며 프로젝트 관리자도 아니고 팀 리더도 아니며 팀 대표자도 아니다. 대신 스크럼마스터는 팀에게 도움을 준다. 즉, 스크럼마스터는 장애물을 제거하고 팀을 외부의 간섭으로부터 보호하며 팀이 새로운 개발 방식에 적응할 수 있도록 돕는다. 스크럼마스터는 제품 책임자와 팀 그리고 나머지 조직원들이 스크럼을 능숙하게 사용할 수 있도록 가르치고 지도하고 설명해준다. 스크럼마스터는 코치이자 선생님이다. 스크럼마스터는 제품 책임자나 관리를 하는 사람들을 포함한 모두가 스크럼의 원칙과 실천 방법들을 반드시 이해하여 조직이 애자일 개발을 성공적으로 마치기 위해서 필요한 어려운 변화들을 극복할 수 있게 돕는다. 스크럼은 팀이나 제품 책임자의 효율에 대한 장애물과 위협이 눈에 보이도록 만든다. 그러므로 이런 문제들을 해결할 수 있도록 활발하게 일할 팀에 소속된 스크럼마스터가 있는 것이 중요하다. 그렇지 않다면 팀이나 제품 책임자는 성공하기 어렵다는 것을 깨닫게 될 것이다. 비록 작은 팀의 경우는 팀원이 기존에 하던 일을 줄이고 이 역할을 할 수도 있지만, 그래도 모든 시간 동안 이 일에만 전념하는 스크럼마스터가 있어야 한다. 훌륭한 스크럼마스터는 공학, 디자인, 테스트, 제품 관리, 프로젝트 관리, 품질 관리 등 어떤 배경이나 지식 분야에서도 나올 수 있다. 스크럼마스터와 제품 책임자는 초점이 매우 다르며 병행할 경우 혼란이나 충돌이 생기기 때문에 같은 사람이 맡을 수 없다. 두 역할을 병행하면 발생하게 되는 흔한 문제 중 하나는 세부사항까지 관리하는 제품 책임자이다. 이는 스크럼이 요구하는 자기조직 팀과 맞지 않다. 기존의 관리자와는 다르게 스크럼마스터는 사람들에게 무엇을 해야 하는지 또는 할당된 일을 말해주지 않는다. 스크럼마스터는 프로세스를 따를 수 있게 돕고 팀이 스스로 조직하고 관리하도록 도와준다. 만약 스크럼 마스터가 이미 팀을 관리하는 위치에 있다면, 그들은 스크럼을 통해 팀이 성공하기 위해서 마음가짐이나 소통하는 방식을 크게 바꿀 필요가 있다.

개발팀

개발팀이라고도 불리는 팀은 제품 책임자가 지시하는 이를 테면 어플리케이션이나 웹사이트 같은 제품을 만든다. 스크럼에서 팀은 다기능적인데 이는 팀이 잠재적으로 출시 가능한 제품을 매 스프린트마다 만들기 위해서 필요한 모든 전문지식을 가지고 있어야 한다는 뜻이다. 그리고 팀은 높은 수준의 자율성과 책임을 가진 자기조직이어야 한다. 팀은 제품 책임자가 제안한 것들 중 한 스프린트 동안 몇 개의 아이템을 완성할 지를 결정해야 하며 그 목표를 달성하기 위해서 어떤 방법이 최선인지도 결정해야 한다. 각 팀원들은 그저 팀원이다. 스크럼을 적용한 그룹에서는 고정된 전문가라는 타이틀은 없다. 그 말은 사업 분석가, DBA, 아키텍트, 팀의 리더, 인터랙션/UX 디자이너, 프로그래머 같은 것들이 없다는 뜻이다. 매 스프린트가 진행되는 동안 팀이 스스로 정한 목표를 달성하기 위해서 팀원들은 어떤 방식으로든 함께 일한다. 오직 팀원만 있기 때문에 팀은 다기능적일 뿐만 아니라 다중학습이라는 측면도 보여준다. 모든 사람들은 확실히 특별한 장점을 가지고 있지만 계속해서 다른 전문 지식을 배운다. 모든 사람들은 1차, 2차 그리고 심지어 3차 기술을 가진다. 이는 일이 있는 곳은 어디든 간다는 것을 뜻한다. 즉, 개개인들은 아이템이 완료되도록 돕기 위해서 다소 덜 친숙한 분야의 일도 맡는다. 스크럼에서의 팀은 7명에서 2명 안팎이다. 그리고 소프트웨어 제품의 경우 팀에는 분석, 개발, 테스트, 인터페이스 디자인, 데이터베이스 디자인, 아키텍처, 문서작성 등의 기술을 가진 사람들이 있어야 할 것이다. 팀은 제품을 개발하고 제품 책임자에게 어떻게 제품을 훌륭하게 만들 것인지에 대한 아이디어를 준다. 스크럼에서의 팀은 모든 팀원들이 스프린트 동안 하나의 제품을 위해서 100% 몰두해서 일할 수 있을 때 가장 생산적이고 효율적이다. 즉, 팀은 주의가 분산되거나 흐름이 바뀌면서 낭비되는 것을 막기 위해서 여러 제품이나 프로젝트에 걸쳐져서 동시에 여러 작업을 하게 되는 것을 피해야 한다. 팀이 안정적인 것은 높은 생산성과 관련이 있으므로 팀원이 바뀌는 것을 피해야 한다. 많은 사람들로 구성된 제품 그룹은 여러 팀들로 구성되는데 각 팀들은 그들의 일에 대해서 긴밀하게 조율하며 제품의 서로 다른 기능들에 집중한다. 하나의 팀이 고객 중심의 기능들을 완성하기 위한 모든 일(계획, 분석, 프로그래밍, 테스트)을 종종 하므로 이런 팀은 또한 기능팀이라고도 불린다. 팀은 주의가 분산되거나 흐름이 바뀌면서 낭비되는 것을 막기 위해, 동시에 여러 프로젝트나 작업을 진행하는 것을 피해야 한다. 팀이 안정적일수록 팀의 생산성이 높아지기 때문에 팀원이 중간에 바뀌는 것은 피해야 한다.

기타

위 세 가지 역할 뿐만 아니라 관리자, 고객, 최종 사용자 같은 제품의 성공에 기여하는 다른 이해관계자들도 있다. 직무 관리자나 공학 관리자와 같은 이해관계자들은 새로운 역할을 찾을 수도 있다. 하지만 그 역할이 여전히 가치가 있을지라도 스크럼을 적용할 때는 변해야 한다. 예를 들면, 1) 그들은 스크럼의 규칙들과 참뜻을 존중함으로써 팀을 지원한다 2) 그들은 팀과 제품 책임자가 찾은 장애물을 제거하는 것을 돕는다 3) 그들은 그들의 전문 지식과 경험을 쓸 수 있도록 한다. 스크럼에서 이런 사람들은 이전에 업무를 할당하고 현황 보고서를 받고 다른 형태의 세세한 관리를 하는 유모 역할을 하며 보냈던 시간들을 팀의 구루나 하인의 역할(멘토링, 코칭, 장애물 제거를 돕기, 문제를 해결하는 것을 도와주기, 창의적인 조언 제공, 팀원들의 기술 개발 지도)을 할 시간으로 바꿔야 한다. 이 변화에서 관리자들은 그들의 관리 스타일을 바꿀 필요가 있다. 예를 들면 단순히 해결책을 정해서 팀에게 할당하는 방식이 아니라 팀이 문제를 해결법을 찾을 수 있도록 소크라테스식 문답법을 사용한다.

추구 가치

• 용기: 팀원 간 갈등과 도전을 위한 용기를 가져야 한다. 해당 기능이 이해가 안 되거나 문제가 있는 경우 일을 더 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득시킬 용기가 있어야 한다.
• 집중(전념): 한 번에 하나씩 일을 마무리하고, 업무에 집중할 수 있도록 불필요한 회의 참석은 지양해야 하며, 주기적인 반복 작업은 제거하거나 자동화해야 한다.
• 헌신/책임: 팀의 목표 달성을 위해 개개인이 공약한 목표를 달성하도록 팀에 헌신하고, 필요한 모든 권한을 부여해야 한다. 개인보다 팀과 공동 목표 달성이 우선이고, 가치 있는 소프트웨어를 개발할 수 있도록 최대한의 지원과 권한이 필요하다.
• 존중: 개개인별로 장단점이 있을 것이고, 그 사람이 그렇게 할 수밖에 없는 이유가 있을 것이다. 팀원 서로를 존중할 필요가 있다.
• 투명성/개방성(정직): 프로젝트에 대한 모든 내용을 투명하게 공개해야 한다. 제품백로그, 스크럼회의, 스프린트 리뷰 등을 통해 공유되어야 하며, 자신에게 불리해도 숨기지 않고 도움을 청해야 한다.

주요 용어

제품 백로그

제품 완성에 필요한 특성, 기능, 개선점 등 제품의 모든 요구사항(사용자 스토리)을 우선순위에 따라 나열한 목록이다. 사업 환경이나 변화에 따라 지속적으로 업데이트되며 좋은 제품 백로그는 DEEP로 표현할 수 있다.

• detailed appropriately: 최우선 순위의 아이템은 낮은 우선순위의 아이템보다 먼저 진행되기 때문에 더 상세하고 세밀하게 기술되어있어야 한다.
• Estimated: 현재 릴리즈의 각 아이템들은 추정이 필요하며 매 스프린트마다 팀원들이 무언가를 배우고 새로운 정보가 생기므로 다시 추정되어야 한다. 팀은 제품 책임자에게 제품 백로그의 각 아이템에 해당하는 일의 양과 기술적인 위험성에 대한 추정치를 제공해야 한다. 제품의 책임자와 다른 사업적인 이해 관계자들은 들은 제품 요구사항의 가치에 대한 정보를 다양한 이해관계자들에게 전달해야한다. 이 정보에는 수익이나 비용 절감, 사업적인 리스크, 중요성이 포함될 수 있다.
• Emergent: 학습한 내용이나 변동되는 것들에 맞추어 제품 백로그는 자주 개선된다. 매 스프린트마다 우선순위에 따라 아이템들이 추가되고 제거되고 수정되며 쪼개지고 변경된다. 그러므로 고객의 니즈 변화, 새로운 아이디어, 경쟁사의 움직임, 기술적인 걸림돌 등을 반영하기 위해서 제품 책임자는 계속해서 제품을 업데이트해야 한다.
• Prioritized: 제품 백로그의 최우선 순위 아이템부터 1에서 N까지의 순서로 우선순위가 매겨져야 한다. 최우선 순위의 아이템들은 적은 비용으로 큰 가치를 내는 것이나, 큰 위험을 포함하고 있는 아이템이다. 전통적인 개발 방식에서는 높은 효과 순으로 결과를 내는 것이 강조되지는 않지만, 스크럼에서는 중요하다. 아이템 위주의 추정 방법을 적용하기에 불명확할 경우, 전반적인 경영 성과를 바탕으로 접근할 수 있다. 이런 경우 성과에 관련된 여러 개의 아이템들이 한 번에 전달되어야 가치를 만드는 경우에 해당되며, 제품 책임자는 최소 기능 제품에 대해서 다음번에 만들 증분을 정의한다. 이러한 방법들은 제안일 뿐, 스크럼에서는 제품 백로그의 아이템들을 표현하거나 우선순위를 매기는 방법에 대해서 정의하지 않고, 추정기술이나 추정 단위에 대해서도 고려하지 않는다.

백로그에는 무엇이 중요한지를 최소한으로 명시해야 한다. 모든 세부사항을 기록하는 것보다는 해당 아이템을 이해하는 데 필수적으로 필요한 것인지 무엇인지 명확히 기록하고, 제품 책임자, 이해 관계자들과의 대화를 통해 이를 늘려나가야 한다. 우선순위가 낮은 제품은 우선순위가 높은 제품에 비해 상세화가 덜 되어 있고, 크기가 크다.

이슈

• 스토리: 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것으로 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋다.
• 에픽(Epic): 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀이다. 하나의 스프린트에 걸쳐서 끝나는 것이 아닌, 여러 스프린트에 걸쳐 종료되는 것으로 주요 기능들을 중심으로 정의된 여러 스토리들의 집합이다.
• 태스크(task): 에픽이나 스토리의 하위 작업으로, 에픽이나 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업이다. 유사 기능 조사, 테스트 시나리오 작성 등이 해당된다.
• 서브태스크: 스토리의 하위작업으로 에픽이나 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업이다.

완료 기준

완료기준(Definition of Done)은 인수 기준(Acceptance Criteria)이라고도 하며, 사용자 스토리를 완료시키기 위한 조건 명세다. 매 스프린트의 산출물은 잠재적으로 출시 가능한 제품 증분이라고 부른다. 첫 번째 스프린트를 시작하기 전에 제품 책임자, 팀, 스크럼 마스터는 제품 백로그의 아이템이 잠재적으로 출시 가능하기 위해서 필요한 모든 것에 대해 검토해야 한다. 제품을 출시하기 위해 필요한 모든 활동은 ‘잠재적으로 출시 가능’이라는 말의 정의에 포함되어야 하며 그렇기 때문에 스프린트 기간 동안 끝나야 한다. 팀이 각 스프린트마다 잠재적으로 출시 가능한 제품을 전달하고자 하는 목표를 이루지 못하는 경우가 있는데, 이는 팀의 자동화가 덜 되었거나 충분하게 다기능 적이지 않기 때문이다. 시간이 지날수록 더 나아져, 이 문제가 해결되겠지만 시작을 위해서는 현재의 역량에 대한 기능을 만들 필요가 있다. 좋은 제품 책임자는 항상 완료 기준이 가능하면 잠재적으로 출시할 수 있을 수준에 가깝게 잡혀서 개발이 투명해지고 지연되는 경우가 줄어들며 리스크가 감소하기를 원한다. 만약 완료 기준이 잠재적으로 출시 가능한 정도가 아니라면 리스크와 지연이 발생하게 될 릴리즈를 하게 될 때까지 계속 작업이 지연될 것이다. 스크림팀은 앞에서 나온 개선 사항들을 끊임없이 개선하여 완료 기준을 늘리는 데 반영해야 한다.

소멸 차트

번 다운 차트(Burn down chart)라고도 하며, 시간 대비 남아 있는 일의 양을 표현한 차트다. 작업물이나 백로그를 수직축에 표현하고 수평축에는 시간을 표현하여 모든 작업들이 완료되는 시점을 예측하는데 사용한다.

스크럼 보드

벽 크기의 업무 보드 형식으로 만든 스프린트 백로그다. 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판이다. 포스트잇에 적힌 작업들은 “할 일”, “작업 중”, “완료” 등이 있다.

참고자료

• Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde, 〈스크럼의 이론과 실천에 대한 가벼운 안내서Version 2.0〉, 《THE SCRUM PRIMER》
• 〈스크럼(애자일 개발 프로세스)〉, 《위키피디아》
• ZeddiOS, 〈thvmxmdnpdj 개발 방법론(애자일/스크럼〉, 《티스토리》, 2017-02-13
• 양민경, 〈애자일 방법론⓵: 스크럼(scrum)〉, 《뉴스레터》, 2018-06-19
• 민현기, 〈애자일 Scrum(스크럼) 이해하기〉, 《미디엄》, 2019-01-26
• 황선영, 〈스크럼의 진행 과정〉, 《미디엄》, 2019-07-17
• 행복한 앵그리비버, 〈[https://hanminwoo.com/33 애자일(Agile)과 스크럼(Scrum)과 지라(JIRA) 이야기〉, 《티스토리》, 2019-12-01
• 도전적인 HarimKang, 〈스크럼(Scrum) 이란?〉, 《티스토리》, 2020-02-04

같이 보기

• 애자일
• 스프린트
• 프레임워크
• 방법론

이 스크럼 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반