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

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

 

애자일(Agile) 방법론

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

 

애자일의 핵심은 '유연하게 일을 진행하자' + '변화에 잘 대응하자'

애자일은 정확히 말하자면 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아니다.

 

애자일을 계승한 방법론 또는 애자일 프레임워크

• 애자일 프레임워크는 애자일 사상 또는 철학에 기반한 개발 접근방식으로 정의가 가능하다.
• 애자일 프레임워크를 방법론, Process로 규정하기도 한다.
• 스크럼(Scrum), 칸반(Kanban), XP(eXtreme Programming), LSD(Lean SW Development) 등이 있다.

 

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

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

 

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

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

 

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

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

 

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

• 프로젝트 관리의 접근 방식이며, 스프린트라고 하는 단기 작업 블록을 통해 프로젝트를 진행하며, 스프린트 기간은 보통 2주로 진행한다.
• 여기서 스프린트는 반복적인 개발주기를 의미한다.

Product Backlog : 프로젝트 요구사항(Issue)

Sprint Planning Meeting : 백로그에 쌓인 프로젝트 요구사항을 가지고, 스토리 포인트를 예측한다. (각 요구사항의 일정이 어느 정도 소진이 될지 예측한다.)

Sprint Backlong : 스프린트를 진행할 Issue 들이 모여있다.

스프린트 진행

Grooming : 다음 스프린트에 들어가기 전에 다음에 진행할 스프린트 개발사항(요구사항)에 대해서 리뷰한다.

Daily Meeting : 진행사항을 간단하게 공유한다.

스프린트 종료

종료 시, 리뷰를 진행한다.
- 이슈를 얼마나 처리했습니다.
- 스프린트 기간 동안 다른 급한 이슈가 발생하여 몇 가지를 놓쳤습니다.

회고 미팅
잘한 것, 못한 것, 개선해야 하는 것에 대해 이야기하는 시간이다.(피드백 회의)

 

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

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

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

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

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