애자일을 도입하면서 느낀 점

먼저, 프로젝트의 스케일이 상당히 크기도 하고 Client와 Server로 나뉘어 있었기 때문에, waterfall만으로는 정확히 뭐가 필요한지 파악이 힘들었다. 이에 따라 클라이언트와 서버가 너무 따로 노는 느낌이고, 상호간의 피드백도 힘들었다. 이에 따라 애자일 개발론을 적용시켰다.

 

스프린트를 일주일로 잡고, 하나의 큰 feature 개발을 목표로 두고, 단기 계획을 짜고 개발을 시작했다. 단기적인 작은 목표가 하나 있으니까 개발 속도가 매우 빨라진 것을 알 수 있었다. 아래는 우리 프로젝트의 커밋 인사이트이다. 참고로 스프린트는 7월 12일부터 시작하였다.

그리고 서버와 클라이언트가 모두 한 섹터를 보고 작업을 하다보니 상호간 필요한 요구사항, 버그 리포트, 피드백이 많아졌고 이는 많은 commit과 코드 향상을 촉진시켰다.

무엇보다도, 적용하기 전에는 개인 프로젝트를 하고 있는 것처럼 느낄 정도였어서 지루함이 컸다. 하지만 애자일을 도입하고 난 뒤, 매주가 즐거웠다. 내가 지금 협업하고 있다라는 느낌을 정말 많이 받았고, 이를 통한 발전도 많았다. 예를 들면, Code Review를 할 때 최대한 기분이 나쁘지 않으면서도 내 의견을 제대로 어필할 수 있는 방법을 고민해본다든지, 아니면 효율적인 의사소통을 어떻게 해야할지와 같은 것들을 생각해보면서 말이다.

 

말이 옆으로 새는 것 같긴 하지만, 최근에 내가 의사소통에 있어 지향해야할 점들을 고민해보았는데 그것들을 나열해보고자 한다.

 - 말하기 전에 미리 생각을 정리하자.

 - Code Review를 남길 때, 문제 원인과 해결 방안을 동시에 제시하자.

 - 회의 때는 잡담을 삼가고, 최대한 '효율적인' 대화를 하자. 대화 내용이 핵심만 담고 있으며 의도가 명확해야한다. 동시에 이것만으로 이해가 안 될 것 같다고 느껴지면 예시를 붙여주자.

 - PR을 완성할 때, 이견 없이 바로 approved될 만큼 꼼꼼하게 코드를 작성한다.

 - 상대방의 PR을 검토할 때 코드를 읽기만 해서는 안 되고, 이해해야한다.

 - 내 PR에 대해 팀원이 리뷰를 남겼다는 것은 내 코드를 제대로 봐주고 있다는 증거가 된다. 리뷰에 대해 감사함을 느껴야한다.

 - 의견을 내지 않는 것은 프로젝트의 방향성이 안 좋은 길을 향하게 하는 지름길이다. 생각난 것이 있다면 최대한 어필해야한다.

 - 팀원에게 돋보이는 장점이 있다면 배워야한다.