Ch03. 애자일 소프트웨어 개발

▶3주차 필기 내용

Ch03. 애자일 소프트웨어 개발

▶신속한 개발과 인도(delivery) 필요 -다수 비즈니스 시스템에서 신속한 개발과 인도가 중요함 -변화하는 비즈니스 환경에 따라 안정적인 요구사항 얻기 힘듬 -시스템 경험 후 요구사항 명확히 알게 되지만 요구사항은 계속 바뀜 ▶계획 주도 프로세스 :신속한 소프트웨어 개발에 부적합 -이 프로세스는 안정성 중심 시스템. 완벽한 분석 필요한 경우 적합 ▶애자일 기법의 등장 -익스트림 프로그래밍 (Extreme Programming) : XP 개발 -스크럼(Scrum) : 관리

 

[애자일 기법의 특징]

-명세, 설계, 구현이 중첩되며 설계문서 최소화

-시스템을 연속적인 증분으로 구현.

-최종 고객 사용자 + 이해당사자가 증분의 명세화와 평가에 참여

-보통 2-3주마다 새로운 증분을 인도

-테스트 자동화 도구, 형상관리 도구, UI 생성 도구 등 여러 도구를 활용

-(고객) 커뮤니케이션 활성화, 문서 최소화

 

[계획주도 VS 애자일 비교]

▶계획주도 개발

-프로세스 단계별로 해당하는 산출물 생성하도록 각 단계를 나눔.

-각 단계의 산출물이 다음 단계에서 사용됨

-활동 별로 반복 이뤄짐

▶애자일 개발

-설계와 구현을 프로세스 중심 활동으로 두고 요구사항, 테스팅 등을 설계와 구현에 포함시킴

-요구사항과 설계를 따로 다루지 않고 함께 발전시킴

---

   3.1 애자일 기법

-계획주도 접근법은 요구사항/설계 등의 ‘문서화’에 중점

-대규모로 오래 지속되는 소프트웨어 시스템 개발에 적합

-중소 규모 비즈니스 시스템을 개발하기에 오버헤드 큼

-요구사항 바뀌면 명세, 설계, 프로그램을 함께 변경해야 함

 

[애자일 기법]

-1990년대 말 등장

-개발팀이 설계, 문서 작업보다는 소프트웨어 자체에 더 집중 O

-요구사항 자주 변경되는 애플리케이션 개발에 적합

-반복적 개발

-고객이 작동하는 소프트웨어 빨리 받아 요구사항 도출에 기여

 

[애자일 선언]

-프로세스의 도구 < 개인과 상호작용

-문서 < 작동 소프트웨어

-계약 협상 < 고객과의 협업

-계획 < 변화에 대응

 

[애자일 기법 원칙들]

고객 참여

변화 수용

점증적 인도

단순성 유지

프로세스가 아닌 ‘사람’

 

[애자일 기법 적용]

-소프트웨어 회사가 중소규모의 제품 개발 시.

-고객이 개발 프로세스에 참여 의사O 참여 가능O

-외부 이해당사자나 규제 없는 조직 내에서 이뤄지는 맞춤형 개발

-같은 장소에 있는 팀으로 구성 (밀접/신속 의사소통 O)

---

   3.2 애자일 개발 기법

[Extreme programming] XP : ‘개발’ 기법

-극단적으로 반복적인 접근법

-하루에 여러 개 버전. 2주마다 증분을 인도

-요구사항을 사용자 스토리라는 ‘시나리오’로 표현. 사용자 스토리를 태스크로 나누어 표현

-프로그래머는 ‘짝’으로 개발하고 코드 작성 전 테스트를 먼저 작성

-새로운 코드를 시스템에 통합하려면 모든 테스트를 통과해야 함  (기존 테스트 자동화 + 추가 테스트)

-시스템 자주 배포함. 시스템 배포 간격이 짧음

[XP 실무]

공동 소유권	모든 개발자는 모든 코드에 책임 O
연속적 통합	작업 끝나자마자 시스템에 통합. 통합 후 모든 테스트 통과해야함
점증적 계획	요구사항은 스토리 카드(시나리오)에 기록. 개발자는 스토리를 개발 태스트로 나눔
고객 참여	고객은 개발 팀의 구성원. 요구사항 도출 책임 가짐
짝 프로그래밍	개발자는 짝을 지어 일하고 서로의 작업 검토
리팩토링	기능은 그대로. 코드의 단순화(리팩토링)
단순한 설계	현재의 요구사항만을 생각하며 설계 수행 (미래 반영X 고려X)
소규모 릴리스	최소한의 기능 먼저 개발 초기 릴리스에 점증적으로 기능 추가하며 자주 시스템 릴리스함
유지할 수 있는 속도	과도한 초과근무 X. 되려 코드 품질과 생선성 떨어뜨림
테스트 주도 개발	자동화된 테스트 프레임워크 이용하여 새 기능 구현 전 테스트 먼저 작성함

 

[애자일. XP 원칙]

1, ‘점증적 개발’은 빈번하고 작은 릴리스를 통해 지원됨 2. ’고객참여‘는 고객이 개발팀에 지속적으로 관여함을 의미. 3. ’프로세스가 아닌 사람‘은 짝 프로그래밍, 공동 소유권, 초과근무 지양하는 지속 가능 개발 4. ’변화 수용‘은 정기적 릴리스, 테스트 우선 개발, 리팩토링, 새로운 기능의 연속적 통합을 통해 지원됨 5. ’단순성 유지‘는 코드 품질 개선하는 계속적인 **리팩토링과 미래의 변경을                                                                  불필요하게 반영하지 않는 단순한 설계를 통해 지원됨

 

[실무적 XP 기법]

▶대부분의 조직에서 XP는 너무 극단적. 실무 적용 어려움

-실무 원칙을 골라서 사용함

-Scrum 관리 중심 기법과 함께 사용

▶주요 실무 원칙

-테스트 우선(주도) 개발 : TDD(Test Driven Development) -리팩토링(refactoring) -점증적 개발 -사용자 스토리 -짝 프로그래밍

 

[1. 사용자 스토리]

*사용자 스토리 :시스템 사용자가 경험할 수 있는 일종의 사용 시나리오

▶XP의 요구사항 관리

-요구사항 변경 지원을 위해 별도의 요구공학 활동 두지 않음

-시스템 사용자가 경험할 수 있는 일종의 사용 시나리오(사용자 스토리) 만들어 관리

-고객은 개발팀과 스토리 카드를 작성. 스토리 카드를 ‘과업’(task)로 나누어 개발

 

▶사용자 스토리의 장단점

-요구사항 문서나 유스케이스 보다 쉽게 이해 가능

-요구사항 완전성 문제

: 스토리들이 시스템 주요 요구사항 전체를 포함하였는지

: 개별 스토리에 누락된 내용은 없는지

 

[2. 리팩토링]

▶전통적인 소프트웨어 공학

-변경을 고려한 설계를 하라

▶XP

-변경이 없거나 예상치 못한 변경 요청 일어나기도 하므로 변경 고려한 설계 = 시간낭비

-변경은 필연적 발생 + 점증적 개발 -> 소프트웨어 구조 망가짐

-지속적 리팩토링으로 소프트웨어 구조와 가독성 개선 -> 구조적 악화 막고 변경 처리 쉬움

▶리팩토링의 예시

*리팩토링 : 개선 가능 부분 찾아서 즉시 구현하는 것 의미

-중복 코드 제거위한 클래스 구조 변경

-속성/메소드 이름 적절 변경

-비슷한 코드 반복 사용을 메소드 호출로 묶어서 대체

 

[3. 테스트 우선 개발]

▶XP의 테스트

-명세 없이 테스팅하는 문제

-테스팅을 자동화하고 변경 후에 모든 테스트 통과해야 진행

▶XP 테스팅 특징

-테스트 우선 개발 -> 코딩 -> 테스트

-시나리오 이용하여 점증적 테스트 개발

-테스트 개발과 검증에 사용자 참여

-테스트 자동화 프레임워크 사용

-스토리 카드 -> 태스크 -> 태스크 별 테스트 작성

-고객은 다음 릴리스에서 구현할 스토리에 대한 인수 테스트 개발을 도움

 

▶[테스트 주도 개발(TDD) ]

-코드 작성 전 테스트 먼저 작성

▶테스트 주도 개발 특징

-테스트 작성하려면 기능, 인터페이스에 대해 알아야 하므로 요구사항 명확히 할 수 있음

-테스트 지연 문제 방지

-자동화된 테스트 프레임워크 사용 필수 (ex. JUnit)

: 테스트 쉽게 작성할 수 있게 함

: 테스팅을 자동으로 실행할 수 있으며 테스팅 결과가 명세에 맞는지 확인 가능

 

▶[테스트 자동화]

-테스트 자동화는 TDD에 필수적

⇒ [테스팅 컴포넌트]

-독립 실행 가능

-테스트 입력과 결과 확인 가능

-JUnit 등 자동화 프레임워크 이용

⇒ [테스트 커버리지] coverage (***)

-완전성 판단할 수 없음

 

[4. 짝 프로그래밍]

▶짝 프로그래밍

-프로그래머가 짝을 지어 코드 같이 개발. (짝 바뀔 수 O)

▶장점

-시스템에 대한 공동 소유권, 책임

-다른 사람이 같이 코드 보기 때문에 비공식적 ‘인스펙션’(코드 리뷰) 프로세스 진행됨

-리팩토링 장려,지지

▶짝 프로그래밍의 실무 적용

-경험 많은 개발자 + 경험 부족한 개발자

-학생 개발자의 경우, 짝 프로그래밍 생산성 낮지 않다는 연구

-경험 많은 개발자의 경우, 생산성이 떨어진다는 연구

-지식 공유가 중요

---

3.3 애자일 프로젝트 관리

▸계획주도 접근법 -무엇이 언제 인도될 것인지, 누가 산출물 만들 것인지 계획 가지고 있음 -관리 쉬움 ▸ 애자일 기법 -프로젝트 진척도가 가시적 X -비공식적 계획과 프로젝트 관리 -큰 조직에 부적합

 

[스크럼] : Scrum

▶ 스크럼: 애자일 프로젝트 조직화, 외부 가시화 제공 위한 프레임워크

-반복적 개발 관리에 중점을 둔 방법

-특정 애자일 실무 원칙 요구 X

▶ 용어

스크럼 마스터	프로젝트 관리자
제품 *백로그(backlog)	할 일 목록 To do list
*스크럼	개발 팀 일일 회의 (짧은 회의)
*스프린트(sprint)	반복

 

[스프린트 주기]

▸2-4주 범위의 고정 길이

-완성 못한 작업 처리 목적으로 기간 늘리지 X 않음

-마치지 못한 작업은 ‘제품 백로그’(전체 할 일)에 돌려놓음

▸제품 백로그 항목 우선순위 매겨서 해당 스프린트에 작업할 ‘스프린트 백로그’를 선정

-‘스프린트 백로그’(이번에 할 일)

▸매일 스크럼 진행

-진척도 점검. 우선순위 조정하는 짧은 미팅

-진척 사항, 문제점, 계획 등 정보 공유

▸‘스크럼 보드‘를 두어 정보 공유함

-스프린트 백로그, 진행상황, 완료된 작업 등 표시

-누구든지 변경 가능

▸스프린트 끝날 때 리뷰 미팅 실시

[소프트웨어 공학]  한티 미디어 10판 교재