brunch

매거진 소프트웨어 퀄리티 엔지니어링

라이킷 6 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 전현수 Apr 15. 2020

애자일에서 항상 잊어버리는 것

정해진 것은 아무것도 없다

애자일

Agile methodology (애자일 방법론)은 소프트웨어 개발 주기 동안 개발과 테스트의 지속적인 반복을 추구하며, 워터폴과는 다르게 개발과 테스트가 동시에 수행되는 방법론이다.

애자일의 핵심은 다음과 같다:

공정/프로세스 및 도구보다는 개인 및 팀원 간의 상호작용

잘 정리된 서류/문서보다는 실제로 작동하는 소프트웨어

회사의 계약 관계/협상보다는 유저와의 관계

계획에 발이 묶이기보다는 변화에 맞춰 대응

애자일은 소프트웨어 설계에 대한 점진적이고 반복적인 접근 방식을 제안해준다. 워터폴 모델과 비교했을 때 구조화되어있지 않다. 애자일 방법론 중 하나로, Scrum (스크럼)을 가장 많이 쓴다. Sprint라는 주기를 이용하여 다음과 같은 주기를 반복한다:

Backlog Refinement (Grooming) > Planning > Daily Scrum > Retrospective

보통 스크럼이 진행되는 팀에는 프로덕트 매니저 (PM), 개발자 (Software Engineer), 디자이너 (Designer), QA가 있고, 때에 따라 스크럼 마스터 (Scrum master), 팀 리드 (Team lead) 등 여러 포지션들이 필요에 따라 추가되기도 하며 빠지기도 한다.

많이 알려진 것이 2주 스프린트 주기이다. 하지만 항상 알아둬야 할 것은, 애자일은 절대 프로세스와 계획이 묶여서는 안 된다. 2주도 한 회사에서의 추천이지, 이것이 어디든 다 적용된다는 것도 아니다. 주변에서 흔히들 아 이 스프린트라는 건 우리한테 안 맞아 라고 하는 곳들을 보면, 대부분 2주 스프린트를 시도해보고 마는 경우가 대부분이었고, 다른 주기를 시도해보려고 하지 않았다. 2주라는 기간 안에 갇혀있을 필요가 없다. 나는 3주 스프린트, 한 달 스프린트도 해보았고, 각 팀과 그때마다 구현해내려는 기능들에 따라서 변화시켰다.

Refinement가 끝난 task는 팀원들이 다 같이 필요한 시간을 예상해본다. Time Estimation은 Story point, 실제 필요시간, S/M/L/XL 등 여러 가지 방법이 있다. 이 방식 또한 각 팀에 맞는 방식을 찾아 사용해야 한다. 예를 들어 한 팀은 Story point를 시도해봤다. 하지만 개개인이 생각하는 스토리 포인트의 개념이 처음에는 조금씩 다르다. 이 의견이 여러 번의 반복된 주기 이후에도 협의가 되지 않는다면, 다른 방식의 예상 방법은 사용해볼 수 있다. 실제로 나는 지금 팀에서는 Story point와 실제 시간을 합치는 것을 제안해 사용하고 있다. 1은 1일 이내, 3은 1-3일, 5는 4-5일, 8은 6-8일, 13은 9-10일로 정해놓고 있다. 또한 한 가지 중요한 점은, 이는 예상시간이며, 정확하게 필요한 시간을 맞추기 위해서가 아니다. 이는 예상이 어느 정도 가능한 크기의 일인지를 파악하기 위해서, 그리고 정해진 주기 안에 맞춰 계획할 수 있는 크기의 일인지 알기 위해서이다. 한 가지 팁이 있다면, 항상 예상은 한 포인트 더 크게 잡는 것이 좋다. 사람일은 모르는 것이니까. 갑자기 내 노트북이 망가질지, 인터넷이 끊어져서 하루 종일 일을 못할지 누가 안 단말인가. 언제나 Buffer를 잊지 않아야 한다.

Daily scrum은 스프린트 주기 동안 진행되는 일들이다. 보통은 daily standup을 진행한다. 매일 정해진 시간에 팀원들이 다 같이 모여서, 스프린트에 관련해서 어제, 현재 그리고 오늘 진행될 일에 대해 업데이트를 한다. 정기적이고 꾸준히 팀원들 간에 소통을 하여 서로의 진행과 문제점들을 알고 서로 도울 수 있다. 간단한 질문이나 문제가 있다면 바로 이야기를 꺼내서 간단하게 상의하거나, 더 시간이 필요하게 된다면 따로 미팅을 잡아 진행하게 된다.

Retrospective는 보통 스프린트 마지막 날 팀원들이 다 같이 모여 지난 스프린트에 관해 리뷰를 하는 시간이다. 어떤 부분이 잘되었고, 어떤 부분이 안 좋았는지 프로젝트나 task 자체에 대해서도 이야기 하지만, 스프린트에 관련된 문제들도 나누어서 좀 더 팀이 효율적으로 일할 수 있는 방향으로 개선할 수 있다. Estimation 방식이 전혀 도움이 안 된다던가, 한 스프린트에 계획된 task가 너무 많았다던가.

Kanban (칸반) 또한 많이 사용되는 방식 중 하나이다. 칸반은 완성 단계를 따라 (To Do, In Progress, Done) 각 단계에서 제품에 대해 수행해야 하는 모든 정보가 들어있는 카드를 뜻한다. 스크럼이 어떠한 기간적 주기를 두고 그에 맞춰 우선순위에 따라 계획하여 개발하는 방식이라면, 칸반은 이러한 기간적 주기를 정해두지 않고 각 task에 대한 status에 집중하여 계속해서 개발하는 방식이다. 그래서 마감기간을 전체적으로 정해두지 않고서, 우선순위를 필요한 때에 언제든지 변경하며 진행할 수 있다는 장점이 있다.

수 없이 잘못 적용하는 사례에서 벗어나자

애자일 집중 트레이닝 코스를 밟았다. 애자일 방법론을 도입할 때 가장 중요한 부분은 Trial & Fail이다. 열심히 시간을 투자해서, 처음 애자일 방법론의 계획을 가져와서 이대로 가자!라고 한다면 이미 실패한 것이다. 애자일의 핵심은 계획에 따라 움직이는 방식이 아니기 때문이다. 애자일은 각 팀의 '사람들'에 따라 최적화된 모델이 달라진다. 그러므로 팀원들끼리 한 가지씩 시도해보면서, 리뷰를 해보고, 팀 내에서 계속해서 발전시켜가야 하는 게 애자일의 현명한 도입 방식이다. Retrospective도 이를 위해 존재하는 것이다.

각 팀이 일하는 방식과 주어진 일의 타입에 따라서 맞는 방식을 사용하는 것이 좋다. 예를 들어 서비스 데스크팀이라면 꾸준히 들어오는 의뢰와 갑자기 들어올 수 있는 중요한 일들을 빠르게 처리할 수 있도록 하려면 칸반이 좋은 방식일 것이다.

가장 말이 안 되는 말은 "애자일은 정석대로 따르기 어렵다"이다. 처음에도 짚고 넘어갔지만, 애자일은 계획을 정해놓고 절대 그에 강제적으로 따르려고 하면 안 된다. 계획은 하되, 유연해야 한다. 갑자기 급한 일이 생겨서 현재 이미 진행 중인 스프린트를 전부 재조정할 수도 있고, 스프린트에 계획을 너무 많이 해서 다음 스프린트로 task가 넘어가는 일이 생길 수도 있다. 스프린트 안에 내가 하던 일을 끝내지 못하면 실패했다고, 완료하지 못했다고 생각될 수 있지만, Progress에 집중하는 것이다. 스크럼을 꼭 따를 필요도 없다. 현재 하는 일에, 팀에 맞지 않는다면 과감하게 다른 방식으로 바꾸면 된다. 다만 모든 문제는 retrospective에서 팀원들과 얘기하고 이러한 일들이 발생했을 시의 대처 방법, 그리고 예방법을 팀으로서 논의해보고 차차 개선해 나가 보는 것이다.

Agile의 뜻은 "민첩한, 재빠른"이다. 빠르고 안정적인 소프트웨어 개발 주기 환경을 조성하기 위해 시작되었다. 애자일은 반복적인 주기를 통해 계속해서 조금씩 개발 주기 환경을 바꿔 팀의 효율성을 발전시키는 것이 포인트이다.