by
Jul 02. 2023
#5 스크럼, BDD, 스프린트 회고
2023년 26주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/39
다음 회고 ☞ https://brunch.co.kr/@327roy/44
인트로
#1 6월 동안의 데일리 노트와 주간 회고
6월 동안 데일리 노트와 주간 회고를 작성하는 개인적인 챌린지를 종료했다. 평일 출퇴근을 최대한 잘 활용하기 위한 챌린지 중 하나였는데 무사히 성공하게 되어 기쁠 따름이다.
데일리 노트를 시작할 때 설정했던 목표를 간단하게 체크해 보자.
1. 회고의 습관이 만들어진 것 같은가? ☞ Yes
2. 출퇴근 시간을 알차게 보냈는가? ☞ Yes
3. 매주 좋았던 점, 아쉬웠던 점, 개선할 점, 그리고 액션 아이템을 뽑았는가? ☞ Soso
4. 회고록을 DB화 시켰는가? ☞ Yes
1. 회고의 습관이 만들어진 것 같은가? ☞ Yes
회고를 하는 습관이 생긴 것 같다. 퇴근 시간 지하철에서 자연스럽게 탭을 열고 회고를 작성하고 있는데, 이 덕분에 매일 생생한 경험들을 담을 수 있게 되었다.
2. 출퇴근 시간을 알차게 보냈는가? ☞ Yes
출퇴근 시간이 왕복 3시간쯤 걸린다. 그래서 생긴 아침 루틴은 오전 6시 50분쯤 출근을 하며 1) 말해보카 일일출석, 2) 아웃스탠딩 등 아티클 읽기 혹은 독서, 3) 아이보스 마케팅 핫토픽 퍼 나르기를 시작으로 퇴근할 때 4) 회고 작성으로 마무리한다. 3시간 중 2시간은 유의미하게 쓰자가 목표였는데 나름 잘 지켜진 듯하다.
3. 매주 좋았던 점, 아쉬웠던 점, 개선할 점, 그리고 액션 아이템을 뽑았는가? ☞ Soso
주간 회고 작성 시, 노트를 짜집기해서 작성하는 터여서 KPT(Keep, Problem, Try)나 액션 아이템을 선정하지는 않았다. 소소하게라도 이를 주간회고마다 정리할 수 있도록 프레임워크를 만들어 봐야겠다.
4. 회고록을 DB화 시켰는가? ☞ Yes
작성한 데일리노트(회고록)는 노션 DB에 잘 쌓아두고 있다. 굳이 노션 DB에 쌓아두는 이유는 CSV로 추출하기 위함이다. 다음 달 내, 6월 회고 DB에 대한 1) 회고록 토큰(Token)화, 2) 이를 통해 자주 사용하는 키워드 빈도수 파악, 3) 워드 클라우드 생성, 4) 사용 빈도가 높은 키워드에 대한 긍정/부정 분석을 해볼 생각이다. 챗GPT와 Pycham을 사용할 생각이고, 1~3번까지는 금방(?) 가능할 것 같은 느낌이 든다. 어제 프롬프트 초안을 짜고 테스트를 돌려봤기 때문. 워드 클라우드 생성하는 것까지는 오픈 API가 있는 것을 확인했다. 4번은 확인 후 가능하다면 진행해 볼 예정
노트
#2 오랜만에 클럽하우스! 주제는 스크럼
#퍼즐러 #스크럼
금일 내가 몸을 담고 있는 기획 커뮤니티, Puzzler의 클럽하우스 세션에서 재밌는 주제를 다뤘다. 주제는 바로 '스크럼이 개발자를 괴롭히는 9가지 이유'. 해당 주제에 대해 세션 진행자가 경험한 인사이트를 기반으로 의견을 공유하는데, 주 내용은 '위 글의 내용에 반대'하는 것이었다.
반대의 큰 이유는 위 글에서 말하는 스크럼의 비효용은 스크럼이 성숙한 곳에서 일어날 것이라는 것. 나 또한 글의 내용을 읽어보다 "개발자들이 알아서 동기부여받고, 제품과의 싱크도 잘 맞추고, 일정을 굳이 정하지 않아도 알아서 잘하는데 왜 괴롭히냐."라는 뉘앙스를 강하게 느꼈고, 이런 부분에서는 세션 진행자가 한 말에 십분 공감했다. 모든 것을 개발자에게 맡겨도 되는 환경은 굳이 방법론이 필요하지 않을 것이다. 그들이 알아서 일을 챙겨서 할 것이니까.
하지만 이런 이상적인 환경을 쉽게 접하기는 힘들다. 우리는 살아남아야 하고, 그러기 위해선 경쟁 서비스보다 빨리 기능을 내놔야 하며 이 때문에 일정의 압박이 생길 수밖에 없다. 당장 스크럼을 쓰며 일정 압박을 느끼는 회사에서 스크럼을 사용하지 않는다고 일정 압박이 없어질 것은 아니기 때문에 글을 읽으면서 다양한 상황을 함께 고려할 수 있어야 할 듯하다.
무엇보다 리뷰와 회고는 꼭 해야 한다고 생각한다. 스프린트 회고 때 해결되지 않는 문제의 원인만 내놓는 것이 비효율적이라는 것은 공감하지만, 회고란 우리가 잘한 것, 부족했던 것, 시도할 것 등 다양한 인사이트를 함께 공유하는 자리라고 생각한다. 그래서 리뷰와 회고는 중요하다.
결국 나도 세션 진행자와 동일하게, 스크럼을 반대하는 의견에 반대하는 입장이다.
※ 퍼즐러가 궁금하다면? ☞ https://brunch.co.kr/@everythingisgag/243
#3 바로 알기
#워크숍
1박 2일로 회사 워크숍을 다녀왔다. 주제는 '긍정'과 '나 바로 알기'.
신규 수시 입사자들이 모여서 진행한 워크숍이었는데, 수시 입사자들이 모인 만큼 경력이 쟁쟁한 분들이 많았다. 미국, 과테말라에서 살며 N개 국어를 구사하시는 분들 등 재밌는 커리어를 가지고 계신 분들이 많았다. 당연히 그들이 속해 있는 부서들도 다양했고.
1박 2일이라는 짧은 시간이었지만 다양한 부서원들과의 네트워크를 구축할 수 있어서 좋았다. 회사에서도 HRD라는 목적이 있겠지만, 직원들이 모일 수 있는 명분을 만들어주기 위해 열었을 터였으니 모두에게 아주 이득이 많이 되는 자리였지 않을까 싶다. 그리고 모두들 진심으로 즐기는 것 같아서 좋았다. 커리큘럼 짜느라 고생한 우리 HRD 프로들에게 박수 (짝짝짝)
긍정은 현재 상황을 인정하고 직면하는 것이라고 생각한다.
명상도 되게 좋았다.
#4 BDD
#BDD #행위주도개발 #개발방법론 #방법론
회사에서 프로세스에 대해 고민이 많은 똑똑한 개발자 분과 오후에 잠깐 인터뷰를 가졌다. 주제는 BDD(Behavior Driven Development, 행위 주도 개발), 소프트웨어 개발 방법론 중 하나로서 개발자와 비개발자 간의 협업 과정을 강조하고, 사용자의 행위를 작성하여 이를 통해 개발을 진행하는 방식이다. 즉, 사용자의 행위를 미리 예상하고 결과를 테스트해 보는 개발 방법이다. (Test Driven Devleopment와 유사한 이유는 TDD에서 파생된 개발 방법론이기 때문이다.)
TDD vs BDD ⓒ Claudia RocaBDD를 진행할 때 보편적으로 사용하는 프레임워크가 있다. 1) Given(주어진 환경), 2) When(행위), 3) Then(기대결과) 기준으로 유저 스토리를 만드는 것.
BDD's user story framework예를 들어 “유효한 전화번호를 입력된 상태에서 인증 버튼 클릭 시 인증번호 문자를 전송하고 인증번호를 입력하는 인풋박스를 노출한다.”라는 유저 스토리가 작성되어 있다고 하면 아래와 같이 정리할 수 있다.
1) Given: 유효한 전화번호가 입력된 상태
2) When: 인증 버튼 클릭 시
3) Then: 인증번호 문자를 전송한다. / 인증번호를 입력하는 인풋박스가 노출된다.
이전에 이 방법론을 적용해서 사이드 프로젝트를 해본 적이 있었는데, 당시 느꼈던 점은 제품 혹은 개발해야 하는 기능의 덩치가 커질수록 BDD를 원래 취지대로 적용하기 힘들었다는 점이었다.
이유는 작업(Task)의 단위가 되는 Then(결과)들이 너무 많아진 것이었다. 제품의 모듈 하나를 통째로 BDD 형식으로 개발하려다 보니 각 기능별 의존성을 고려해야 했고, 오히려 기획 쪽에서 명세해야 했던 것들이 많아져 Then이 끝없이 생겨나 움직임이 오히려 애자일하지 않게 되었다. (BDD, TDD 등 개발자들이 주도로 이런 시나리오, 스토리들을 함께 고려했으면 좋았겠지만 당시에는 그러지 못했던 것도 컸다.)
따라서 했던 생각은 1) 제품이 이미 완성되어 있고, 2) 개선 혹은 개발해야 하는 범위가 작으며, 3) 제품 증분을 통해 고도화를 진행하는 경우에는 이를 잘 활용할 수 있을 것 같고, 덩치가 크거나 모듈이 덕지덕지 붙은 프로덕트를 신규 개발하는 데는 실제 적용하기에 심적, 물리적 허들이 많을 것 같다는 느낌이었다.
이 주제로 내가 느끼는 프로세스에 대한 내용을 인터뷰 답변으로 공유드렸다. 여기에서 그분이 집중했던 부분은 기획자의 업무를 어디까지 볼 것인지였다. 상세 기획이라는 역할을 제품 출시 사이클의 앞단에서 뒷단으로 바꾸는 것에 대해 특히 관심이 많아 보였다.
- 앞단: 기획자가 유저 스토리 설정 → 기획자가 정책 설정 및 상세 기획 → 디자인 → 개발
- 뒷단: 개발자와 함께 유저 스토리 설정 → 기획자가 정책 설정 및 유저 스토리 정정 → 개발 및 디자인, 필요시 상세 기획
물론 나도 비슷하고 재밌는 상상을 하긴 하지만, 실제 구성원이 많았을 때 이것이 잘 동작할지는 미지수라고 생각한다.
#5 스프린트 회고
#스프린트회고 #회고
벌써 이번 스프린트가 종료되었다. 현재 조직은 스크럼 프레임워크에서 제안하는 정석적인 절차를 모두 따르는 중이고, 오늘은 스프린트의 마지막 날인 만큼 간단한 리뷰와 회고를 진행했다.
※ 스크럼(Scrum) 절차: 스프린트 플래닝(1d) → 스프린트!(데일리 스크럼, 8d) → 리뷰 및 회고(1d)
리뷰는 개발이 완료된 기능에 대해서 간단하게 시연(생략할 때도 많다고 함)을 가지고 격려와 피드백을 주고받는 정도로 마무리하며, 스프린트의 피날레인 '회고'를 본격적으로 진행한다.
현재 조직에서는 회고 시에는 대부분 개발에 대한 얘기 어서 기획자가 바쁜 경우에는 요약본을 보는 정도로 갈음하기도 한다. 일단 나는 분위기와 상황 파악을 위해 참석했다.
이번 스프린트 회고의 주요 주제는 배포 프로세스였다. QA 역할이 기획과 개발자들에게 반반 넘어간 상황이어서 배포까지의 프로세스 또한 개발자들의 QA가 포함되는 형태로 개선될 필요가 생겼는데, 효율화를 위해 이것저것 시도 중이었고, 오늘은 그 시도에 대한 회고를 진행했다. 기억에 남는 안건은 1) End-to-end 테스트를 입고 시마다 해야 하는지(개발 서버에서 QA 서버, 혹은 QA 서버에서 Staging 서버), 2) 서로 다른 개발자의 산출물을 검증하는 형식이 과연 효과가 있었는지(A 개발자는 B 개발자, B 개발자는 C 개발자, C 개발자는 A 개발자의 산출물을 검수)였다.
※ End-to-end(E2E) 테스트란 프로덕트를 사용자 관점에서 처음부터 끝까지 테스트해 보는 것을 의미한다. 현 조직의 경우 사용자 시나리오를 기반으로 환경을 세팅하는 것부터 전수 검증을 진행하는 의미로 자주 사용하는 듯하다.
