<애자일 개발이 처음인 내가 출근했더니 스크럼 마스터가 된 건에 대하여>

왜 관심을 가지게 됐나?

협업을 더 잘하고 싶어서! 팀 프로젝트를 할 때마다 협업이 잘 안되는 것 같아 생각이 많아지는 경우가 종종 있었다. 협업을 잘 하고 싶은 마음은 항상 있는데, 구체적으로 어떻게 무엇을 해야 팀원끼리의 시너지를 끌어낼 수 있는지 궁금해서 애자일 방법론에 관심을 갖게 되었다. gpt가 코드는 짜주지만 사람 대신 행동을 해주지는 않기 때문에, 앞으로 협업과 소통 능력이 더 중요하겠다는 생각이 문득 들었다.

지금까지 학교나 동아리에서 프로젝트를 여러번 했었는데, 사실 그 과정이 순탄했다고 느낀 적은 단 한번도 없다. 칸반 보드나 일간 보고, 페어 프로그래밍, 컨벤션 등의 도구는 부분적으로 사용해봤으나, 어떠한 맥락에서 이 도구가 효과적인지를 느끼지 못해 결국 편한대로 막 개발하게 되었다. 이번 기회에 스크럼 방법론을 배워서 다음 팀 프로젝트에 적용해보고 싶다.

 

책을 읽고 나서 배운 것

스크럼이 중요하게 생각하는 가치는 이 정도인 것 같다. 스크럼에서 제시하는 다양한 방법들은 이 가치를 달성하기 위한 수단이다. 모든 이벤트들을 적용하려고 하면 오히려 역효과가 날 것 같고, 우리 팀 상황에 맞는 가치를 지키기 위해 부분적으로 적용하는 것이 좋을 것 같다. 이벤트를 적용할 때는 팀원들이 이걸 왜 하는지 목적을 이해하고 설득해야 한다.

• 스크럼이 제시하는 역할, 이벤트, 산출물
  • 역할 : 스크럼 마스터, 프로덕트 오너, 개발자
  • 이벤트 : 스프린트, 스프린트 플래닝(스프린트 작업의 모호함을 없앰), 데일리 스크럼(문제 발견), 스프린트 리뷰(피드백 및 작업물 점검), 스프린트 회고 (일하는 방식을 개선)
  • 산출물 : 프로덕트 백로그, 스프린트 백로그, 인크리먼트
• 목표 : 스크럼은 개발의 결과물이 목표에 가까워지는지 수시로 점검한다. 비즈니스 상황이나 팀의 성장, 고객의 피드백 등의 변수에 대해 실행 계획을 지속적으로 수정한다. 제품 개발의 목적은 더 나은 제품을 만드는 것이어야 한다.
• 일감 정리 : 작업해야할 기능을 프로덕트 백로그에 작성하고, 목표 달성에 있어 중요한 순서대로 정렬한다. 누구나 프로덕트 백로그에 일감을 추가할 수 있고, 정렬은 PO가 담당한다. 처음 백로그를 작성할 때는 작업량을 추정해서 포인트를 부과한다. 일감들은 프로젝트를 진행하면서 생기는 변화를 반영하기 위해 수시로 점검하고 계획을 보완한다. 프로덕트 백로그를 보면 프로젝트의 전체 흐름을 알 수 있어야 한다.
• 경험에 기반한 수치를 신뢰하기 : 백로그의 항목에 대해 견적을 내더라도, 이는 추정치에 불과하다. 실제 몇번의 스프린트를 해보고 어느 정도의 벨로시티를 가지는지 확인하고, 이 수치를 기반으로 앞으로의 스프린트를 계획하고 릴리스가 언제 가능한지 추정한다. 또 밸로시티가 얼마나 안정적인지에 따라 스크럼 팀이 얼마나 일을 잘 하고 있는지 확인한다. 그러므로 밸로시티를 측정할 때는 타임박스를 지켜야 한다.
• 피드백 받기 : 피드백을 받는 것은 작업 결과물이 목표를 달성하는데 도움이 되는 방향으로 가고 있는지 점검하는 방법이다. 매 스프린트를 할때마다 피드백을 받는 것은 매우 중요하며, 더 나은 제품을 개발하기 위한 스크럼 팀의 원동력이다. 매 스프린트마다 피드백을 받기 위해 스프린트의 결과물은 반드시 시연 가능해야하고, 제대로 동작해야 한다. 매 스프린트마다 릴리스가 가능하면 더 많은 피드백을 받을 수 있을 것이다.
• 문제 관리 : 조기에 문제를 발견하고 조치를 취하여 더 큰 문제가 발생하는 것을 막는다. 이때 문제는 개발에 어려움이 생기거나, 기능 구체화가 충분히 되지 않아 모호한 부분을 추측하거나, 코드가 복잡해져 추가하기 어려워지거나, 외부 상황으로 인해 결정이 지연되는 등 다양한 상황을 포함한다. 문제 발견을 위해 데일리 스크럼 같은 이벤트를 통해 진행 상황을 공유하고 문제를 점검한다. 투명성을 위해 진행 상황을 가시화하는 태스크 보드나 번다운 차트를 작성하기도 한다.
• 자기 조직화된 팀 : 문제 발견을 위해 스크럼 마스터, 프로덕트 오너, 개발자의 역할을 구분한다. 스크럼 마스터는 스프린트의 원활한 진행, PO는 제품의 비전과 개발 영역 제시, 개발자는 어떻게 구현할지를 고민한다. 단, 역할의 구분은 문제를 찾기 위한 것이고 문제 해결은 팀 단위로 이루어진다. 스크럼 과정에서 책임이 뒤따르는 약속을 선언하게 되는데, 각 팀원은 책임감을 가지고 문제를 해결한다. 초반에는 실패를 통해 배워도 된다. 경험을 통해 약속을 지켜나갈 수 있다면 충분하다.
• 의사소통을 통해 팀원의 인식 맞추기 : PO는 why와 what을, 개발자는 how를 고민하므로 관점에 차이가 발생한다. 스프린트를 계획할 때, 프로덕트 백로그 항목의 시연 순서나 시연 방법을 그림으로 그려 표현해서 작업해야할 결과물에 대한 이해를 통일한다. 그리고 완료 조건을 정의해 개발자의 품질 기준이 스프린트 결과물에 반영되도록 한다. 스프린트마다 릴리스할 것이라면 품질 기준이 더 높아야 할 것이다.

 

책을 읽으면서 지금까지 했던 프로젝트에서 팀원간의 인식 맞추기와 문제 관리, 투명한 운영에 소홀했다는 생각이 들었다. 사실 개발을 하면서 막히는 부분이 있으면 혼자 끙끙대다 시간이 지체되는 경우가 많았는데, 팀 분위기를 문제 공유와 실패를 인정할 수 있게 조성했다면 더 빠른 해결과 몰입이 가능했겠다는 생각이 들었다. 또 시간이 지날수록 지쳐 의사소통을 대충하고 추측해서 기능을 개발했다가 나중에 재작업하는 경우가 종종 있었는데, 이야기를 많이 하면서 서로의 인식 차이를 줄이는 것에 신경 써야겠다는 생각이 들었다. 이 책에서 제시한 페이퍼 프로토타이핑이나 완료 조건, 사용자 스토리 등의 방법을 도입해보면 좋을 것 같다.

 

내 상황에 어떻게 적용할 수 있을까?

지금 싸피 1학기 과정을 수강하고 있는데, 과목이 끝날 때마다 하루나 일주일 단위로 프로젝트를 진행한다. 기간이 워낙 짧아서 스프린트를 적용하기는 어려울 것 같다. 하지만 스크럼에서 중시한 몇몇 가치들을 지키려는 노력은 해볼 수 있을 것 같다. 대표적으로 의사소통과 문제 가시화, 일감 정리와 태스크 구체화에 집중하고 싶다. 내가 스크럼 마스터 같은 역할을 맡아서 프로젝트를 진행하면서 지켰으면 하는 가치를 설득하고, 이를 달성하기 위해 모두 노력할 수 있도록 분위기를 조성하는 역할을 해봐야겠다. 프로덕트 백로그와 태스크 구체화, 시연 방법 정의, 데일리 스크럼, 정기적인 리뷰를 통해 달성할 수 있을 것 같다. 혹시 아이디어를 제시하는 사람이 있으면 그 사람에게 프로덕트 오너의 역할을 맡기고 싶다. 앞으로의 프로젝트에서 시너지가 나는 팀을 만들고 싶다.

 

스크럼을 처음 접하는 팀원들에게 보여주고 싶은 영상!

 

스크럼에 영감 받아 공부 중인 목록도 백로그 형태로 정리해보고 있다. 노션은 싱크로나이즈 기능을 제공해서 내용을 여기저기 복사하더라도 편집한 내용이 그대로 반영되서 좋다.