Agile Team - How do we work?

현재 직장인 Agile 팀 일한지 1년 5개월째, 이번 글은 약 1년 동안 느낀 애자일 조직 문화를 주제로 써보려고 한다.

입사 전, "애자일" 이라는 단어만 들었을 땐 무슨 개발 용어인줄 알았다. 현재 팀에 합류한 뒤 온보딩 과정에서 애자일 방법론에 대한 교육을 받았을 때, 적지 않은 충격을 받았던 기억이 난다.

이전 회사에선 워터폴 방식으로 업무를 했었기도 했고, 모든 개발팀은 다 그런식으로 일하는 줄 알았기 때문이다.

애자일과 워터폴은 프로젝트 방법론으로, 조직의 특성에 맞게 알맞은 방식을 채택하여 사용한다. SaaS(Software as a service) 제품을 개발하는 우리는 팀의 특성에 맞게 애자일 방식을 채택하여 운영중이다.

간단히 설명하자면,

우리 팀은 애자일 방법론 중에서도, Scrum이라는 방식을 사용하고 있다.

우리 팀이 일하는 방식을 하루 일과를 통해 알아보자🙌

10:30am - 데일리 미팅

다들 각자 할일이 명확하게 정해져 있기 때문에 하루 일정을 자유롭게 사용하면 된다.

나는 보통 코드 리뷰할 일이 있다면, 오전에 리뷰를 요청드려서 오전 시간을 보내는 편이다.
(우리 팀은 PR이 아닌 1:1 또는 1:2 코드 리뷰를 하기 때문에 시간이 꽤 소요된다)

점심 시간은 자유롭게 편한 시간에 사용하고, 오후 업무를 시작한다.

오후 일정도 특별한 일은 없고, 데일리 미팅 때 정한 todo를 이어서 하면 된다.

sprint planning
2주 주기로 있는 스프린트 회의는 PO(Product Owner)의 주도 하에 앞으로 2주동안의 계획을 짠다.

기획, 개발 팀은 필수로 참여하고, 영업/마케팅 팀은 영업적 측면에서 고객의 요구사항 등 필요한 기능들을 전달한다.

돌아가면서 짧게 회고를 하고, 각 이슈에 대한 내용을 공유하며 해당 이슈에 대한 estimation을 한다.

작업이 어느 정도 소요될지를 정하는 단계이며 스프린트 회의의 핵심이라고 할 수 있다.

1d, 3d 등 day 기준으로 estimation이 이루어지고, 디테일한 일정은 개발팀끼리 따로 2차 플래닝 때 정한다.

2차 플래닝 때는, estimation이 된 이슈를 가지고 세부 계획을 짠다.
만약 2d(1d = 6h) 기준 짜리 작업이 있다면, 시간 단위(h)로 또 일정을 세운다.

ex)

2주라는 짧은 기간동안 작업한 것들을 상용에 배포시키기 때문에 성취감이 잘 느껴진다.
미리 2주동안의 계획이 있기 때문에, 급하게 요청받을 일이나 계획에 없던 작업이 생길일이 거의 없다.
(크리티컬한 버그를 급하게 수정해야 할 일이 아니라면)
각자 주도하에 todo만 잘 해낸다면, 일정이 자유롭다.
(회사의 분위기에 따라 다르겠지만, 만약 오늘 6h가 걸리는 일을 3h 만에 끝냈다면? 그냥 퇴근해도 아무런 문제가 없다!!)
기획, 디자인 일정에 영향을 받지 않는다.
- 만약, 워터폴 방식이라면 기획이 늦어지면 디자인, 개발을 진행하기 어렵다.
- 애자일 방식은, 기능 단위로 기획-디자인-개발-테스트-배포가 진행되기 때문에 기획 + 디자인이 완료된 다른 기능 개발을 시작하면 된다.

2주 스프린트가 계속 반복되기 때문에 일의 강도가 높은 편이다.
- 이 부분도 팀마다 다를 순 있겠지만 보통 일정이 여유로울 때도 있고 빡빡(?)할 때도 있는데, 일정한 강도의 업무가 계속 이어져서 지치기 쉽다.

(최근 팀에 합류한 동료의 말에 따르면, 처음에 적응하기 어려웠다고 한다)

보통 스프린트 플래닝 하는 날엔, 하루 종일 플래닝을 하기 때문에 끝나고 나면 기가 엄청 빨릴 때도 있다😅😅

그래도 지금까지 경험하기에 단점보다 장점이 훨씬 많고, 개인적으로도 잘 맞는 업무 방식이기 때문에 충분히 만족하고 추천할 만한 개발 방법론이라고 생각한다.

이번에 이렇게 글을 작성하면서, 다시 한번 이상적인 애자일 팀에서 일하고 있다는 생각이 들었다. 시니어 분들이 이미 애자일에 경험이 많으신 분들이라 시스템화가 잘 되어있고, 항상 더 효율적인 업무 방식을 고민하시기 때문이다.

애자일 방식을 채택하지 않은 팀에 간다면 적응하기 힘들 정도로, 잘 적응이 되었고 애자일의 스크럼 이외에도 더 좋거나 공유하고 싶은 개발 방법론이 있는지 알아봐야겠다.

DEV Community