애자일 개발

1. 애자일 개발 개념
1. 애자일 배경
1. 기존의 무겁고 규범적인 방법론에서 탈피하여 가벼운 방법론을 지향하며 등장
2. 애자일 개념
1. 애자일 선언문
1. 우리는 소프트웨어를 개발하고 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법을 찾아 나간다.

이러한 작업을 통해서 우리는 다음과 같은 가치를 추구하게 되었다.

1. 절차나 도구 보다는 개인과 상호작용을
2. 포괄적인 문서 보다는 작동하는 소프트웨어를
3. 계약에 대한 협상 보다는 고객과의 협력을
4. 계획을 고수하기 보다는 변화에 대한 대응을

더욱 가치 있게 여긴다.

2. 애자일 선언문의 12가지 원칙
1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 간결함(안 하는 일의 양을 최대화하는 기술)이 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 발생한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
3. 애자일 특징
1. 애자일에 기반한 소프트웨어 개발은 반복적이고 점진적인 개발을 특징으로 가짐
2. 이런 유형의 개발 형태를 효과적으로 진행하기 위해 자기조직화, 교차기능팀 등의 기법을 사용한다.
3. 폭포수 방법론과 애자일 방법론 간의 주요 차이점

1. 구분	폭포수 방법론	애자일 방법론
   계획중심 vs 고객 중심	프로젝트 시작 전에 전체적인 프로젝트 일정 계획을 만들고, 일에 따라 프로젝트를 진행	프로젝트의 불확실성을 감안하여  현재 시점에 고객에게 중요하거나 확정된 내용을 중심으로 계획을 수립
   빅뱅 릴리즈 vs 작은 릴리즈	프로젝트 종료 시점에 모든 기능을 한 번에 릴리즈	이터레이션이라는 일정 기간 단위로 작은 릴리즈를 지속적으로 반복
   산출물 중심 vs 동작하는 SW 중심	단계별로 지정된 산출물이 작성되었는지 여부를 확인함으로써 프로젝트가 제대로 진행되고 있는지 확인	소프트웨어가 얼마나 제대로 동작하는지, 얼마나 요구사항에 맞게 개발되었는지가 중요

4. 애자일 방법론 종류
1. 애자일 선언문이 나온 이후 다양한 애자일 방법론이 등장한다.
2. 세계적으로 널리 채택된 애자일 방법론은 스크럼, 익스트림 프로그래밍(XP) 가 있다.
3. 주요 애자일 방법론
1. 스크럼
2. 적응형 소프트웨어 개발 방법론
3. 기능 주도 개발 방법론
4. 동적 시스템 개발 방법론
5. 크리스탈 패밀리
6. 익스트림 프로그래밍
7. 린 소프트웨어 개발 방법론
8. 애자일 UP
2. 애자일 개발 방법론 - XP
1. XP 개요
1. 중소규모 개발 조직에 적합한 경량화된 개발 방식
2. XP를 적용함에 있어서 가치와 가치를 달성하기 위한 실천법으로 구성되며 이 두 가지의 균형을 유지하기 위한 원칙이 필요하다.
3. XP는 반복적 개발 방법론의 일종이다.
4. 프로젝트 수행 과정에 여러 번의 반복이 있으며 테스트 결과에 따라 반복적으로 업무를 수행한다.
2. XP 가치
1. 의사소통
1. 팀 단위 소프트웨어 개발에서 가장 중요한 것은 의사소통 이다.
2. 고객, 개발자, 관리자들 간의 의사소통을 통해 문제를 해결하고 팀 빌딩을 강화해야 한다.
2. 단순성
1. 가능한 한 가장 단순한 것은 무엇인가? 라는 물음을 늘 갖는다.
2. 불필요한 복잡성을 제거하여 설계를 단순, 명확하게 하도록 유지한다.
3. 피드백
1. 완전성을 추구하는 것보다 점진적인 개선이 효과적이다.
2. 팀이 다룰 수 있는 한도 내에서 최대한 빨리, 많은 피드백을 만들어 개선에 활용한다.
4. 용기
1. 요구사항 및 기술 변경에 용감하게 대처해야 한다.
5. 존중
1. 팀에 속한 다른 사람들을 중요하게 여기지 않고 프로젝트를 제대로 할 수는 없다.
3. XP의 실천 방법
1. 개발
1. 단순한 설계 : 유 무선 인터넷 망과 이동 통신망을 이용한 음성 통화
2. 테스트 기반 개발 : 코드를 작성하기 전에 테스트로부터 작성하고 테스트 도구를 사용하여 자동화하라
3. 리팩토링 : 코드의 중복과 복잡성을 제거하여 기존 코드의 디자인을 향상시켜라
4. 코딩 표준 : 효과적인 의사소통을 위해 코딩 표준을 만들어라
5. 짝 프로그래밍 : 두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 개발 작업을 진행하라
6. 코드 공유 : 팀의 모든 개발자가 소스코드에 대한 공동 책임을 져서 언제든 누구라도 코드를 수정해서 더 좋게 만들 수 있게 하라
7. 지속적인 통합 : 작업이 끝날 통합 작업을 수행하라.
2. 관리
1. 계획 게임 : 프로젝트 전체 계획과 주기 계획을 비즈니스와 기술적인 측면을 고려하여 세우고, 실행과 피드백을 통해 업데이트를 유지하라
2. 짧은 릴리스 : 실행 가능한 모듈을 가능한 한 빨리 배포하여 고객이 수시로 소프트웨어의 동작을 볼 수 있게 하라
3. 메타포 : 시스템에 대한 전체 모습을 이해하기 쉬운 그림, 스토리로 표현하라
3. 환경
1. 주당 40시간 작업 : 품질의 유지를 위해 일주일에 40시간 이상 일하지 마라
2. 현장 고객 : 실제 시스템을 사용한 고객이 개발 현장에 상주하게 하라
3. 스크럼
1. 스크럼 개요
1. 추정, 조정 기반의 경험적 관리 기법의 대표적인 형태
2. 스크럼 역할자 유형
1. 제품 책임자
1. 제품 기능 목록에 해당하는 제품 백로그를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리
2. 스프린트 계획 수립 시점에는 핵심 역할을 담당, 스프린트 시작 후에는 가능한 팀의 운영에 관여하지 않는 것을 권장
2. 스크럼 마스터
1. 팀의 업무를 방해하는 요소 제거에 노력
2. 원칙과 가치를 지키면서 팀이 개발을 진행할 수 있도록 지원
3. 스크럼 팀
1. 일반적으로 5 ~ 9명으로 구성된다.
2. 사용자 스토리를 사용하여 한 스프린트 동안에 개발할 기능을 도출한다.
2. 스크럼 프로세스
1. 스크럼 프로세스의 구성
1. 스프린트 : 1~4주 단위의 반복 개발 기간을 가리킨다.
2. 3가지 미팅
1. 스프린트 계획
1. 각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행할 항목을 선택
2. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립
2. 일일 스크럼
1. 매일 진행하는 15분간의 프로젝트 진행 상황을 공유하는 회의
3. 스프린트 리뷰
1. 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의
2. 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다.
3. 3가지 산출물
1. 제품 백로그
1. 제품에 담고자 하는 기능의 우선 순위를 정리한 목록
2. 고객을 대표하여 제품 책임자가 주로 우선 순위를 결정한다.
3. 제품 백로그에 정의된 기능을 사용자 스토리라고 한다.
2. 스프린트 백로그
1. 하나의 스프린트 동안 개발할 목록
2. 사용자 스토리, 이를 완료하기 위한 작업을 태스크로 정의
3. 각각의 태스크의 크기는 시간 단위로 추정한다.
3. 소멸 차트
1. 개발을 완료하기까지 남은 작업량을 보여주는 그래프
2. 각 이터레이션 별로 남아있는 작업량을 스토리포인트로 나타낸 것
3. 스크럼 특징
1. 투명성
1. 스크럼 회의, 소멸 차트, 스프린트 리뷰와 같은 기법을 이용해서 프로젝트의 상태, 문제점을 효과적으로 파악할 수 있다.
2. 타임박싱
1. 스크럼을 진행하는 데 들어가는 시간을 제한함으로써 프로젝트 진행에만 집중하는 것이 가능해 진다.
3. 커뮤니케이션
1. 스크럼에서는 팀원 간 커뮤니케이션을 원활하게 하기 위해 많은 노력을 기울인다.
4. 경험주의 모델
1. 프로젝트에 참여하고 있는 개개인의 경험을 중요시 한다.