애자일 개발 기법

XP(eXtreme Programming)
비즈니스 상의 요구가 시시각각 변동이 심한 경우 적합한 개발 방법
애자일 개발 프로세스라 불리는 개발 방법 중 대표적인 하나로 꼽힌다.
비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다.
개발 문서 보다는 소스코드를, 조직적인 개발의 움직임보다는 개개인의 책임과 용기에 중점을 둔다.

XP는 애자일 방법론과 구분되는 특징으로 테스팅이 있다.
XP는 프로그래머들이 코딩을 할 때 테스트 코드를 작성하도록 함과 동시에 테스트를 기반으로 프로젝트를 
완성시켜 나가도록 한다.
이러한 테스트에 기반을 둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인
"반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"
를 실천하는데 큰 도움을 줄 수 있다.

구체적인 실천 방법(XP(eXtreme Programming) practice)
- 공동 소유권
- 연속적 통합

- 점증적 계획

- 고객의 참여

- 짝 프로그래밍

- 리팩토링

- 단순한 설계

- 소규모 릴리즈

- 유지할 수 있는 속도

- 테스트 우선 개발

애자일 선언의 원칙을 잘 반영
- 점증적 개발은 작은 크기의 잦은 시스템 릴리즈를 통해 이루어짐

- 고객 참여는 고객이 개발팀에 지속적으로 참여하는 것으로 자원이 이루어짐

- 짝 프로그래밍, 시스템 코드의 집단 소유와 너무 오랜 근무시간을 요구하지 않는 지속가능한 개발 
프로세스를 통해 프로세스가 아닌 사람을 지원함
- 고객에게 제공하는 정기적인 릴리즈, 테스트 우선 개발, 코드 품질 저하를 막기 위한 리팩토링과

새로운 기능의 연속적 통합을 통해 변화를 허용함

- 코드 품질을 향상시키는 끊임없는 리팩토링을 통해, 시스템에 발생할지도 모르는 불필요한 
향후 변경을 고려하지 않은 간단한 설계를 사용함으로써 단순함을 유지함

 

 

리팩토링(Refactoring)
- 소프트웨어의 구조와 신뢰성을 개선
- 소프트웨어를 변경할 때 발생하는 구조적 악화를 막음
EX) 중복 코드를 제거하기 위해 클래스 계층 구조 변경하기
     속성과 메소드 정리하기 및 이름 변경하기
     유사한 코드 영역을 프로그램 라이브러리에서 정의한 메소드 호출로 대체하기

짝 프로그래밍(Pair Programming)

• 장점
  시스템에 대한 집단 소유와 책임이라는 개념을 제공
  
  짝 프로그래밍을 함으로써 작성하는 모든 라인을 최소한 두 명이 살펴보기 때문에
  일종의 비정형적 리뷰 프로세스를 진행하게 됨
  
  소프트웨어 구조 개선을 위해 리팩토링을 사용
  
  
  
• 단점
  짝 프로그래밍이 두 명의 프로그래머가 개별적으로 일하는 것에 비해 생산성이 떨어짐

 

---

 

Agile Project Management(애자일 개발 방법론)

애자일 프로젝트 관리

 

- 스크럼(Scrum)

원래 럭비 경기에서 사용되던 용어
럭비에는 스크럼과 라인 아웃이라는 두가지 기본 대형이 있는데, 

이 중 스크럼은 반칙으로 인해 경기가 중단됐을 때 쓰는 대형

럭비 경기에서 쓰이던 용어가 소프트웨어 개발 프로세스에서 사용되는 것은

"팀이라는 단어가 주는 의미를 개발 팀에 적용하여 효율적인 성과를 얻기 위함"

 

애자일 프로젝트를 조직화하기 위해 프레임워크를 제공
진행중인 내용에 대한 외부 가시화를 제공

 

• 장점
  반복주기(스프린트)마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있다.
  
  일일회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능하다.
  
  일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다.
  
  다른 개발 방법론들에 비해 단순하고 실천지향적이다.
  
  스크럼 마스터는 개발 팀원들이 목표달성에 집중할 수 있도록 팀의 문제를 해결한다.
  
  프로젝트 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능하다.
  
  프로젝트 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있다.
  
  
  
• 단점
  추가 작업 시간이 필요하다.(반복 주기가 끝날 때 마다 실행가능하거나 테스트할 수 있는
  제품을 만들어야 한다. 이 작업이 많아지면, 그만큼 작업 시간이 더 필요하다.)
  
  일일 스크럼 회의를 15분 안에 마쳐야함  
  
  투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수를 측정하지 않기 때문에 
  얼마나 효율적으로 수행되었는지는 알기 어렵다.
  
  프로세스 품질 평가 불가(스크럼은 프로젝트 관리에 무게중심을 많이 둔 방법..품질을 평가하지 않기 때문)
  
  
  
  
  

Scaling Agile Methods

애자일 기법은 같은 방에서 함께 일하고 평소에 의사소통 할 수 있는 
작은 규모의 개발팀이 사용할 수 있도록 개발한 것
애자일 기법을 진화시켜 큰 규모의 소프트웨어 시스템과 대규모 회사에서도 사용할 수 있도록
많은 노력을 시도


Scaling Up and Scaling Out
- 작은 규모의 단일팀이 개발하기에는 어려운 대규모 시스템 개발을 다루기 위한 애자일 기법의 Scaling Up
- 특화된 개발 팀을 다년간의 소프트웨어 개발 경험을 가지고 있는 대규모 회사에서 더 광범위하게 사용하기 위한 애자일 기법의 스케일 아웃(Scaling Out)

Agile maintenance(유지 보수)
핵심 문제는?
- 제품 설명서가 없음(Lack of product documentation)
- 고객이 개발 프로세스에 참여하도록 유지(Keeping customers involved in the development process)
- 개발 팀의 연속성 유지(Maintaining the continuity of the development team)

---

 

애자일 계획 주도 방법

시스템 문제
- 애자일 방법은 비공식적으로 의사 소통을 할 수 있는 상대적으로 작은 공동 배치 된 팀이 가장 효과적
- 구현하기 전에 많은 분석이 필요한 시스템은 이 분석을 수행하기 위해 상당히 세부적인 설계가 필요

- 수명이 긴 시스템은 시스템 개발자의 의도를 지원 팀에 알리기 위한 문서화가 필요

- 시스템이 규제되면 시스템 안전 사례의 일부로 상세한 문서를 작성해야 할 것

 

 

 

 

대규모 시스템을 위한 애자일 기법
- 애자일 기법은 대규모 소프트웨어 개발에 사용할 수 있도록 변경할 수 있어야 함

1. 요구 사항 엔지니어링에 대한 점진적인 접근 방식은 불가능합니다.

2. 단일 제품 소유자 또는 고객 담당자가 있을 수 없습니다.

3. 대규모 시스템 개발의 경우 시스템 코드에만 집중할 수 없습니다.

4. 팀 간 의사 소통 메커니즘이 설계되고 사용되어야한다.

5. 지속적인 통합은 사실상 불가능합니다. 그러나 자주 시스템을 빌드하고 정기적으로 시스템을 릴리스해야합니다.