내가 사용한 애자일(2/2)

우리 팀에서 사용했던 애자일을 정리하고 개선점을 생각하기

 

 

요약하자면 우리 팀은 평일에는 데일리스크럼을 진행하고

스프린트 마다 백로그 리파인먼트-플래닝-스프린트 리뷰-회고를 진행했다.

 

데일리스크럼

어떻게 했는가?

보통 오후 10시에 시작해서 15분~20분 사이로 Discord를 통해 진행했다.

만약에 팀원 중에 일정이 있는 경우에는 약속시간을 미루거나 비동기 스크럼* 방식으로 했다.

 

* 비동기 스크럼은 디스코드 채널에 내용을 공유하고 댓글을 다는 방식이다.

* 데일리스크럼 템플릿
- 기분 점수: 기분 점수는 프로젝트 몰입도나 개인적인 상황을 종합해서 1~10점 이내로 정한다. 
- 오늘 한일/내일 할일 : 진행사항과 어려운점 등을 적는다.
- 공유하거나 도움 요청할 일이 있나요?: 일정을 리마인드하거나 내가 겪고 있는 어려움을 공유할 때 사용한다. 
- 기타 사항들: 새로 배운 것, 사담, 갑자기 떠오른 기획 아이디어 등을 공유할 때 사용한다.

 

좋았던 순간

# 비동기 스크럼에서 더 구체적으로 표현하기

비동기 스크럼에서는 텍스트로 공유하기 때문에 이 사람이 어떤 문제를 겪고 있는지, 내가 얼마나 힘든지 등을 전달하기 쉽지 않다.

그래서 최대한 말하듯이, 일기 쓰듯이 공유했다. 추가적으로 JIRA 링크나 그림도 같이 달아서 이해하기 쉽게 작성하려고 노력했다.

 

초기에 작성했던 비동기 데일리스크럼

개선 한 데일리스크럼

 

 

# 외부자극을 받을 수 있도록 하기

함께 자라기에서는 곱하기 개발자를 외부 자극을 받아들이고 이를 체화하는 개발자로 설명한다.

이 책을 읽고 실험했던 것 중 하나는 데일리 스크럼 시간에 내가 받은 자극을 팀과 공유하는 것이었다.

 

우연히 두잇 CEO의 인터뷰 영상을 접하게 되었는데, 마침 우리 팀이 서비스 기획 단계에서 방향성에 대한 어려움을 겪고 있던 상황이었다.

 

이 사례가 우리 팀의 문제를 해줄 수 있는 계기가 될 수 있겠다고 판단해 데일리 스크럼 시간에 공유했고,

고맙게도 팀원이 영상을 보고 느낀 점을 공유해 주는 등의 좋은 반응을 얻을 수 있었다.

 

데일리스크럼에서 내가 느낀 것들을 공유함

 

# 데일리스크럼 ≠ TODO공유

데일리 스크럼에서 가장 주의해야 할 점은 TODO 공유로 끝나지 않는 것이다.
“나는 이걸 했어요, 나는 저걸 했어요”로 마무리된다면 데일리 스크럼의 의미는 퇴색된다고 생각했다.

 

그래서 나는 데일리 스크럼 시간에 궁금증을 가지려는 태도를 유지했다.

팀원이 공유한 내용에 대해 질문을 던지고, 그 과정에서 내가 가지고 있던 생각을 동기화하려 노력했다.

 

아쉬웠던 점, 개선해야 할 점

# 모호한 기분점수

프로젝트 후반부로 갈수록, 특별히 좋지도, 나쁘지도 않은 상태였고, "아무 생각이 없다"는 표현이 가장 가까웠다.

그래서 "기분점수는 5점에서 6점 정도고요,,, 그냥 별다른 생각은 없습니다"라고 공유했던 순간들이 있었다.

 

하지만 돌아보면 이런 공유가 팀원들에게 과연 의미 있었을지는 의문이다.

커뮤니케이션은 내가 한 말에 대해 상대방의 반응을 어느 정도 예상한 상태에서 이루어져야 하는데,

의도와 맥락이 없는 감정 공유는 팀에 도움이 되기 어려울 것이라 생각한다.

 

 

# 아무것도 하지 않은 데일리스크럼

취업준비와 병행하고 다른 약속 등이 있을 때는 오늘 한일이 없을 경우도 있었다. 심지어는 모두 아무것도 하지않은 날도 있었다..

 

어쩌면 데일리스크럼 주기를 조절해 봤으면 어땠을까 하는 아쉬움이 남는다.

우리는 회사에 소속된 팀이 아니었고, 매일, 매 순간 프로젝트에 집중하기 어려운 상황이었기 때문이다.

그래서 매일이 아니라 이틀에 한 번씩 스크럼을 진행해 보는 시도도 가능했을 것이라 생각한다.

 

백로그 리파인먼트

어떻게 했는가?

1. 프로덕트 백로그 작성

본인이 생각하기에 필요하다 생각하는 태스크들을 각자 적는 아이디에이션 시간

 

2. 우선순위 매기기

프로덕트 백로그들을 상/중/하로 우선순위를 매긴다.

 

3. 백로그 리파인먼트 

우선순위가 높은 백로그부터 디스커버리를 진행했다.
해당 태스크를 수행하기 위해 필요한 작업은 무엇인지, 사전에 논의되어야 할 사항은 무엇인지 정리하고 공유했다.
이 과정에서 서로 궁금한 점을 질문하며 맞춰 나갔다.

 

백로그 리파인먼트는 태스크를 더 깊이 이해하는 단계라고 느꼈다.

“이 기능을 구현하려면 이런 부분까지 고려해야 하는구나”, “내가 이 부분을 잘못 이해하고 있었네”

와 같은 생각을 하게 되었고, 그만큼 요구사항과 구현 범위에 대한 이해도가 높아지는 계기가 되었다.

 

스프린트 플래닝

어떻게 했는가?

스프린트 플래닝에서는 플래닝 포커를 활용해 스토리 포인트를 산정했다.
스토리 포인트는 작업 시간이 아니라, 불확실성을 기준으로 측정했다.

 

예를 들어

“이번 스프린트 안에 끝낼 수 있을지 모르겠다”
“기술적으로 구현이 가능할지 확신이 없다”

 

와 같은 불안 요소들도 모두 포인트 산정에 포함된다.

 

실제로 같은 태스크라도 나는 2점이었지만, 다른 팀원은 13점으로 평가되는 경우도 있었다.

나는 익숙하지만 다른 사람은 익숙하지 않거나, 내가 모르는 리스크를 떠올리고 있기 때문이라고 느꼈다.

이 과정에서 각자가 생각하지 못했던 고려 사항들이 공유되었고, 팀 전체가 동기화되어 갔다고 생각한다.

 

스토리 포인트가 20점 이상인 태스크의 경우에는 작업을 더 작은 단위로 쪼개는 방식을 적용했고,
최종적으로는 스토리 포인트를 기준으로 이번 스프린트에서 가져갈지 여부를 결정했다.

 

좋았던 순간

# 플래닝과 백로그를 통합하기

스프린트 1주는 꽤 짧았다. 백로그와 플래닝은 보통 각각 1시간씩 걸렸고 우리가 백로그, 플래닝, 회고를 스프린트마다 진행하는데 힘이 들었다. 그렇기 때문에 자연스럽게 플래닝과 백로그를 연속으로 진행하려고 했다.

 

# 이전 플래닝 포커 가져오기

플래닝 포커에 대한 스토리포인트 점수는 사실 엄청 모호하다.

예를 들어서 비슷한 기능이라도 당시의 느낌에 따라서 점수가 미세하게 달라질 수 있다.

내가 저번 플래닝에서는 7점을 줬는데 4점을 준다거나 할 수 있다.

 

그렇기 때문에 일관된 스토리포인트를 부여하기 위해서 아래와 같이 이전 스프린트 내용을 가져와서 포커할 때 참고했다.

이전 스프린트 내역을 캡처해서 표로 만들어달라고 GPT한테 요청함

 

아쉬웠던 점, 개선해야 할 점

# 우선순위가 낮으면 영원히 백로그에

우선순위가 낮다고 분류되는 일들이 있다.
Kotiln Lint 적용처럼 서비스에 직접적인 변화는 없지만, 장기적으로는 도움이 되는 작업들이다.

 

이런 일들은 “나중에 하자”는 생각으로 스프린트에 포함하지 않았다.

당시에는 다른 작업들을 더 우선순위가 높다고 보았기 때문이다.

 

이 작업은 진짜 우선순위가 낮은 일이었을까?

다시 생각해 보면, 이 일에 대한 가치를 충분히 설명하지 못했던 것 같다.

다음에는 “그냥 내가 할게”로 끝내기보다, 왜 이 1시간이 나중의 시간을 줄이는지를 설득하는 경험을 하고 싶다.

 

회고

어떻게 했는가?    

매 스프린트가 끝날 때마다 회고를 진행했다. 회고는 FigJam을 활용해 약 1시간 동안 진행했다.

회고는 크게 두 가지로 나누었다.

• 스프린트 회고: 각 스프린트에서 진행한 작업과 그 결과를 돌아보는 회고
• 목적 회고: 특정 주제를 정해 논의하는 회고, 1차 MVP의 광고 성과가 기대에 미치지 못했기 때문에, 실패 원인을 분석하고 향후 개선 방향을 도출하려는 목적으로 진행해 보았다.

 

스프린트 회고 중 하나

 

좋았던 점?

# 회고 시간 줄이기

보통 1시간 정도 회고를 진행했는데, 초반에는 회고에 걸리는 시간이 1시간 반이 넘고 이래서 힘들기도 하고 최대한 줄이기 위해서 여러 가지 노력을 했다. 만약 완료되지 않더라도 꼭 필요한 것들만 하기, 만약 꼭 해야 하는 것들이 있다면 각자 한 개씩 말하거나 하기

 

아쉬웠던 점, 개선해야 할 점

# Action Item은 실행할 수 있는 단위로

회고 과정에서 각 이슈에 대해 논의하고, 이를 반복하지 않거나 더 잘하기 위한 Action Item을 도출했다.

다만 일부 Action Item이 실제로 지켜졌는지 판단하기가 모호했던 부분이 있었다.

 

“언어가 다르긴 하지만 다이어그램 같은 걸로 도식화해 보면 어떨까요?”

 

예를 들어서 왼쪽그림에 있는 Action Item은 겉보기에는 그럴듯하지만, 실제로 무엇을 해야 하는지는 명확하지 않았다.
즉시 실행할 수 있는 Action Item이라면 다음과 같은 요소가 포함되어야 한다.

• 어떤 상황에서
• 어떤 다이어그램 툴을 사용해
• 무엇을 도식화하고
• 어디에 공유할 것인지

 

반면, 오른쪽 그림과 같은 Action Item은 실행 단위가 명확했다.
스프린트 백로그 작성 시 태스크와 기대하는 결과를 함께 작성함으로써 요구사항이 모호해지는 문제를 개선하고자 했다.

구체적으로는 다음과 같이 정의했다.

1. 스프린트 백로그에 태스크와 기대하는 점을 함께 작성한다.
2. 스프린트 중반 이전에, 구체적인 수치를 포함해 JIRA에 기록한다.

이 경우에는 무엇을, 언제까지, 어떻게 해야 하는지가 분명해 Action Item의 실행 여부를 확인할 수 있었다.

 

개선해야할 Action Item(왼쪽), 잘 작성했다고 생각하는 Action Item(오른쪽)

 

다음에 시도해 볼 Action Item

다음에 애자일을 경험해 볼 때, 시도해 볼 만한 Action Item

• 기술&소프트스킬 자료를 읽고 프로젝트와 연관된 내용이 있을 경우, 핵심 인사이트를 정리해 데일리스크럼 시간에 공유하기
• 데일리 스크럼에서 공유 내용이 없는 경우가 3회 이상 발생하면, 스크럼 빈도를 주 3회로 줄이는 안을 팀에 제안하기
• 백로그 우선순위에 대한 이견이 발생할 경우, 해당 백로그가 어떤 목표에 기여하는지 한 문장으로 정리해 설명하기