- Rapid development and delivery ( = incremental )
- Plan-driven development 계획주도기법 ( = waterfall )
: 각 단계들이 모두 별개의 단계이며 수정이 필요할 경우 처음으로 돌아가야한다
Agile development
- 명세화, design, implementation이 모두 중첩되어 있다 (inter-leaved)
- 명세화 최소화 ( 요구사항이 계속 변하기 때문에 )
- stakeholders들이 개발에 포함되면 점진적으로 발전, 증가하는 버전
- 고객이 개발팀의 거의 일부로 참여 - Extensive tool support
- CASE tool ( Computer Aided Software Engineering )
Agile 방법론의 종류
스크럼 scrum , 익스트림 프로그래밍 XP , 적응형 소프트웨어 개발 방법론, 기능주도 개발 방법론, 크리스탈 패밀리, 린(Lean) 소프트웨어 개발방법론 , 애자일 UP
Agile 방법론
디자인보다 코드 자체에 집중하며 빠르게 변경, 수정 가능
Agile 방법론의 원칙
- 고객 참여
고객이 개발 프로세스 전반에 밀접하게 관여해야한다 ( 평가, 요구 추가, 요구 변경 등 ) - 변화 수용
변화할 시스템 요구사항을 예측하고, 변화가 있을 것을 숙지하고 설계 - 점증적 인도
소프트웨어를 점증적으로 개발한다 - 단순성 유지
개발하고 있는 소프트웨어와 개발 프로세스 모두 '단순성'에 집중 - 프로세스가 아닌 사람
팀 구성원이 규정된 프로세스에 얽매이지 않고 각자의 업무 방식대로 효율적으로 개발
Agile 방법론 적용가능성 (applicability)
- 중소 규모의 회사
- clear commitment from the customer to become involved in 개발 과정
- 규제가 많이 없고, 그리 치명적이지 않은 경우
XP (Extreme programming)
1990년대에 소개된 애자일 방법론
사용자가 요구사항을 보다 쉽게 말할 수 있도록 유도하기 위해 '스토리'로 말할 수 있게 한다
user requirements 는 card에 적어서 implementation tasks로 쪼갠다
= task 단위로 말하기 힘드니 story에서 task들을 유도한다
- flexible하고 작업에 대한 이해도가 높아질 수 있다는 장점이 있지만, 사용자가 그 스토리/시나리오를 완전히 기억하지 못하여 '완전성'이 떨어질 수도 있다
- 스토리를 기능으로 mapping 시키는 데 어려움이 있을 수 있다
XP에서의 원칙 / 실무
- 연속적 통합 - 각 증가분을 전체 시스템에 계속해서 통합해나간다
- 점증적 계획 - 요구사항은 '스토리카드'로, 해당 스토리를 '작업'으로 쪼개어 작업
- 고객의 참여 - 증가분에 들어갈 내용 결정 및 피드백 등 개발팀의 구성원으로 취급
- 짝 프로그래밍 : 짝을 지어 서로의 작업을 점검
- 공동 책임
- informal review process -> 코드의 품질이 좋아짐
- refactoring을 encourage한다
- pair가 dynamically 지어지기 때문에 전체적인 코드를 모두 볼 ㅅ 있다
-> backup 용도로도 좋음
- 공동 소유권 : 짝 프로그래밍을 통해 더 강화됨
- 리팩토링 : 코드의 품질을 높여 유지보수를 쉽게 만들어 줌
- 중복되는 코드 제거, 직관적인 변수명, 클래스,모듈화, comment
- 시행결과는 같으나 가독성이 올라감
- 단순한 설계 : 현재의 요구사항만을 만족시키는 설계
- 소규모 릴리스 : 최소한의 유용한 기능 먼저 개발 후 빈번한 릴리스를 통해 점증적 기능 추가
- 유지할 수 있는 속도 : 많은 양의 초과근무를 허용하지 않는다 - micro한 에러가 후에 critical한 문제가 될 수도 있기 때문
- 테스트 우선 개발 : 자동화된 단위 테스트 프레임워크 이용 ( 증분별로 계속해서 test 진행 )
- 애러 test를 말하는 것이 아닌 사용자 니즈에 맞는지 확인하는 test
SCRUM
반복적인 개발을 관리하는 데에 집중
구성원
-
개발팀 scrum team
팀원 5~9명으로 구성되며 사용자 요구사항을 사용자 스토리로 도출하고 이를 구현
기능을 작업단위로 나누고 일정이나 속도 추정
일일 스크럼 회의에 참여하여 진척 상황 점검
-
제품 소유권자(책임자) product owner
이해 당사자들
제품 기능 목록, 우선순위와 중요도 매김 -
스크럼 마스터 scrum master
제품 책임자를 돕는 조력자 PM
스크럼 팀이 스스로 조직하고 관리하도록 지원
개발 과정에 방해될 만한 요소 찾아서 제거
용어들
- 증가분
- 제품 백로그 product backlog : 제품 기능 목록
- 스프린트 sprint
- 속도 velocity
- 스크럼 scrum
product backlog 제품 기능 목록
사용자가 요구하는 제품의 기능 목록 ( 사용자 요구사항 )
- 제품에 관한 모든 요구사항에 대해 우선순위가 정해져있음
- 한 번 결정된 제품 기능 목록은 확정된 것이 아니라 개발중이라도 수정가능하지만, 한 주기가 끝날 때 까지는 제품 기능 목록을 수정하지 안는다 ( backlog를 freeze해두었다가 주기가 끝나면 수정 )
- 제품 소유권자가 작성한다.
sprint 스프린트 ( '증분' )
작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발
- 스크럼에서 의 반복주기 기간은 보통 2~4주정도
- 결정된 스프린트의 목표와 내용은 개발 도중에 바뀌지 않아야한다
- 한 스프린트가 완료되면 사용자에게 시연하고 피드백을 받아야한다.
일일 스크럼 회의 daily scrum meeting
스프린트 기간에 하는 회의
- 매일 서서 모든 팀원들이 약속된 시간에 짧게 한다
- 진행상황만 점검하며 잘 개발하고 있는지 확인
sprint backlog 스프린트 작업 목록
- 각각의 스프린트 주기에서 개발할 작업 목록
- 세부적으로 어떤 걸 구현해야하는지 세부작업 항목과 작업자, 예상 작업시간에 관한 정보
sprint review
- 하나의 스프린트 반복주기가 끝났을 때 생성되는 실행가능한 제품에 대한 검토
- 스프린트 동안 작업한 결과 시연, 테스트, 피드백 수령
소멸차트 burndown chart
계획 대비작업이 어떻게 진행되고 있는지 날짜별로 남은 작업량으로 나타냄
기울기가 급하면 작업이 빠르게 진행됨
가로축 : 스프린트 반복 주기 날짜 수
세로축 : 완료된 작업의 추정일수
진행 절차
- 제품 기능 목록 작성 : 우선순위 매겨서 목록 작성
- 스프린트 계획 회의 : 스프린트 작업 목록 작성 , 개발 시간 추정
- 스프린트 수행 : 스프린트 개발, 일일 스크럼 회의, 현황판 변경, 소멸차트 표시
- 스프린트 개발 완료 : 실행 가능한 최종 제품 생산
- 스프린트 완료 후 : 스프린트 검토 회의, 회고, 두번째 스프린트 계획 회의
스크럼 기법의 장점
- product가 관리가능한, 이해가능한 조각들로 쪼개진다
- 요구사항이 변경되어도 큰 영향을 미치지 않는다
- 의사 소통을 원활하게 할 수 있다
- 2-4주마다 증가분을 확인할 수 있으며 피드백을 요구할 수 있다
- 고객과 개발자 사이에 신뢰관계가 형성된다
애자일 기법의 규모조정
- 애자일 기법은 요구사항이 고정되어 있지 않으므로 계약시 사용할 수 있는 문서가 없다
- 빠른 개발에는 유리하지만, 유지 보수에는 불리하다
- 작은 규모의 회사들에게는 유리하지만, 세계적 협업이 필요할 경우 적절하지 않다
