Debt(잔업)과 그것이 릴리즈에 미친 영향

우리의 마지막 릴리즈
Agile을 적용한 두 가지 주된 목적은 낭비를 줄이는 것과 재미를 우선시하는 것이다.

우선순위가 매겨진 ‘완성된’ 인크리먼트의 게임에 범위(scope)를 추가하는 것에 초점을 맞추어 위의 목표를 달성하고 마지막에 혼란을 피할 수 있기를 바란다.

우리는 2-3주 단위로 게임을 개발하는데 이 기간을 ‘스프린트’라고 한다. 각 스프린트 때에 게임의 재미에 추가되는 기능들의 수직적 슬라이스(slice)를 추가한다. 게임은 매 2-3주 마다 개선되어야 한다. 우리는 또 2-3달에 한번씩 “릴리즈”를 한다. (한번의 릴리즈는 약 4번의 스프린트로 이루어진다.) 릴리즈는 "게임의 잠재적으로 출시 가능한 버전"이다. 릴리즈는 매거진이나 E3데모라고 생각할 수 있다.

다른 릴리즈를 정리하면서 나는 작업을 더 잘할 수 있는 방법을 찾아 보았다. 예를 들면, 낭비를 줄이면서 재미를 늘릴 수 있는 방법 같은 것이다.

지난 2개월 릴리즈를 보면, 팀이 근무 시간 외 작업을 하기로 결정한 마지막 스프린트(마지막 주말과 주중의 몇 번)까지 그다지 대단한 작업이 이루어지지 못한 것을 볼 수 있다. 이것이 죽음의 행진까지는 아니었지만, 개선의 필요성은 분명히 있는 것이었다.

그래서 이 것에 대해 생각해봤다.

스크럼(Scrum)의 가치 중 하나는 무슨 일이 진행 중인지 투명하게 볼 수 있는 도구를 가지고 있다는 것이다. 그런 도구 중 하나로 "Release Burndown"이 있다. 이 도구는 팀이 각 스프린트 마다 몇 개의 “스토리 포인트”를 마쳤는지 보여준다. 스토리 포인트는 서로 연결되어 있는(그리고 가장 중요하게, 시간에 얽매이지 않는) 난이도 기능의 척도이다. 그것은 앞으로의 릴리즈를 계획할 때 속도를 측정할 수 있는 매우 유용한 기능이다.

마지막 릴리즈 동안, 우리는 릴리즈의 마지막으로 갈수록 스토리 포인트 속도가 감소하는 것을 보았다:

위 도표는 무슨 일이 벌어졌는지 설명해준다. 이 것은 실제 Release Burndown은 아니지만 요점을 보여주기 위해 단순화 시킨 것이다. 파란 선은 스토리 포인트 Burndown을 보여준다. 보라색 선은 게임이 얼마나 재미있는지의 정도를 고객의 관점에서 보여준다.

Debt(잔업)

Debt(잔업)는 아직 마치지 못한 작업을 말한다. 이것은 "차고 바닥의 부품들"이라고 할 수 있다. Debt(잔업)는 다음과 같은 것이 될 수 있다.

• 버그
• 누락되거나 곧 빌드될 에셋들
• 오버 디자인

버그를 예로 들자면, 스프린트 빌드에서는 버그를 무시하고 넘어가는 것을 볼 수 있다. 팀은 해당 스토리를 완성했지만(그리고 그것은 포인트가 된다.) 이 버그들은 여전히 수정을 필요로 한다. 이 버그들은 수정하는 데에 시간이 걸리기 때문에 이 팀은 완성했다고 생각한 스토리와 연관된 debt(잔업)를 가지고 있는 것이다. 이 dept(잔업)는 처리되어야 한다. 대체로 이런 일은 프로젝트 알파에 일어나지만 이런 경우에 대부분 릴리즈 이전에 다시 처리되어야 한다.

버그가 재미(가치value)를 방해하기 때문이다. 우리는 버그가 수정되었다면 훨씬 더 재미있을 수 있는 게임을 버그 때문에 덜 재미있게 했던 경험을 몇 번씩은 가지고 있다. 그런 영향을 위의 도표에서 볼 수 있다; 팀이 스토리에서 버그 수정으로 이동하여 작업하는 경우 스토리 포인트 속도는 줄어들겠지만 게임의 재미는 더욱 증가할 것이다. 우리 고객들은 이런 거슬리는 버그가 수정되었을 때 더욱 즐겁게 게임을 하게 된다.

("모든 debt(잔업)는 나쁘지 않다"는 코멘트가 떠올랐다. 다음 게시의 주제로 삼겠다.)

왜 시간이 초과되는가?
이제, 우리는 왜 릴리즈의 마지막에 근무 시간 외 작업을 해야 할까? 두 가지 원인이 있다:

1. 제품 품질 성장이 정점에 가깝고 시간이 부족해서 팀이 초과 작업을 하는 경우.
2. 제품에 심각한 버그가 아직 남아 있기 때문에 초과 작업을 하는 경우.

일정이 품질과 QoL을 결정하게 되기 때문에 이런 상황을 좋지 않다. 일정은 범위(scope)를 결정해야 한다.

권장되는 작업 상황:

1. 매 스프린트마다 팀이 범위(scope)의 수직적 슬라이스를 완성한다.
2. 범위(scope) 에 우선 순위를 매긴다.
3. 릴리즈 마지막에 가까워지면 범위(scope) 속도가 범위 한계 포인트를 결정한다. 낮은 가치의 기능들은 남겨진다.

Debt(잔업)이 컨트롤을 잃게 한다.

원인? 수정?

이게 가장 어려운 부분이다. 이 것을 처리하는 방법에는 두 가지가 있다:

우리 `고객들은 매 스프린트마다 완성도에 대한 기대치를 설정해야 한다. 우리는 dept(잔업)을 파악하고 대처해야 한다. 게임 개발에서 dept(잔업)을 파악하기란 상당히 힘들다.

팀은 스토리나 포인트가 아닌 재미의 정도에 초점을 맞춰야 할 필요가 있다. 그들은 스프린트 Burndown 에 집착해야 하고 게임에 좀 더 집중할 필요가 있다.

이올린에 북마크하기(0) 이올린에 추천하기(0)