[소프트웨어공학] #2 Software Process(2) Agile

9/26

 

2-1 Background of agile method

agile의 배경

-신속한 소프트웨어 개발

 

 

2-2 Agile methods

-고객의 참여(customer involvement): 가장 중요한 원칙. 개발프로세스에 고객이 참여하는 것.

-점증적 인도(Incremental delivery): 

-변화의 수용(Embrace change): 변화 가능성을 인정하고 수용

-단순성 유지(Maintain simplicity): 최대한 간단하게, 알아보기 쉽게

-프로세스가 아닌 사람(People not process): 프로세스에 맞춰서 운영하는 것이 아닌, 사람의 능력에 맞춰서 운영

 

적용 자체는 소형~중대형에 적용 가능.(대형에 적용하는 것은 연구중)

 

2-3 Agile development techniques: XP programming

agile 방법은 여러가지가 있지만, 무엇을 사용하는지는 팀 상황마다 다르다.

XP(Extreme programming)

-극단적이게 빠르게

-하루에 여러번 빌드 가능.

-증분(Increment)는 2주에 한번

-빌드전에 실행이 가능해야한다(test에 들어가는 cost 최소화)

 

점진적 계획(Incremental Planning): 요구사항을 story card로 만들어서 task들로 쪼갬

소규모 릴리즈(Small Releases): 증분형태. 하나하나 작게작게 구현한다.

단순한 설계(Simple design)

테스트 우선 개발(Test-first development): 

리팩토링(Refactoring): 기능은 그대로. 코드의 내부적 변화. 모든 개발자가 가능한 권한

짝 프로그래밍(Pair Programming): 페어가 되어 일함. 아래의 공동소유권이 이런 이유로 생김

공동 소유권(Collective ownership): 각 개발이 독립적이지 않게함.

연속적 통합(Continuous integration)

유지할 수 있는 속도(Sustainable pace): 야근이나 과한 업무로 순간적으로 업무속도를 높이지 X

고객의 참여(On-site customer): 고객이 full time으로 참여하는게 좋으나, 현실적으로 쉽지는 않음.

 

agile과의 공통 원칙

-점진적 개발

-고객의 참여

-오래 일하는 것은 지양

-릴리즈마다 기능이 추가됨

-간편화 & 리팩토링

 

리팩토링 예시

-반복되는 부분은 함수로

-속성이나 메소드를 이해하기 쉬운 이름으로 변경

-라이브러리 활용

 

테스트 우선 개발

-모든 변경마다 테스트

 

고객 참여

-테스팅 프로세스에 참여해야한다.

-현실은 고객이 한정적인 시간만 가능

-테스트케이스 기술서도 제작

 

테스트 우선 개발의 문제

-개발자가 그냥 문제를 회피해버리게 코딩할 수도 있다.

-테스트 케이스 만들기가 어렵다.(이해관계가 상충되기도 함)

-테스트 해결이 완전함을 보장하진 않음.

 

2-4 Agile projcetm anagement: Scrum

소프트웨어는 제시간에, 계획된 예산 안에서 개발되어야 함

이전의 유행은 plan-driven 방식.

증분 개발과 agile 방법들.

 

Scrum

-반복적인(iterative) 개발방식.

-1. 개발 이전: outline잡기, 목표 설정, 구조 설정

-2. sprint cycles: 1-4주 간격으로 주기적 개발

-3. 프로젝트 종료 단계: 완료

 

Scrum 용어(terminology)

Development team: 개발 팀. 보통 10인 미만, 7인 넘는 경우 많이 없음. 소프트웨어 개발, 문서화

Sprint: 개발에 대한 반복. 2-4주 길이

Scrum: 매일 개발한 사항 공유, 세세한 룰들 설정

Scrum Master: 스크럼 마스터, 리더, 프로젝트를 관리하고, 외보와 소통하여 팀원은 외부와 단절되게.

Potentially shippable product increment: 잠재적 전달 가능한 제품 증가분

Product backlog: 제품 백로그, todo list

Product owner: 제품 소유권자

Velocity: 속도. 한 sprint에서 개발할 수 있는 정도

 

Teamwork

Scrum master는 조력자 역할

- 일일 미팅 주관

- 백로그 추적

- 의사 결정 기록

- 외부와 소통

모든 팀원은 일일 미팅에 참여해야한다.

 

장점

- 관리와 이해가 가능한것

- 말도 안되는 요구는 불가능

- 가시적인 점이 커뮤니케이션으로 이어짐

- 증분으로 확인이 가능하니 바로 피드백 가능

- 고객과의 신뢰

 

2-5: Scaling agile methods

모두를 참여시켜야하나, 대형 팀/대형 프로젝트는 그것이 어려워짐.

plan-driven이 더 쉬워짐.

요구사항을 대략적으로 추출하기에 불분명한 요구사항의 상태.

유지보수엔 적합하지 않음.- 문서화가 최소화되어 유지보수가 어려움

같은 공간의 팀도 어려움.(재택의 증가)

스팩 명시가 어렵다보니 계약과 비용측정이 어려움.

 

부족한 문서, 고객의 꾸준한 참여, 개발팀 유지 어려움.

서로 개발 공유가 필요

원래 개발하던 사람이 없으면..?

 

Agile+plan-driven의 조합을.

- 고객 참여

- 변화 수용

- 점증적 인도

- 단순성 유지

-프로세스가 아닌 사람

 

이슈

-개발할 시스템의 크기

- 시스템 타입

-기대하는 것

-외부의 규제

-잘 디자인하고, 코딩하는 사람(냉정한 평가)

-통합 개발환경

-어떻게 피드백을 줄 수 있는지.

-정보 agile과 개발이 fit한지.

-대형 시스템에 어떻게 적용해야 하는

 

 

대형 시스템의 Agile

-product owner와 scrumMaster가 각 팀에 존재

- 전체 시스템 구조 결정

-추려서 릴리즈 시점 정렬

-다시 통합 Scrum