Agile(에자일) 방법론

UX design process 중 Agile 방법론에 대한 자료 공유합니다.

Agile 방법론이란, 프로세스나 도구보다 의사소통을 강조함으로써 요구사항변경에 적극적으로 대처하고,  시스템 변경사항을 유연하고 기민하게 대응할 수 있도록 하는 개발 방법론을 뜻하는 총칭이다.

전통적인 개발 방법론과 Agile 개발 방법론은 각각의 장단점을 가지고 있다.
따라서 전체적인 개발 방법론은 전통적인 개발 방법론과 같이 각 단계별 절차와 계획에 따라 정하고, 경우에 따라 각 모듈 별 세부 개발시에 Agile 개발방법론을 도입학는 것이 유용하다.

Agile의 주요 방법론 유형

• XP(eXtreme Programming) : 개발방법론 혹은 개발 기법 중심
• SCRUM : 프로젝트 관리 방법론 중심
• RUP : 반복, 점진적인 개발방법론을 대표
• LSD(Lean Software Development) : 식스시그마 품질 선도
• DSDM(Dynamic System Development Method) : 점진적 개발, 일정 확정, 범위예측
• FDD(Feature-Driven Development) : 기능주도 개발

XP (eXtreme Programming)

1) XP 개요

• 1990년대 후반 만들어진 개발 기법 중심의 Agile 방법론 중 하나이다.
• 반복형 모델의 개발주기를 극단적으로 짧게 함으로써 개발자가 설계, 구현, 테스트 활동을 전체 소프트웨어 개발 기간에 걸쳐 조금씩 자주 실시하도록 하고 소프트웨어 변경의 비용을 최소화하는 기법이다.

2) XP 목적

• 기본 가치, 원칙, Pracices을 통하여 변경 비용 및 일정 감소

3) XP 주요 활동

• Coding : 시스템 개발활동의 진짜 중요한 산출물은 코드
• Testing : 단위테스트는 코딩의 불확실성을 검증하고 승인테스트는 의도에 대한 불확실성을 검증
• Listening : 비즈니스에 의하여 기능 결정, 기능 결정에 의하여 비즈니스를 파악
• Designing : 시스템의 복잡성, 종속성 회피를 위한 방법

4) XP 프로세스

• 유저스토리

           고객이 자신이 원하는 내용을 기술한다.
           릴리즈 계획 및 승인테스트 계획의 기반이 된다.

• 스파이크솔루션

           기술적 또는 설계상의 어려운 문제를 해결하기 위한 것이다.
           기술적인 문제를 줄이고 유저스토리의 추정한 개발일정의 신뢰도를 높이는 것이다.

• 메타포어

           일관된 명명규칙을 이용하여 클래스와 메소드 등을 명명

• 릴리즈계획

           주기(1~3주)의 시작마다 회의를 통한 처리할 유저스토리를 고객과 선정한다.
           고객관점의 유저스토리를 개발자관점의 프로그램으로 변경하여 진행한다.

• 주기

           릴리즈 계획에 따른 개발을 의미
           해당 주기가 시작될 때 주기 계획회의를 통해 주기에 해야할 일을 결정한다.

• 승인테스트

            각 주기의 유저스토리에 대한 처리완료 기준이 된다.

5) XP 핵심가치

• 의사소통 : 단순한 디자인, 공통의 메타포어, 사용자/개발자간 협업, 빈번한 구두 의사소통, 피드백
• 단순성 : 단순한 솔루션, 단순한 설계, 단순한 코드(의사소통의 질 향상)
• 피드백 : 시스템, 고객, 팀으로부터의 피드백
• 용기(Courage) : Practice 수행을 위하여 용기 필요. 간단한 디자인, 간단한 코딩

6) XP 원칙

• 피드백, 단순한 가정, 변화 수용

7) XP Practices

• 정교한 피드백 : 페어 프로그래밍, 게임 계획, TDD, 전체 팀
• 지속적 프로세스 : 지속적 통합, 리팩토링 또는 디자인 개선, 작은 배포주기
• 이해의 공유 : 코딩 표준, 코드 공동 소유, 간단한 설계, 시스템 메타포어

8) XP 활용 분야

• 모바일이나 쇼핑몰처럼 소비자의 변화에 따라 짧은 시간에 민첩하게 변화되어야 하는 분야
• 요구사항 등의 변화가 자주, 많이 발생하거나 개발자가 소규모이고 같은 공간을 사용하는 경우에 높은 효과
• 유동성이 큰 프로젝트, 단 기간의 프로젝트
• 기술적으로 신기술을 도입하였거나 경험이 없거나 한 경우

 SCRUM

1) SCRUM 개요

• 비즈니스 요구를 충족시키는 소프트웨어를 개발하는데 초점을 맞추기 위해 복잡함을 제거하는 관리 및 제어 프로세스이다.
• 사람들이 효과적으로 협업할 수 있게 해주며 그로 인해 복잡하고 정교한 제품을 생산할 수 있게 해준다.
• 프로젝트 관리 방법론 중심의 Agile 방법론이며 XP의 실천 방법으로 사용한다.
• 작은 개발팀, 짧은 개발주기(4~6주) 반복 등의 특징이 있다.

2) SCRUM Process

• 제품 백로그(Product Backlog)

           시스템이 해결해야 하거나 시스템에 포함되어야 할 모든 것으로 기능, 특성과 기술을 모두 나열한다.
           모든 요구사항을 우선순위에 따라 나열한 목록을 말하며 결코 확장되지 않고 제품과 함께 성장하고 진화한
           다.
           우선순위가 가장 높은 항목이 가장 필요한 항목이다.
           백로그 내용은 누구나 제안할 수 있지만 제품 책임자만이 백로그 항목들의 우선순위를 부여할 수 있다.

• 스프린트(Sprint)

           약 30일의 반복 주기로 개발 가능하다고 생각되는 만큼의 기능을 제품 백로그에서 선택한다.
           매 스프린트 끝에는 새로운 기능이 추가되어 실행 가능한 제품이 인도되어야 한다.
           아키텍쳐와 설계는 첫 스프린트에서 완료되는 것이 아니라 여러 번의 스프린트를 거쳐야 드러나게 된다.

• 스프린트 백로그(Sprint Backlog)

           팀이 해당 스프린트에서 수행할 태스크 목록

• 스크럼 마스터(SCRUM Master)

           팀원들이 스크럼의 실천법을 실천하도록 강제하고 팀이 결정을 내리거나 혹은 자원을 얻을 수 있도록 돕는
           다.
           스프린트 동안 팀은 외부의 어느 누구에 의해서도 방해를 받거나 지시를 받아서는 안된다.

• 일일스크럼(Daily SCRUM)

           약 15분 정도의 매일 하는 짧은 회의
           일일 스크럼에서 관리자는 진행 사항을 검토하고 제거해야 하는 장애물을 확인한다.
           일일 스크럼에서 팀의 진척 정도를 확인할 수 있다.

TDD (Test Driven Development)

1) TDD 개념

• 미리 작성되는 테스트를 기반으로 짧은 반복주기를 이용하여 소프트웨어를 개발하는 기법이다.
• 테스트 작성을 통해 요구사항을 정의한다.
• TDD는 단순한 테스트 기법이 아닌 소프트웨어 설계의 한 기법이다.

2) TDD 요구사항

• 테스트 작성 -> 코드 작성 -> 테스트 실행 -> Refactoring
• 반복주기 1~n 수행

            테스트작성 : 요구사항을 명확히 이해, 유스케이스, 유저스토리 등 이용
            테스트검증 : 테스트케이스의 올바른 작동 여부 확인
            코드 작성 : 완벽하지는 않지만 테스트는 성공할 수준        
            자동화된 테스트 실행 : 모든 테스트 요구사항 충족 확인
            Refactoring : 불필요한 코드, 중보코드 제거
            반복 : TDD 사이클이 길어지면 규모 조정 필요

3) TDD 효과

• 품질 및 생산성 향상
• 더 빠르고 좋은 소프트웨어 빌드
• 작성 코드에 대한 테스트 커버리지 보장
• 모듈화, 유연한/확장 가능한 코드 생성

4) TDD 제약

•  성공 확인을 위하여 모든 기능을 테스트 하여야 하는 경우 적용 어렵다.
• 관리자의 지지가 필수적으로 필요하다.
• 전통적으로 테스트에 대하여 개발자가 아키텍트에 비하여 상대적으로 낮은 인식을 가지고 있다.
• 테스트 자체가 프로젝트 유지보수 오버해드가 된다.

출처 : [사이트] http://searchstory.tistory.com/268