스크럼 – 효과적이고 매력적인 개발 방법에 대해
스크럼
안녕하세요,
깃플입니다.
지난주에 애자일 방법론에 대한
포스팅을 올렸습니다.
여기서 조금 더 깊이 들어가면
다양한 스타일의 애자일이
존재한다는 것을 알 수 있는데요.
스크럼(Scrum), 칸반(Kanban) 등
독특한 이름을 가진 종류들이
애자일에 포함되어 있습니다.
오늘은 이 중 스크럼에 대한 글을 쓰려고 합니다.
들어가기에 앞서,
먼저 애자일 방법론의 핵심에 대해
짧게 설명하도록 할게요.
애자일 방법론은
짧은 단위의 계획과 유연한 대처로
개발/업무를 진행하는 방법론입니다.
더 자세한 내용은
아래 링크 참고 부탁드려요. 🙂
애자일이 이런 형태의 업무 방식을
통칭하는 용어라면, 스크럼은 조금 더
세분화 된 방법론입니다.
이제부터 스크럼에 대해
알아보겠습니다!
스크럼 (Scrum)
우선 스크럼을 이해하기 위해서는
단어의 유래를 알아야 합니다.
스크럼은 럭비에서 유래된 용어인데요.
경기가 반칙으로 인해
잠시 중단되었을 때,
양 팀 선수들이 공을 중간에 놓고
어깨를 밀착해서 형성하는
전술 대형입니다.
단어의 유래와 위 이미지에서 알 수 있듯이
스크럼은 팀워크와 책임감이 중요한
업무 프로세스 방법입니다.
스크럼의 장점은
팀원끼리 적극적으로 독려하고
서로에게 피드백을 제공하며
궁극적으로 제품/서비스의 발전을 위해
꾸준히 노력한다는 점입니다.
또한, 애자일과 마찬가지로
소프트웨어(SW) 개발 프로세스에서
가장 적극적으로 활용됩니다.
스크럼에서는 팀의 업무를
구조화하고 관리하기 위해 부여하는
특별한 역할들이 있는데요.
이 역할과 스크럼의 구조 등을
하나씩 설명하도록 하겠습니다.
프로세스와 역할
제품 백로그 > 스프린트 백로그 > 스프린트
순서로 진행되는 스크럼.
아직은 이해가 조금 어려우실 텐데요.
위 이미지를 보시면 사람들의 역할과
백로그, 스프린트 등 어려운 용어들이 보이시죠?
하나씩 설명해 드릴게요.
Product Owner (PO)
PO는 말 그대로 제품의 주인,
즉 제품의 총괄 책임자를 뜻합니다.
스크럼의 PO는 팀의 제품/서비스에 대해
모든 피드백과 요구사항에 관한
결정권을 가지고 있습니다.
지난 스프린트 때 얻은
모든 피드백을 바탕으로
어느 기능에 대한 개발이
먼저 진행되어야 하는지 결정합니다.
PO는 SW 개발에 대한 역량도 중요하지만,
비즈니스에 대한 통찰력과
고객과 커뮤니케이션 능력이
뛰어난 사람이 맡습니다.
그 이유는 아무래도
제품/서비스의 발전을 좌지우지하는
최종 결정권자이기 때문이죠.
고객에게 어떤 타이밍에
어떤 기능 개발이 가장 필요한지,
그리고 이 결정이 장기적으로 봤을 때
긍정적인 영향을 줄 수 있는지에 대해
끊임없이 고민하는 자리입니다.
Scrum Master
스크럼 마스터의 역할은
팀의 스크럼이 잘 진행되도록
도와주는 것입니다.
스크럼 마스터는 PO와 달리
비즈니스 운영보다는 스크럼 자체에 대한
모든 것을 관리하는 역할입니다.
팀원들을 동기부여하고
일정도 철저히 관리하면서,
스프린트 마무리 단계에는
계획대로 되었는지 점검하는 역할이
바로 스크럼 마스터입니다.
스크럼이 잘 적용될 수 있도록
팀원들을 교육하고 안내하는 것이
주요 임무이기도 하죠.
스크럼에 대한 이해도는 물론,
SW 개발 지식/경험, 그리고 무엇보다
리더십을 겸비해야 하는 자리입니다.
Team (팀)
스크럼 팀의 팀원들입니다.
좋은 제품/서비스를 만들기 위해
다양한 능력을 갖춘 사람들이 모인
스크럼 팀입니다.
럭비 팀원들이 어깨를 맞대고
하나의 목표를 위해 힘쓰는 것처럼,
스크럼 팀원들끼리도 의견을 맞춰
목표를 향해 전진합니다.
그럼 이제 꼭 알아야 할
용어들에 대해 설명해드릴게요!
Sprint (스프린트)
애자일 방법론과 스크럼에서는
일정 주기를 정해서
업무를 진행한다고 했는데요.
이 일정 주기를 스프린트라고 합니다.
Backlog (백로그)
제품 및 서비스의
개발 기능 목록입니다.
보통 지난 스프린트 때 얻은
고객 피드백을 바탕으로 구성되죠.
Product Backlog (제품 백로그)
개발 예정인 모든 백로그를
제품 백로그라고 합니다.
우선순위부터 나열해서
하나씩 해결해 나갑니다.
Sprint Backlog (스프린트 백로그)
스프린트 동안 개발할 백로그를
스프린트 백로그라고 합니다.
스크럼 예시
용어들에 대한 의미만 보시면
스크럼이 정확히 어떻게 진행되고
어떤 효과를 가져다주는지
감이 잘 안 잡히실 텐데요.
그래서 오늘도 몇 가지 예시를
알려드리고자 합니다. 😄
네덜란드 철도
하루에 평균 120만 명의 탑승객에게
교통편을 제공하는 네덜란드 철도.
네덜란드 철도에서는, 운영하는 모든 역에
열차 정보 안내 시스템을(오디오 & 화면)
통합 관리하는 컨트롤 타워를 구축하고자 했습니다.
첫 3년은 폭포수 모델을 따라
업무를 진행했는데,
결국 실패로 돌아갔는데요.
* 폭포수 모델: SW 개발 프로세스를 순차적으로 진행하는 방법론
그래서 도입한 프로세스가
바로 애자일의 스크럼입니다.
거시적인 목표를 세우고
업무를 한 번에 진행하기보다,
3주의 스프린트 기간을 정해
단기적인 목표를 세우고,
최고의 서비스를 제공하기 위해 노력했습니다.
네덜란드 철도에서는 최초
PO를 선임하는 데에 어려움을 겪었지만,
비즈니스 전문가를 PO로 선임하면서
탄력을 받기 시작했습니다.
실패로 여겼던 3년이지만,
이때 세웠던 뚜렷한 목표들이 있던 덕에,
네덜란드 철도는 스프린트 때마다
개발 우선순위와 업무 분담에 있어서
빠른 결정을 내릴 수 있었습니다.
네덜란드 철도 스크럼 팀은
테스트를 반복하면서, 추가 개발이
필요한 부분들을 캐치하며
꾸준히 개선하고 있습니다.
덕분에 탑승객들은 편리하게
탑승 안내를 접하면서
철도를 이용할 수 있게 되었습니다.
사브 (Saab)
사브는 스웨덴의 항공기 회사입니다.
보통 전투기를 만들기 위해서는
천문학적인 비용이 발생하는데요.
사브의 목표는 저비용 고효율의
전투기를 개발하는 것이었고,
이를 위해 스크럼을 도입했습니다.
훌륭한 전투기를 만들기 위해서는
뛰어난 하드웨어와 SW
모두 갖추고 있어야 합니다.
그렇기 때문에 개발 전에
맡은 분야에 대한 뛰어난 전문성 ,
원활한 소통, 그리고
탄력적인 업무 운영이 필수였습니다.
사브는 스크럼을 통해
각 파트별로 업무 우선순위를 정했고,
이를 모든 팀원들이 착실히 따르면서
개발을 진행했습니다.
스크럼 팀은 피드백 수용에도 굉장히 자유로웠으며,
팀원들끼리 투명하게 업무를 진행할 수 있었습니다.
그들은 결국 목표했었던
빠르고 강력하지만, 저비용인 전투기를
만들어낼 수 있었습니다.
깃플의 스크럼
깃플에서도 현재 스크럼을 통해
업무를 진행하고 있어요.
2주의 스프린트 동안 PO, 스크럼 매니저,
그리고 팀원들의 끈끈한 조직력으로
뛰어난 서비스를 제공하기 위해
노력하고 있습니다.
깃플에서 팀원을 모집하고 있습니다.
스크럼 팀에 합류하고 싶으시다면,
아래 링크를 통해 지원해주세요.
다음에도 흥미로운 주제로
찾아뵙도록 하겠습니다.
감사합니다.
