[출근했더니 스크럼 마스터가 된 건에 관하여] 개념 정리 및 회고

 

해당 책으로 스터디를 진행했다.

 

스토리 방식으로 어떤 팀이 스크럼을 적용하면서 겪는 다양한 이슈와

 

어떻게 하면 좋을까에 대한 내용이 정리된 책이었다.

 

먼저 스크럼이 뭐고 어떻게 하는지 정리하고,

 

인상깊었던 내용과 회고를 작성하려 한다.

 

스크럼이 무엇인가?

 

스크럼을 말하기 전에 먼저 애자일을 알아야 한다.

 

애자일은 모든 것을 예측하고 대비할 수 없다는 것을 일찌감치 인정하는 것이다.

 

 

한 번에 전체를 완성하기 보다 조금씩 만들되, 조기에 동작시켜 피드백을 받는 것이다.

 

만들 때는 중요한거 먼저 만드는 것이다!

 

스크럼은 애자일 개발 기법의 하나인 것이다.

 

일하는 절차와 기켜야 할 규칙이 최소한으로 정의된 프레임워크이다.

 

 

투명성

 

스크럼의 특징 중에 투명성이 있다.

 

현재 상태와 문제점을 명확하게 밝히는 것이라 하는데

 

팀장님은 이것을 "목표가 같다" 라고 본다고 하셨다.

 

회사 일을 하면 의도가 무엇인지, 왜 해야하는지

 

이해를 하는게 얼마나 중요한지 다시 한 번 생각을 하게 되었다.

 

 

그럼 스크럼은 어떻게 하는 것인가?

 

스크럼의 참여자는 세 가지로 나뉜다.

각 참여자의 특성을 요약해보겠다.

 

1. 프로덕트 오너

2. 디벨로퍼

3. 스크럼 마스터

 

프로덕트 오너

 

프로덕트 오너는 제품의 가치를 책임지는 사람이다.

 

왜(why) 실현하는지, 무엇(what)을 실현하는지를 생각한다.

 

이를 위해서 

 

요구 사항과 제품 명세, 계획 수립과 같은 일에 관여한다.

 

디벨로퍼

 

백로그(기능이나 요구사항, 개선 사항과 같이 제품 개발에 필요한 일감)에 등록된 내용을 순서대로 하나씩 구현하는 사람이다.

 

어떻게(how) 실현할지 생각한다.

 

제품을 동작하게 만드는데 관심이 있다.

 

스크럼에는 3인에서 9인으로 구성된 개발팀이 참여하고

 

이 개발팀은 제품 개발에 필요한 모든 역량을 가지고 있어야 한다.

 

이런 역량을 갖춘 조직을 기능횡단팀이라고 한다.

 

처음부터 완벽할 수 없고 

 

스프린트로 출시를 통해 팀 전체가 학습을 해가는 것이다.

 

스크럼 마스터

 

프로덕트 오너와 개발팀과 함께 제품을 만들어가는 과정이 원활하게 진행되고

 

더 좋은 제품이 나올 수 있도록 이 둘을 돕는 것이 스크럼 마스터이다.

 

일에 방해되는 요소를 제거하고 스크럼이라는 프레임워크가 자리 잡게 돕는 것이다.

 

중요한 것은 업무 할당이나 진척 관리는 하지 않는다.

 

어떻게 작업할까?

 

중요한 것은 역할은 역할일 뿐 직책이 아니다.

 

회사 조직도에는 프로덕트 오너가 없을 수 있다고 한다.

 

참여한 인원 중에 역할을 할당하면 된다.

 

개발자면서 PO

 

개발자면서 스크럼 마스터가 된다.

 

근데 PO면서 스크럼 마스터는 금지이다.

 

프로덕트 오너는 제품을 더 좋게 만드는데 주력하기 때문에

 

무의식적으로 개발자에게 무리한 부담을 줄 수 있다.

 

반면 스크럼 마스터는 일이 원활하게 돌아가도록 애써야 하기에

 

접근법이 상반되기 때문이다.

 

기억에 남는 내용들

1. 완료라는 것은 뭘까?

 

책에서 말하는 완료 조건은

 

스프린트 시연에서 보여줄 체크리스트와 같다고 한다. 

 

이 완료 조건은 스크럼 팀에서 같이 상의해야 한다고 한다.

 

개발자의 관점은 완료 조건에 녹아있고,

 

프로덕트 오너의 완료 조건은 프로덕트 백로그에 녹아있다고 한다.

 

개발자의 관점에서의 완성과 프로덕트 오너관점에서의 완성 모두에 부합해야 완성인 것이다.

 

그러면 내가 실무에서 적용해보려면?

 

회사에서 일할 때 내가 지시받는 것은 명확하면서 단순하다.

 

"우리 빌드 시간이 너무 느려. 더 빨라져야 해"

 

이 업무를 완료한다는 것은 무엇일까?

 

만약 빌드 시간이 전엔 5분이 나왔는데 

 

2분으로 줄었다면 실패일까 성공일까?

 

그러면 2분 10초로 줄었다면 실패일까 성공일까?

 

나는 따로 팀으로 작업하지 않는다.

 

임원진들의 요구 사항을 전달받으면 그 때 그 때 혼자 작업을 진행한다.

 

그러니 내가 개발자이자 프로덕트 오너이다.

 

겸업하면 안되니 스크럼 마스터는 공석이다 굳이 따지자면 개발실 실장님이실거다.

 

팀은 없지만 내 작업물에 대한 고객은 우리 개발실로 확정되어 있으니

 

내 제품의 가치를 느낄 고객과 직접 상의할 수 있는 환경인 것이다!

 

따라서 나는 개발실 직원들과 상의해서 어느 정도로 줄이는 것이 완성일지 정할 수 있을 것이다.

 

이 완성 조건도 스프린트 별로 정해두자.

 

혹시 완성되고 나서 맘에 안든다고 하더라도 결과를 인정하기 싫을 수 있다.

 

그렇다고 하더라도 다음 스프린트에서 완성해가면 된다.

 

2. 엘리베이터 피치

 

스크럼의 목표를 확인하기 위한 도구다.

 

엘리베이터를 타는 짧은 시간(15초 ~ 30초)안에 제품을 설명하는 것을 말한다. 

 

인셉션 맵이라는 것이 있는데

 

스크럼에는 포함되지 않지만, 목표와 과제를 명확히 정의할 때 쓴다고 한다.

 

여기서 엘리베이터 피치는 인셉션 맵의 목표에 해당한다.

 

다시 엘리베이터 피치로 돌아가서

종착지를 알아야 달릴 수 있다!

 

라는 문구가 있다.

 

스크럼에 참여하는 모든 팀원들이 목표와 과제를 이해할 수 있어야 가치있는 제품을 완성할 수 있는 것이다.

 

엘리베이터 피치를 작성하는 방법은 아래와 같다.

 

간결성: 매우 짧고 명확하게 핵심 메시지를 전달해야 한다.
가치 중심: 기술적 세부사항보다는 제품이나 기능이 가져올 가치와 문제 해결 방식에 초점을 맞춘다.
청중 맞춤: 기술팀이 아닌 이해관계자들도 이해할 수 있는 언어로 설명한다.
설득력: 제품이나 프로젝트에 투자하거나 관심을 가질 이유를 제공한다.

 

이 방법을 통해 엘리베이터 피치를 만들어서

 

제품 백로그 항목이나 스프린트 결과물을 이해관계자들에게 설명할 때, 

또는 제품 비전을 팀과 공유할 때 엘리베이터 피치를 자주 활용한다. 

 

나도 지금 내가 받은 업무가 무엇인지 

 

스스로 엘리베이터 피치를 만들어 정리해보는 습관을 가져야겠다!!

 

3. 닭과 돼지의 우화

 

이 책에서는 스스로의 책임에 대해서 중요시하고 제 삼자의 의견은 그저 참고 사항이라는 것을 강조하기 위해 설명했지만

 

나는 다른 느낌을 받았다.

 

인턴 때 진행했던 프로젝트에서 기획과 개발을 노코드 툴을 활용해서 다같이 진행했는데

 

서로 어려운 부분이 다르다는 것을 제대로 이해하지 못하고 진행하다보니

 

전문적인 용어를 그대로 사용하여 소통 문제를 겪은 적이 있다.

 

실무 중에도 기획안의 수정이 개발에 어떠한 영향이 있는지 고려되지 않아

 

문제가 되는 것을 많이 보았다.

 

그렇기에 더더욱 개발 기획을 벗어나 

 

지금처럼 어떤 기획안을 만들어 개발팀에 전달하는 것이 아니고 

 

함께 성장한다는 목표를 가지고 존중하며

 

전체가 투명하게 목표를 공유하는게 좋다는 생각을 했다.

 

 

 

회고

회고는 중요하다.

 

인간관계론이라는 책에서도

 

미래를 예측해 대비한 사람보다 회고를 한 사람이 더 좋은 성과를 냈다는 연구가 나왔었다.

 

이 책에서도 스프린트 회고 여기선 스프린트 레트로스펙티브라는 것을 중요시한다.

 

잘된 점은 계승하고 안된 점은 개선하기 위해 회고를 하는 것이다.

 

좋았던 점은

 

이번 스터디는 기획실과 같이 스터디를 진행했던 점이다.

 

나는 팀으로 실무를 한 경험이 적었기에

 

다양한 생각과 입장을 들을 수 있어서 좋았다.

 

 

아쉬운 점은

 

내가 팀단위로 업무를 진행하지 않아서 크게 와닿지 않았던 점이 아쉬웠다.

 

개발팀에서는 팀단위로 업무를 진행하긴 하지만

 

스크럼을 바로 적용하기에는 큰 벽이 있는 상황이라

모두가 책의 스크럼 사례들을 읽으며 오히려 무기력감까지 느끼기도 했다.

 

하지만

 

팀장님의 격려로 인해 모두가 다시 힘을 낼 수 있었다.

 

중요한 것은 그럼에도 불구하고 이다! 

 

이래서 안돼 저래서 안돼보다는

 

그럼에도 불구하고 내가 할 수 있는게 뭐가 있을까?

 

하는 정신이 중요하다!!

 

개발뿐만 아니라 실생활의 모든 곳에도 똑같다.

 

앞으로 업무를 하면서 그럼에도 불구하고

 

팀과 함께 성장해서 더 좋은 성과를 내기 위해 노력할거다!!