[CS] 13. Agile 방법론

 

초기 소프트웨어 개발 방법은 계획 중심의 프로세스였다.(폭포수 모델) 90년대 이후, 소프트웨어 분야가 넓어지면서 소프트웨어 사용자들이 '일반 대중들'로 바뀌지 시작했다. 이제 모든 사람들이 소프트웨어 사용자들의 대상으로 되면서 트렌드가 급격하게 빨리 변화하는 시대가 도달했다. 이 때문에 제품 수명이 짧아졌고, SW 개발의 불확실성이 높아지게 되었다.

 

개발의 불확실성이 높아지며 전통적 개발 방법 적용이 어려워졌고 새로운 SW 개발 방법을 구축하게 되었다. 그 방법 중 하나가 규칙을 적게 만들고 가볍게 대응을 잘하는 방법을 적용하는 것이다. Agile 방법은 협력과 피드백을 중시하고 신속한 방법 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 SW 개발 방식을 의미한다. 앞서 언급한 협력은 SW를 개발한 사람들 안에서의 협력을 말하며 (직무 역할을 넘어선 협력) 피드백은 본인이 어떻게 했는지 확인하며 학습을 진행해야 한다. SW의 불확실성이 높을수록 학습도의 중요도가 올라간다.

 

전통적 방법은 요구분석단계에서 한번에 모든 요구사항을 명확하게 전달하는 것이 원칙이나, 현재와 같이 변화가 많은 프로젝트에는 현실적으로 불가능에 가깝다. 이러한 한계점을 극복하는 agile은  개발 과정에 있어서 시스템 변경사항을 유연하거나 기민하게 대응할 수 있도록 방법론을 제공해준다.

Waterfall VS Agile

진행 방법

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로 한다.
3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다. (예측하지 않는다.)
4. 주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
5. 프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로 한다.

agile을 통한 가장 많이 사용하는 개발 방법론이 스크럼이다. 소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고, 효율적인 성과를 얻기 위한 것이다.

1. 제품 기능 목록 작성

우선순위가 매겨진, 사용자의 요구사항 목록이라고 말할 수 있음

개발 중에 수정이 가능하기는 하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙

개발할 제품에 대한 요구사항 목록 작성

2. 스프린트 계획 회의

스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록을 확인한다. 이로 인해 최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능

3. 스프린트

작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발하는 형식으로, 한달동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면 이것이 스크럼에서 스프린트에 해당한다. 주기가 회의를 통해 결정되면 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의 없이 바꿀 수 없는 것이 원칙

4. 일일 스크럼 회의

5. 완성 및 스프린트 검토 회의

6. 스프린트 회고

 

---

Reference

https://www.redhat.com/ko/devops/what-is-agile-methodology

애자일 방법론(Agile Methodology) 개념, 방식, 기법

https://gyoogle.dev/blog/computer-science/software-engineering/Agile.html

애자일(Agile) | 👨🏻‍💻 Tech Interview

https://www.roweb.ro/blog/agile-vs-waterfall/