이 글은 공식 LeSS 사이트에 있는 Product, Potentially Shippable Product Increment, Definition of Done을 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 SAFe와 LeSS가 가장 인기있는 대규모 애자일 프레임워크라고 할 수 있다. 많은 이들이 애자일 트랜스포메이션에 관심을 갖고 있는 우리의 상황에서 비슷한 고민을 오래 전에 먼저 시작한 이들의 문제 인식과 통찰을 살펴보는 것은 흥미로운 일이다.

대규모 조직에 애자일을 적용하고자 하는 분들에게 도움이 되길 바란다.

0. 대규모 스크럼, 레스(LeSS)
1. 왜 레스(LeSS)인가?
2. 레스(LeSS)의 규칙
3. 피처 팀(Feature Teams)
4. 제품 책임자(Product Owner)
5. 스프린트(Sprint)
6. 제품 백로그(Product Backlog)
7. 제품 그리고 완료의 정의
8. 팀간 조율 및 통합
9. 스크럼 마스터(ScrumMaster)
10. 레스(LeSS)의 적용

제품(Product)

레스(LeSS) 처음 적용하기 시작할 때 가정 먼저 확인해야 할 것 중 하나가, “실제 제품이 무엇인가?”라는 질문이다. 레스(LeSS)에서 바람직한 제품의 정의와 초기 제품의 정의가 서로 같지 않은 경우가 많기 때문에, 이것이 사고의 변화로 이어지고 결국 조직의 변화까지 이르게 된다.

제품의 정의(Product Definition)는 아래와 같은 것들에 영향을 미치기 때문에 명확해야 한다.

  • 제품 백로그의 범위
  • 제품 책임자(PO)가 될 사람
  • 제품 (및 제품 팀의) 크기 및 그에 따르는 레스(LeSS) 또는 레스 휴즈(LeSS Huge) 적용 여부

대개는 다음 두 가지를 구별한다.

  • ‘이상적’ 제품 정의 – 넓히는 질문을 통해 이끌어 냄
  • ‘실용적’ 제품 정의 – 이상적 제품 정의의 부분 집합이며, 거기서부터 시작해서 개선해나가는 방식으로 정의할 수 있음

제품 정의를 찾는 일반적인 방법은, 넓히는 질문을 던진 다음 실용적 정의로 좁혀가는 것이다.

넓히는 질문

넓히는 질문은 대부분 제품의 정의를 더욱 고객 중심으로 만드는 경향이 있다. 다음을 포함한다.

  • 실제 최종 고객이 누구이며 그들은 무엇을 제품이라고 생각하는가?
  • 제품이 해결하려는 원래 문제는 무엇인가?

좁히는 질문

좁히는 질문은 기존 상황과 조직을 살펴보고, 제품의 정의를 좁혀서 시작이 가능하도록 실용적으로 만든다. 대표적인 좁히는 질문은 다음과 같다.

  • 당신의 회사 안에는 무엇이 있는가?
  • 당신의 통제 범위 안에는 무엇이 있는가?
  • 제품의 비전을 명확하게 표현할 수 있는가?

지속적인 개선

초기 제품 정의를 찾아내고 레스(LeSS)를 적용하기 시작한 후, 조직은 장기적으로 이를 확대할 수 있는지에 대한 여부 및 그 방법을 살펴봐야 한다. 레스(LeSS)는 다음과 같은 이유로 보다 넓은 제품 정의를 선호한다.

  • 대체적인 윤곽을 더 잘 만들고 우선순위를 세분화해서 부여할 수 있음
  • 비슷한 제품 간의 중복을 방지할 수 있음
  • 소규모 ‘제품’ 간의 의존성을 해결할 수 있음
  • 실제 고객 문제에 초점을 맞출 수 있음
  • 조직의 복잡성을 감소시킬 수 있음

잠재적으로 출시 가능한 제품 증분(Potentially Shippable Product Increment)

모든 스프린트의 결과물을 ‘잠재적으로 출시 가능한 제품 증분(Potentially Shippable Product Increment)’이라고 부른다. 모든 스프린트가 끝나기 전에 모든 팀의 업무는 반드시 통합되어야 한다. 통합은 스프린트 동안에 이루어져야 한다. 이렇게 하면 다음과 같은 효과를 얻게 된다.

잠재적으로 출시 가능하다는 것은 소프트웨어의 가치나 시장성에 대한 이야기가 아니라 소프트웨어의 품질에 대한 이야기다. 제품이 잠재적으로 출시 가능하다는 것은 “현재 구현된 기능이 작동하는 데 필요한 모든 업무를 마쳤으며, 기술적으로 제품을 출시할 수 있는 상태”라는 뜻이지, “구현된 기능이 새로운 릴리스를 원하는 고객에게 충분히 가치있는 상태”라는 뜻이 아니다. 후자의 여부를 결정하는 것은 제품 책임자(PO)다.

제품이 정말로 출시 가능한지는 현재 완료의 정의에 따라 달라질 것이다. 만약 완벽한 완료의 정의를 갖고 있다면, 각 스프린트마다 제품을 출시할 수 있다. 완료의 정의가 빈약하다면, 여전히 해야 할 일이 끝나지 않은 채 남아 있어서, 낮은 투명성, 낮은 유연성, 개발 위험 증가로 이어진다.

완료의 정의(Definition of Done)

스크럼의 검토-적응(inspect-adapt) 사이클이 효과를 발휘하려면 투명성이 있어야 한다. ‘완료’가 무엇을 의미하는지 공식적으로 정의해 놓으면, 변동성 및 미계획 업무(undone work)가 생길 가능성이 감소하고, 진척도를 명료하게 측정할 수 있으며 (‘완료’ 아니면 ‘미완료’), 투명성이 증가한다.

완벽한 완료의 정의는 조직이 제품을 고객에게 전달하는데 해야 할 모든 것을 포함한다. 한 팀으로 이루어진 제품 그룹은 이를 달성하기가 상대적으로 쉬울 것이다. 팀이 완벽한 완료의 정의를 달성할 수 없는 상태라면, 완벽한 정의의 부분 집합을 ‘완료’라고 정의한다. 이런 팀은 언젠가 자신들의 완료의 정의를 완벽하게 만들고, 각 스프린트마다 또는 그보다 더 자주 출시할 수 있도록 완료의 정의를 개선하는 것을 목표로 삼는다.

완료의 정의란 소프트웨어에서 각 제품 백로그 항목에 대해 충족시켜야 할 기준을 정해놓은 목록이다. 목록을 이 정도 수준으로 만들려면 작업 목록을 팀이 작성해야 한다. 모든 작업을 완료했을 때 그 항목이 완료되는 것이다. 완료의 정의를 인수 기준(acceptance criteria)과 혼동하지 말자. 인수 기준은 개별 항목이 인수되기 위해 이행해야 하는 구체적인 조건을 말한다. 완료의 정의는 모든 제품 백로그 항목에 동일하게 적용된다.

완료의 정의 만들기

초기 완료의 정의는 첫 번째 스프린트 전에 합의를 이루어야 한다. 대개는 초기 제품 백로그 개선 워크숍에서 만든다.

완료의 정의를 만들려면 다음 단계를 수행한다.

  • 최종 고객에게 출시하는 데 필요한 활동을 정의한다.
  • 각 스프린트에서 할 수 있는 활동을 결정한다.

이 단계들을 좀 더 자세히 살펴보자.

최종 고객에게 출시하는 데 필요한 활동 정의하기

핵심 질문은 “우리 제품을 출시하는 데 현재 필요한 활동은 무엇인가?”이다.

  • 출시란 “최종 고객에게 전달하는 것”을 의미하는 것이지 “개발 부서 밖으로 내보내는 것”을 의미하는 것이 아니다.
  • 중간 산출물의 필요성에 이의를 제기한다. 명세 문서가 정말로 필요한가?

팀은 필요한 활동을 포스트잇 노트에 작성한다. 여기에는 코딩이나 테스트 같은 활동이 포함될 수도 있지만, 고객 지원 준비, 하드웨어 제작, 심지어 마케팅 활동을 포함할 수도 있다. 이 목록을 ‘출시 기준(Potentially Shippable)’이라고 부른다.

이 단계에서는 조직의 완벽한 목표를 만들었다. 모든 스프린트에서 각 항목에 대해 이 활동들을 전부 수행한다. 이 과정에서 제품 그룹은 이 목록이 개선이 많이 필요하다는 것을 깨닫는 경우가 많다.

각 스프린트에서 할 수 있는 활동 결정하기

핵심 질문은 “우리의 현재 맥락과 역량을 고려했을 때, 각 스프린트에서 정말 할 수 있는 활동은 무엇인가?”이다. 이것이 초기 완료의 정의의 부분 집합이다. 완료의 정의는 작은 부분 집합일 때 빈약하고 출시 기준과 거의 엇비슷할 때 강력하다.

팀은 자신들의 맥락을 논의하고 모든 팀이 스프린트 동안 현실적으로 가능하다고 생각하는 활동의 부분 집합을 선택한다. 이것이 초기 완료의 정의다. (아래 그림의 예시 참조) 더 많은 활동을 할 수 있는 팀은, 이 완료의 정의를 자기 팀 내부에서 확장해 적용할 것이다.

완료의 정의와 출시 기준 간의 간극을 미계획 업무라고 부른다. 스프린트 계획은 완료의 정의에 따라 수립하는 것이므로, 그 계획에서 미계획 업무는 빠져있다. 즉, 미계획 상태로 남겨두기로 계획하는 것이다.

출시 기준과 완료의 정의

완료의 정의 관련 용어

출시 기준 및 완료의 정의 관련 용어를 일관성 있게 사용하는 경우가 많지 않지만, 레스(LeSS)에서는 매우 정확하게 그 의미를 정의하고 있다. 관련 용어의 의미는 다음과 같다.

출시 기준(Potentially Shippable)—제품을 출시하기 전에 반드시 수행해야 하는 모든 활동

완료의 정의(Definition of Done)—스프린트 내에서 어떤 활동을 수행할 것인지에 대한 팀과 제품 책임자(PO) 사이의 합의. 완료의 정의가 출시 기준과 같다면 완벽한 완료의 정의가 된다. 팀은 완료의 정의를 개선해서 완벽에 가까워질 수 있도록 노력한다.

미계획 업무(Undone Work)—완료의 정의와 출시 기준 사이의 차이. 완료의 정의가 완벽하다면 미계획 업무는 없는 것이다. 그렇지 않은 경우라면 조직은 (1) 미계획 업무를 어떻게 처리할 것인지, (2) 향후 미계획 업무가 줄어들 수 있도록 어떻게 개선할 것인지, 결정해야 한다.

미완료, 미완성 등 (Unfinished, not finished, or not done)—스프린트에서 계획했지만 끝내지 못한 업무. 이 용어를 미계획 업무(undone work)와 혼동하는 경우가 많다. ‘미완료’은 팀이 계획했지만 끝내지 못한 업무인 반면에 미계획 업무는 계획조차 없었던 업무다. 팀에게 미완료 업무가 생기면 불편함을 느끼면서 회고에서 개선 조치를 논의해야 할 것이다.

팀은 스프린트를 끝낼 때 진행 중 업무를 남겨두고 다음 스프린트로 “넘기기”를 해서는 절대로 안된다. 이렇게 하면 투명성이 부족해지고 범위 유연성이 줄어든다. 너무 많은 업무를 예측했다면, 아직 시작하지 않은 완전한 항목을 제거해야 한다.

완료의 수학

출시 기준(Potentially Shippable) = 완료의 정의(Definition of Done) + 미계획 업무(Undone Work)


이터레이션 내 업무(Work in Iteration) = 제품 백로그 항목(Product Backlog Item) * 완료의 정의(Definition of Done)

미계획 업무 -> 위험과 지연

맨 먼저 시나리오를 통해 미계획 업무가 미치는 효과를 탐색해보자.

팀은 첫 번째 스프린트에서 20개의 제품 백로그 항목을 (완료의 정의에 따라) 완료했다. 미완료 업무는 없었지만, 이들의 완료의 정의가 빈약했기 때문에 미계획 업무가 많다. 팀이 세 번째 스프린트에서 40개의 제품 백로그 항목을 (빈약한 완료의 정의에 따라) 완료한 후에는, 미계획 업무의 양이 어마어마하게 늘어났지만 실제보다 더 많은 진척을 이루었다고 착각했다.

그러나 출시할 수가 없다. 기능을 ‘완료’하긴 했지만 빈약한 완료의 정의로 인해 막대한 양의 미계획 업무가 누적되어 있었다. 이러한 미계획 업무는 지연 및 숨어있는 위험의 원인이 된다.

지연(Delay)—미계획 업무를 수행하려면 추가 노력이 필요하다. 이것이 제품 책임자(PO)가 유연성을 발휘하지 못하게 만든다. 시장의 요구와 변화에 직접적으로 대응할 수 없다. 미계획 업무를 끝내는 데 드는 노력의 변동성이 매우 커서 예측이 어렵기 때문에 이 지연으로 생긴 고통이 더욱 악화된다.

위험(Risk)—미계획 업무는 투명성을 부족하게 만든다. 위험이 미계획 업무 안에 숨어있다. 예를 들어, 성능 테스트를 미계획 상태로 남겨두면, 릴리스에 가까워질 때까지 (즉, 가장 큰 타격을 입을 때까지) 부실한 시스템이라는 위험을 지연시킨다.

좋은 제품 책임자(PO)는 제품의 위험을 줄이고 지연을 방지하는 완벽한 완료의 정의를 원한다.