애자일(Agile) 방법론,개발기법 확인

[애자일(Agile) 방법론,개발기법 확인 편]

IT 업계에서 일을 하는 분들이라면 누구나 사실 공감할 부분일겁니다. 바로 끊임없이 바뀌는 클라이언트의 요구사항과 클라이언트 본인 자체도 무엇을 원하는지 모르는 채 막연하게 전산과는 거리가 먼 꿈의 소프트웨어를 그려내는 순간 몰아치는 짜증스런 감정과 아, 오늘도 또 야근인가 라는 피곤이 교차되는 날 내가 정말 여기를 떠나야지. 라는 것. IT 업계 종사자분이라면 대부분은 공감하실건데요. 오늘은 이런 흔들흔들 흔들리는 클라이언트에 대비하여 나왔던 소프트웨어 공학에서는 예전부터 주창되었던 애자일(Agile) 방법론,개발기법에 대해 한번 알아볼까 합니다. 자~ 그럼 알아보러 가실까요.

| 애자일(Agile) 방법론,개발기법 확인

일단 애자일(Agile) 방법론, 개발기법은 위 화면과 같은 싸이클로 개발이 이루어진다고 보면 되는데요. 클라이언트와 팀원과 개발자의 끊임없는 교류를 통하여 모든 변화에 빠르고 유연하게 대응하여 개발에 적용하겠다는 것을 목적으로 하고 있는데요. 

기존의 방법론과 애자일(Agile) 방법론의 차이를 되짚어보자면 일단 클라이언트의 요구사항에 대해 지속적으로 관리를 한다는 점에서 확연하게 다르다고 할 수 있겠습니다. 기존 방법론에서는 예를 들어 01/01~01/31 까지 요구사항 분석 및 완료로 계획을 잡으면 그 안에 수용하지 못한 요구사항은 제외하고 개발을 진행하는 방식입니다. 또한 일정 및 각 프로그램에 대한 상세한 계획기반의 프로세스를 다 잡고 각각의 단계에 대해 문서화를 강조하며 엄격한 역할분리를 통해 철저히 자기책임하에 일하게 하는 방식이지요. 하지만 애자일(Agile) 방법론에서는 이와는 반대로 지속적으로 요구사항을 받아들이고 그 요구사항을 수용하여 거기에 맞게 개발하고 주로 요구사항에 맞는 UI를 먼저 클라이언트에게 선보여 컨펌을 받은 뒤 개발을 완료하고 전적인 자기부담,자기책임보다는 팀워크를 중요시하여 설사 한명이 프로젝트에서 빠지더라도 남은 팀원들로 개발진행에 무리가 없을 수 있도록 적절히 분배 가능한 역할을 한다는 것이 기존 방법론과는 다르다고 할 수 있겠습니다.

좀더 자세히 살펴보자면 위 화면과 같이 애자일(Agile) 방법론에 따른 개발기법 프로세스는 할당된 요구사항을 일단 처음 구현하게 됩니다. 당연히 가장 기본이 되는 요구사항에 맞는 분석/설계/구현을 끝낸 뒤 테스트를 진행합니다. 그 후 피드백을 받고 추가된 요구사항을 다시 구현하는 것이지요. 그렇게 몇단계를 거쳐 클라이언트의 요구를 충족시켜 소프트웨어의 질을 높인다는 측면을 강조한다고 보면 되는 것인데요.

결국 프로세스나 툴보다 개인간의 교류를 소중히 하라,포괄적인 문서작성에 힘을 쓰기보다 잘 동작하는 소프트웨어 개발에 노력하라, 계약의 교섭보다 고객과의 협업을 중시하라, 이미 계획된 것에 충실히 따르려는 노력보다 변화에 유연하게 대응하는 것을 중시하라. 이런것들이 결국 애자일(Agile) 방법론, 개발기법의 핵심이 아닐까 싶습니다.

이상 애자일(Agile) 방법론,개발기법에 대해 알아보았는데요. 사실 우리나라에서는 적용하기 힘들다고 많은 현장에서 거부하고 있다고 하네요. 애자일 기법의 가장 큰 장점이라 할 수 있는 프로젝트 리펙토링 기능은 결국 클라이언트의 만족과 계획에서 벗어나 받아들여야 하는 어쩔수 없는 추가 요구라던가 유지보수 측면에서도 오히려 더 수용해야 하는 방법론이 아닐까 싶습니다. 그럼 아직도 일하고 계실 개발자분들 부디 퇴근하여 행복한 가정에서 꿈나라 갈수 있기를 바라며 애자일(Agile) 방법론,개발기법 확인에 대한 포스팅을 마치겠습니다.