[Software Engineering] Agile Software Development

Agile Software Development

전통적인 Waterfall 모델의 한계를 극복하기 위해 등장한 소프트웨어 개발 방법론이다. 이는 팀 협업, 빠른 응답, 고객 중심 개발, 지속적인 개선을 중시하며, 변화하는 요구사항에 유연하게 대응할 수 있는 반복적(iterative)이고 증분적(incremental)인 개발 방식을 사용한다.

 

12 Principles of Agility

1. 고객에게 가치 있는 소프트웨어를 조기에 지속적으로 전달함으로써 고객을 만족시킨다.

2. 변화하는 요구사항을 환영한다. 개발의 후반부에서도 고객의 경쟁 우위를 높이기 위해 변경 사항을 수용한다.

3. 짧은 주기로 동작하는 소프트웨어를 자주 전달한다.

4. 비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 긴밀하게 협력한다.

5. 신뢰할 수 있는 사람들로 팀을 구성하고, 필요한 환경과 지원을 제공하며 업무를 신뢰한다.

6. 대면 커뮤니케이션이 가장 효율적이며 효과적이다.

7. 진척의 주요 척도는 작동하는 소프트웨어다.

8. 개발 속도는 지속 가능해야 한다. 모든 참여자는 지속 가능한 페이스를 유지한다.

9. 지속적인 기술적 개선과 좋은 설계가 민첩성을 향상시킨다.

10. 불필요한 작업을 줄이는 단순성이 중요하다.

11. 최고의 아키텍처, 요구사항, 설계는 자율적인 팀에서 나온다.

12. 팀은 정기적으로 자신을 돌아보고 더 효과적으로 만들기 위해 프로세스를 조정한다.

 

Agile에 대한 비판과 한계

1. 경험 많은 개발자에게 더 적합하며, 초급 개발자에게는 어렵다.

2. 초기 설계 부족으로 인해 프로젝트 관리가 복잡해질 수 있다.

3. 문화적 변화가 필요하여 조직 차원에서 수용이 어렵거나 저항이 발생할 수 있다.

4. 계약 협상 과정에서 범위 변경으로 인해 갈등이 발생할 수 있다.

 

Extreme Programming (XP)

객체 지향 및 반복적이고 증분적인 개발 방식으로 Planning, Design, Coding, Testing의 4가지 주요 활동으로 진행한다.

 

1. XP Planning

사용자 스토리(User Story) 작성을 통해 시작된다.

• User Story 형식
  • “As a <역할>, I want <목표> so that <이익>”
  • 예시:
    • “As a user, I want to search for customers by their first and last names.”
    • “As a mobile tester, I want to test my cases and report results.”
• Story Card 작성 및 평가:
  • 고객이 각 Story의 우선순위/가치를 결정
  • XP 팀은 개발 소요 시간을 평가
  • 개발 시간이 3주 이상 소요될 경우, Story를 더 작은 단위로 나눈다.
• Story Map
  • User의 워크플로우 기반으로 Story를 정리하여 우선순위를 시각화
  • 수평적으로는 Big User Story(Epic), 수직적으로는 우선순위에 따라 정렬

 

2. XP Design

XP 설계는 단순성(KIS, Keep It Simple) 원칙을 따른다.

• CRC 모델링(Class-Responsibility-Collaborator) 사용
  
  • 클래스 이름, 책임, 협력자 정보를 기록한 인덱스 카드 사용
  • 책임(Responsibility): 클래스가 수행하는 작업
  • 협력자(Collaborator): 작업 수행에 필요한 다른 클래스
   
• Spike Solution:
  • 어려운 설계 문제 발생 시, 프로토타입(Spike Solution)을 통해 위험을 줄이고 초기 추정을 검증
• 리팩토링(Refactoring):
  • 코드 작성 중 설계를 지속적으로 개선

 

3. XP Coding

단위 테스트(Unit Test)부터 시작한다.

• 단위 테스트: 모든 코드가 작성되기 전에 자동화된 테스트 케이스 작성
• 페어 프로그래밍(Pair Programming): 두명의 개발자가 한 컴퓨터에서 함께 코딩
  • 실시간 문제 해결 및 품질 보장
  • 한 명은 코드 작성, 다른 한 명은 코딩 표준과 일관성을 검증
• 지속적 통합(Continuous Integration):
  • 매일 코드 통합 및 테스트를 통해 버그를 조기에 발견

 

4. XP Testing

테스트 중심 개발(Test-Driven Development, TDD)를 권장한다.

• 자동화된 단위 테스트: 반복적으로 테스트 가능하도록 자동화된 단위 테스트 작성
• 수용 테스트(Acceptance Test): 고객이 작성하고 시스템의 주요 기능을 검증

 

Scrum

1. 개발 팀이 하나의 목표를 위해 유기적으로 협력하는 방식에 초점

2. 팀원 간의 자율성과 자기 조직화(Self-Organizing)를 중시

3. 모든 팀원이 동일한 공간에서 작업하고 대면 소통을 권장

 

Scrum Framework

 

Scrum Team

• Product Owner
  • 제품의 가치 극대화와 Product Backlog 관리를 책임
  • 제품의 기능 요구사항을 정의하고 우선순위를 설정
• Development Team
  • 잠재적으로 배포 가능한 제품 증분(Increment)을 매 스프린트마다 제공
  • 팀 구성원은 자율적으로 작업을 선택하고 진행
• Scrum Master
  • Scrum의 이론과 규칙을 이해시키고 지원
  • 팀의 생산성을 높이기 위해 장애 요소를 제거

 

Scrum Artifacts

• Product Backlog
  • 제품에 필요한 모든 요구사항 목록
  • Product Owner가 관리하며 내용과 우선순위를 지속적으로 업데이트
  • 각 Backlog는 설명, 우선순위, 추정 시간, 가치 등의 속성을 포함

• Sprint Backlog
  • 개발 팀이 스프린트 동안 수행할 작업 계획
  • 팀원이 자율적으로 작업을 선택하며, 이는 팀의 자기 조직화를 촉진
• Increment
  • 완료된 Product Backlog 항목들의 집합
  • 이전 스프린트의 증분과 합쳐져 최종 제품을 형성

 

• Burn Down Chart
  • Sprint Backlog의 남은 작업량을 시각적으로 표시
  • 매일 업데이트되며 전행 상황을 간단히 파악할 수 있는 도구

 

Scrum Event

1. Sprint

• 1~4주 동안 진행되는 개발 주기
• 설계, 코딩, 테스트가 스프린트 내에서 완료

2. Sprint Planning Meeting

• Sprint의 작업 목표와 Sprint Backlog를 설정
• 총 8시간이 소요 되며 두 부분으로 나뉨
  • 1부: Entire Team이 Product Backlog 우선순위 선정 및 Sprint Goal 설정
  • 2부: Development Team이 Sprint Backlog 생성

3. Daily Scrum Meeting

• 15분 이내로 진행되는 일일 미팅
• 진행 상황 공유, 장애 요소 확인, 계획 조정
• 문제 해결이 아닌 팀 내 약속과 소통 강화가 목적

4. Sprint Review

• Sprint가 끝난 후 진행, 팀이 작업한 결과를 시연
• 고객, 관리, 기타 이해관계자가 참석해 피드백 제공

5. Sprint Retrospective Meeting

• 팀의 개선 방안을 찾기 위해 매 Sprint가 끝날 때마다 시행
• 시작, 중단, 계속할 일을 정리하며 팀 역량 강화

Scalability of Scrum

• 팀의 규모: 일반적으로 6~10명
• Scrum of Scrums (메타 스크럼):
  • 여러 팀이 협력할 때 팀 간 의사소통을 위한 회의
  • 지정된 팀원이 대표로 참석해 작업 공유 및 통합

 

Scrum vs. XP