애자일 개발 모형 5가지!

어제의 애자일 모형의 5가지 종류에 대하여 알아보자

1. 스크럼(Scrum)기법

팀에 중점을 둔 기법이다. 구성요소는 다음과 같다.

제품 책임자(PO, Product Owner) : 요구사항이 담긴 백로그를 작성하며, 제품의 이해가 높고 요구사항을 잘 전달하며 의사를 결정할 수 있어야 한다.

스크럼 마스터(SM, Scrum Master) : 스크럼 수행의 책임을 가진다.

개발팀 (DT, Development Team) : 그 외 팀원

개발 단계는 다음과 같다.

출처 : https://ko.wikipedia.org/wiki/스크럼_(애자일_개발_프로세스)

제품 백로그(Product Backlog) : 개발할 제품에 대한 요구 사항 목록

스프린트(Sprint) : 반복적인 개발 주기 (회사에서 정하는 이터레이션이 개발 주기가 된다. 계획 회의부터 제품 리뷰가 진행되는 날짜 까지의 기간이 '1스프린트'이다)

스프린트 계획 회의 (Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의

스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

일일 스크럼 회의(Daily Scrum Meeting) : 날마다 진행되는 미팅 (어제 한일, 오늘 할일, 장애 현상 등을 공유)

실행 가능한 제품(shippable product) : 개발스프린트의 결과로써 나오는 실행 가능한 제품

2. XP(eXtream Programing)기법

스크럼은 팀이 중심이였지만 XP는 고객의 요구사항이 중심이다. 그에 따라 요구사항과 개발을 반복하여 생산성을 향상시킨다. 핵심 가치로는 의사소통, 단순성, 용기, 존중 피드백 5가지이다. (볼때마다 용기는 진짜 적응 안된다..)

 

개발단계는 오른쪽 그림과 같다.

릴리즈 계획 (Release Plan) : 일정을 수립하는 단계

이터레이션 계획 (Iteration plan) : 1~3주정도의 실제 개발

승인 검사 (Acceptance test) : 하나의 이터레이션에서 고객의 요구사항이 구현됬는지 테스트한다.

기립회의 (Stand-up meeting) : 문제점에 대한 팀단위 의사소통 회의

협의 (Pair negotiation)

단위 테스트 (Unit test)

짝 프로그래밍(Pair programming)

코딩 (Code)

(아랫부분은 딱히 설명을 안붙혀도 될 것 같다..)

 

주요 실천 방법에는 다음과 같이 있다.

짝 프로그래밍 (Pair programming) : 공동 플로그래밍으로 개발의 책임을 공동으로 나눠갖는다.

동동 코드 소유 (Collective Ownership) : 개발 코드 권한과 책임을 공동으로 소유한다.

테스트 주도 개발 (Test-Driven Development) : 실제 코드 전 테스트케이스를 작성해 방향을 정확히 파악한다.

전체 팀(Whole Team) : 에자일, XP 방법론 전에는 팀기반 소프트웨어 개발이 흔하지 않았으나, 이후로 팀 전체에 대한 중요성이 높아지며 그 역할에 대한 책임도 중요해졌다.

계속적인 통합 (Continuous Intergration) : 모듈 단위로 나눈 뒤, 계속적으로 작업 마무리마다 통합한다.

리팩토링 (Refactoring) : 프로그램의 기능은 그대로, 대신 성능과 이해도를 향상시키기 위해 재구성한다.

소규모 릴리즈 (Small Releases) : 릴리즈 기간을 짧게 함으로 신속히 대응한다.

3. 칸반(Kanban)

작업 항목 표현을 위해 카드들을 사용하고 각 프로세스 단계를 표현하기 위해 컬럼을 사용하여 시각적으로 다양한 단계의 프로세스의 일을 시각적으로 표현한다. 카드는 왼쪽에서 오른쪽으로 움직여 진행상황을 표현하고 작업을 수행하는 팀의 조율을 돕는다.

짧은 프로젝트는 To Do, Doing, Done, ETC 정도로 적게 구분하여 사용할 수 있고, 눈에 간편하게 들어와 사용하기 좋다.

사족으로 ㅡ Spring 교육 받을 때 칸반을 쓰기는 했지만, 이번에 공부하면서 이 칸반이 일본어 간판에서 왔다는걸 알았다... 신기하네;

4. 린(Lean)

도요타 기업의 프로세스를 S/W개발에 적용한 방법론이다. 낭비제거와 가치의 빠른 제공에 중점을 두는 개발방식이다. 7가지 기본 개발 원칙을 가지고 작업을 한다.

Ⅰ 낭비의 제거 Ⅱ 품질의 내재화 Ⅲ 지식 창출 Ⅳ 확정의 연기 Ⅴ 전체의 최적화 Ⅵ사람 존중 Ⅶ 빠른 인도

에자일과 비교하여 둘 다 요구사항을 빠르게 받고 제공한다는 것은 같지만, 린 개발 방법론은 "낭비의 제거"에 좀 더 초점을 둔다.

5. 기증중심개발 (FDD, Feature Driven Development)

feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

위키에 단 1줄 써있네.. 뭔가 엄청 마무리가 짧아서 애매하므로 도망!