[독후감] 출근했더니 스크럼 마스터가 된 건에 관하여 : 리뷰

안녕하세요. 황진성입니다.

애자일 조직에서 일하기 위해서 애자일에 대한 이해가 어느 정도 필요하다는 생각이 들었습니다. 그리고 회사에서도 애자일 조직의 운영을 위해 비용 투자를 하고 있는데, 뭐가 좋은 거고 어떻게 하는 거고 내 행동을 어떻게 바꿔야 하는지 알고 싶어서 책 한 권을 읽어봤습니다.

 

책 제목은 "출근했더니 스크럼 마스터가 된 건에 관하여" 입니다.

https://product.kyobobook.co.kr/detail/S000200083569

출근했더니 스크럼 마스터가 된 건에 관하여 | 니시무라 나오토 - 교보문고

 

각 섹션은 상황별로 구성되어 있고, 섹션별로 전달하고자 하는 바를 요약 및 해석해 봤습니다.

 

 

애자일, 스크럼이 낯설거나 용어에 익숙하지 않다면 이전 글을 참고해 주세요!

[애자일] 애자일 개발을 하고 있지만 공부해 본 적 없는 분들을 위해

 

섹션 별 요약

---

Section 1: 스크럼을 준비한다.

• 스크럼 프로젝트 참여자는 프로덕트 오너, 개발자, 스크럼 마스터로 구성된다.
  • 프로덕트 오너는 제한된 리소스를 활용해서 목표를 달성할 수 있도록 프로덕트를 관리하는 사람이다. 목표 달성에 집중한다.
  • 개발자는 프로덕트 오너가 목표한 것을 실현하게 만드는 사람이다. 요구사항 분석, 작업량 추정, 설계, 개발, 테스트 등 구체화와 관련된 모든 업무를 수행한다.
  • 스크럼 마스터는 프로덕트 오너와 개발자가 스크럼을 하는 데 어려움이 없도록 옆에서 서포트해주는 사람이다. 프로젝트가 잘 진행될 수 있도록 도와주고, 방해 요소가 있다면 사전에 제거하는 등의 역할을 수행한다.
• 역할은 역할이고, 개인의 역할을 온전히 수행하기 힘든 상황이라면 그 상황을 팀 내에서 도와줘야 한다. 개인보다는 팀으로 진행됨을 잊지 말아야 한다.
• 다만 스크럼 마스터와 프로덕트 오너의 겸업은 예외적으로 금지한다. 예를 들어, 프로덕트 오너는 목표 달성에만 집중해야 하기 때문에 개발자의 업무량은 크게 고려하지 않는다. 하지만 스크럼 마스터는 모든 일이 원활하게 진행되는 것에 집중하기 때문에 개발자에게 과도한 업무가 생기는 것을 그냥 넘기지 않는다. 의견이 충돌될 수 있는 두 역할이기 때문에 겸업을 금지한다. (정답은 없다..)

 

Section 2: 목표를 이해한다.

• 스크럼 자체는 팀원이 어떻게 협업해서 제품을 완성시키는 가에 초점이 맞춰져 있다.
• 하지만 초기에는 목표만 보고 제품을 어떤 방식으로 만들어 나가야 하는지 구체화하기 힘들다.
• 이럴 때는 인셉션 덱(Inception Deck)을 만들고, 10가지 항목에 대해 정리해 보는 시간을 가져봐도 좋다.
• 또한 팀이 왜 이 자리에 모이게 됐는지 생각해봐야 한다.
• 인셉션 덱에 대한 내용은 여기를 참고해도 좋다.
• 처음부터 누군가가 슬라이드에 정리해서 발표하는 것보단, 모두가 모여서 목표를 구체화하고 그 과정에서 많은 대화가 오가며 끊임없이 의견의 수렴과 발산이 이뤄져야 한다. 팀원 모두가 생각을 나누면서 목표와 과제를 구체화하는 것이 중요하다.

 

Section 3: 프로덕트 백로그를 만든다.

• 개략적인 계획만으로는 언제 릴리즈를 하고, 릴리즈를 하기 위해 얼마큼 작업해야 하는지 파악하기 힘들 수 있다.
• 프로덕트 백로그에 해야 할 일을 하나씩 만들어 등록하면서 파악을 해보는 거다.
• 프로덕트 백로그의 각 아이템은 아래와 같이 구성된다. 예시로,
  • 기능 : 로그인
  • 목적 : 대외비를 보호하기 위함
  • 설명 : 사원번호와 비밀번호로 인증
  • 예상 견적 : 5
• 위와 같은 아이템 형식도 좋지만, 이 일이 사용자에게 어떤 가치로 전달되는지 파악하기 힘들다.
• 따라서 사용자 스토리(User Stroy) 방식으로 작성해 보는 것도 좋다.
  • 스토리 : 나는 xxx이고 xxx 기능이 있으면 xxx가 더 좋아질 것 같다.
  • 시연 방법 : xxx 화면에 들어가면 xx가 표시된다. xxx를 입력하고 xxx 하면...
  • 예상 견적 : 5
• 프로덕트 백로그에 아이템을 채워 넣을 때, 빠뜨린 일감이 없는지 충분히 고민해야 한다. 나온 일감 중에서 어떤 일감이 우선순위가 높은지, 긴급도가 높은지 판단하고 진행할 업무의 순서를 결정한다.
• 아이템에 대한 중요도와 긴급도는 팀 내에서 결정하기보단 스테이크홀더(이해관계자)가 결정하는 것이 더 바람직하다고 보일 수도 있다. 그럼에도 만드는 제품에 대한 이해도는 팀이 더 높을 수도 있으니 반드시 필요한 부분이라면 충분한 소통을 통해 결정해야 한다.

 

Section 4: 작업량을 추정한다.

• 각 항목을 구현하는 데 얼마나 걸릴지 파악하기 위해 작업량을 숫자로 추정한다.
• 예전에는 Man day, Man month 같은 단위를 사용했다.
• 하지만 일정이란 언제나 계획대로 되지 않을 수 있고 정확하게 추정하는 것이 불가능하다는 것을 인정해야 한다.
• 따라서 팀원 모두가 이해하기 쉬운 작업 하나를 3 정도로 잡고, 다른 작업이 몇 배나 더 쉽고 어려운지 가늠하며 추정한다.
• 다만, 10인지 11인지 고민하는 것은 무의미하기 때문에 피보나치 수 중 하나로 결정한다.
  • 피보나치 수는 1, 2, 3, 5, 8, 13, 21,...이다.
  • 10 일지 11 일지 고민하지 말고 8 일지 13 일지만 고민해서 추정하자.
• 중요한 점은 추정에 너무 오랜 시간을 사용하지 않는 것이다. 어차피 정확한 추정은 없다!
• 추정치로 나중에 팀이 전체적으로 한 번의 스프린트에 얼마만큼의 일을 할 수 있는지 확인 가능하다.

 

Section 5: 다 함께 모여서 추정치를 보완한다.

• 추정치는 실제 일감에 투입되는 팀원 모두가 모여서 진행해야 한다. 다 함께 진행하지 않으면 큰 의미가 없다.
• 플래닝 포커를 사용해도 좋다.
• 경력이 낮은 개발자는 13을 냈지만, 경력이 많은 개발자는 8을 내는 경우가 있을 수 있다. 이럴 때는 모두의 의견을 들어보고 다수결로 결정하는 것이 좋다.

 

Section 6: 앞으로 벌어질 상황을 그려본다.

• 작업을 스토리 단위로 작성하고, 스토리에 추정치를 매기면 그 값을 스토리 포인트라고 부르기도 한다.
• 한 스프린트에 진행될 스토리 포인트의 총합을 벨로시티라고 한다.
• 벨로시티를 알면 언제 어떤 기능이 나올지 가늠이 가능하다.
• 벨로시티는 팀마다 스프린트마다 다른 것이므로 절대적인 수치로 참고하면 절대 안 된다!

Section 7: 스프린트 시작 전에 한번 더 계획을 구체화한다.

• 스프린트 플래닝
  • 완료 조건을 명시한다.
  • 이번 스프린트 때 유저에게 어떤 가치를 전달할지 결정하는 시간이다.
• 태스크가 너무 많아서 목표가 묻히면 안 된다.
• 인수 기준과 완료 기준의 차이는? 예를 들어,
  • 인수기준 : 메인 화면에서 알림 조회가 가능하다.
  • 완료기준 : 알림 조회 기능이 스테이지 환경에 배포되어 있어야 한다.

 
Section 8: 위험에 재빠르게 대응한다.

• 데일리 스크럼을 매일 짧게 15분 정도 하면서, 일 완성도와 어려운 점은 없는지 공유를 한다.
• 지금 어떤 일을 하고 있고, 어디까지 했고, 어떤 일을 할 건지 간단하게 말한다.
• 스크럼 마스터에게 공유를 하는 것이 아니라 팀원들에게 공유한다.

 
Section 9: 상황을 투명하게 가시화한다.

• 태스크보드 (to do -> doing -> done)를 활용한다.
• 번다운 차트를 활용한다. 스프린트 리뷰 시간에 보고 있는데, 데일리 스크럼 사이에 매일 보여줘도 좋을 것 같다.
• 상황을 가시화해서 현재 시점에 얼마나 많은 이슈가 남아있는지, 어떤 이슈가 오랫동안 해결되지 않고 있는지 확인할 수 있다.

 
Section 10: 완료의 의미를 명확하게 한다.

• 개발이 끝난 후 스프린트 리뷰, 스프린트 회고를 진행한다.
• 스프린트 리뷰 시 만들어낸 결과물이 문서라면 문서 그 자체겠지만, 소프트웨어라면 반드시 동작하는 단위로 완성이 되어 있어야 하고 시연을 반드시 해야 한다. 시연 후 이해관계자 등에게 피드백을 받는다.
• 스프린트 시작 전에 어떤 작업에 대해 완료 조건을 설정해야 한다. 해당 작업의 완료를 구체화한 것이며, 당장 릴리스해도 된다는 의미와는 거리가 있다.
• 리뷰 때 나온 프로덕트를 개발자는 완료 조건을 보고 완성도를 결정한다. 프로덕트 오너는 프로덕트 백로그에 기재된 내용을 보고 완성도를 결정한다.

 
Section 11: 예측을 쉽게 하기 위해 시간을 엄수한다.

• 일정을 예측하기 쉽게 하기 위하 타임박스를 설정한다.
• 타임박스가 필요한 이유?
  • 타임박스가 없는 경우, 늘어지면서 일을 안 하게 되는 경향이 있다.
  • 타임박스를 너무 길게 잡아두면 의식해서 늦게 일하게 된다. 3일 만에 할 수 있는 일도 타임박스에 맞춰서 일하게 된다.
  • 스프린트를 반복하며 효율화, 개선을 해야 하는데 시간을 정해놓지 않으면 정확한 능력 측정이 불가능하고 예측 또한 힘들어진다.
• 이번에만 연장하고.. 이런 건 없다.

 
Section 12: 다음에 할 일을 구체화한다.

• 너무 빨리 스프린트 작업이 끝났다면
  • 프로덕트 백로그에서 중요하지만 못했던 일을 꺼내서 미리 하거나
  • 기술 부채를 고려해서 코드 리팩터링이나 테스트를 견고하게 작성하는 일을 수행하거나,
  • 백로그 정재를 한다 -> 다음 스프린트에 할 일을 미리 결정한다.

 
스크럼을 하는 이유??

• 프로덕트를 기획하고 만들고 운영하는 과정에는 명확한 것보단 불명확한 것이 훨씬 많음.
• 불명확한 것을 명확한 것으로 잡기 위함.
• 조직 구조나 업무 프로세스가 구체화된다.
• 그러기 위해서 무의식적으로 따를 수 있는 룰이 스크럼이라고 생각한다.
• 애자일을 온전히 이해하면 모든 문제를 풀 수 있는 능력이 생긴다고 생각한다.
• 그러면 어떻게 온전히 이해할 수 있는지? -> 관심의 끈을 놓지 않고 끊임없이 발전하려고 노력하면 천천히 바뀐다.
  • 책을 읽는 것도 Good!

 
Section 13: 스스로 원칙을 지킨다.

• 목표에 변화가 생겼거나 위험이 생겼을 경우 궤도 변경을 허용한다.
• 각 스크럼 이벤트에는 목적이 있고 팀원 모두에게 역할이 있다. 역할이 잘 지켜지지 않을 경우에는 그라운드 룰을 만들어서 운영해 보자.
• 스크럼 이벤트 목적과 역할은 강제하는 것이 아니라 이해시켜야 한다.

 
회고를 즐겁게 진행하는 팁!

• 다과를 준비해서 편안한 분위기가 되도록 한다.
• 사소하더라도 장점을 찾아서 얘기한다. 너무 단점만 얘기하는 자리가 되지 않도록 한다.

 
Section 14: 벨로시티를 높인다.

• 주변에서 벨로시티를 높이라는 말을 들었다면 무시하는 것이 오히려 좋을 수 있다. 벨로시티를 높였더니 일의 효율이 늘어나는 것이 아니라 작업량 추정 때 일부러 높게 잡거나, 구현 시 완성도를 낮추고 완성되었다고 할 수 있다.
• 하지만 벨로시티를 높이고 싶다면? 지금 구성원들의 실력을 키우는 것이 가장 확실하다. 하지만 쉬운 일이 아니다. 오히려 불필요한 회의를 없애거나, 업무를 방해하는 잡일을 분할한다거나, 고성능 PC로 변경하는 등의 변화가 벨로시티를 개선할 것이다.
• 가장 쉬운 방법으로는 팀원을 추가 영입하는 것인데, 이 또한 쉬운 일은 아니다. 추가된 팀원이 업무에 잘 적응해야 하며, 팀의 목표가 뭔지 이해를 해야 하며, 현재 팀원들이 하는 업무에 발목을 잡지 말아야 한다. 다양한 조건들이 만족되지 않으면 오히려 팀원을 추가하는 것이 벨로시티에 역효과를 줄 수 있다.
• 어차피 벨로시티는 한 번에 올라가지 않는다. 한 번 올라간 후 안정성이 확인 됐다면 비로소 올라간 것이라고 볼 수 있다. 즉, 벨로시티가 올라간 채로 유지되어야 한다.
• 이럴 때 일을 더 잘할 수 있도록 하는 것이 스프린트 회고이다.
• 구현해야 할 기능의 범위를 줄여보는 것도 좋은 선택이다.

Section 15: 역할 구분은 문제를 발견하기 쉽게 만든다.

• 스프린트 플래닝, 리뷰, 회고만 팀원 전체가 모여서 진행한다. 각 구성원의 역할이 있는 건데, 누군가 빠져버리면 곤란한 상황이 생긴다. 이럴 경우에는 스크럼 마스터가 역할을 조정하거나 일정을 조정한다.
• 이런 일이 발생하면 스크럼 마스터가 가장 먼저 도와야 한다. 반대로 스크럼 마스터가 빠지면 PO가 대체할 수 있어야 한다.

 
Section 16: 사용자의 관점에서 의도를 명확히 한다.

• 개발자는 왜 개발을 할까? 유저한테 좋은 가치를 전달한다. 그 결과로 얻어지는 비즈니스 성공이 목적이다.
• 따라서 반드시 "유저에게 xxx 문제를 해결해 준다."가 우선되어야 하고, 어떻게 해결할지 결정을 한다. 반드시 개발자가 나서서 어떤 기술을 써서 어떻게 개발을 해야 하는 게 아니라, 개발 없이 우회하는 방법이 있으면 그 방법을 사용하는 것이 더 적합할 수도 있다. 애자일 원칙 중에 "우리가 해야 할 일을 최소화해야 한다."가 있다 이를 실현하는 것이다.
• 우회 예시로,
  • 타 부서에서 우리 쪽 데이터 조회가 필요한 상황이다. 직접 접근할 수 있는 어드민 페이지를 만들어 줄 수 있었지만, 좀 더 얘기해 보니 한 달에 한번 접근한다고 해서 직접 조회를 해서 데이터를 전달하기로 했다.
  • 배민 범준님이 해주신 엘리베이터애 거울을 설치한 얘기도 좋은 예시인 것 같다.
• 뭔가 기능 개발을 염두에 두고 문제 정의를 하는 것 같다. 이런 경우에는 가설을 세우고 최소 기능만 개발해서 검증하고 다음 단계로 넘어가는 것이 좋다.
• 프로덕트 오너는 개발자에게 어떤 것을 실현해야 할지 알려준다.
• 프로덕트 오너는 "무엇을, 왜"에 집중하는 반면 개발자는 "어떻게"에 집중한다. 같은 얘기를 하더라도 집중하고 생각하는 부분이 다르다. 그 과정에서 오해가 발생할 수 있다.
• 이러한 오해를 줄이기 위해 사용자 관점에서 의도를 명확히 하는 것이 중요하다. 스크럼에서는 이것을 "사용자 스토리"라고 한다. 사용자 스토리 형식에 맞춰 작성하고 공유하자. 주로 사용자 스토리는 "스토리 + 시연방법 + 견적"으로 구성된다.

 
Section 17: 어려움에 처한 팀원을 돕는다.

• 기술 부채가 너무 쌓였다면 프로덕트 오너와 따로 얘기해서 시간을 내야 한다.
• 기술부채는 너무 쌓이지 않게 개발팀에서 관리를 잘해야 한다.
• 이런 문제는 코드에서만 발생하는 것이 아니다. 역량을 넘어선 일을 부여받았을 경우 이런 일이 발생할 수 있다. 다양한 원인이 있을 수 있는데, 원인을 찾아내서 해결하지 않는다면 똑같은 문제는 반복될 것이다.
• 스크럼 마스터는 모두를 도와 목표에 달성하도록 도와줘야 한다. 서번트 리더십이라고도 한다. 개발자가 스프린트 일정에 맞추기 힘들어하는 것 같으면, "괜찮아요?"라고 간접적으로 물어서 현재 상황을 파악할 수도 있다. 상황을 파악했다면 비슷한 문제가 발생하지 않도록 조치해야 한다. 그것 또한 스크럼 마스터의 중요한 역할 중 하나이다.
• 스프린트 회고 때 어려운 점을 모두 적게 하고, 어떤 표가 공감을 많이 받는지 확인해 보는 것도 좋은 방법이다.
• 기술 부채뿐만 아니라 팀의 컨디션 or 야근 관련돼서도 생각해 볼 수 있다.
• 컨디션 관리를 잘하는 것은 중요하다. XP(eXtream Programming)에는 40 hours week (1주일에 40시간만 일하자) 원칙이 있다. 참고하자.
• 업무시간이 끝나면 곧장 퇴근하자! 가 핵심이 아니라 업무시간 내 최선을 다해서 일을 마무리 하자. 가 핵심이다.

 
Section 18: 더 나은 상태로 만든다.

• 문제가 발생했다면 빠르게 해결하고 프로젝트를 진행해야 한다. 하지만 해결 과정이 쉽지 않을 수 있다.
• 프로덕트 측면의 장애요소와 스프린트 회고에서 나오는 일하는 방식에 대한 방해요소가 공존한다.
• 태스크 보드에 방해 요소 관리 컬럼을 만들어 보는 것도 좋다. 매일 어떤 요소가 일을 방해하고 있는지 파악할 수 있고, 해결할 수 있는 수준이면 당장 가져가서 해결한다. 즉, 방해 요소 또한 일반 업무와 동일하게 취급한다.
• 회고까지 가지 않더라도 스크럼 마스터가 파악하고 있어야 하며, 모두가 인지하기 쉽게 시각화해야 한다.

 
Section 19: 다음에 할 작업을 명확히 한다.

• 프로덕트 백로그는 언제 어떻게 추가/수정/삭제될지 아무도 모른다. 예측하기 힘들다. 그러니까 누군가만 프로덕트 백로그의 변경 권한을 주는 것은 비효율적이다. 모두에게 이슈 추가 권한을 준다. 하지만 최종적으로 어떤 우선순위로 일을 하게 될지는 PO가 결정한다.
  • 권한을 나눠야 하는 이유는 PO가 실무자가 아니기 때문에 작업:기술, 결함 이슈의 경우에 리포트를 제대로 작성할 수 없다.
• 다양한 의견이 모이면 뒤죽박죽이 될 수 있다. 뒤죽박죽인 프로덕트 백로그 각각 아이템에 작업량 추정을 먼저 한다. 작업량 추정은 개발자가 리드해서 산정한다. 그 이후에 추정치를 참고해서 프로덕트 백로그 우선순위를 재정의한다. 이 과정을 백로그 정제, 백로그 리파인먼트라고 한다. 이 작업은 정기적으로 하는 게 아니라 평소에 하는 것인데, 처음 시작하기 부담스럽다면 정기적인 이벤트로 해보다가 넘어가도 좋다.
• 백로그 정제는 반드시 해야 하는 이벤트는 아니다. 언제 해야 할지는 팀의 상황에 따라 다르다. 코드 리팩토링을 진행해야 코드를 잘 작성할 수 있듯, 백로그를 보고 일을 할 수 없을 때 백로그 정제를 진행한다. 주 1회 하자는 식으로 정해볼 수도 있다. 스프린트 시작 전에는 한 번쯤 하는 게 좋다.

 
Section 20: 재작업을 없앤다.

• 어떤 작업이 끝나고 리뷰를 진행하는데, 다시 만들어야 하는 경우가 생길 수 있다.
• 처음 작업 시작하기 전에 페이퍼 프로토타이핑이나 간단한 스케치를 해보는 것만으로 필요한 일일지 판단이 가능하다.
• 하지만 위 프로토타이핑을 했다고 하더라도 재작업이 필요할 수도 있다. 그래도 하는 게 좋다.
• 가치 있는 스토리를 찾아내서 가치있는 스토리로 만들어 내는 것, 그것이 가장 중요하다.

 
Section 21: 목표에 다가선다.

• 스프린트 리뷰에서 다음 릴리즈 때 어떤 기능이 반드시 포함되어야 하고, 어떤 기능이 더 추가되면 좋을지 판단한다. 이해관계자도 함께 진행할 수 있는데, 그 과정에서 목표와 더 멀어질 수 있다.
• 멀어진 목표에 다시 다가가는 방법은 2가지가 있다.
  • 스크럼 팀의 컨디션을 더 좋게 만든다.
  • 프로젝트 일정에 영향을 주는 요소를 조정한다. (품질, 예산, 기간, 범위)
• 구현 방법을 조절하고, 개발 범위를 조절하는 게 답인 것처럼 나와있지만 꼭 정답은 아니다.

 

 

책을 읽고 든 생각

---

앞으로 일을 할 때, 아래와 같은 상태를 가질 수 있도록 노력해보고자 합니다.

(실제로 일을 하면서 느껴지는 점이 있다면 여기 아래에 하나씩 추가하겠습니다.)

 

1. 내가 하고 있는 일이 사용자에게 어떤 가치를 전달할 것이라 생각하는지, 어떤 기능을 개발하고 있으며 어떻게 개발할 예정인지를 누군가 물어보면 술술 설명이 가능하게 준비하자. 내가 지금 하는 일의 핵심이 무엇인지 잊지 않아야 한다.
2. 데일리 스크럼 시간을 적극적으로 활용하자. 적당히 보드를 보며 설명하는 정도가 아니라, 최소 5분 정도는 어떤 말을 할지 준비해서 들어가자. 공유를 "잘" 하고 싶다면 준비는 반드시 해야 한다.
3. 내 일. 혹은 개발 관련 기술적 이슈가 아니더라도 진지하게 고민을 한 번쯤 해보자. 내가 만드는 서비스가 어떻게 만들어지는지 전체적인 흐름을 파악하는 데 좋은 방법이 될 것 같다.