애자일 프로세스 모델(애자일 방법론)

현 직장은 전통적인 폭포수 모델 방식으로 개발하는데 산출물 중심으로 개발하고 최종 릴리즈 후 새로운 요구사항을 추가하는 것이 쉽지 않다. 특히 개발 중간에 산출물도 변경되는 경우가 많다(┬┬﹏┬┬)

 

많은 기업들이 애자일 방식으로 일을 하는 것 같다.

다음 직장을 위해 애자일 방법론을 알아둬야 할 것 같아 애자일 프로세스 모델이 무엇인지에 대해 정리해봤다.

 

⚡ 애자일 프로세스 모델

고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론

 

📝 애자일의 기본 가치

‣ 프로세스와 도구 중심이 아닌, 개개인의 상호 소통 중시

‣ 문서 중심 X, 실행 가능한 소프트웨어 중시

‣ 계약과 협상 중심이 아닌, 고객과의 협력을 중시

‣ 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시

 

정리해보자면,

고객과의 협업 • 빠른 시간 안에 고객이 작동해볼 수 있는 소프트웨어 • 환경과 고객의 변화에 능동적으로 대처하는 것을 강조하고 있다.

 

📑 애자일의 원칙 (일부)

• 고객 만족을 위해, 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것

• 개발 후반에 새로 추가되는 요구사항도 기꺼이 받아들인다

• 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달한다

• 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구사항, 설계가 나온다

• 개발 팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아보고 조율 및 수정한다

 

💬 애자일 개발방법

예를 들어 문서 편집기를 개발한다면 

1) 우선 문서를 작성하는 데 가장 기본이 되는 기능만 1차 요구사항으로 분석하고 이를 반복으로 나누어 개발

   (문서작성, 단순 편집, 저장 등)

2) 사용자는 기본기능을 빨리 확인하고 사용

3) 그동안 개발자는 좀 더 복잡한 기능을 추가하여 2차 개발을 진행

 

이처럼 애자일 개발 방법은 반복적인 개발을 통한 잦은 출시를 목표로 한다. 실행가능한 프로토타입을 만들어 사용자에게 확인받고, 좀 더 빠른 시간 안에 일부이지만 소프트웨어를 사용할 수 있게 하는 것을 중요하게 생각한다.

 

🙄 장점과 단점

 장점은 계획/기능에 대한 수정이 유연하고 점진적으로 테스트할 수 있어서 버그를 빠르게 발견할 수 있다.

 단점으로는 요구사항 및 계획이 크게 변경될 경우 모델이 무너질 수 있고 개인이 아닌 팀이 중심이 되다보니 공통으로 해야 할 작업들이 많을 수 있다. 

 

🧒 끝으로

 개인적으로 폭포수 방법론으로 각자 작업을 나눠 개발기간에 맞춰 개별작업을 주로 해왔기 때문에 팀단위로 개발하는 것이 무척 재밌을 것 같다. 그리고 점진적으로 테스트 해서 버그나 수정사항들을 빠르게 발견해서 수정할 수 있는 것도 너무 좋다. 최근 프로젝트에서 전체 테스트를 하는데 하루가 걸렸는데, 개발 중간중간에 팀원들과 단위테스트를 진행했음에도 버그들이 많이 나와 당황했던 기억이 있다...  

 

 애자일 개발방법론에도 스크럼, 린스타트업 등 여러 방법론이 존재하는데 주로 많이 쓰이는 스크럼(scrum)에 대해서도 알아봐야겠다.

 

 

※ 해당 포스팅은「쉽게 배우는 소프트웨어 공학(김치수 저)」책을 바탕으로 작성하였습니다.