소프트웨어 개발 방법론 - 애자일(Agile) 방법론

소프트웨어 개발 방법론 - 애자일(Agile) 방법론

• 애자일(Agile) 방법론은 구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다.
• 변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법
• 문서화보다 코드, 프로그램, 소프트웨어 자체를 중요시 함
• 요구사항의 변화는 불가피하며 이에 대응하는 것이 현실적이다.
• 기존의 개발 프로세스는 설계 기간이 길며 재작업 시 오버헤드가 크다.
• 환경의 빠른 변화에 대응하는 것이 중요하다.
• 애자일 선언문(Agile Manifesto) 🔗
  
  • 공정과 도구보다 개인과 상호작용을
  • 포괄적인 문서보다 작동하는 소프트웨어를
  • 계약 협상보다 고객과의 협력을
  • 계획을 따르기보다 변화에 대응하기를
• 요구사항이 바뀌기 쉬운 중소형의 비즈니스 시스템이나 전자 상거래 응용에 적합하다.
• 애자일 방법론의 종류
  • 익스트림 프로그래밍(Extreme Programming, XP)
  • 짝 프로그래밍(Pair Programming)
  • 테스트 주도 개발(Test Driven Development, TDD)
  • 스크럼(Scrum)

 

1. 애자일 방법론 - 익스트림 프로그래밍(Extreme Programming, XP)

폭포수 모델, 반복형 모델, XP 모델의 비교

 

• 좋은 실천 지침들(good practices)을 적극적으로 적용
• XP의 실천 지침
  • 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선
  • 고객도 개발 팀의 일원
  • 프로세스 중심이 아닌 사람 중심의 작업
  • 짝 프로그래밍(pair programming)
  • 단순한 설계와 테스트 주도 개발(Test Driven Development, TDD)
  • 리팩토링을 통한 코드 품질 개선

 

2. 애자일 방법론 - 짝 프로그래밍(Pair Programming)

• 두 사람이 짝이 되어 한 사람이 코딩을, 다른 사람은 검사를 수행
• 30분마다 역할 교체
• 장점
  • 코드에 대한 책임 공유
  • 비형식적 검토 수행
  • 코드 개선을 위한 리팩토링 장려
  • 생산성 - 두 사람이 짝을 이뤄 개발하지만 각각 개발하는 경우에 비해 생산성이 떨어지지 않는다.

 

3. 애자일 방법론 - 테스트 주도 개발(Test Driven Development, TDD)

• 테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 개발
• Task 별로 테스트 케이스를 만듦
  • 요구사항 ➡️ 스토리 카드 ➡️ Tasks
  • 요구사항은 스토리 카드로 표현되고 스토리 카드는 태스크들로 분해됨
  • 요구사항 - 코드 관계가 명확해 짐
• 통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류 유입 방지

 

4. 애자일 방법론 - 스크럼(Scrum)

* 스크림의 특성
스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있다.

- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
- 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
- 날마다 15분 정도 회의를 가져라. 항상 팀 단위로 생각하라.
- 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

* 스크럼의 진행 과정
스크럼에서는, 30일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다.

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO(Project Owner, 제품 책임자)가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
3. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
4. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
5. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
6. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
7. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
8. 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.

• 애자일 개발 과정의 관리에 초점을 둔 프로젝트 관리 프레임워크/소프트웨어 개발 프로세스 프레임워크
• 계획-스프린트의 반복
• 프로젝트 계획 ➡️ 제품 백로그: 우선순위가 부여된 요구사항 목록
• 스프린트 사이클
  • 3~9명의 스크럼 팀에서 제품의 증분을 개발하는 작은 프로젝트를 수행하여 한 달 이내로 개발
  • 스프린트 계획 ➡️ 스트린트 백로그: 제품 백로그에서 이번 스프린트 사이클에 개발할 요구사항 목록을 선택
  • 일일 스크럼 회의
  • 진행중인 스프린트 사이클이 종료되기 전에 스프린트 리뷰, 회고 수행
• 스크럼 팀의 구성
  • 개발팀
  • 제품 책임자(Project Owner, PO): 제품 백로그(요구사항) 작성 및 관리
  • 스크럼 마스터: 프로젝트 관리자. 스크럼 회의 주관, 외부 소통 창고 역할

 

References

한국방송통신대학교 컴퓨터과학과 소프트웨어공학(김희천 교수)

위키백과 - 스크럼 (애자일 개발 프로세스)