일을 더 잘하기 위한 애자일(Agile) 실천
현재 근무 중인 회사(원티드)에서 제가 소속된 스쿼드(이하 SQ)가 더 높은 수준의 제품을 만들어내기 위해 시도했던 몇 가지 시도를 공유해보려고 합니다. 애자일 실천이라는 제목을 사용했지만 애자일을 실천해보기 위해 이 방법들을 선택했다기보다는 더 일을 잘할 수 있는 방법이 뭐가 있을까 고민하는 과정에서 이미 나와있는 방법 중에 우리에게 맞는 방법들을 골라서 사용 중입니다. 각 팀이나 상황에 맞는 옷을 고르는 게 중요한 것 같습니다.
데일리 스크럼 Daily Scrum
출근을 하면 가장 먼저 Daily Scrum(이하 데일리 스크럼)을 진행합니다. 데일리 스크럼은 업무의 진행 상황을 업데이트하고 그 과정에서 각 구성원이 겪고 있는 어려움을 해결해 주거나 도움을 줄 수 있습니다. 다 같이 모여 얼굴을 보면서 진행하는 게 중요합니다.
일방적인 보고의 형식이 아닌 마치 커피 한 잔을 마시면서 어제 있었던 일, 오늘 할 일과 일을 진행하면서 겪는 어려움, 고민 등을 주어진 시간 동안 편하게 나누는 방식이라고 할 수 있을 것 같습니다. 15분이라는 시간을 정해서 진행 중이며 보다 깊이 있는 대화가 필요한 경우에는 데일리 스크럼이 마무리되고 따로 시간을 잡아 추가로 이야기를 진행하고 공유합니다.
매일 아침 얼굴을 보고 이야기를 나누는 것의 중요성은 뒤에 이야기할 회고를 진행하는 데 있어서도 아주 큰 도움이 됩니다.
User story 작성 및 Story Point 산정
기존에는 작업 진행 전에 화면 단위, 혹은 데이터 단위로 서버/프론트 개발자가 신규화면 UI 작업, API 연동 등의 이름으로 Jira에 이슈 단위로 생성을 했었는데요, 현재는 방식을 바꾸어 User Story에 기반하여 Story 작성 후에 하위 작업으로 각 담당자가 기술적인 관점으로 각 이슈를 생성합니다.
일단 기존 방식으로는 개발 지식이 부족한 사람의 관점에서 해당 작업이 완료되었을 때 어떤 수준으로 기능이 추가되거나 제품이 완성되는지 추정하기가 어렵지만 보다 자연어에 가까운 형태로 작성되는 Story를 사용할 경우, 비 기술적 직군의 협업자들도 업무의 우선순위를 산정하는데 협력하기 쉬워집니다.
Story Point는 각 스토리별로 점수를 매기는데요. 주로 서버/프론트엔드 개발자, PO 세명이 모여서 플래닝 포커 앱을 이용하여 산정합니다. 이 과정에서 각 담당자가 바라보는 스토리에 대한 관점, 작업량 등이 측정되고 데이터가 쌓이면 각 스프린트별로 얼마의 스토리 포인트가 해결 가능한지 평균을 알 수 있어 추후에 일정 산정에도 용이합니다. 덧붙여 각 스토리에 대해 논의를 하면서 서로의 업무에 대한 이해가 높아지는 장점이 있습니다.
Retrospective
제가 가장 좋아하는 시간 중에 하나인 회고입니다. 타임라인 회고 방식으로 진행하고 있으며 스프린트의 마지막 날 오후에 진행합니다.
스프린트를 진행하면서 서로가 잘한 점에 대해서는 보다 격하게 칭찬하고 아쉬운 점, 어려운 점에 대해서는 비난보다는 개선을 위한 방향으로 편하게 논의하여 다음 스프린트를 위한 액션 아이템으로 지정합니다. (액션 아이템은 이후 스프린트에서 실천 여부를 추적하고 관리합니다.)
예전 입사 후에 처음 회고할 때가 생각나는데요. 생각보다 여러 명이 모인 자리에서 누군가를 칭찬하거나 아쉬운 점을 이야기하는 게 쉬운 일은 아니었습니다. 칭찬 혹은 고마운 마음을 표현하는데 익숙하지 않았고 분명 좋은 의도로 아쉬운 점을 이야기했음에도 상대방이나 제가 비난으로 받아들여 마상을 입었던 적도 몇 번 있었죠. 이런 점을 개선하기 위해서는 습관이 중요한 것 같습니다. 면대 면 칭찬이 어렵다면 Slack이나 Jira 등 업무툴에서 긍정 Emoji를 다는 것부터 시작하면 도움이 됩니다. 그다음에는 댓글 등으로 누군가를 칭찬하는 겁니다. 칭찬을 하다보면 면대 면 칭찬이 보다 자연스러워지는 순간이 오더라고요.
그리고 무엇보다 어렵고 조심스러운 건 절대 상대방을 비난하지 않는 겁니다. 상호 신뢰가 중요하다고 생각합니다. 저는 데일리 스크럼 시간이 많은 도움이 되었습니다. 데일리 스크럼을 통해 매일 아침마다 얼굴을 마주보며 대화를 하다보면 그 사람의 말하는 성향 등을 알 수 있고 서로 적응할 수 있습니다. 업무를 진행하면서 겪는 어려움, 고민 등에 대해 나누고 도와주다 보면 상호 신뢰를 형성하는데 큰 도움이 되는 것 같습니다.
위의 방법 이외에도 Sanity Test에 대해 추가적으로 이야기하겠습니다.
Sanity Test
Sanity Test라는 용어가 낯설어서 찾아본 적이 있는데요. 현재 스쿼드에서 진행 중인 Sanity Test는 Smoke Test와 Sanity Test의 중간 형태를 띠고 있는 것 같습니다.
QA 분이 작성한 Sanity Test TC를 기반으로 수행하며 Sanity Test를 통해 95% 이상의 항목이 Pass가 되어야 보다 엄격한 단계의 테스트로 넘어가게 됩니다. 엄격한 테스트를 진행하기 전에 제품의 합리성을 검증하여 QA 분들이 엄격한 테스트를 진행할 때 시간과 노력을 낭비하지 않기 위한 검증 단계로 사용 중입니다.
처음에는 서버/프론트엔드 개발자 2명이 수행하였으나 PO, 제품 디자이너 분도 참여하여 보다 다양한 시각에서 검증하고 있습니다. 같은 테스트 케이스를 수행하더라도 직무별로 발견하는 버그의 양상은 미묘하게 다른데요. 이런 점을 활용하기 위하여 보다 다양한 직무의 사람들이 테스트를 수행하여 최소한의 검증을 거치게 됩니다.
P.S.
평소 생각을 notion에 정리하고 있는데요. 막상 블로그에 작성하려고 하니 쉽지가 않네요. 2020년에는 스스로를 더 다그치기 위해 주변 지인들과 한 주에 포스트 하나 쓰기 스터디를 시작했습니다. 이 글이 첫 시작이네요. 주로 제가 일을 하면서 배운 점, 공부한 것 그리고 트러블 슈팅에 대한 글을 적어나갈 예정입니다. 부디 매주 잘 실천하기를 저에게 바랍니다.
