소프트웨어 개발 방법론 - 애자일(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일간의 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다.
    • 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
    • PO(Project Owner, 제품 책임자)가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
    • 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
    • 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
    • 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
    • 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
    • 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
    • 스프린트 기간 중 다음 스프린트를 준비 하기 위해 PO와 필요 인원이 모여 백로그를 준비하는 시간을 갖는다.
  • 애자일 개발 과정의 관리에 초점을 둔 프로젝트 관리 프레임워크/소프트웨어 개발 프로세스 프레임워크
  • 계획-스프린트의 반복
  • 프로젝트 계획 ➡️ 제품 백로그: 우선순위가 부여된 요구사항 목록
• 스프린트 사이클
  • 3~9명의 스크럼 팀에서 제품의 증분을 개발하는 작은 프로젝트를 수행하여 한 달 이내로 개발
  • 스프린트 계획 ➡️ 스트린트 백로그: 제품 백로그에서 이번 스프린트 사이클에 개발할 요구사항 목록을 선택
  • 일일 스크럼 회의
  • 진행중인 스프린트 사이클이 종료되기 전에 스프린트 리뷰, 회고 수행
• 스크럼 팀의 구성
  • 개발팀
  • 제품 책임자(Project Owner, PO): 제품 백로그(요구사항) 작성 및 관리
  • 스크럼 마스터: 프로젝트 관리자. 스크럼 회의 주관, 외부 소통 창고 역할