애자일(Agile) 방법론을 내 경험을 바탕으로 다시 이해하며

대학교 시절 전공 관련 수업에서 '애자일'이라는 단어를 많이 접했고

그 후 3년 조금 안되게 스타트업에 개발자로 일하면서도 자주 들은 말이 있어.

'애자일 방식으로 가자'라는 리더의 말이었어.

 

지금 와서 이 말이 왜 생각났냐면 '인문학도, 개발자 되다.'라는 책을 읽던 중 애자일에 관한 이야기가 나와서야.

마르코 저

안타깝게도 많은 이들이 애자일이라는 방법론이 단순히 개발자에게 많은 일을 할당할 수 있는 마법 같은 방법이라고 생각하는 것 같아.

하지만 이 애자일 방법론의 발달 배경을 보고 그것이 진짜 추구하는 방향을 알아야 해.

 

나도 자세히는 몰랐지만 문맥상 이해하기로 빠르게 빠르게 구현해서 반응을 살펴보는 방식인가?라고 이해했었다. 그런데 그런 의미만 있는 것은 아니더라고.

 

먼저 애자일 이전에 개발 조직을 이끄는 방법론이 있었는데 바로 '폭포수(Waterfall) 이론'이야.

폭포수 이론에 대해 간략히 설명하자면

• 개발하고자 하는 서비스의 전체를 기획하는 천재 기획자,
• 그 기획을 바탕으로 시안을 만들어내는 황금손 디자이너,
• 기획과 디자이너가 만든 시안으로 서비스를 개발하는 개발자

 

이 말도 안되는 3명의 인재가 모여 순차적으로 서비스 개발을 진행하는 것을 말해.

 

하지만 세상은 빠르게 급변하고 소비자들의 니즈 역시 급변해.

기능이 한달에 수차례 씩 수정되고 추가되지.

 

그래서 나온 개발 프로세스 방법론인 '애자일 방법론'이야.

애자일(Agile)은 영단어로 민첩함을 의미해.

 

애자일 소프트웨어 개발 선언문 (Manifesto for Agile Software Development)

• 프로세스와 도구를 넘어서 서로 소통하기
• 문서화보다는 실제로 작동하는 소프트웨어를 개발하기
• 계약 내용으로 협상을 하기보다는 고객과 협력하기
• 계획을 따르기보다는 변화를 받아들이기

 

내가 왜 이 책을 보다 말고 이 글을 적냐면 이 문장들을 보면서 내가 일했을 때 경험하고 이렇게 했으면 좋겠다고 속으로만 생각하고 회사에, 기획자에, 디자이너에게 먼저 제안하고 분위기를 이끌지 못했던 아쉬움에서야.

다음에 재취업한 곳에서는 이 방법론에 대해 깊이 이해하고 조직이 유기적으로 좋은 방향으로 움직였으면 해서야.

 

프로세스와 도구를 넘어서 서로 소통하기..

그냥 계급장 떼고 소통하라는 것 같음. 내가 이해하기론.

 

문서화보다는 실제로 작동하는 소프트웨어를 개발하기

사실 많은 곳에서 이것 때문에 많이 싸울 것 같아.

그런데 내가 있던 곳은 싸웠다기보다 계신 분들이 다 착하셔서 회사의 일이 많고 마감 기한일이 촉박하다는 사실을 알기 때문에 디테일한 기획서, 또는 간단한 기획서가 나오지 않는 경우 모두 참다가 참다가 한두 번씩 말하는 걸 본 적이 있어.

이걸 보니 애자일이라는 방법론을 배워서 사람이 보인 조직에서 그와 같이 행동하는 것이 아니라 조직은 현재 주어진 환경에 맞춰서 행동하는 것이고 그러다보니 애자일 방법론에 맞게 일하고 있는 것 같아. 

 

계약 내용으로 협상을 하기보다는 고객과 협력하기

이건 내가 있던 곳에 한 PM님이 정말 잘하셨던 부분 같아.

사실 이거 또한 환경에 맞게 자연스레 그렇게 행동하는 것이지만

이게 안되면 사실 클라이언트들에게 끌려다니기 십상일 것 같아.

아무튼 개발자 입장에서 봐도 더 나은 방향이 보이면 그를 제안하고 고객사와 협의하여

수정하여 더 완성도 높은 서비스를 개발하는 것이 모두를 위한 일이라고 생각해.

 

계획을 따르기보다는 변화를 받아들이기

이게 3번째 내용도 포함되고 더 넓은 의미도 포함하는 것 같아.

단순히 개발 내용 뿐 아니라 더 넓은 범주로.

사실 잘 모르겠어 뭔지. 세 번째랑 같은 내용 같아.....

 

아무튼 다 떠나서 가장 중요한 것은 이거야.

고객의 Pain Point, Needs를 기가 막히게 파악해서 고객을 위한 서비스를 개발하고
사람들(팀원, 고객 등)과 원활히 소통하며 더 나은 서비스를 위한 변화를 두려워하지 말자