곰개발자
2019-12-14 14:56:57 작성 2019-12-14 15:06:45 수정됨
8
2927

스크럼에 대한 단상


외국에서 스크럼 마스터로 한 2년을 보내면서 느낀 점과 배운 점을 정리해 보았습니다.


- 최소 20퍼센트 이상은 스프린트 마다 기술적 부채를 해결하기 위한 스토리들을 포함시킵니다. PO와의 합의가 중요합니다. 어느 회사에서나 기술적 부채는 쌓이다 보면 손댈 수 없는 지경이 오게 됩니다. 이 기술적 부채 스토리들은 개발자들의 권한입니다.

- 제품 스토리와 기술적 부채 스토리는 epic으로 관리해도 괜찮습니다. 

- Backlog grooming은 스프린트 중간에 2-3번 정도 미팅을 통해 미리 하는 것을 추천합니다. 미리 스토리들을 Break down할 수 있고, 스프린트 시작전에 요구사항의 정확한 이해가 가능합니다. 

- 스토리 작성은 정확한 요구사항, Acceptance criteria와 Definition of done이 중요합니다. 요구사항과 Acceptance criteria는 PO로 부터 나오고, 나머지 항목들은 개발자들이나 QA가 작성할 수 있습니다. QA가 정확한 테스트 케이스를 gherkin grammer로 스토리 내에 포함시켜 놓으면 활용도가 좋습니다. 정확한 테스트 케이스를 개발자가 이해하거나, BDD를 한다면 나중에 acceptance test를 만드는데 도움이 됩니다.

- 스토리의 Sub tasks를 세부적으로 break down하면 일의 진행과정이나 스토리의 이해도가 훨씬 높아집니다.

- 개인적인 경험으로 한 스토리에서 한사람이 일해야 할 양이 7일을 넘어가면 스토리를 2개나 3개로 나누는 걸 추천합니다. 스토리의 사이즈가 크다보면 스프린트의 진행사황을 파악하기가 좀 힘듭니다. 

- 스탠드 업 미팅에서는 swimlane을 회의실에서 빔프로젝트로 보여주면서 하는 걸 추천합니다. 예를 들어 개발중, 코드 리뷰, 테스팅, 배포같은 lane들을 부가적으로 만들어주고 한눈에 볼 수 있게하면 좋습니다. 스탠드 업에서 가장 중요한 항목은 내가 무슨 어려움을 겪고 있고, 무엇이 Blocking issue인지 말하는 것입니다. 그러면 다른 Senior 개발자들이 도와줄 수 있습니다. 스프린트 내에서 개발 속도의 변수는 어려운 이슈를 재때 공유하지 않아서 발생하는 일이 많습니다. 스탠드 업은 최대 10분 이상을 넘지 않는 것을 추천합니다. 

- 가능하다면 설계 문서 링크를 스토리에서 포함시키는 것을 추천합니다. Wiki를 회사에서 사용한다면 링크 공유를 해서 항상 찾기 편하게 할 수 있습니다. 

- 2명이 적어도 10일 정도 해야 되는 일이 시작되었다면 그 이전에 Technical design 스토리를 만들어서 Architecture 설계 할 수 있는 시간을 별도로 가져야 합니다. 일종의 Architecuture review입니다. 이건 모든 팀원들이 다 같이 참여하면 좋습니다. 기술적 부채가 생기는 것을 막아줍니다. 

- Time tracking은 중요합니다. 모든 직원들이 스토리마다 시간을 얼마나 투자했느냐는 underestimate 나 overestimate 되었는지에 대한 판단이 가능합니다. 나중에 스프린트 Capacity를 파악하는데도 큰 도움이 됩니다. 퇴근전에 Time을 logging하는 건 1분도 채 걸리지 않은 일입니다. 그러고 나중에 큰 백데이터를 얻게 됩니다.

- 스토리가 완료되지 않는 것은 Close하지 않고 다음 스프린트로 넘깁니다. 스토리 포인트는 변경하지 않고, time tracking을 계속 진행하면서 얼마나 시간을 썼는지 나중에 확인할 수 있고, 이력이 한 스토리에 남아서 나중에 스토리에 대한 요구사항을 찾기도 용이합니다. 

- Burndown chart를 개발자들이 항상 볼 수 있는 곳에 화면으로 보여주는 것도 서로의 목표지점을 공유하는데 좋은 툴로 활용될 수 있습니다. 

- Scrum은 민주적인 프로세스입니다. 모든 의사 결정은 모든 개발자의 동의를 얻어야 하고, Deadline이 있어도 요구사항의 Scope만 변경될 뿐 PO가 story points에 개입하는 일은 절대 없습니다. 

- Backlog grooming을 이상적으로 잘 하고 있으면 sprint  planning때는 시간이 생각보다 적게 듭니다. 

- PO는 요구사항에서는 절대적이지만, 개발과정에서 모순이 있을 경우에 수정을 요구하는 것은 개발자의 몫입니다. 이슈를 제기할 수 있는 문화가 스크럼에서도 중요합니다. 

- 경험상 3 ~ 8명 정도 규모에서 스크럼이 잘 돌아가는 것 같습니다. 그리고 스프린트 주기는 2주가 적당합니다. 하지만 이것도 회사나 프로젝트의 특성상 바뀔 수 있습니다.

- Sprint review는 팀원끼리 돌아가면서 presentation을 만들고 발표하는 것을 추천합니다. 보통은 Burndown chart나 스토리의 완료나 진행상황, 데모를 보여주면 좋습니다. 스토리를 맡았던 개발자가 직접 데모하는 것을 추천합니다.

- Retrospective 즉 회고는 스프린트의 마지막에 하고, 개인적으로는 매우 중요한 과정이라고 생각합니다. 스프린트 초기에 Trello같은 Board를 전 팀원이 볼 수 있게 공유하고, 스프린트 중간에 생각날때마다 무엇이 잘 되었는지 무엇이 잘 안되었는지 작성합니다. 포인트는 특정 대상을 비난하는 목적이 아닌, 합리적으로 개선을 어떻게 해야할지 작성하는 것이 중요합니다. 잘 안된 항목들에서 댓글로 투표를 해도 되고, 개선해야 된다는 분위기가 만들어지면 토론을 통해 Action items를 만들고 어떻게 개선시킬지 작성합니다. 이전 스프린트 Action items를 체크해서 개선 안된 것은 현재 Trello로 옮겨서 다시 remind해 주는 것도 도움이 됩니다. 실제 기술적 부채로 해결해야 할 일이면 스토리를 작성해서 다른 스프린트에서 실행하도 됩니다. 

- 모든 팀원들이 active하고 프로세스를 정확히 이해하고, 스토리 작성에 적극 협조하면, 스크럼 마스터는 사실 필요 없습니다. 스크럼 마스터는 팀을 리드하는 역할이 아니기 때문입니다.

6
4
  • 댓글 8

  • 박가사탕
    2019-12-14 16:31:19

    매우 어렵고.. 이해도 안되네요 ㅎ

    0
  • fender
    17k
    2019-12-15 08:30:51 작성 2019-12-15 08:34:51 수정됨

    좋은 글 감사합니다. 여기선 스크럼이 자주 언급되지 않고 편견을 가진 분들도 자주 보이는 터라 스크럼을 직접 운영하신 분의 경험을 공유하는 글이 반갑네요. 개인적으로 궁금한 내용 몇 가지를 질문 드리고 싶습니다.

    우선, 스토리 포인트를 피보나치 수열로 쓰는 건 아직도 널리 쓰이는 관행인가요? 전 소규모 조직에 스크럼의 일부 관행을 선별적으로 적용하고 있는데 피보나치 포인트에 대해선 쓰면서 유용성에 다소 의구심이 들더군요. 혹시 단순한 1, 2, 3, 4와 같은 수열로 대체한다면 문제가 있을까요?

    가끔 스크럼이 경영진이 개발자를 압박하는 수단으로 악용되는 사례를 듣는데, 그런면에서 스토리 포인트는 기본적으로 개발자가, 스코프와 우선순위는 PO가 담당한다는 건 중요한 내용이라고 생각합니다.

    단지 개인적으로 스크럼은 전반적으로 비즈니스적 고려를 담당하는 팀원에 비해 개발 책임자의 역할이 다소 부실하게 반영되어 있다는 느낌을 받습니다.

    스토리 포인트 설정의 경우도 제가 읽어본 문서들은 대부분 기술적 난이도 보다는 비즈니스적 중요성을 기준으로 삼는 것을 추천하더군요.

    설사 기술적 내용을 고려한다 해도 예컨대 특정 개발자가 스토리 포인트를 과다하게 부여하는 경향을 보인다던지, 아니면 당장 비즈니스적 가치로 환산되지 않거나 그 연관관계가 기술적 지식이 없이 이해하기 힘든 스토리의 우선 순위를 두고 이견이 생긴다던지 하는 경우 어떤 방식으로 의견을 조율하는 것이 일반적인지가 궁금합니다.

    특히 스크럼에는 PO에 상응하는 개발 쪽 입장을 대변하는 역할을 정의하지 않기 때문에 언급한 성격의 문제를 조율하는 측면에 대해선 딱히 정의하는 프로세스가 없다는 점이 다소 의아하게 느껴졌습니다.

    혹시 이런 부분에 대해서 경험하거나 생각하신 부분이 있으시다면 의견을 부탁드리고 싶습니다.


    0
  • 곰개발자
    2019-12-15 13:15:01

    @fender

    질문 감사드립니다. 

    스토리 포인트의 경우, 저는 여러가지를 많이 사용해 보았습니다. 피보나치 실제 카드를 사용하기도 해 보았고, 스크럼 앱을 모든 개발자가 설치해서 보여주면서 해보았고, 계산기 앱으로 1, 2, 3, 4, 5와 같이 단순한 숫자로 해보았습니다. 사실 결론부터 말하자면 어떤 선택을 하시던 상관 없다는 것이 제 생각입니다. 저는 단순한 숫자를 지금 사용하고 있습니다. 상황에 따라 개발자마다 포인트가 엇갈릴 경우, 1.5나 2.5를 사용하기도 합니다. 팀원들의 의견에 따라서 다수가 그걸 동의하면 어떤 선택을 해도 괜찮아 보입니다. 하지만 기본적으로 7 story points ( 1사람이 1일동안 개발해야 한다는 가정 ) 가 넘어가면 스토리를 분리하는 걸 추천합니다. 

    한국 회사에서만 일하다가, 처음 외국 회사에서 일을 했을 때 적응이 잘 안되었던 부분중에 하나가 개발 책임자나 프로젝트 관리하는 사람이 없다는 것입니다. 모든 외국회사가 다 그런건 아니지만, Technical architecture를 설계하는 사람이 없고, 책임이 불분명 하다는 것입니다. 제가 일해왔던 한국적인 방식이라면 책임자가 모든 설계를 관여하고 Top-down으로 일을 해 나가는데, 특정 책임자가 프로젝트를 관리하거나 설계를 하면 그것은 이미 스크럼이라고 말하기가 힘이 듭니다. 관리를 받기 시작하면 이미 스크럼의 본질을 잃습니다. 본질은 Sprint planning때 했던 모두의 약속 그리고  Burndown chart로 보여지는 현재의 그래프가 지금 현 상황을 보여줄 뿐입니다. 

    이 말인 즉슨, 속도는 조금 느리지만 Architecure를 설계하는 스토리가 별도로 있어야 하고 그 스토리의 Acceptance criteria는 실제 설계, 회의, 문서 작성, 피드백 반영, 모든 팀원의 공유까지 같이 포함되어 있어야 합니다. Senior engineer가 이 스토리를 Lead 해야 하는 것이 좋고, 다른 Senior들의 Feedback을 같이 반영하는 것이 굉장히 중요합니다. 다른 팀 사람들에게 리뷰를 맡기는 것도 도움이 됩니다. 그래서 제가 생각하는 스크럼에서는 기술적인 책임은 개발자 모두의 몫이 되는 것입니다. 이게 장단이 있는 부분입니다. 책임이 분산되면 아무도 책임을 지지 않는 다는 것. 사실 회사내에 팀원들의 적극적인 동참의 문화로 극복되어 져야 하는데 이게 사실 쉽지 않은 부분이긴 합니다. 

    비즈니스와 기술에 관한 내용은 제 경험상으로 75:25를 추천합니다. PO는 제품을 빨리 개발해서 빨리 출시하기를 항상 바랍니다. 깨진 유리창이 생긴다고 하더라도 개발자들의 꼼수로 인한 코드로 점점 기술적인 빚이 쌓이게 되죠. 

    예를 들어 5명의 개발자가 2주동안 개발한다고 했을 때  5 * 10일 = 50 story points. 

    거기서 한 스프린트에 80% 정도만 Capacity에 포함시켜 주는 걸 추천합니다. 왜냐하면 회사에서 주간회의나 일반적으로 있는 일정때문에 하루를 다 쓰지는 않거든요. 50 story points * 0.8 = 40 story points. 

    75:25로 봤을 때 30 story points는 PO가 원하는 기능. 10 story points는 개발자들이 평소에 개선시키고 싶었던 기술적인 Tasks들을 포함시키는 것입니다. 여기서 어떤 예외도 없이 스프린트 마다 이 10 sotry points는 개발자들의 권한이 됩니다. 개발자들이 우선순위를 정하고, 어떤 걸 빨리 개선시켜야 할지 논의하고 우선순위를 정할 수 있는 거죠. 이건 제가 2년 넘게 하면서 깨달은 사항인데, PO는 나의 Architrecture의 Refactoring이 어떤 제품으로써 장점을 가져오는지 마음에 와닿지 않습니다. 기술적 부채를 해결한다는 건 유지보수를 용이하게 해주겠다는 것인데 그것이 PO의 관심사는 아니죠. 

    75:25의 합의는 회사내의 경영진과 PO의 동의가 필요합니다. 그리고 부채를 해결해 나가고, 기술적인 framework의 개선을 꾸준히 한다는 회사 문화로서 굉장히 중요한 일이기도 합니다. 특정 기능을 개발하기 위해 특정 framework의 반영이 필수적이라고 생각하면 25 내에서 하시면 됩니다. 이 방법이 대부분 PO에 상응하는 개발 쪽 입장에 대한 해결책으로 사용 될 수 있습니다. 하지만 PO나 개발자들 사이에서 Shortcut으로 가기 위해 기술적 부채를 코드 안에 넣는 행위는 피하셔야 되고, 이걸 수정하기 위해 나중에 2배 이상의 시간이 소모 된다는 것에 대해 어필하셔야 하고, 논쟁을 통해서라도 막아야 합니다. 

    개발 설계에 대한 논쟁이 있을 경우는, 별도의 스토리를 만들어서 진행하고, 1, 2, 3 안과 같이 옵션을 통해 어떤 장단이 있는지 설계 스토리를 담당하는 Senior가 전 팀원에게 보여주면서 논란을 해결하는 것도 많은 도움이 됩니다. 

    개발자가 스토리 포인트를 많이 부를 경우는, 보통 왜 그렇게 생각하는지에 대해서 질문하고 논의합니다. 제일 많이 부른 친구와 제일 적게 부른 친구에게 왜 그런지 물어보고 그게 합당한지 팀원들에게 다시 물어보고, Estimation을 다시 함으로서 그 격차를 줄여갑니다. 사실 문화적인 부분은 굉장히 접근하기가 힘이 듭니다. 스크럼이라는 것 자체가 너무 민주적인 방식이고 보기에 느리다고 생각하기 때문에 많은 반감이 있긴 하지만, 의사 결정 과정에서 모든 사람들이 인지하거나 동의하고 넘어가고 이것이 우리의 일이라는 것을 차츰 느끼기 시작하면 이전에 수직적인 사고방식의 단점보다 낫다는 것에 분위기가 바뀌게 됩니다. 

    마지막으로 가장 중요한건, 회사에서 스크럼을 일정의 압박 수단으로 하려는 조짐이 보이면 이 스크럼을 하지 않는 것을 추천합니다. 국내 특성상 이 경계가 가장 애매하고, 관리하는 사람들의 특성상 무언가 쪼아야지 된다는 욕구가 일어나는 건 사실이긴 합니다. 여기서 인내를 가지고 기다려 보자는 일종의 합의는 스크럼 마스터의 역할일 수도 있습니다. 






    0
  • fender
    17k
    2019-12-15 13:34:05

    상세한 답변 감사드립니다. 사전 협의에 의해 개발자들이 자유롭게 사용할 수 있는 스토리 포인트를 미리 예비해놓는 건 생각하지 못했던 방식인데 괜찮은 대안인 것 같습니다.

    아키텍쳐 같은 기술 주제에 대한 스토리를 만드는 것은 저도 그렇게 하고 있기는 하지만 항상 의구심이 드는 내용이었습니다.

    스크럼에 대한 일부 사이트나 문서에서는 스토리 포인트는 철저하게 비즈니스/고객 관점으로 작성할 것을 권장하면서 대략 '최종적으로 비즈니스 가치로 설명할 수 없는 기술 개선은 필요없는 것이다'라는 정도의 논리를 펴는 경우가 있더군요.

    원론적으로 틀린 말은 아니라고 생각하지만서도, 과연 기술은 모르는 PO가 기술적 부채의 누적이 향후 구체적으로 얼마나 비즈니스에 영향을 줄지 고려해서 스코프나 우선순위를 정할 수 있을 것인가라는 부분에서 좀 회의가 들더군요.

    그런 점에서 말씀대로 예컨대 25%의 스토리 포인트는 개발팀이 자율적으로 활용할 수 있다면 적어도 그런 문제를 완화할 수는 있을 것 같습니다.

    다만 앞으로 '스크럼 2.0'이라도 등장한다면 그런 측면에 대해 좀 더 명시적인 프로세스를 제시했으면 좋겠다는 생각도 듭니다.

    한편, 스크럼을 성공적으로 도입하기 위해서는 경영진의 이해와 전폭적인 지원이 전제되어야 한다는 점은 저 역시 전적으로 공감합니다. 단지 그런 일이 과연 예컨대 국내 SI 프로젝트 환경에서 쉽게 가능할 것인가 하는 건 여전히 오랜 시간 어려운 숙제로 남을 것 같긴 합니다.

    다시 한 번 좋은 글과 답변 감사드립니다.

    1
  • 인절미후후
    654
    2019-12-25 14:56:28

    스크럼 역시 재밌는 개발방법론이죠 정답인지 아닌지는 아직 잘 모르겠지만 좋은 길잡이라고 생각합니다.


    피보나치 수열 같은 숫자로 정하는 이유는 일정 이상 숫자가 커지면 예측하기가 어렵기 때문이라고 생각합니다.

    그럴경우 결국 해당 스토리는 분할이 필요하다는 판단이 되는거죠.

    아시겠지만 스토리 포인트 란것은 결국 규모를 유추해 내는데 필요한 서로간의 합의 의견일치 수단일뿐 정량적인 구체적 숫자는 아닌것으로 이해하고 있습니다.


    gherkin grammer 이라는 단어를 처음봐서 검색해봤네요.

    CucumberStudio 라는 프로젝트에서 자주 사용되는 용어 같은데.

    아마 밑의 뜻이 맞는거 같네요.

    Gherkin is a plain-text language with a little extra structure. Gherkin is designed to be easy to learn by non-programmers, yet structured enough to allow concise description of examples to illustrate business rules in most real-world domains.

    https://support.smartbear.com/cucumberstudio/docs/bdd/write-gherkin-scenarios.html

    0
  • javaing
    2k
    2020-01-08 23:16:06

    멋진 글 공유 감사합니다. 한 가지 궁금한게 있는데 25% 보다 시간이 더 필요한 tech debt들을 처리 할 땐 어떻게 핸들 하시나요? 당연히 PO 입장에선 기능적으로 변화가 없기 때문에 그 이상 할애해주기 싫어할텐데, PO와 합의해서 특정 스프린트만 tech debt의 비중을 높이는 쪽으로 가는건가요?

    저는 개발자의 입장에서 느끼는게 시간이 지남에 따라 tech debt이 점점 늘어나는것에 비해 너무 적은 할당량을 가지는것 같아 살짝 불만입니다. 

    0
  • 곰개발자
    2020-01-09 10:17:18
    @javaing
    질문 감사합니다. 일단 tech debt이 늘어나서는 안됩니다. 늘어나는 추세를 보이면 팀 내에서 잘못하고 있는 것입니다.
    예를 들어, legacy api에서 새로운 rest api로 변환하는
    작업이 있다고 했을때 코드 리뷰에서 걸러주어야 합니다. 누군가 계속 legacy api을 수정하지 않도록 해야합니다. Tech debt이 쌓이는 것이거든요.
    어떻게 PO와 이야기를 해야 하느냐, 이 해당 기능을 수정 하기 위해서는 새로운 api를 개발해야 한다. 그러기 위해서는 며칠의 지연이 발생한다고 협의를 하고, 25퍼센트 내에서 처리하면 됩니다. 가장 좋은 시나리오는 백로그 그루밍할 때 이런 수정사항을 발견하고 스토리를 생성하는 것입니다.
    제가 좋아하는 말 중에 Later equals never가 있는데 나중에 한다는 것은 안하겠다는 의미입니다. 회사 팀에서 tech debt이 생길만한 일이면 즉시 팀원 중에 누구라도 이의를 제기하고 더 나은 방안으로 처리해야 합니다. 나중에 수정이란 2-3배 이상의 시간이 더 들어갑니다. 
    0
  • 초무쿤
    4k
    2020-01-31 03:39:56

    우리나라에선 스크럼=출근체크 아닌가요 ㅎㅎ;;

    좋은 기억이 별루 없어서 ㅎㅎ;;

    우리나라에는 뭐가 들어와도 관리 관점에서 적용하다보니 이상하게 변해버려서...ㅎㅎ;;

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.