애자일과 익스트림 프로그래밍(Agile , XP)

애자일 프로그래밍 

# Agile Software Development

(Aglie: 날렵한, 회전이 빠른)
다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점이다.

• 프로세스와 도구보다 개인 간의 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를 (Code-Oriented)
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를

 

# 각 모델의 차이점

• [ 폭포수 모델 ] 은 전형적인 사업의 모습, 즉 전체적인 사업 계획을 기반으로 요구사항을 분석하고, 설계를 완료 한 후 개발을 하여 단계별로 진행되지만 한번 결정 난 사항은 되돌리기 어렵다고, 프로토타입이 최종단계에 가까워져야 나온다는 단점이 있어서 요구사항 변화가 잦은 개발에는 맞지 않다.
  
  
• [ 나선형 모델 ] 은 폭포수 모델처럼 하되, 특정 주기(보통 6개월에서 2년)을 프로젝트 생명주기(Life Cycle) 로 잡고 주기마다 요구사항 분석, 위험분석, 계획, 개발, 유닛테스트를 반복한다.
  
  
• [ 애자일 모델 ] 은 얼핏 들으면 나선형 모델과 비슷해 보이지만, 가장 크게 다른 점은 분기점이 ‘개발주기’ 나 ‘프로토타입 생성’ 이 기준이 아니다. 다수의 작은 기능으로 분할하여 기능 별로 짧은 반복 주기(보통 2~4주)를 가지고, 끊임 없이 고객과 의사소통, 요구사항을 추가하여 점진적으로 나아가는 방식이다.

Theme: “태블릿과 클라우드 서비스를 통한 레스토랑 주문 시스템.”
Epic:  “고객으로서, 테이블의 태블릿을 통해 음식과 관련된 일을 처리할 수 있다.
Story: “고객으로서, 음식을 주문하기 위해, 메뉴를 볼 수 있다.”
Task: “음식 사진이 배열된 메뉴 화면을 구현한다.”

애자일은 Story 중심으로 유연하게 개발, 폭포수는 Task를 중심으로 계획적으로, 체계적으로 개발한다. 쉽게 말해 ‘소프트웨어 제품’에 초점을 맞춘 게 아니라, 고객에 초점을 맞춘 방식이 애자일 방법론이라고 볼 수도 있겠다

 

---

# 애자일이 추구하는 것

소프트웨어 개발에서는 전통적인 폭포수 모델은 따라가기 힘들다. 고객의 요구사항은 끊임없이 변화한다. 기능(구현)에 초점을 맞추는게 아니라 서비스(추상화)에 기준을 맞춰 서비스 단위의 짧은 주기로 [기획-개발-테스트-배포]하는 애자일 접근법이 필요하다.

서비스 중심으로 짧은 단위의 개발주기를 가지는 것.

 

• 일의 단위
  - 폭포수: 구현해야 할 기능을 기준으로 정한다. “레스토랑 메뉴 선택 화면을 구현한다."
  - 애자일: 사용자의 경험을 기준으로 스토리를 정한다. “식당 손님으로서, 레스토랑에서 주문을 하기 위해, 메뉴에서 음식을 선택할 수 있다.”
  
  
• 데드라인
  - 폭포수: 데드라인을 정하고 데드라인에 맞춰 자원을 투입하거나 있는 자원을 최대한 활용한다.
  - 애자일: 계속 개선하므로 데드라인이 별 의미가 없다. 팀 프로젝트 진행 속도(throughput)를 측정한다.
  
  
• 외부 요청에 반응
  - 폭포수: 계획이 이미 끝났기 때문에 외부 요청은 다음 버전까지 반영할 수 없거나 변경하려면 큰 비용이 발생하므로 반영을 최소화한다.
  - 애자일: 프로덕트 사이클(기획-개발-테스트-배포)가 짧으므로 프로덕트 매니저가 엔지니어링 매니저와 협력하여 외부 요청을 빠르게 반영한다.
  
  
• 프로덕트 매니저(PM)의 팀 내 역할
  - 폭포수: 매니저가 팀에 상주할 필요 없다. 처음 기획자가 모든 기획안을 만들어서 넘기면 개발팀에서 데드라인에 맞춰 구현한다.
  - 애자일: 팀의 프로젝트 진행 속도를 측정하여 이 속도로 진행하면 언제쯤 완성될 것인지를 측정한다. 끊임없이 외부 팀과 소통하여 요구를 반영하고 프로덕트 완성 시점과 우선순위를 업데이트한다.
  
  
• 엔지니어링 매니저(개발팀장)의 역할
  - 폭포수: 데드라인에 맞춰 프로젝트를 끝내는 것을 관리한다. 데드라인을 못 맞출 것 같으면 외주를 주거나 팀원들에게 지속적인 동기부여(또는 위협)를 한다.
  - 애자일: 팀이 매 스프린트마다 일정한 속도로 프로덕트를 만들도록 관리한다. 버그 등을 관리하여 기능이 퇴화되지 않도록 한다.

 

---

# 애자일 프레임워크 도구

스크럼(Scrum), 칸반 보드(Kanban), XP(eXtreme Programing)와 같은 애자일 소프트웨어 개발용 프레임워크는 CI/CD와 같은 대중적인 개발 프로세스의 틀을 만들 수 있도록 도와준다. 무조건 스크럼이 좋다. 칸반이 좋다 이런건 없다. 팀마다 알맞은 방법이 있고, 그걸 사용하면 되는 것이다. 프로세스와 도구에 의존하지 말자.

 

• Scrum
  스프린트라는 일정기간 안에 완료할 수 있는 작업으로 업무를 분할한다.

 

• Kanban 보드

 

그리고 우리가 알아볼 마지막 애자일 프레임워크가 바로 XP (익스트림 프로그래밍)이다.

 

---

# 익스트림 프로그래밍 (XP, eXtreme Programing)

애자일 방법론중 하나로 빠른 개발 속도를 유지하며 고객이 원하는 요구들을 지속적으로 피드백하는 방법

• 10~12개 정도의 구체적인 실천 방법(Practice)을 정의
• 짧은 주기로 여러번 고객에게 납품 반복
• 개발문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시
• 다만 대규모 프로젝트엔 적용하기 어렵고, 개인의 습관-실력에 따라 프로젝트 품질차이 발생

익스트림 프로그래밍의 철학
- 용기: 문서로 변명하기 보단 진실되고 용기있게 개발
- 존중: 개발자의 역량을 존중하고 충분한 권한과 권리 부여
- 의사소통: 이해관계자 모두가 팀원이라는 생각으로 모든 사항 공유
- 피드백: 의사소통에 따른 즉각적인 피드백
- 단순성: 필요한 것은 하지만 더이상은 하지 않음

 

# 익스트림 프로그래밍을 해보자

1-1. User Stories, 유저 스토리 (요구사항 정리)

• 사용자 요구사항 / UML의 유스케이스와 같은 목적(요구사항 수집, 의사소통 도구)
• 릴리즈 계획을 작성하기 위한 단위
• 기능단위로 필요한 내용을 간단하게 기재, 필요시 간단한 테스트 사항도 표기 가능
• 시스템을 사용하는 고객이 필요한 것이 무엇인지를 기술 → 인수테스트시 사용

 

1-2. Architectural Spike, 구조적 스파이크(기술적인 문제)

• 어려운 요구사항 혹은 잠재적인 솔루션들을 고려하기 위해 작성하는 간단한 프로그램
• 사용자 스토리의 신뢰성을 증대시키거나 기술적인 문제의 위험을 줄이고자 하는데 목적

 

2. Release Planning, 릴리즈 계획 잡기

• 전체 프로젝트에 대한 배포 계획을 생성

 

3. Iteration, 반복

• 하나의 반복을 1에서 3주 정도로 나누고 반복들을 프로젝트 전반에 균일하게 유지
• XP의 반복은 프로세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목 → 반복 계획 미팅
• 사용자 요구사항 변경, 기술적인 문제 등 상황에 따라 릴리즈 및 반복 계획 수정 가능

 

4. Acceptance Test, 인수 테스트

• 릴리즈 전의 인수 테스트.  고객이 실제 사용자 환경에서 사용자의 입장으로 테스트를 수행

 

5. Small Release, 소규모 릴리즈

• 작은 배포는 XP 주기의 마지막 단계
• 소규모로 빈번하게 배포하면 고객에게 여러 가지 이득을 조기 제공
• 프로그램은 빠른 피드백을 제공 받음

 

---

# 익스트림 프로그래밍을 효율적으로 하기위한 12가지 실천사항(Practice)

• Fine scale feedback
  • Pair Programming: 하나의 컴퓨터에 2명의 프로그래머가 모든 코드를 코딩과 리뷰 역할을 바꿔가며 공동작업 진행
  • Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획에 임하라
  • Test Driven Development: 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
  • Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
• Continuous process
  • Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
  • Design Improvement: 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
  • Small Releases: 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 함
• Shared understanding
  • Coding Standards: 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성
  • Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정 가능함
  • Simple Design: 가능한 가장 간결한 디자인 상태 유지
  • System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 기술
• Programmer welfare
  • Sustainable Pace: 일주일에 40 시간 이상 작업 금지, 2주 연속 오버타임 금지