[agile] 일개 개발자가 본 스크럼 개발방법론

최근 재미난 형태의 프로젝트에 참여하고 난 후,

세상에 존재하는 다양한 형태의 개발 프로세스를 접하고 싶다는 생각이 들었습니다.

개발 프로세스에 따라,

- 제품이 완성되는데 소요되는 기간

- 완성품의 질적수준

- 프로젝트 참여자의 만족감

등이 확연하게 달라지는 것을 체감하였기 때문입니다.

학부 때부터 줄곧 보아왔던 개발 프로세스는,

공산품 제조 프로세스를 거의 그대로 따온 Waterfall 프로세스였습니다.

제조 기반의 소프트웨어업체는 아직도 상당수 이 프로세스를 사용하겠지요.

Waterfall 개발방식은 누가봐도 명확한 절차를 따릅니다.

- 개발에 앞서 고객으로부터 요구사항을 받고,

- UX 디자이너는 요구사항을 면밀히 분석하여 User eXperience 문서를 작성하고,

- 아키텍트는 UX를 이리저리 보고 UX Designer와도 협의를 하여 아키텍쳐를 설계하고,

- 프로그래머 혹은 코더는 온갖 삽질을 병행한 개발을 시작합니다.

- 까탈스러운 검증자는 결과물을 보고 딴지를 걸기 시작하지요.

아키텍트나 프로그래머에 의해 개발단계에서 UX 디자인이 변경되기도 합니다.

주로 개발제한요건이나 일정상의 이유로 UX 디자이너와 논의하여 디자인을 변경하지요.

이런 수정은 개발단계 이전이나 진행 중에 주로 발생합니다.

개발자가 요청하여 UX에 반영한 사항이기 때문에 개발자는 기분좋은 마음으로 수정에 임하지요.

하지만, 구현이 완료된 다음 검증자에 의해 UX 디자인이 바뀌는 경우도 있습니다.

요구사항 혹은 UX 디자인 단계에서도 검증자의 눈에 들지않을 만한 것을 끊임없이 수정하였겠지만,

검증자가 완성품을 보고 문제를 제기할 수 있습니다.

검증자는 단순 테스터일 수도 있고 경영진 중 한 분 일 수도 있겠지요.

바로 이 시점에 UX 디자이너는 자신의 디자인에 대한 자부심을 지킬 것인지

아니면 자신의 밥그릇을 지킬 것인지 고민합니다.

물론, 검증자가 제기한 문제가 프로젝트에 치명적인 결함을 막을 혜안의 결과일수도 있습니다.

어찌되었건 UX가 바뀌면 디자이너는 하루나 이틀 작업으로 새로운 가이드를 만듭니다.

그리고 개발자는 새로운 가이드를 보고 며칠씩 밤을 새며 작업을 이어가겠지요.

이미 프로젝트를 완성해야하는 시간이 임박해왔을테니,

아키텍쳐 따위는 잠시 접어두고 스트레스가 행간에 가득한 땜빵(?) 코드가 들어갑니다.

제가 경험한 대부분의 프로젝트는,

프로젝트 시작단계에서부터 마지막에 이르기까지 Requirement가 계속 바뀌었습니다.

첫 단계가 바뀌기 때문에 이후에 진행되는 모든 단계마다 리스크 관리를 해야했습니다.

소프트웨어 개발은 Requirement가 너무나 쉽게 변경되곤 합니다.

그리고 이런 식으로 Requirement가 바뀐다면 개발 프로세스도 그에 적합하게 바꾸는 것이 좋겠지요.

사실, 개발 프로세스를 바꾸려면 변경된 프로세스에 최적화된 조직을 구성해야합니다.

개발조직이 변경되면 변경된 조직에 대한 관리체계도 다시 세워야하고요.

관리체계를 뿌리부터 흔들면 관리자들은 여러가지로 고민하겠지요.

그래서 개발 프로세스를 변경하는 것이 매번 좌절되는 것인지도 모르지요.

하지만, 스크럼은 기존 조직을 유지하면서 개발 프로세스에만 변화를 줄 수 있습니다.

그것이 수많은 조직에서 스크럼을 선택한 이유이겠지요.

제조업 중심의 조직에 스크럼을 적용하기 위해서는,

각 조직별로 To do list부터 정리하는 것에서부터 시작해야합니다.

To do list에는 말 그대로 수행해야할 태스크들의 목록입니다.

하나도 빠짐없이 적겠다는 필념으로 나열할 필요는 없습니다.

현 시점에서 파악된 디테일에 대한 태스크 정도만 명시해두면 됩니다.

스크럼에서는 이 To do list를 백로그(backlog)라고 부르고,

제품을 완성하기 위해 수행하는 백로그는 제품백로그라 부릅니다.

그리고 백로그에 아주 중요한 항목을 하나 추가합니다.

바로 '우선순위'입니다.

각 태스크별로 우선순위를 명시해줍니다.

우선순위는 우선순위가 높은 것을 개발하기 위해 우선순위가 낮은 것을 포기할 수 있다는 의미입니다.

모든 태스크가 전부 최우선순위일리는 없습니다.

최우선순위부터 최하위순위까지 순차적으로 순위를 정해봅니다.

'나쁜' 아이디어는 없지만 우선순위에서 밀려서 구현에서 제외되는 아이디어가 생기겠지요.

그리고 백로그에 명시된 태스크를 하나씩 살펴보며 각각 소요시간을 산정해봅니다.

각각의 태스크는 4시간 ~ 16시간 정도 사이즈로 관리되는게 좋겠지요.

최소 반나절에서 최대 이틀정도의 시간에 처리가 가능한 태스크인게 좋겠지요.

추정치는 말 그대로 '추정'이기 때문에 반드시 일치할 필요는 없습니다.

백로그를 작성하였다면 이제 실천할 차례입니다.

우선순위가 높은 항목을 위주로 '스프린트' 기간동안 개발가능한 피쳐들을 고릅니다.

'스프린트'는 스크럼에서 반복적으로 백로그 중 일부를 수행하는 기간을 의미합니다.

'스프린트'는 통상 한달 정도의 시간으로 운영되지만 팀사정에 따라 변경할 수 있기에,

팀원들은 기간에 알맞게 피쳐들을 골라야 합니다.

스프린트에 수행할 백로그'만' 스프린트 기간내에 처리하면 됩니다.

정해진 태스크 외에는 설사 ASAP 꼬리표가 달린 태스크라 할지라도 다음 스크럼 기간으로 미룹니다.

'연기의 미학'을 유감없이 발휘해야합니다.

어디서부터 요구사항이 비롯되었건 다음 스크럼 기간으로 과감하게 연기합니다.

그래서 개발자는 현재 스크럼 기간에 할당된 일에만 집중할 수 있게 됩니다.

불필요한 컨텍스트 스위칭을 제거하여 개발효율이 높아질 수밖에 없습니다.

이 점에서 두뇌노동자인 개발자들의 환호를 받습니다.

온전히 하나에 집중할 시간을 보장받게 되는 짜릿한 순간입니다.

이렇게 한 달 동안 스프린트 백로그에 명시된 태스크만 수행해나갑니다.

아키텍쳐나 프로토콜 설계를 첫 스프린트에 완성할 필요는 전혀 없습니다.

그저 주어진 백로그에 맞는 아키텍쳐만 그리면 충분합니다.

나머지는 다음 스프린트 또 그 다음 스프린트에서 처리하면 됩니다.

계획은 추정일 뿐이기 때문에,

태스크를 수행하다보면 시간이 모자라거나 남을 수도 있습니다.

그때는 '상식적으로' 행동하면 됩니다.

스프린트에 수행할 태스크를 좀 빼거나 더하여 현실적으로 달성가능한 목표를 재설정합니다.

한달이 지나면 '데모 가능한 수준'의 릴리스가 나와야합니다.

릴리스 회의에는 프로젝트 참여자 뿐만 아니라 관리자나 경영자 혹은 고객까지 참여할 수 있습니다.

데모를 통해 개발의 현단계를 가늠할 수 있고,

다음 스크럼 기간동안 해야할 일들의 우선순위를 조정합니다.

실제로 소프트웨어가 돌아가는 모습을 보면 번뜩이는 아이디어도 쏟아져 나오기 마련입니다.

제품 백로그에 새로운 의견을 잔뜩 추가하고,

다음 스프린트에 수행할 태스크를 우선순위를 기준으로 고릅니다.

'스프린트'는 백로그의 태스크로 움직입니다.

그렇다면 매일매일의 일과에서는 스크럼은 어떤 영향을 줄까요?

스크럼은 매일 아침 '일일 스크럼'이라 불리는 15분 정도의 회의를 진행합니다.

회의에는 오직 세가지 물음에 대한 답변만 존재합니다.

- 어제 한 일은 무엇인가?

- 오늘 할 일은 무엇인가?

- 일을 수행함에 있어 장애는 무엇인가?

이 회의는 누구나 참석할 수 있지만,

간결한 회의 진행을 위해 오직 팀원만 발언할 수 있습니다.

매일매일의 회의를 통해 개발자의 귀중한 시간을 빼앗지 않으려고 하는 것이지요.

일일 스크럼이 끝나면 일일 스크럼 시간에 나온 다양한 이슈들로 토론이 벌어집니다.

모든 팀원이 참여할 필요는 없습니다.

관심있는 개발자만 참석하여 고민거리를 함께 해결해나가는 것이지요.

그리고 스크럼을 운영하는 스크럼 마스터는 개발에 장애가 되는 부분을 잘 갈무리해두었다가,

개발자들이 원활히 개발할 수 있게 모든 장애를 제거해주어야 합니다.

스크럼 마스터는 처음부터 끝까지 '어떻게 하면 개발자가 개발본연에 집중할 수 있을까?'에 대해 집중적으로 고민합니다.

스크럼 마스터를 제외하고는 전부 코딩을 해야합니다.

아키텍트나 프로토콜 설계자라고 코딩을 하지 않을 이유는 없습니다.

팀이 스프린트 백로그 개발을 모두 달성하려면,

중간관리자라이든 신규개발자이든 한마음으로 vi를 열고 코딩을 해야겠지요.

한국의 개발환경에서는 백발개발자를 찾기 힘든데요,

백발개발자의 찬란한 노하우가 후배개발자에게 원활히 전수되는 그 날이 어서 와야합니다. :)

스프린트 초반에 흔히 볼 수 있는 모델링에 대해 스크럼은 아래처럼 이야기 합니다.

"모델링을 할지 여부를 선택에 맡겼을 때 팀의 생산성이 올라가는가?"

모델링이나 문서는 코드가 진화함에 따라 퇴화하는 경우가 많습니다.

개발자가 생각을 정리하는 용도로만 모델링을 사용하는 것은 좋은 선택이겠지요.

오로지 개발에 유익한 활동만을 추려내고 그 외의 루틴은 다 거둬들여야 합니다.

스크럼을 적극적으로 도입했을때 얼마나 효과를 볼까요?

스크럼 본문에 있는 내용을 그대로 옮겨봤습니다.

이렇게 스크럼을 적용하면 생산성은 5~25% 정도만 (향상되는게) 아닙니다. 스크럼에서 생산성이 높다고 말할 때에는 종종 서너 자리, 즉 수백 퍼센트 더 높다는 것을 의미합니다.^[각주:1]

오늘은 여기까지 하겠습니다.

그럼 좋은 하루 보내세요~

끝_

1. 켄 슈와버 · 마이클 비들, "스크럼", 인사이트, 2008, xxiv [본문으로]