AGILE Framework - 스크럼(SCRUM) Basics (3)

미리 일러두는 말: 본 포스팅은 LinkedIn 에서 제공하는 [Agile Methodology] Scrum 과정을 참고하여 정리한 내용임을 알려드립니다.

스크럼을 활용하여 일하기

지난 “AGILE Framework - 스크럼(SCRUM) Basics (1)편과 (2)” 포스팅을 통해 우리는 스크럼의 유래, 의의, 그리고 스크럼의 구성요소를 어떻게 프로젝트에 안착시키는지 알아봤습니다. 이번 “스크럼 Basics (3)” 포스팅에서는 스크럼 Basics (1), (2)편을 통해 계획한 스크럼을 어떻게 운영해야 하는지 알아보겠습니다.

스프린트 측정하기

앞서 릴리즈 계획과 로드맵을 세우고 사용자 스토리를 할당해 스프린트 진행을 계획한다고 논의했습니다. 계획을 했으면 이제 실제 스프린트를 진행해 봐야겠죠. 모든 스프린트는 시작 초기에 각 스프린트별로 할당된 사용자 스토리에 기반하여 스크럼 팀원들이 어떤 역할을 해야하는지 협의하는 ‘스프린트 계획 미팅’을 진행해야 합니다. 이 자리는 모든 스크럼 팀원들이 어떤 사용자 스토리를 완료해야 하는지 그리고 각 사용자 스토리가 왜 이번 스프린트의 일감으로 수행되어야 하는지 이해하는 기회가 됩니다. 더불어 팀원 간에 ‘완료’의 정의, 기준을 다시금 상기시키게 됩니다.

위의 이미지를 같이 보면 사용자 스토리 A가 세분화된 테스크 1,2,3으로 나뉘어 있음을 알 수 있습니다. 사용자 스토리 A는 스토리 포인트 3을 갖는 일감입니다. 그런데 첫번째 포스팅에서 잠깐 살펴보았듯 사용자 스토리는 쉬운 말로 표현되어 있고 큰 기능 단위를 나타내는 개념이라 약간 모호하게 다가 올 수 있습니다. 따라서 이를 조금 더 세분화된 개별 기능으로 나눌 필요가 있습니다.

이렇게 나뉘어진 테스크는 드디어 실제 개발에 필요한 공수를 산정할 수 있게 됐습니다. 예를 들어 “새 사용자 ID를 DB에 입력한다.”는 테스크 1을 고려했을때 고급 개발자 기준으로 3시간이 걸린다고 해봅시다. 마찬가지로 태스트 2와 3은 각각 4시간, 3시간이 투입되어야 개발을 완료할 수 있습니다. 그럼 사용자 스토리 A 전체를 고려할 때 총 10시간이 투입되어야 완료할 수 있다고 볼 수 있겠죠. 앞 선 포스팅에서 논의했던 스토리 포인트를 이렇게 사용자 스토리를 구성하는 각 테스크에 필요한 개발 시간을 개별적으로 추정해 합치고 이를 다시 다른 사용자 스토리의 그것과 비교함으로써 ‘상대적’인 크기를 추정합니다. 다시 그림을 보시면, 사용자 스토리 B는 전체적으로 6시간이 필요하고, 사용자 스토리 D는 전체적으로 16시간이 필요합니다. 즉, 각 사용자 스토리에 필요한 각각의 공수를 비교했을 때 A는 3 포인트, B는 2 포인트, D는 5 포인트로 측정할 수 있고, 나아가 첫번째 스프린트 전체가 총 10 스토리 포인트가 배치되어 있고, 시간 단위로는 총 32 시간이 필요하다는 것을 알 수 있습니다.

이렇듯 사용자 스토리를 테스크로 세분화하고 실제 공수를 측정하는 행위를 통해 우리는 비로소 사용자 스토리가 스프린트에 ‘반영’되도록 해줍니다. 테스크 레벨에서 볼때 시간(공수)은 스크럼 팀원이 책임 질 수 있는 분량을 대변하는 개념으로도 해석할 수 있습니다. 따라서, 스프린트 내 모든 계획된 일감의 양을 표지하는 단위로써 일감들을 완료하기 위해 스크럼 팀이 필요로 하는 시간을 정의할 필요가 있습니다.

스프린트 진행하기

자, 이제 정말 ‘일’을 진행해 봅시다. 정의한 사용자 스토리들은 각 스프린트 내의 상태 값을 구분해 가며 그 진행 상태를 살펴 볼 수 있습니다. 스크럼에서는 이를 Status 라고 표기하고 JIRA와 같은 협업 Tool이나 단순히 오프라인 보드에 게시함으로써 전체 스크럼 팀원에게 공유하게 됩니다. JIRA에 관해 좀 더 자세히 알고 싶은 분께서는 JIRA에 관한 포스팅들(https://engineering-skcc.github.io/categories/#devops-tools)을 참고해 주세요.

그럼 예시를 들어 볼까요? 실제 프로젝트에서는 아래 설명과 같이 간단하지는 않지만, 설명의 단순화를 위해 사무실 한쪽 벽에 아래와 같이 공간을 구분하고 포스트잇을 활용해 일감 관리를 하는 경우를 생각해 보겠습니다.

• 우리가 사용자 스토리 A, B, C, 이렇게 세 개의 일감을 갖고 있다고 해봅시다. 그리고 이 일감들은 각각 테스크 1, 2, 3의 하위 일감을 갖고 있습니다. 스프린트 계획 회의 시 사용자 스토리들은 최초 ‘열림’ 상태에 위치합니다. 그리고 회의를 거쳐(일감 진행 확정 후) ‘할 일’ 상태로 넘어갑니다. 그리고 ‘할 일’ 상태에 있는 일감들은 각 개발자들에 의해 실제 개발이 진행됨에 따라 ‘진행 중’ 상태로 재차 넘어갑니다.

• 바로 위의 표는 스토리를 이루고 있는 하위 일감들, 테스크의 진행 상태를 표시한 것입니다. 보시다시피 테스크도 스토리들과 같은 상태들을 거치면서 자신의 진행 상태를 알립니다. 당연히 테스크도 스토리와 같이 실제 진행 상태를 반영해 ‘할 일’ -> ‘진행 중’ -> ‘완료’ 의 순서대로 표시합니다.

• 실제 스프린트 내에서 사용자 스토리들은 이 ‘진행 중’ 상태에 가장 오래 머물게 됩니다. 2주 혹은 4주간의 스프린트 기간 중 실제 소스를 개발하고 개발자 스스로 테스트하는데 필요한 시간이 가장 큰 부분을 차지하기 때문이죠. 다만 진행 상 개념으로는 동일한 하나의 단계이므로 똑같은 크기로 표시했으니 참고해 주세요.

• 이제 각 스토리에 포함되어 있던 세 개씩의 테스크들이 모두 완료됐습니다. 다만, 테스크가 모두 완료됐다고 스토리 자체가 완료된 것은 아닙니다. 바로 PO외 모든 스크럼 팀원이 참석하는 ‘스프린트 리뷰’ 를 거쳐 모두의 동의 하에 ‘완료’ 여부를 결정해야 하기 때문입니다. 이에 대해서는 아래 별도의 세션에서 자세히 알아보겠습니다.

• 실제로 JIRA와 같은 협업 Tool 내에서는 스토리와 테스크가 하나의 화면에 동시에 표시되어 모든 팀원들이 스토리와 테스크의 진행 상황을 일목요연하게 볼 수 있습니다. 이 때의 화면을 우리는 ‘스크럼 보드’라 부르는데, 이미 언급했다시피 모든 스크럼 팀원은 물론 팀 외부의 프로젝트 참여자에게도 스프린트의 진행 상태를 알려주고 문제는 없는지 체크할 수 있도록 하는 장을 제공합니다.

• 아래 그림은 제가 JIRA에 테스트 용으로 만든 스프린트의 스크럼 보드를 캡쳐 해 온 것입니다. 간단히 설명하자면, 우선 ‘TEST 1 스프린트’에 TEST 1과 2, 3이라는 세 개의 스토리를 진행하고 있고, 각 스토리는 하위작업인 3건씩의 테스크 갖고 있습니다. 어느 사용자 스토리의 어떤 테스크가 진행 중이고 완료됐는지 한 눈에 볼 수 있죠? 이렇게 실제 협업 Tool에서는 스토리와 그 것의 테스크를 하나의 스크럼 보드에 동시에 노출시키고 각각의 진행상황을 투명하게 공유하는 것을 알 수 있습니다.

번 다운(Burn-down) 차트

스프린트의 전체 진행상황을 살펴 볼 수 있는 좋은 도구가 하나 더 있습니다. 바로 ‘번 다운(Burn-down)’ 차트입니다. 번 다운(Burn down)이란 단어가 갖는 뜻과 같이 스프린트를 진행하면서 해결해야할 일감(스토리)들을 태워 없앤다는 의미로써 아래 그림과 같이 표시됩니다.

스프린트 초기, 스토리를 구성하고 있던 스토리 포인트들이 스프린트가 진행될 수록 즉, 시간이 지날 수록 줄어듭니다. 물론 이러한 과정은 이상적으로(녹색 선) 진행이 될 수도 있지만, 그렇지 않은 경우가 더 많습니다. 예를 들어 스토리(테스크 포함) 진행에 따른 스토리 포인트 ‘연소’가 주황색 선을 따라 간다고 해보죠. 어쨌든 스프린트가 진행될 수록 스토리 포인트는 꾸준히 줄어 들어 스프린트가 마쳐지는 시점(FINISH)에 가서는 이상적인 녹색 선을 따라 진행된 것과 같이 모두 ‘연소’됩니다. 이는 곧 스프린트가 잘 완료됐다는 말이 되겠죠? 이렇게 ‘번다운(Burn-down)’ 차트는 일감의 진행상황을 시각화함으로써 스프린트의 진행을 좀 더 명확하게 표시해줍니다.

데일리 스탠드-업 미팅

스프린트를 진행하면서 스크럼 팀원 모두는 매일 오전 같은 시간을 정해 간략한 공유 미팅을 갖게 됩니다. 이를 데일리 스탠드업(Daily Stand-up) 미팅이라 부르고, 각 팀원은 오늘의 기분이 어떤지 전날까지 작업은 어땠는지, 진행하면서 어려운 점은 없었는지를 팀원들과 공유합니다.

데일리 스탠드업 미팅에서 강조하는 것은 스크럼 팀 내 1)협력, 2)소통, 3)스프린트 진행 체크를 가능케 하는 중요한 역할을 수행합니다.

특히 미팅 이름에도 명시되어 있다시피 반드시 선 자세로 진행해야 하며 서서 진행하는 만큼 가능하면 15분 내에 빠르게 미팅을 진행합니다. 미팅으로 인해 많은 시간을 빼앗기지 않도록 하면서도 매일 미팅을 필수적으로 진행하는 것으로 정해 스크럼 팀내 ‘협력(Collaboration)’를 높이고 모두에게 프로젝트 관련 정보를 오픈(Communication)하는 장치를 마련한 것입니다.

더불어 모두가 모인 자리에서 스프린트 중간중간 스크럼 보드를 함께 보며 우리가 어느 정도를 진행했어야 하는지 체크하고(Cadence), 만약 그에 미치지 못하다면 어떤 방법을 통해 만회할 수 있을지를 논의해 볼 수도 있습니다.

해외에서는 아래 그림처럼 ‘플랭크’를 하며(!) 회의하는 문화가 유행(?)이라고 합니다. 회의 시간이 무려 70% 이상 줄어들었다고 하는데… 시간을 줄이는 건 차치하고 회의를 5분 이상 할 수는 있을 지 모르겠네요… ^^;

백로그 그루밍(Grooming)

이제 스크럼의 최대 장점이라고 할 수 있는 필요에 따라 유연하게 일감을 추가하고 일정을 조정하는 방법에 대해 알아보겠습니다. 애자일 방법론의 가장 큰 장점 중 하나는 변화하는 시장 상황에 맞춰 프로젝트를 수정해 진행할 수 있다는 점일겁니다. 스크럼에서도 이를 반영하여 PO가 추가할 필요가 있다고 판단하는 일감, 스토리를 추가할 수 있습니다.

다만, 이 스토리 추가하는 과정에서 가장 주의해야할 점은 의사결정을 PO 혼자 내려서는 안된다는 점입니다. 바로 스크럼 팀과 특히나 Scrum Master 와 면밀히 협의한 뒤에 추가 및 그에 따른 진행 일정을 조정해야 합니다.스크럼에서는 정례적인 백로그 그루밍(Grooming) 세션을 갖도록 해 이런 상황을 미연에 방지하도록 합니다.

백로그 그루밍 세션은 1) 스프린트 진행 중간에 갖도록 하고, 2) 진행 시간은 30~60분 이내로 제한합니다. 세부적으로 백로그 그루밍 세션은 다음과 같이 진행됩니다.

• PO가 긴급하게 진행되어야 하는 새로운 스토리를 발굴하고 세션에 팀원들에게 공지합니다.
• 팀원들은 새로운 스토리의 세부적인 사항을 질문하고 PO는 그에 대해 답변합니다.
• 질의 응답과 협의를 통해 스토리를 추가하는 것으로 결정되면, PO는 추가될 스토리의 우선순위를 파악하여 반드시 미래의 스프린트 배치합니다.
• 이 때, 새로운 스토리가 끼워진 스프린트에서는 가장 우선순위가 떨어지거나 다른 기능들과 연관관계가 적은 기능의 스토리를 마찬가지로 미래의 적절한 스프린트에 재배치합니다.

이 백로그 그루밍 작업이 애자일과 스크럼 내에서 갖는 의의는 다음과 같이 정리해 볼 수 있습니다. 우선 애자일의 기본 사상인 변화에 대응하는 방법을 제공하면서도, 이미 진행되고 있는 스프린트 일정은 무분별하게 바꾸지 못하도록 보장합니다. 더불어 이러한 스토리 추가 및 재배치는 반드시 스크럼 팀의 동의에 기반하여 이루어져야 한다는 점도 놓치지 않음으로써 스크럼 팀 내 수평성과 협업을 다시 한번 강조하고 있습니다.

스프린트 리뷰(Review)

자! 드디어 스토리를 완료할 시간이 다가 왔습니다. 2주 간의 스프린트 기간동안 고생하셨지만, 마지막으로 스프린트 리뷰(Review)를 통해 스크럼 팀이 모두 동의를 해야 스토리들을 정말로 완료시킬 수 있습니다.

앞선 포스팅에서 스프린트를 시작하기 전에 완료의 기준을 세워야 한다고 했던 것, 기억하시나요? 네, 스토리들은 스프린트 리뷰에서 모든 스크럼 팀원이 모여 해당 스프린트에서 개발한 프로그램을 함께 살펴보고 미리 세워둔 완료 기준을 충족했다고 판단할 때 비로소 마무리될 수 있습니다.

물론 스크럼 팀 내에서 개발자들은 자기들이 개발한 프로그램, UI 등을 PO에게 시연하고 PO는 그 시연 사항이 애초에 정의된 스토리의 내용을 충실하게 반영하고 있고, 나아가 프로젝트 비전에서 어긋나지 않는지 판단합니다. 언뜻보면 PO의 권한이 막강해 보입니다. 당연하죠. PO는 프로젝트의 결과인 제품(Product)에 대해 가장 잘 알고 있는 비지니스의 대표니까 스크럼 팀의 성실한 작업을 요구할 권한을 갖습니다.

다만 이 막강한 권한이 소위 ‘갑질’에 활용되어서는 안됩니다. 앞선 모든 애자일 포스팅를 통해 설명했듯 스크럼 팀은 언제나 수평적인 관계 속에 유지되어야 하고 그 안에서의 의사결정 또한 투명하고 공정해야 합니다. 따라서 스프린트 리뷰에서도 PO는 스프린트에서 개발된 프로그램들의 시연에 진지하게 임하고 스토리 완료 요건에 부합하는지 면밀하게 검토해야 하며, 만약 미흡하다면 정당하게 보완과 수정을 요구해야합니다. 이 과정은 당연히 Scrum Master를 포함한 스크럼 팀원들과의 협의를 거쳐야 확정될 수 있습니다.

한가지 덧붙일 것은 스프린트 리뷰 세션에 들어오기 전에 PO와 SM, 그리고 팀원들이 수시로 개발의 방향성을 재확인하고 실제 개발 사항에 대한 피드백을 활성화해 일종의 Concensus를 스프린트 기간 중에 형성하는 게 더욱 생산적인 방법이라는 것입니다. 반대로 말해 스프린트 리뷰에서 모든 것을 다 확인하려고 한다면 스프린트 내 모든 스토리의 종료는 조금 어려워 질 수도 있습니다.

말그대로 스프린트 리뷰 세션은 개발이 예정되어 있던 프로그램들의 기능을 최종 확인하고 스토리를 종료시키는 협의의 기회로 삼는 것을 추천합니다. 마치 정상회담이 예정됐을 때, 각국의 공무원들이 실무적인 협의는 사전에 모두 완료해 놓고 실제 정상회담 시에는 국가 수반 사이에 가벼운 환담을 나누고 협정서에 최종 서명하는 ‘행사’ 로써 활용하는 것처럼 말이죠. 마찬가지로 스프린트 리뷰는 스프린트 중간중간 진행하는 ‘비공식’적인 협의를 최종적으로 확인하고 ‘공식화’하는 스프린트 말미의 ‘행사’로 삼는게 좋습니다.

스프린트 회고(Retrospective)하기

스프린트 회고(Retrospective)는 스프린트를 이루는 가장 마지막 세션입니다. 회고 세션 역시 모든 스크럼팀원이 참여해야 하며 스프린트를 되돌아보고 반성하면서 앞으로 어떠한 것을 바꿔야 앞으로의 스프린트가 더욱 효율적으로 진행될 수 있을 지 함께 생각해보고 공유하며 궁극적으로 합의를 이루는 세션을 일컫습니다.

그렇다면 회고 세션을 따로 정의해 두는 이유는 무엇일까요? 사실 스프린트 중간중간 이야기를 나눌 수도 있고, 리뷰 세션에도 시간이 있는데 말이죠. 그 이유는 회고라는 활동이 정례화된 소통을 통해 스크럼 팀의 유기성을 높이는데 매우 유용한 방법이기 때문입니다. 아래의 그림을 함께 보시죠.

여러 가지 회고 방식들이 있지만 가장 간단하고 직관적인 방식인 3L 방법을 예시로 가져왔습니다. 회고의 기본 방식에 따라 스크럼 팀원 모두가 참여해 짧은 시간동안(보통 30분 이내) 진행하게 되며, 스프린트 기간동안 개인적으로 느꼈던 좋았던 점(Liked), 부족했던 점(Lacked), 배운 점(Learned)을 각자 종이에 기입하게 하고 함께 이야기합니다. 이 과정을 통해 개인과 팀원 모두의 발전 측면에서 스프린트를 되돌아보고 개인적으로 혹은 팀원 간 협력 작업이 어떤 점에서 좋았는지 또 반대로 어떤 점을 개선하면 더 좋을 것 같은 지를 공유하게 되죠. 그러면서 팀원은 서로를 조금 더 이해할 수 있게되고 추후 불거질지 모를 갈등의 씨앗을 사전에 발견해 제거할 수도 있습니다.

중요한 것은 회고 세션을 가볍게 생각하고 생략하면 안된다는 점입니다. 회고는 스프린트를 마무리하면서 이를 반추해보고 각자의 느낌과 소회를 솔직하게 공유함으로써 팀이 앞으로의 프로젝트 진행을 조금 더 효율적으로 진행할 방법을 찾아낼 기회이기 때문입니다. 이에 더해 서로의 솔직한 이야기를 나눈다는 점에서 팀 내 소통에 있어서도 큰 역할을 한다는 점도 무시할 수 없습니다.

앞서 말씀드렸듯 3L 방법 외에에도 회고를 진행할 수 있는 방법은 다양합니다. 더 다양한 방법을 보고 싶은 분께서는 회고에 관한 포스팅과(“Sprint 리뷰 이후 회고(Retrospective) 방법” https://engineering-skcc.github.io/culture/agileretrospective/), Funretrospectives.com 홈페이지(http://funretrospectives.com)를 참조해 주세요.

마무리

우리는 지난 세 편의 포스팅을 통해 가장 많이 활용되는 애자일 Framework인 스크럼(Scrum)에 대해 자세히 살펴봤습니다. 스크럼은 조금은 모호할 수도 있는 그래서 적극적으로 활용될 수 없었을지도 모를 애자일을 우리가 프로젝트에 적용할 수 있도록 해 준 유용한 모델입니다. 상대적이지만 우리의 일감의 공수를 측정해 그를 바탕으로 스프린트 게획을 세우고, 다시 그를 기반으로 로드맵을 그릴 수 있도록 해주며, 마지막 큰 계획인 릴리즈 계획까지 이끌어 냄으로써 우리의 궁극적인 목표인 프로젝트의 완수, 고객이 원하는 제품을 만들어 낼 수 있도록 도와주는 거죠.

물론 애자일을 실용의 영역으로 내려주는 Framework이 스크럼만 존재하는 것은 아닙니다. 다만, 지난 세 편의 포스팅을 통해 스크럼을 자세히 다룬 것은 가장 많은 애자일 프로젝트가 차용한 Framework이기 때문이고, 또 애자일 Beginner가 가장 먼저 익혀야 할 Framework이라 생각하기 때문입니다.

아무쪼록 이번 스크럼 포스팅을 읽으시는 분들께서 애자일에 대한 생소함은 줄이고 이해도는 높이는데 도움이 됐으면 좋겠네요. 포스팅에 대해 궁금한 점이 있거나 수정이 필요한 부분을 발견하신 분께서는 아래에 댓글로 남겨 주시면 잘 살펴보고 답변을 드리도록 하겠습니다.

길게 이어진 글 읽으시느라 고생하셨습니다. 그럼 다음 포스팅을 통해 다시 뵙겠습니다. :)

관련 글

AGILE Framework - 스크럼(SCRUM) Basics (1) https://engineering-skcc.github.io/culture/scrumbasics1/

AGILE Framework - 스크럼(SCRUM) Basics (2) https://engineering-skcc.github.io/culture/scrumbasics2/