안녕하세요. 아이들나라 Mobile팀 박왕근 입니다.
지난해 아이들나라 서비스는 한단계 더 성장하기 위한 리본(Reborn) 프로젝트라는 중요하고 큰 프로젝트를 진행했습니다.
그 중 ‘퀴즈백과’라는 신규 프로젝트를 담당하면서 조직 내 처음으로 Scrum/Sprint 방식을 도입하면서 겪은 경험을 공유하고자 합니다.
‘퀴즈백과’ 프로젝트에 Agile?
퀴즈백과는 아이들나라에 신규로 출시되는 서비스로 아이들이 게임처럼 퀴즈를 풀면서 학습할 수 있는 서비스 입니다.
콘텐츠 제작부터 웹/서버(CMS, API), 모바일 앱(AOS, IOS), IPTV용 앱 개발 등 아이들나라에 포함되지만 별도 관리되는 서비스로 처음부터 개발이 필요한 프로젝트 였습니다.
이 프로젝트에서 저는 모바일 앱 개발PM의 Role로 시작을 했는데 IPTV 앱 개발을 담당하던 PM의 퇴사로…..해당 부분까지 인수인계 받아 진행하게 되었습니다.
일단 인수 인계를 받아 프로젝트를 담당하게 되었지만…IPTV 앱의 경우 개발, 품질 등의 내부 Process가 모바일과 다르고,
지원하는 IPTV 단말도 총 6종으로 각 단말마다 품질, 배포 일정이 다르기 때문에 모바일 앱의 개발/품질 주기와 맞지 않아 개발 관리에 어려움이 예견되었습니다.
업무의 범위가 확장되고 한정된 일정과 자원으로 프로젝트를 진행하기 위해 보다 유연한 프로젝트 관리가 필요하다는 생각이 들었고,
Agile한 업무 운영을 위해 Scrum/Sprint 방식을 채택하여 프로젝트에 도입하게 되었습니다.
지금 생각해보면 당시가 조직의 업무 방식을 변화하기 위해 노력하던 시기로 새로운 업무 방식을 실무에 도입하면 어떤 실질적인 이점이 있을까?? 하는 궁금증도 있었고,
말로만 하는 Agile이 아닌 실무에서의 경험을 통해 배우고 느끼고 싶었던 개인적인 욕심으로 맨 처음 도입하겠다고 손을 들었던 것 같네요..^^
Scrum Team 구성
퀴즈백과의 Scrum Team은 크게 2그룹으로 나누어 볼 수있습니다.
•
LGU+ : 아이들나라CO 구성원으로 전반적인 협의 및 담당 업무 관리 & 실무 병행
Scrum Master, 모바일앱, IPTV앱은 제가 담당을 했고, 웹/서버(1), PO(2), UI(1), GUI(1), 품질(1) 총 7명으로 구성된 팀입니다.
•
협력사 : 각 담당부분의 현장 대리인 or 실무자로 실무 관련 업무 진행
Mission? Possible!!
호기롭게 시작한 Agile 도입!!!
하지만 진행 단계 하나 하나가 미션이었습니다.
[ Mission #1 ] Risk 관리
신규로 출시되는 앱이나 서비스의 경우 보통 여러 부서의 담당자와의 협업이 무엇보다 중요하다고 생각합니다. (기획, 콘텐츠, 편성, UI/UX, GUI, 품질, 서버, 웹 등등등…)
특히 경험상 새로운 타입의 콘텐츠가 필요한 서비스의 경우 콘텐츠의 제작/편성 등이 지연 되었을 때 서버/앱 개발의 일정에 큰 영향을 줄 수 있다고 생각했습니다.
게다가 퀴즈백과의 경우에는 신규 출시되는 서비스로 모바일, IPTV 앱 모두 협력사를 통해 동시에 개발되다보니 새로운 업무 진행 방식 등으로 인한 여러 Risk 들이 예견되었습니다.
그래서 프로젝트 시작 전 발생가능한 Risk를 최소화 할 수 있는 방법을 고민하게 되었고, 대안을 아래와 같이 마련하여 접근했습니다.
< Risk>
•
업무 진행 방식
: Scrum Team 멤버, 개발사 모두 Scrum/Sprint 방식의 업무 경험 없음
•
협업 툴 사용
: Scrum Team 멤버, 개발사 모두 Jira, Confluence, slack 등의 협업툴 사용 경험이 부족함
•
개발 Process
: 모바일 앱 (AOS, IOS)과 IPTV 의 앱은 내부 개발 Process가 상이하고 관리 툴도 다름.
•
같은 일정 내 동시에 여러개 진행되는 프로젝트
: 퀴즈백과 외 SNS 로그인, 모바일 결제, 디즈니 러닝+ 등등 서로 다른 큰 규모의 프로젝트가 동시에 진행 됨.
각 프로젝트마다 다른 담당자, 개발 일정을 가졌지만 배포 일정은 동일하기 때문에 상호 영향을 주는 범위에 대한 관리 필요
•
품질 검증 및 일정
: 모바일은 내부 QA팀에서 진행하지만, IPTV는 별도 IPTV 품질팀에서 진행하고 일정도 각 셋톱 담당자들과 각각 협의가 필요함
•
배포 일정
: 모바일과 달리 IPTV용 앱은 각 IPTV 셋톱 담당자들과 협의가 필요하며 셋톱의 배포일정에 맞춰야 함
•
API 신규 개발
: 각 기능, 화면 별 API가 필요하며, 다양한 Type의 퀴즈기능 구현을 위해서는 콘텐츠의 Metadata가 종류별로 필요함
•
편성
: 편성을 위한 CMS개발이 필요하며, 신규 제작한 콘텐츠의 정보를 편성해야 함, 기존 VOD 편성 내용과도 연동이 필요함
•
로그인 및 결제 시나리오
: 리본 프로젝트의 주요 포함 기능으로 프로젝트 중간에 포함됨
•
퀴즈 콘텐츠
: 신규 type의 콘텐츠로 다양한 유형의 콘텐츠 제작이 필요하고, CMS가 콘텐츠에 대한 검수 기능을 제공하지 않기 때문에 검수방법에 대한 고민이 필요함.
•
콘텐츠 검증 방법
: CMS도 미개발된 상태이며, 퀴즈 풀기 API를 통해 전달되는 콘텐츠는 중복 제거 기능이 있어 한번 출제된 콘텐츠를 다시 확인하는데 어려움이 있음
< 주요 Risk 및 대응 방법>
1.
업무 진행 방식의 교육 및 가이드 제공 [MISSION #2] [MISSION #3] [MISSION #4]
a.
Scrum/Sprint 방식의 업무 진행에 대한 설명 및 진행 가이드 제공 (세미나 진행)
b.
상호 문서 및 정보 공유는 협업툴을 이용하며, 문서 작성 가이드 제공
i.
Sprint Planning, Sprint Daily Meeting, 개발사 주간보고, CDR(개발분석자료) 샘플 작성 및 실무 적용
2.
개발 범위 및 일정 관리 [MISSION #3]
a.
AOS, IOS, IPTV앱의 경우 화면 단위가 거의 유사하여 Sprint 일정을 거의 동일하게 Planning 함
b.
우선 순위가 높은 추가 개발건 발생 시 Sprint Planning 시 일정 단축을 위한 방안 마련 (4번 해당)
3.
품질 관리 [MISSION #3]
a.
모바일 앱 기준 Sprint 기간 내 품질 검증을 함께 진행함
b.
IPTV앱의 경우 기존과 같이 IPTV 품질팀에서 검증하되, 개발 완료 기간을 모바일과 최대한 맞춘 후 QA 입고
4.
콘텐츠 및 API동작 확인 [MISSION #5]
a.
API 연동규격 전달 받고 샘플 콘텐츠로 구성된 Dummy API 개발 하여 앱 화면 개발 시작
b.
Dev API 배포 후 앱 동작에 이슈 없는지 선 검토 후 Sprint 반영
c.
CMS 개발 전/후 API 반영결과를 확인하기 위한 콘텐츠 검색 기능 개발 (개인 프로젝트)
d.
콘텐츠 편성 검수 및 품질 검증 시 Metadata 확인을 위한 기능 개발 (개인 프로젝트)
[ Mission #2 ] 업무 진행 방식의 변경 교육 및 가이드 (Scrum Team, 협력사)
기존의 업무 방식에 익숙해져 있는 Scrum Team 동료들과 오랜 기간 폭포수 방식으로 지원해준 개발 협력사 담당자들에게
기존과 다르게 Agile한 업무 방식으로 진행 함을 알리고 어떤식으로 운영이 될지에 대한 안내 교육을 진행하여 업무 방식 변경으로 인한 혼선을 줄일 필요가 있었습니다.
1. Scrum, Sprint 방식에 대한 세미나 진행
2. Scrum Team 구성원 R&R 정의 및 퀴즈백과 Ground rule 세미나 진행
[ Mission #3 ] Sprint Planning = 전력 질주를 위한 목표 설정
Sprint Planning 과정이 그 어느 단계 보다 중요하다는 걸 진행을 하면서 또 깨달았습니다.
아래 Sprint Planning 과정이 중요한 이유, 유의할 점을 퀴즈백과 경험 기준으로 적어 봅니다.
1.
프로젝트 일정 전반에 걸쳐 어떤 일정을 가지고 진행이 되는지 Scrum Team 모두가 이해하고 그림이 그려질 것~!
•
업무 우선 순위는 각 담당자에 따라 다릅니다. 하지만 Sprint Planning을 통해 각 화면 or 기능 별로 목표를 설정하면 기획, 디자인, 개발의 대부분의 일정은 조정이 가능합니다.
•
Sprint Plannig 과정에서 주어진 기간 안에 어떤 작업을 하게 될지 상호 인지하면, 서로의 상황을 조금 더 이해 할 수 있습니다.
서로 목표로 한 작업을 진행하기 위해 정해진 일정에 맞게 작업이 진행 되어야 프로젝트가 순항 한다는 것을 알고 있기 때문에 Sprint 내 추가 요청 및 일정 지연의 이슈들이 다른 팀원에게 부담을 줄 수 있다는 것을 알게 됩니다.
그렇기 때문에 Sprint Planning 과정에서 면밀히 검토하고 추가 변경사항이 발생하지 않도록 노력합니다.
2. Sprint 진행 간 Planning 목표 이외의 추가 작업은 추가하지 않을 것~!
•
Sprint Planning에서 목표로 한 작업은 해당 스프린트가 끝날 때 결과물 확인이 가능하다! 라는 경험이 무엇보다 중요하다고 생각합니다.
•
적어도 해당 화면, 기능에 대하여 품질 검수가 가능한 수준으로 목표를 설정하기 때문에 목표로 한 작업의 안정성을 보장 하려면 Sprint 내 추가 요청은 받지 않습니다.
•
이러한 경험이 각 Sprint 를 진행하면서 쌓이게 되면, 남은 Sprint 작업과 비교하여 작업의 완료 일정 및 해당 일정 내 품질 수준을 예측 할 수 있게 됩니다.
3. Sprint 기간은 목표로 한 작업과 일정을 최대한 준수하되, 유연하게 조정은 가능할 것~!
•
Sprint Planning에서 작업의 범위와 일정을 산정하여 진행을 하더라도 일을 진행하다보면 예상치 않게 지연되거나 진행이 불가능한 상황이 생기게 됩니다.
•
퀴즈백과의 경우 기본 2주 정도의 Sprint 주기를 가지고 계획이 되었으나 각 Sprint 전 Sprint Plannig을 한번 더 진행 했습니다.
개발 범위에 조정이 있거나 서버, 디자인 등의 전달 일정이 조금씩 지연이 될 경우 유연하게 일정을 줄이거나 늘려서 진행을 했습니다.
단, Sprint Planning을 다시 진행하여 전체적인 일정에 영향을 주지 않도록 하고, 업무의 난이도에 따라 작업 순서를 조정 하는 등의 방법으로 필요 시 Scrum Team 모두와 협의 후 탄력적으로 수정했습니다.
•
아래 그림은 퀴즈백과의 Sprint Planning 중 일부입니다.
각 Sprint의 일정, 목표로 하는 개발 건, 그리고 상세 개발 내역 및 결과 등을 함께 공유 할 수 있도록 관리했습니다.
각 작업에 대한 Jira 이슈를 생성해서 작업 일정을 Sprint Planning 과정에서 정했고, 해당 작업들의 전체적인 일정이 한눈에 파악이 되도록 아래와 같이 관리했습니다.
처음에는 Jira에서 제공하는 Road Map, 활성 스프린트 등의 기능을 이용했지만 대부분의 회의는 Online으로 진행되었기 때문에 페이지 이동을 최소화 하고 참여자 모두가 한눈에 업무 단위를 파악하여 협의 시 활용하는 페이지로 사용했습니다.
•
Sprint 진행하면서 범위가 축소되거나 변경이 필요할 시 개발 진척도를 확인 후 협의하여 Sprint의 업무 범위를 변경했습니다. (빨간 글씨)
[ Mission #4 ] Sprint Daily Meeting
매일 업무 시작 전 각 담당자가 작성한 이슈 항목등을 체크하고 미팅에서 공유할 사항과 이슈 등에 대해 공유했습니다.
때론 같은 이슈, 해결되지 못하고 잔재하는 이슈들이 쌓이는 경우도 있지만, 매일 관련 내용을 체크하며 목표로 한 업무 중 어떤 업무가 지연되고 있는지 알 수 있었습니다.
또한 급한 확인이 필요한 경우 각 담당자에게 Jira 이슈를 할당하고 구두로 미팅 때 다시 전달함으로써 업무 협조가 빠르게 이뤄질 수 있도록 했습니다.
•
진행 기간 : 2022년 2월 18일 ~ 2022년 10월 14일
•
진행 시간 : 매일 오전 9:30 진행
•
참석 인원 : Scrum Team 멤버 전원 (아이들나라 CO 구성원 Only)
•
작성 방법
◦
Scrum Master가 기본 포맷을 만들어 배포하고 각 담당자들은 자신이 진행하는 업무에 대한 Jira 이슈를 발행 & 해당 이슈에 이슈 발생 시 내용을 간략하게 남김
◦
확인 요청이 필요한 경우 담당자에게 Jira 이슈를 발행하여 링크 추가하고 간략하게 멘트 남김.
◦
전체 공유가 필요한 사항은 내용을 간단히 내용을 남김 (일정, 주요 이슈 등)
•
진행 방법
◦
Google Meet으로 해당 화면을 공유하고 각자 작성한 내용에 대해 이슈 및 공유가 필요한 내용만 설명한다.
◦
Scrum Master는 각 이슈를 확인하고 원인 파악 및 대안을 제시하며 이슈가 해결 될 수 있도록 돕고, 상호 확인 요청한 이슈에 대해 지연이 발생하지 않도록 담당자 지정 및 전달 가능 일정 등을 체크한다.
◦
가급적 15분을 넘지 않도록 진행하며 전체적인 논의, 공유가 필요한 경우 길게 진행하되, 그 외 이슈는 담당자와 따로 진행한다.
[ Mission #5 ] 개발사 주간 보고
퀴즈백과의 경우 Sprint Planning 부터 AOS, IOS, IPTV 앱의 개발 일정을 동일하게 계획 했기 때문에 각 Sprint에서 개발해야 하는 범위는 거의 동일하게 맞추었습니다.
매주 1회 주간보고 시간을 가졌습니다. 그리고 목표로 한 진척도를 확인하며 이슈가 있는지 확인했습니다.
각 플랫폼 특성과 개발 스킬이 다를 수 있기 때문에 진척도가 조금씩 다르지만, 동시에 같은 화면을 개발하기 때문에 다른 플랫폼 개발 건의 진척도를 한 눈에 확인 할 수 있었고, 결과물도 작업완료된 범위 까지 반영된 설치파일(APK, TestFlignt)을 전달 받아 직접 확인& 테스트를 진행할 수 있었습니다.
모바일의 경우 Sprint 중반 부터는 Sprint 기간 내 개발 된 부분에 대해 품질 검증도 함께 진행 되었습니다. 그래서 QA이슈가 전달되면 주간보고 시간에 함께 이슈 원인을 검토하고, 수정된 결과를 확인할 수 있었습니다.
3개의 플랫폼을 동일한 주기로 개발하며 각 상황에 따른 이슈들이 Sprint 진행 간 전달 가능했고, 빠른 해결을 통해 이슈를 Close 할 수 있었습니다.
•
진행 기간 : 2022년 3월 21일 ~ 2022년 10월 28일
•
진행 시간 : 매주 목요일 오후 16:00 진행
•
참석 인원 : Scrum Master, 개발사 PM (AOS, IOS, IPTV)
•
작성 방법
◦
Scrum Master & 각 개발 담당 PM은 Sprint Planning 과정에서 개발 단위에 따른 Jira 이슈 생성
◦
각 개발 PM은 각 화면 단위로 캡처화면을 포함하여 Confluence에 기입
◦
해당 개발 부분이 포함되어 빌드된 설치파일을 업로드 (버전 기입)
◦
이슈 확인 요청 및 QA 이슈 수정 내용 공유
•
진행 방법
◦
약 30분 간 진행. 개발사 PM은 개발 사항 진행 상태 공유
◦
지원 필요 사항이나 이슈 부분을 Scrum Master에게 전달
▪
유관부서의 도움이 필요하거나 Scrum Team 내 빠른 확인이 필요한 경우
◦
Scrum Masters는 주요 공지 및 진행사항 전하고, 전달 받은 이슈에 대해 처리 결과 및 파악된 원인 공유
◦
개발사 주간 보고 결과는 다음날 Sprint Daily Meeting에서 구성원에게 공유. 이슈사항 및 지원요청 받은 내용 또한 전달
[ Mission #6 ] 회고
•
회고의 경우 상호 업무 진행 중 개선이 되면 좋을 점, 다음 스프린트에서 신경써야 할 점 위주로 진행했습니다.
◦
퀴즈백과 프로젝트의 경우 Sprint 진행 초반에 ‘변경된 업무 방식, 기존 문서 작성 → Jira, Confluence 작성 등의 협업 툴로 변경’하는 과정에서 기존 Process가 일부 유지되어 같은 내용을 2번 작성하는 비효율이 발생했습니다.
Ground Rule 대로 진행한 업무였지만 회고 과정에서 관련 의견을 듣고, 협의를 통해 비효율을 개선했습니다. 그리고 업무 진행에 초점을 맞추어 대응해 나갔습니다.
이처럼 상호 업무를 진행하는데 있어 어려움이나 개선점 등을 공유하는 과정이 있어야 함께 협업하고, 불협화음을 줄일 수 있다고 생각합니다.
•
보통 Sprint 사이클을 아래의 순서로 진행을 했는데요. 지속적으로 반복하다보니 회고의 시간을 따로 갖지 않고 Daily Meeting에서 함께 결과물을 공유하고 의견을 말하는 식으로 진행이 되었습니다.
◦
결국 회고라는 과정은 보다 나은 업무 진행을 위하여 소통하는 것으로 구성원이 Sprint 사이클에 익숙해 질 때쯤 되면 대부분의 의견은 Sprint Daily Meeting에서 공유하고, 자신의 의견을 말하기 때문에 별도의 회고 시간을 갖지 않아도 되었습니다.
▪
결국 잦은 소통이 도움이 된 것 같습니다.^^
[ Mission #7 ] 퀴즈백과 관리용 Web/App 개발 (콘텐츠 편성, 검수, QA 대응을 돕기 위한 Side Project!)
개인적으로 진행한 Side Project로 퀴즈백과 콘텐츠 편성, 검수, API 동작 확인, QA 검증 등 다양하게 활용하여 실무에서 사용할 수 있었습니다.
결과적으로 다양한 케이스를 선 확인하고 빠르게 대응 하여 개발 일정을 단축 시킬 수 있었고, 서비스 품질 검증 및 상용 운영 시 이슈 확인용으로 잘 활용하고 있습니다.
< 퀴즈백과 관리용 Web, App의 활용 >
1.
Dummy / Dev / 상용 API 기능동작 확인
a.
Sprint에서 각 화면을 개발하기 전 편성 결과 및 앱 개발에 이슈가 없는지 관리용 앱을 선 개발하여 확인함
b.
API 응답 등을 확인하고 앱 UI를 구성하기 위한 값들이 API를 통해 전달되는 지 확인 → 관리용 앱을 통해 구현까지 완료하고 Sprint에 포함 → 개발사에서는 기능 개발 진행만 하면되도록 환경을 제공하여 결과적으로 개발 일정을 단축 시킴.
2.
퀴즈 문제 풀기 기능 및 Metadata 확인
a.
다양한 퀴즈 Type에 맞게 문제/보기 유형이 전달 되는지, 이미지와 음성파일에는 이슈가 없는지 등 편성된 결과를 실제 앱 동작과 동일하게 구현하여 확인함
b.
API를 통해 전달되는 정보들을 쉽게 확인할 수 있도록 제공 함으로써 개발, 편성, 품질 검증 시 잘못된 부분을 찾아 빠르게 대응함.
3.
퀴즈 카테고리, 이용안내 등의 편성 결과 확인
a.
CMS를 통해 편성된 결과가 정상적으로 노출되는지 확인
4.
모바일, STB 등의 여러 단말, 테스트 환경에서의 동작 확인
a.
Setting에서 서버 및 사용자 설정 값 등을 변경하여 특정 단말이나 사용자에서 발생하는 이슈 확인
5.
퀴즈 검색 기능으로 퀴즈 관련 이슈 원인 파악
a.
퀴즈백과 기능에는 없지만, 3500개가 넘는 퀴즈문제 중 특정 퀴즈문제를 찾기 위해 추가로 API개발 요청하여 적용시킨 기능입니다.
b.
서버종류, 퀴즈 난이도, 카테고리 등의 구분 검색 및 contentID로 검색하는 기능 등을 제공합니다.
운영 QA 중 발견된 이슈
이미지 편성은 정상적으로 되어 있으나 AOS에서 이미지 노출이 되지 않는 이슈
퀴즈백과 관리용 앱으로 원인 파악한 사례
검색 기능을 통해 이미지 노출에 문제가 없는 것을 확인함.
이미지 url을 검색 결과 하단의 편성된 정보란에서 확인하여 편성된 이미지를 확인하고 이미지 용량이 너무 큰 것으로 확인하여 전달
→ 이슈를 출근길에 확인하고 ‘퀴즈백과 관리용 모바일 앱’을 이용해 바로 원인 파악 & 수정요청을 할 수 있었습니다.
퀴즈백과 관리용 Web
퀴즈백과 관리용 APP
[ Mission #8 ] 2022 유아 교육전
서비스 오픈 후 고객에게 서비스를 소개하고, 현장에서 뜨거운 반응을 확인 할 수 있었던 2022 유아교육전~!
•
테이블형 시연 기기 제작에 기술 지원
•
퀴즈백과 제공 기능 중 ‘오늘의 퀴즈 티켓'은 1일 3개만 지원이 되는데 각 단말의 티켓을 초기화 할 수 있도록 관리하는 별도 기능을 개발하여 지원함
•
행사 기간 중 원활한 시연 진행을 위해 기술 지원 및 테스트 진행
시연용 테이블 제작 지원
시연 진행자 용 퀴즈백과 관리용 앱 개발
유교전 진행 기술 지원
2022 유아 교육전
퀴즈백과 IPTV앱 시연
퀴즈백과 체험 테이블
프로젝트 진행 간 느낀 점들
퀴즈백과 프로젝트는 새로운 업무 방식을 도입하고 Scrum Master 역할로 프로젝트를 진행하면서 많은 점을 배우며, 새로운 경험을 했습니다.
프로젝트 진행 간 느꼈던 점들을 간단하게 정리했습니다.
1. 프로젝트 초중반
: 새로운 업무 방식을 왜 도입해야 하는지, 실무에 어떤 도움이 되는지에 대해 다양한 그룹에 세미나를 진행했지만 결국 직접 경험하며 장단점을 느껴야 한다고 생각했습니다.
모두가 처음 시도하는 만큼 좌충우돌 하더라도 프로젝트가 종료 되었을 때 구성원 모두가 '시도할 가치가 있었다'라는 긍정적인 경험을 남기고 싶었던 것 같습니다.
2. 프로젝트 중반
: 이전보다 3~4배 이상의 업무를 소화하고, Scrum Team 멤버들에게도 많은 업무 요청과 피드백을 주고 받으며 서로 긴밀하고 타이트하게 업무를 진행했습니다.
매일 진행하는 Sprint Daily Meeting과 매주 진행한 개발사 주간보고도 몇 개월에 거쳐 반복되다 보니 스스로 업무를 만들어서 하는건가;; 라는 생각도 들었던 것 같습니다.
그래도 Sprint가 반복적으로 진행되면서 구성원 모두가 새로운 업무 방식에 익숙해지고, 스스로 Jira 이슈 발행, Confluence에 문서 작성을 하며 자연스런 Rule로 자리 잡은 시점엔 왠지 모를 뿌듯함을 느꼈던 것 같네요 ^^
하지만.. 지금 프로젝트가 진행되는 방향이 맞는가? 잘 하고 있는건가?
예상치 못한 이슈와 업무 진행에 따라 Sprint Planning을 변경할 때면 과연 계획대로 프로젝트가 잘 마무리 될 수 있을까? 라는 물음을 늘 스스로에게 던지곤 했는데..
그럴 때 CTO님께 조언을 구하고, ‘잘 하고 있다’는 응원을 받은 것이 ‘한번 끝까지 해보자!’라고 생각하게 된 큰 힘이 되었던 것 같습니다. ^^
3. 프로젝트 마무리
: Sprint가 진행될 수록, 구성원 모두가 그동안의 업무에 대한 결과를 Sprint 종료 시점마다 결과물로 직접 확인하면서 자신감을 갖게 된 느낌이었습니다.
이처럼 반복된 경험은 프로젝트 진행에 대한 안정감을 주었습니다. 또한 Sprint 내 품질 검증도 함께 진행되면서부터는 서비스의 디테일을 올릴 수 있었습니다.
이전에는 프로젝트 마무리 시점에 서로 다른 여러 이슈들이 조금씩 쌓여 일정에 영향을 주거나, 품질 검증 입고 시점…그 이후에도 추가 개발을 하게 되는 상황이 발생하곤 했는데..
오히려 Sprint 내 반복된 검증과 꾸준한 이슈 대응으로 프로젝트 마무리 시점부터는 큰 이슈 보다는, 그 동안 발견하지 못했던 엣지 케이스를 대응하고, 새로 제작하는 콘텐츠를 검수 하는 등
확실히 이전과 다른 경험을 하게 되었습니다.
마치며
퀴즈백과 Scrum Master를 경험하며 느낀 점을 한줄로 요약하면 아래과 같습니다.
“충분한 소통, 서로에 대한 업무의 존중, 서비스를 애정하는 마음으로 너의 일 나의 일을 구분하지 않고 일을 할 때 서로에게 믿음을 줄 수 있는 결과를 낳을 수 있다!”
퀴즈백과 프로젝트에 새로운 업무 방식을 도입했지만, 100% Agile 하게 진행된 프로젝트로 보기엔 어려울 순 있습니다.
하지만 프로젝트가 종료 된 후 Scrum Team 구성원들과 회고를 진행했을 때 모두가 끝까지 잘 마무리 된 프로젝트로 기억하고, 그 과정과 결과에 대해 만족하는 모습을 볼 수 있었습니다.
저는 이러한 작은 시도와 경험들이 개인적인 성장 뿐만아니라 조직문화에도 영향을 끼친다고 생각합니다.
퀴즈백과 Scrum Master 경험 이후 저는 Android 개발을 담당하며 함께 협업하는 분들과 충분한 소통을 통해 최상의 결과를 얻기 위해 노력하고 있습니다.
지금의 아이들나라는 운영을 비롯해 프로젝트를 진행할 때도 Sprint 단위로 개발 진행 중이고, 이제는 구성원 모두가 변경된 업무 방식으로 업무를 진행 하고 있습니다.
함께 업무를 진행하면서 느낀 것은 이 모든 것이 주변에 부족한 점을 보완하고 더 발전하고자 노력하는 구성원들이 있어 가능했다는 것입니다.
앞으로도 아이들나라와 새로운 경험을 더 해볼 수 있다는 생각이 드네요 ^^
긴 글 읽어 주셔서 감사합니다 ^^