brunch

You can make anything
by writing

C.S.Lewis

by 번역하는 개발자 Sep 23. 2022

한국 개발자는 스크럼을 어떻게 하고 있을까? #1

스크럼과 플래닝 포커, 다른 사람은 어떻게 쓰고 있나 궁금해졌다.

제목은 창대하나 내용은 미약합니다.

이 글은 한국의 개발자는 스크럼과 플래닝 포커를 어떻게 쓰고 있나 궁금해서 설문을 돌려본 이야기입니다.

한국을 대표할 만큼 충분한 데이터는 아닌 관계로 이런 사례가 있구나... 하면서 참고만 해주시면 좋겠습니다.




대체 왜 난데없이 설문을?


최근 '출근했더니 스크럼 마스터가 된 건에 관하여'라는 스크럼 입문서를 번역했습니다.

원서는 'SCRUM BOOT CAMP THE BOOK'이라는 일본서인데요.

원서 현지에서의 아마존 평점 4.3

제가 번역을 할 때는 아무리 번역서라도 독자는 한국인인 만큼 한국 상황을 알 수 있게 현지화를 하는 편인데요. 이 책의 주제가 스크럼(scrum)이고, 작업량을 추정하는 방법으로 플래닝 포커(planning poker)를 안내하다 보니 한국의 개발자는 어떻게 쓰고 있나 궁금해졌습니다. 그걸 책 말미에 부록으로 담으면 좋겠다고 생각했죠. 물론 원서 저작권자의 동의를 구해야겠지만 그들도 분명 궁금할 거라 생각했습니다. 


크라우드 펀딩 진행 중인 스크럼 입문서 '출근했더니 스크럼 마스터가 된 건에 관하여'

텀블벅 크라우드 펀딩 프로젝트: https://tum.bg/x0ZhwI


저 자신도 스크럼을 익혔을 때 남들은 어떻게 하고 있는지 무척 궁금했던지라 이번 기회에 몇 가지 질문을 만들고 개발자가 모일만한 곳에 설문 요청을 해봤습니다.





설문 방법은 이러합니다


뭔가 통계학적으로 의미 있는 기법을 생각해보려다 그냥 페이스북에 물어보기로 했습니다.

설문 대상 집단은 다음과 같은 채널을 통해 모집했습니다.


페이스북 그룹 '코딩이랑 무관합니다만' (멤버 4.1만명)

페이스북 그룹 '생활코딩' (멤버 11.6만명)

페이스북 개인 타임라인  (친구 1.3천명 ㅜㅜ)


두 페이스북 그룹은 결이 좀 다르지만 다양한 연령대, 다양한 이력의 IT 업계 종사자가 모이는 곳이라 타깃으로 선정했습니다. 개인 타임라인에서 설문을 받은 건 페친 대부분이 이 바닥 사람이라 그들의 생각도 담고 싶었을 뿐 다른 의미는 없습니다. 

설문을 유도했던 전단지(?)





설문 결과는 놀랍게도! (빠밤)


무려 총 27명이 응답을 해주셨습니다. (음?)

페이스북 그룹 가입 멤버 수가 많긴 하나 사실 이런 설문에 피로감을 느낄 수 있기 때문에 어지간히 관심 있는 주제가 아니라면 응답을 얻어내긴 힘듭니다. 더구나 '애자일' 테마는 해리포터의 볼드모트처럼 사람들이 언급하길 꺼려하는 경향이 있죠. 


결국 통계학적인 인사이트를 얻기엔 설문 설계도 어설프고 데이터도 적다 보니 '오오.. 이것이 대한민국의 스크럼 활용 실태인가!' 하며 보기엔 무리가 많습니다.


(대충 샤아가 '이것이 연방의 모빌슈츠인가?' 하는 짤)


다만 데이터가 적다 보니 하나하나 살펴보며 응답자의 경험을 간접 체험할 수 있었는데요.

응답 내용 중에는 여러분도 공감하는 내용이 분명 있을 겁니다. 어떤 내용이 있었는지는 뒤에 상세히 살펴보시죠. 어쨌거나 통계학적인 의미를 뽑아내긴 어렵지만 자신의 경험과 비교해서 다른 사람은 어떻게 활용하고 있는지 엿볼 수 있는 참고 자료로 의미는 분명 있습니다.





설문 결과는 이렇습니다


질문 내용은 놔두고 응답 내용 중 1위인 것만 뽑아 나열했습니다.


나는 스크럼을 활용해봤고 앞으로도 쓸 것 같다: 44%

나는 플래닝 포커를 알지 못한다: 25.9%

우리 스크럼팀 개발자는 4명이다: 25.9%

나는 국내 스타트업 소속이다: 40.7%

내 역할은 개발자다: 44.4%

이 책은 현업 개발자 중 애자일 소프트웨어 미경험자에게 도움된다: 88.9%


다시 한번 말씀드리지만 총응답자가 27명이라는 점, 대상이 페이스북 개발 관련 그룹이라는 점을 감안해야 합니다. 같은 설문을 다른 집단을 대상으로 돌려보면 또 다른 결과가 나오게 되겠죠. 예를 들어 SI 회사 개발자가 많이 모이는 곳, 대기업 개발자가 많이 모이는 곳에서 설문을 받은 후, 집단별로 결과를 비교해보는 것도 재미있을 것 같습니다. 나중에 기회가 되면 다음에 한번 해보기로 하죠. 





설문 결과를 더 자세히 들여다봅시다


대체 뭘 어떻게 물어봤기에 저런 결과가 나오나 궁금하실 텐데요.

각각의 질문과 답변을 아래에 나열했습니다. 나라면 어떤 답을 했을까 생각하는 것도 재미있겠네요.

모든 질문에는 기본적인 보기가 있고 보기에 해당되지 않을 때는 자유 기재하게 했습니다.



Q1 

스크럼(scrum)은 칸반(kanban)만큼이나 많이 쓰이는 애자일 소프트웨어 개발 방식인데요. 여러분은 어떻게 활용하고 계신지요?


이에 대한 응답은 다음과 같았습니다.


활용해봤다. 앞으로도 쓸 것 같다. (44.4%)

"프로젝트 별로 각각의 담당자가 있다 보니 전체적인 일정이나 이슈 등 조율에 편리"
"유저와 맞닿아있는 서비스를 개발하는 조직이라면 적절한 방법론으로 생각됩니다. 적용해봤을 때, 데모/회고를 통해 업무에 대한 어느 정도의 마무리와 함께, 비개발직군의 구성원들에게도 서비스의 달라진 점을 브리핑하고 피드백받는 시간이 유용했습니다."
"현재 스타트업 CTO로 담당 부서(약 50명)에게 적용했고 전보다 훨씬 나아졌다는 피드백을 많이 받았기 때문 (물론 부임 이전의 개발 프로세스나 조직 구조에 문제가 많긴 했음)"
"작은 단위의 스프린트를 통하여 일이 지속적으로 잘 이뤄지는지 확인할 수 있고, 백로그를 살펴보면서 우선순위에 따라 엔지니어가 스스로 해야 할 일을 확인하고 일정관리할 수 있어 편리한 것 같습니다."
"팀원 의견 수용 및 고객사의 요구사항"
"소규모 스타트업에서 근무 중인지라 구성원 전체의 의견이 의사결정에 영향을 주는 편이다. 이때 스크럼은 서로의 업무와 생각, 일정을 빠르고 정확하게 알 수 있는 방법 중 하나라서 잘 활용하고 있는 편이다."
"프로젝트 이해관계자 사이에 공유할 수 있는 프로세스의 정립. 회사 차원에서 공유 가능한 작업 단위(유저 스토리)를 설정. PO팀이 프로젝트의 대략적인 마무리 기한이 언제인지 물어보는 경우, 대답하게 되는 일정이 사실 정확할 수 없음. 그렇기에 지켜질 일정도 아님. 나는 대략적인 일정으로 알고 ‘대략적으로’ 대답했는데, PO팀은 그 일정을 픽스된 일정으로 생각함. -> 에픽 하나가 진행되고 있는 퍼센티지 공유로 프로덕트 개발 진행도를 공유하고, 벨로시티 측정으로 에픽 완성 기간 예측 시스템을 구축하고 싶음."
"현재 회사에서 스크럼을 2주 단위로 계획해 데일리 스크럼을 진행하며 활용하고 있습니다. 스크럼을 통해 서로의 업무에 대한 세세한 파악이 가능해지고, 업무 속도와 업무량 조절이 빠르게 이뤄진다는 점. 또한 짧게 끊어 이뤄지는 스크럼을 통해 피드백이 빠르게 이뤄진다는 점이 장점이라 생각합니다."
"도입한 지 얼마 되지 않았습니다만, 짧은 주기로 목표를 갈아치울 수(?) 있어서 텐션 유지에 좋았기 때문입니다."


뭔지 안다. 기회가 된다면 적용하고 싶다. (25.9%)

"한 명이 아닌 여러 명의 멤버가 다 같이 참여하는 형식은 없었다."
"통찰력을 얻을 수 있다. 정보의 신속한 스크랩, 조합과 아이디어를 발전시키는데 군더더기 없이 빠르게 집중해서 진행되는 게 좋다"
"바둑에서는 정석을 배우고 잊으라 하더군요. 스크럼 역시 의도를 충분히 이해한 다음 나의 조직에 녹여내면 큰 효과가 있으리라 봅니다"
"이론으로만 접해봤기에 실무에서 정확하게 어떻게 사용해야 할지 좀 막막하네요."
"빠른 속도와 쉬운 피드백, 그리고 확실한 개발 내용 설정 등이 장점으로 존재하기 때문입니다."
"전 직장에서 다른 팀이 운영하는 것을 보았는데 기회가 된다면 적용하고 싶네요"
"IT기업에서 들어본 용어이다. 개발자분들이 쓰는 용어를 들은 적이 있으나 제가 직접 경험하진 못했습니다. 개발자분들이 스크럼 방식으로 일한다 들었고, 개발 요청사항을 말씀드릴 때 이번 스프린트에는 어려울 거 같다 이런 멘트로 들어본 적이 있습니다. 정확한 정의는 잘 모릅니다."


뭔지 안다. 기회가 되더라도 적용하고 싶지 않다. (7.4%)

"팀원 전원이 해당 기능에 대해 정통하거나, 혹은 리더가 해당 기술에 대해 잘 알고 제대로 적용할 줄 알아야 하나, 리더가 이름만 들어봤고 좋은 사례만 알고 있을 뿐, 제대로 하지 않고, 실무자도 이론만 알고 있을 뿐 실제로 실행할 수 있는 리더가 없다. 결국 업무만 과중되고 업무 효율성 향상은 전혀 기대할 수 없다. 물론 제대로 된 전문적인 지식이 있는 리더와 함께한다면 적용할 생각이 있다."
"이터레이션 자체는 좋으나 변동 사항이 많을 때 스크럼보다는 칸반이 자유로웠습니다."


뭔지 모른다. (7.4%)

"이름은 들어보긴 했는데, 배우거나 써본 적 없어요"
"애자일 방법론은 대충 아는데 스크럼 방식을 사용하지 않았다. 사용하더라도 오늘 하루 뭐했는지 다음에 뭐할지 정리해서 공유만 했다"


활용해봤다. 앞으로는 쓰지 않을 것 같다. (3.7%)

"작업 정의에 시간이 너무 많이 할애되는 경향이 있고, 프로젝트 초반에 작업을 구체화한다는 것도 어려움이..."


하고 있지만, 뭔지 잘 모르는 것 같다. (3.7%)

"회사에서 스크럼과 스프린트라는 명칭을 사용하며 일하고 있지만, 구성원들이 아직 애자일이 어떤 것인지 잘 모르는 것 같다. 스크럼은 그냥 회의시간이고, 데일리 스크럼은 데일리 업무보고 시간이며, 스프린트는 칸반과 차이가 없다."


데일리 스크럼만 사용한다. (3.7%)

"아직 스크럼에 방법론에 대해서 전문적인 경험이 없기 때문에 칸반에 데일리 스크럼만 사용하고 있습니다."


뭔지 알고, 활용해보려고 노력 중이다. (3.7%)

고객에게 가치를 주기 위한 방법으로 활용되는 것이 아니라 일정을 관리하기 위한 용도로 사용되어서 어렵습니다.


Q2

플래닝 포커(Planning Poker)는 작업량을 가늠할 때 쓰는 기법인데요. 여러분은 어떻게 활용하고 계신지요? (온라인 방식, 오프라인 방식 모두)


이에 대한 응답은 다음과 같았습니다.




뭔지 모른다. (25.9%)

"플래닝 포커는 처음 들어봐요."
"뭔지 모르겠다."
"잘 모르지만 경험자가 내는 견적이 유사하지 않을까 합니다."
"들어보지 못한 용어입니다."
"작업 및 일정은 별도의 중요도 평가 없이 간트차트로 관리 중이다. 플래닝 포커는 들어본 적 없으나, 괜찮다면 도입해봐도 좋을 것 같다는 생각이 든다."
"모름"
"처음 들었습니다."


뭔지 안다. 기회가 된다면 적용하고 싶다. (22.2%)

"이야기는 들었지만, 아직 써 본 적은 없다."
"개인적 체감량은 다른데, 통계를 내거나 혹은 나와 다른 수치라면 의견을 들을 수 있다."
"이 또한 제대로 실행되고 있는지 판단하기 어려워서 적용하지 못하고 있네요."
"다른 사람들의 의견에 영향받지 않고 온전히 자신의 의견을 펼칠 수 있기 때문입니다."
"각 이슈에 대한 대략적인 설계와 진행방향이 공유될 수 있는 시간이기도 한 것 같아서"
"알고는 있는데 쉽게 적용하기가 어려워서"


활용해봤다. 앞으로도 쓸 것 같다. (22.2%)

"일 크기를 팀 안에서 소통을 통해 정하고  다른 사람의 의견을 보고 다시 재조정하기에도 좋았습니다."
"플래닝 포커를 초기에는 진행하다가, 최근에는 시간이 많이 걸린다는 이유로 진행하지 않고 있음. 또는,  애초에 플래닝 포커에 의해 산정된 스토리 포인트가 의미 없다고 생각하는 구성원들이 있었던 때문이기도 한 것 같음. 또한, 구성원이 적은 경우(3-4명) 플래닝 포커가 의미가 없다고도 생각하는 분위기가 있는 듯 -> 그냥 그 자리에서 포커 과정 없이 몇 정도 될 것 같다고 사로 합의함. 그렇기에 플래닝 포커를 하지 않게 되었을 때 플래닝 포커를 해야 한다고 방어하는 사람이 없었던 것 같은 느낌. 플래닝 포커가 어느새 스토리 포인트가 아닌 man-day 산정으로 바뀜. (우리 회사에선, 스토리 포인트가 man-day임…) 어싸이니는 나중에 자원하여 설정하는 게 원칙이나, 스토리가 만들어지면 암묵적으로 누가 할지 알고 있게 되는 경우가 있음. 그래서 그 사람의 능력을 고려하여 스토리 포인트(맨 데이..)를 산정함."
"저희는 스토리 포인트라는 개념으로 활용하고 있습니다. 현재 시행착오도 겪는 중이지만, 작업량 가늠을 개개인이 미리 생각해보고 다른 팀원들과 비교도 해보며 결론적으로는 실력에 대한 메타인지의 향상으로까지 이루어진다는 점에서 큰 메리트가 있는 것 같습니다."
"빠르고 간편합니다. 서로 모르는 의견 차이를 드러낼 수 있습니다."
"업무 규모 추정은 어떤 일을 하건 매우 중요한 부분인데, 대략의 추정을 하고 계속 정교화하도록 주문하고 있음. 다른 방법에 비해 비교적 간단하고 설명하기도 쉬움"
"플래닝 포커를 통해서 다수의 의견을 반영하여, 일정이 얼마나 걸리는지를 대략적으로 산출할 수 있습니다. 이를 통하여 한 스프린트를 적정 업무량으로 유지할 수 있습니다."


활용해봤다. 앞으로는 쓰지 않을 것 같다. (11.1%)

팀원의 역량에 따라 공수 산정이 들쭉날쭉
"모든 팀원이 해당 업무를 충분히 이해하도록 매번 업데이트를 해줘야 합니다. 결과는 이상적이나, 시간/정신적 비용이 많이 들어 고민입니다."


"처음에는 정해진 값들을 선택하는 방식(범위의 숫자가 아니라 1 3 5 8과 같이 임의의 숫자)이었는데, 우리의 맨 데이가 파악되지 않은 초기여서 그런지 실제와 많이 달랐고, 현재는 범위 안에서 1점을 1시간으로 하는 선택 방식을 사용 중"


활용해봤다. 기회가 되더라도 적용하고 싶지 않다. (7.4%)

팀원의 역량에 따라 공수 산정이 들쭉날쭉
"우선 태스크를 산정하는 것부터가 굉장히 어렵다. 경험이 적은 기획자 아니 설사 경험이 많은 PM이라도 완벽하게 태스크를 산정하는 것은 쉽지 않다. QA에서부터 적용된다면 모를까, 프로덕트를 만드는 초기부터 협업까지 테스크를 덩어리로 나누거나 아예 턴키로 작업하는 데에 익숙한 문화를 바꾸는 것은 쉽지 않다."
이건 익숙해지는데 시간이 걸릴 것 같다


활용은 했고 필요하나 운영의 문제가 있었다. (3.7%)

"특정 팀원들의 성향에 따라 특정 업무에서는 공정성 부여가 올바르지 않았다."


알지만 활용하지 못하고 있다. (3.7%)

"업무를 진행하는 사람이 해당 업무에 다하여 잘 알고 있기에 일정이 그분에 의해 결정이 되어버립니다."


간단하게 이해는 하고 있다. (3.7%)

"간단하게 이해는 하고 있지만 정말 필요한 부분인지 모르겠다. 하지만 이런 측정은 필요할 것 같다"



Q3

내가 속한 스크럼팀, 혹은 내가 본 스크럼팀은 개발자가 몇 명인가요? (프로덕트 오너, 스크럼 마스터 제외)


이에 대한 응답은 다음과 같았습니다.

4명 (25.9%), 5명 (22.2%)
9명 (11.1%), 내가 스크럼을 하지 않고, 주변에 스크럼 하는 팀을 본 적이 없음 (11.1%)
6명 (7.4%), 7명 (7.4%), 8명 (7.4%)
3팀을 운영 중이고 각 팀은 6, 5, 5명으로 구성 (3.7%), 6명 데일리 스크럼만 진행해보았음 (3.7%)



Q4

여러분은 어떤 조직에 계신가요?


이에 대한 응답은 다음과 같았습니다.

국내 스타트업 (40.7%), 국내 중소기업 (25.9%)
국내 대기업 (18.5%), 프리랜서 (11.1%)
해외 기업 (3.7%)




Q5

스크럼팀에서 여러분의 역할은 무엇인가요?


이에 대한 응답은 다음과 같았습니다.


개발자 (44.4%), 프로덕트 오너 (14.8%), 스크럼 마스터 (11.1%), 이해관계자 (7.4%)
스크럼 써본 적 없어요. (3.7%), 스크럼을 하지 않으나 만일 한다면 개발이나 중재를 맡을 것 같습니다. (3.7%), 이제 스크럼을 도입하고 싶어 하는 오너 (3.7%), 프로젝트로 모일 때가 많으므로 역할은 보기를 통틀어 다 일 때가 많다. (3.7%), 하지 않습니다. (3.7%), CTO. 프로세스와 조직 구조를 정하고 애자일 방법론을 적용하도록 전반적인 안내를 하고 있음 (3.7%)



Q6

'출근했더니 스크럼 마스터가 된 건에 관하여'는 일본의 스크럼 커뮤니티에서 축적된 사례와 경험이 한 권의 책으로 정리된 책입니다. 스크럼을 처음 도입하는 팀원이 겪는 에피소드를 만화와 해설로 풀어쓴 어쩌면 내 경험담 같은 이야기인데요. 국내의 잠재 독자 중에서는 어떤 분에게 도움이 될까요?


이에 대한 응답은 다음과 같았습니다.

현업 개발자 (애자일 소프트웨어 개발 미경험자) (88.9%)
현업 개발자 (애자일 소프트웨어 개발 경험자) (59.3%)
예비 개발자 (학생, 일반인) (48.1%)
비개발자 (퍼실리테이터, 기획자, 관리자, 부서장, 임원,...) (48.1%)
PO들이 많이 볼 것 같아요. (3.7%)
제가 딱 출근했더니 스트럼 마스터가 된 케이스라서 감정이입이 많이 되네요. 꼭 좋은 책 내주셔서 저희 조직의 스크럼이 보다 잘 진행될 수 있도록 도움을 부탁드립니다. (3.7%)
모여서 어떤 발칙한 일을 작당해야 한다면, 모두에게 도움 되고 필요할 것 같아요. (3.7%)



설문을 마치며


한국을 대표하는 설문은 아니지만 현장에서 스크럼과 플래닝 포커를 어떻게 경험하고 계신지 엿볼 수 있는 좋은 기회였습니다. 응답 주신 27분 중 15분에게는 약속대로 12/1에 출간될 도서 '출근했더니 스크럼 마스터가 된 건에 관하여' 1권씩을 드릴 예정입니다. (무려 56%의 확률!)

만화 반, 해설 반으로 설명하는 스크럼 입문서 '출근했더니 스크럼 마스터가 된 건에 관하여'

이제까지 긴 글 봐주셔서 감사합니다. 

어설프게 시작한 설문이지만 누군가에게는 도움되는 자료면 좋겠습니다. 

현재 설문 데이터로는 책 부록에 넣긴 역부족인지라 책 완성 전까지 다른 그룹에 설문을 더 해서 데이터를 모아볼까 생각 중입니다. 


혹시 준비 중인 이 책이 궁금하다면 크라우드 펀딩에 참여해보시는 건 어떨까요? 

서점에서는 보기 힘든 다양한 굿즈가 패키징되어 있습니다. :)

텀블벅 크라우드 펀딩: https://tum.bg/x0ZhwI






다른 출판사가 잘 내진 않지만 하나쯤 있으면 좋겠다는 책
1인 출판 프로젝트 ZZOM이 만들어 보겠습니다. 


작가의 이전글 그렇게 불평하더니 결국 idus에 입점을 했다
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari