[소프트웨어공학] 애자일 기법의 개념과 활용

---

애자일 기법 등장 배경

• 예전엔 계획 주도 접근법이 주로 사용됨(1980년대 ~ 1990년대 초)
  • 더 좋은 소프트웨어를 만들기 위해서
  • 대규모의 소프트웨어 제작을 위한 방식이자 그런 시스템을 개발했던 공학단체로부터 비롯됨
    • 예 ) 현대식 항공기 제어 시스템 - 초기 명세부터 배포까지 10년은 족히 걸림
      
      
  • 계획, 설계 및 문서화에 오버헤드가 많이 발생 → 애자일 기법 등장 이유
    
    
• 무거운 접근법에 대한 불만 때문에 애자일 기법 등장(1990년대 말)
  • 개발팀이 설계와 문서작업보다 소프트웨어 개발 자체에 더 집중
  • 요구사항이 자주 변경되는 어플 개발할 때 적합한 방식
  • 유용한 소프트웨어를 빠르게 만들 수 있도록 고안(신속한 소프트웨어 개발)

 

---

신속한 소프트웨어 개발의 필요성

• 비즈니스 시스템에서 가장 중요한 요구사항
  ← 새로운 기회와 시장, 변화하는 경제적 조건, 제품, 서비스의 등장에 대응하기 위해
  
  
• 완벽하게 안정적인 소프트웨어 요구사항을 얻어내는 것은 불가능
  • 사용자가 시스템을 경험해 봐야 진짜 요구사항을 명확하게 알 수 있게 됨
  • 외부 요인들에 의해 요구사항이 변경될 수 있음

 

 

---

애자일 기법

• 사용하는 증가분이 적은 점증적 개발 기법

2~3주마다 새로운 시스템을 만들어 고객이 사용

• 고객이 개발 프로세스에 참여
  • 비공식 커뮤니케이션으로 문서화 최소화
    
    
• 설계와 구현을 프로세스 프로세스 중심 활동으로 간주
  • 요구사항 도출 및 테스팅과 같은 다른 활동을 설계와 구현에 포함
    
    

---

모든 애자일 기법들의 공통적 특징

• 중첩된 명세화, 설계 및 구현 프로세스
  • 상세한 시스템 명세를 만들지 않음
    • 설계 문서 최소화 혹은 프로그램이 환경에서 자동 생성
    • 사용자 요구사항 문서는 시스템에서 가장 중요한 특징을 개괄적으로 표현
      
      
• 시스템을 증가분의 연속으로 구현
  • 매 증가분을 명세하고 평가(최종 사용자와 다른 시스템 이해당사자)
  • 소프트웨어에 대한 변경 요청 및 새로운 요구사항 제안(최종 사용자와 시스템 이해당사자)
    
    
• 개발 프로세스를 지원하기 위해 방대한 도구 사용
  • 테스트 자동화 도구, 형상 관리와 시스템 통합 지원 도구, UI 자동 생성 도구 등

 

---

애자일 선언

프로세스와 도구보다는 개인과 상호 작용을
이해하기 좋은 문서보다는 작동하는 소프트웨어를
계약 협상보다는 고객과의 협업을
계획을 따르기보다는 변화에 대응하는 것

빨간색 내용에 더 많은 가치를 둔다.

 

---

애자일 기법 원칙

• 고객 참여 : 고객이 개발 프로세스 전반에 밀접하게 관여해야 한다.
  • 고객의 역할은 새로운 시스템 요구사항을 제공하고 우선순위를 정하며, 시스템을 평가하는 것
    
    
• 변화 수용 : 변화할 시스템 요구사항을 예측, 이러한 변화를 수용할 수 있도록 시스템을 설계하는 것
  
• 점증적 인도 : 고객이 다음 증가분에 포함해야 할 요구사항을 명세하면서, 소프트웨어를 점증적으로 개발
  
• 단순성 유지 : 개발 소프트웨어와 프로세스 양쪽에서 단순성에 집중한다.
  • 언제든 시스템으로 인한 복잡성을 제거하기 위해 능동적으로 대처한다.
    
    
• 프로세스가 아닌 사람 : 개발팀의 기술을 인지하고 잘 활용해야 한다.
  • 팀 구성원이 규정된 프로세스 없이 각자의 업무 방식을 개발할 수 있도록 해야 한다.

 

---

애자일 기법 적용 사례

• 구글
  • 소수의 개발자로 구성된 작은 조직 → 신속한 의사 결정 가능
  • 3개월 단위로 성과에 따라 인력 조절하며 프로젝트 강약 조절
    → 제품 출시 기간의 단축과 생산성 증대
    
    
• 아마존
  • 새로운 사업 아이디어를 벤처 캐피털 방식으로 사업성 평가
  • 초기 투자 가치가 있으면 독립 사업 조직 육성
  • 대부분의 의사 결정을 2~3단계로 단축
    
    
• 쿠팡
  • 2개월 주기로 개발 및 결과물을 점검, 최종 검증된 서비스를 정식 적용(로켓배송, 쿠팡맨)
    
    
• 삼성전자
  • 예 ) 갤럭시 S7 등에 탑재하는 SW를 당초 계획보다 1~2개월 개발 기간 단축
    
    
• 네덜란드 ING은행
  • 직원들의 기존 업무를 없애고 소규모 애자일 조직에서 새로운 업무를 익히게 함
    → 업무 몰입도 향상, 금융상품 개발 속도도 10배 빨라짐

 

---

익스트림 프로그래밍

• 변화하는 소프트웨어 개발 문화를 다루는 가장 중요한 접근법
• 좋은 방법들을 극단적으로 밀어붙이는 방식(예 : 반복 개발)
• 해당 작업을 반복하며, 시스템을 배포하는 간격이 짧음

익스트림 프로그래밍

 

---

익스트림 프로그래밍 실무

• 공동 소유권
  • 개발자는 시스템 모든 영역에 대해 짝을 이뤄 작업하고, 코드에 대한 공동 책임을 가진다.
  • 모든 개발자가 어떤 것이든 변경할 수 있다.
    
    
• 연속적 통합
  • 특정 작업에 대한 업무가 끝나자마자, 전체 시스템에 통합된다.
    그 이후에는 해당 시스템에 속하는 모든 단위 테스트를 통과해야 한다.
    
    
• 점증적 계획
  • 요구사항은 스토리 카드로 기록하고, 릴리스에 들어가는 스토리를 가용한 시간과
    상대적 우선순위에 근거하여 정한다.
    
    
  • 개발자들은 이러한 스토리를 개발 작업으로 쪼갠다.
    
    
• 고객의 참여
  • 최종 시스템 사용자의 대표(고객)는 XP팀의 이용을 위해 전적으로 시간을 할애할 수 있어야 한다.
  • XP 프로세스에서, 고객은 개발팀의 구성원이며 구현팀에게 시스템 요구사항을 전달할 책임이 있다.
    
    
• 짝 프로그래밍
  • 개발자는 서로의 작업을 점검하고 항상 작업을 제대로 할 수 있도록 지원하면서 짝을 이루어 작업한다.
    
    
• 리팩토링
  • 개발자들은 코드 개선 사항이 발견되자마자 코드를 리팩터링 한다.
  • 리팩토링 작업은 코드를 단순하고 유지보수하기 쉽게 만들어준다.
    
    
• 단순한 설계
  • 현재의 요구사항을 만족시키기 위해 충분한 설계를 수행한다.
    
    
• 소규모 릴리스
  • 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발한다.
  • 시스템 릴리스는 빈번하게, 초기 릴리스는 점증적으로 기능을 추가한다.
    
    
• 유지할 수 있는 속도
  • 많은 양의 초과 근무를 허용하지 않는다
    → 코드의 품질을 떨어뜨리고, 중간 정도의 생산성으로 이어짐
    
    
• 테스트 우선 개발
  • 새로운 기능에 대한 테스트를 작성하기 위해 자동화된 단위 테스트 프레임워크를 사용한다.
    
    

 

---

사용자 스토리

• 시스템 사용자가 경험할 수 있는 일종의 사용 시나리오
  • 요구사항 도출과 개발을 함께 진행할 수 있게 함
    
    
• 기존의 요구사항 문서나 유스케이스보다 시스템을 더 쉽게 이해 가능
  → 사용자가 요구사항을 제안하도록 할 때 유용함
  
  
• 완전성 문제
  • 스토리가 요구사항 전체를 다루기에 충분한지 판단 어려움
  • 어떤 활동에 대해 제대로 된 그림을 보여주는지 판단 어려움
  • 숙련된 사용자는 특정 업무에 익숙해서 그 업무를 빼먹을지도

 

---

스토리 카드와 작업 카드

• 스토리 카드
  • 고객의 요구를 담고 있는 스토리를 간단하게 설명하는 도구
  • 개발팀은 소프트웨어 릴리스에 포함시킬 시나리오를 실제로 구현하는데 집중
    
    
• 작업 카드
  • 스토리 카드의 내용을 여러 과업으로 나눈 것
  • 각 과업을 구현하는데 드는 노력과 자원을 추정
  • 요구사항 개선을 위해 고객과 의견을 주고받음
    

 

---

시스템 반복 계획에서 스토리카드

• 스토리 카드 작성
  → 스토리 카드를 여러 과업으로 나눔
  → 다음 릴리스를 전달하기 전까지 구현 가능한 유용한 기능 탐색
  
  
• 요구사항이 바뀌는 과정에서 스토리가 바뀌거나 사라질 수 있음
  • 이미 배포한 시스템 변경 시, 신규 스토리 카드 작성 후 우선순위 비교 필요
    

 

---

리팩토링

• 프로그래밍 팀이 소프트웨어에서 개선 가능한 부분을 찾아서 즉시 구현하는 것
  → 당장 고칠 필요가 없어도, 발견하면 코드 개선
  
  
• 소프트웨어의 구조와 신뢰성을 개선
  • 소프트웨어 변경 시 발생하는 구조적 악화 방지
  • 부분적 변경으로 인한 구조 파괴 방지(점증적 구조의 문제점 해결)
    
    
• 실제로 적용 어려움 ← 신규 기능 구현 때문에 시간 없음, 시스템 아키텍처 변경해야 하는 경우

 

---

짝 프로그래밍

• 짝이 유동적으로 바뀌어 개발 프로세스 동안 모든 팀 구성원이 서로 같이 개발 작업 가능
• 장점
  • 시스템에 대한 집단 소유와 책임이라는 개념 제공
    → 공동 책임을 가지게 됨
    
    
  • 일종의 비정형적 리뷰 프로세스를 진행하게 됨
    
    • 정형적인 코드 인스펙션과 리뷰의 경우 많은 비용과 시간을 필요로 함
      
      
  • 소프트웨어 구조 개선을 위해 리팩토링을 사용
    • 다른 개발자의 도움을 받을 수 있음(집단 소유 특성)
      
      
• 현황
  • 애자일 기법을 도입한 많은 회사들은 짝 프로그래밍 사용 X
  • 어떤 회사들은 짝 프로그래밍과 개별 프로그래밍을 혼합 사용
    
    
• 짝 프로그래밍의 효과에 대한 연구 결과
  • 경험이 많은 개발자로 이루어진 연구에서는 개별적으로 일하는 방식이 더 효율적
  • 학생 지원자의 경우 생산성이 큰 차이 없음
    
    • 오류나 재작업 줄어듦, 인스펙션 오류를 막아 테스팅 프로세스 시간 줄어듦
      
      
• 짝 프로그래밍으로 이뤄지는 지식 공유 중요

 

 

---

익스트림 프로그래밍 특징

• 작은 크기의 시스템 릴리즈
  • 요구사항은 간단한 사용자 스토리나 시나리오 기반으로 작성
  • 시스템 증가분에 어떤 기능을 추가할지에 대한 토대가 됨
    
    
• 고객대표가 개발팀에 지속적 참여
  • 고객 대표는 시스템에 대한 인수 테스트를 정의
    
    
• 지속가능한 개발 프로세스
  • 프로세스가 아닌 사람을 지원
    (짝 프로그래밍, 시스템 코드의 집단 소유, 유지할 수 있는 속도 등)
    
    
• 변화 허용
  • 고객에게 제공하는 정기적인 릴리스
  • 테스트 우선 개발, 리팩토링, 새로운 기능의 연속적 통합
    
    
• 단순함 유지
  • 코드 품질을 향상하는 리팩토링
  • 시스템에 발생할지도 모르는 불필요한 향후 변경을 고려하지 않은 간단한 설계
    
    
• 애자일 개발 실무 방식들을 커뮤니티에 알렸다는 점에서 큰 공헌
  • 애자일 기법을 채택한 회사들은 업무 방식에 적합한 익스트림 프로그래밍 실무 방식을 골라 사용