1. Agile 방법론의 배경
소프트웨어의 빠른 배포 VS 소프트웨어의 퀄리티는 상충되지만 모두 중요한 문제였다. 기존에는 폭포수 모델과 Plan-driven 방식이 주류였기에 세부적인 문서화가 필요한 방식이었지만, 문서화와 디자인에 초점을 맞추지 말고 소프트웨어 자체에 초점을 맞추자는 발상과 빠른 소프트웨어 개발에 대한 필요성으로 agile 방법론이 대두되었다.
2. Plan-driven 방식과 Agile 방식의 차이
1) Plan-driven 방식
- 모든 프로세스 activity가 사전에 계획되고, 안전이 중요한 시스템에 활용된다.
- 프로세스 activity '내부'에서 반복이 일어난다.
- 프로세스 단계 간 커뮤니케이션에 formal document들이 사용되었다.
2) Agile 방식
- Planning은 서서히 증가하며 개발 과정 전반적으로 계속되는 과정이다.
- 비즈니스 시스템처럼 빠른 변화가 필요한 경우에 이용
- 프로세스 activity '간에' 반복이 일어난다.
- 요구사항과 디자인/개발이 함께 개발된다.
- 디테일한 계획이나 세부적인 문서들, 명세서가 모두 간소화되었다.
- 시스템은 여러 버전의 시리즈로 개발된다.
- 자동화된 테스팅 툴, 자동화된 사용자 인터페이스 개발 툴 등 여러 툴들이 사용된다.(기존 plan-driven 방식에서도 이러한 자동화된 툴이 이용되긴 함)
3. Agile 방식의 원칙
1) Customer Involvement
고객들이 소프트웨어 개발 전반에 참여한다.
2) Incremental Delivery
소프트웨어는 주요 기능부터 차근차근 증가하며 제공된다.
3) Embrace Change
변화될 것을 전제하고, 변화를 수용한다.
4) Maintain Simplicity
소프트웨어의 복잡성을 제거하고 단순하게 만든다(코드 리팩토링 등)
5) 프로세스보다는 사람 (관행 x)
4. Extreme Programming (XP)
- Agile 방식의 대표적 방법론으로서, 전체적인 개발 주기를 극단적으로 매우 많이 반복하는 것.
- 하루 안에 유저 스토리를 선택하고, task별로 나누고, 플랜을 만들고, 개발하고, 릴리즈하고, 평가하는 과정
1) Collective Ownership : 모두가 함께 구현
2) Continuous Integration (CI) : 기능을 하나씩 추가하여 통합
3) Incremental Planning
4) On-site Customer : 고객의 역할이 중요하며, 팀의 멤버로서 활동
5) Pair Programming
6) Refactoring
7) Simple Design : 현재의 요구사항만 만족하는 단순한 디자인
8) Small Releases
9) Sustainable Pace
10) Test-first Development
5. Agile 방법론의 4가지 요소
1) User Story
- 시스템 유저의 경험을 작성한 시나리오
- 유저 스토리를 task로 쪼갠 이후, 각 task 별 필요한 자원과 노력을 측정한다. 그리고 구현의 우선순위를 정한다.
- 스토리를 잘 이해할 수 있다는 장점이 있지만, 이야기만으로 개발하기에 내용이 불충분한 경우가 많다.
2) Test-first Development
- 테스트 케이스를 먼저 만드는 방법론
- 어떠한 경우 테스트가 incremental 하게 만들어지기 어렵다.
3) Pair Programming
- 프로그래머가 짝을 지어 개발하는 방법
- 서로 오너십을 가지고 할 수 있고, 리팩토링을 독려하며 프로그램 코드 리뷰가 가능하다.
6. Agile Project Management : Scrum
1) Motivation
- agile 방법론은 계획의 비중이 적기 때문에 항상 비즈니스의 진행사항을 체크해야 하는 요구사항과 충돌이 있었다. 따라서 진행사항을 체크하고 관리하기 위한 방법론으로서 'scrum'이 대두되었다.
- scrum은 agile project를 관리하고, 현재 어떠한 것이 진행되고 있는지 가시성을 제공하는 프레임워크라고 할 수 있다. 기존의 전통적 방법론에서 쓰이지 않던 새로운 용어들이 사용된다.
2) Terminology
(1) Development Team : 7명 미만의 소규모 그룹
(2) Sprint : 개발주기 (2-4주)
(3) Scrum : 진행사항을 리뷰하고 우선순위를 정하는 데일리 미팅
(4) Scrum master (= Project Manager) : 전체적으로 팀을 가이드하고 프로세스를 확인하는 역할
(5) Product Backlog : 투두리스트
(6) Product Owner : 고객, 프로덕트 매니저 등 프로덕트의 피처나 요구사항을 확인하는 것. 중요한 비즈니스 니즈를 충족시키고 있는지 프로덕트 백로그를 리뷰
(7) Velocity : 한 스프린트에 한 팀에 의해 백로그가 얼마나 달성될 수 있는지
3) Sprint Cycle(Scrum Process)
- 스프린트는 절대 연장되지 않으며, 끝내지 못한 작업들은 프로덕트 백로그에 들어가게 된다.
4) Scrum의 장점
- 프로덕트들은 관리가능하고 이해가능한 덩어리로 나눠지게 된다.
- 전체적 팀이 모든 visibility를 가지게 된다.(커뮤니케이션 향상에 도움)
- 고객들은 현재 진행상황을 보고 피드백을 줄 수 있으며, 고객과 개발자 사이의 신뢰가 형성된다.
7. Scaling Agile Methods
1) Problems
- agile 방법론은 작거나 중간 크기의 소프트웨어 개발에 최적화된 방법론이다.
- 큰 규모의 경우 문서없이 개발하는 것은 계약상의 문제도 있다.
- agile 방법론은 SW 유지 보수에 특화되어 있지 않고, 새로운 SW 개발에 적합한 방법론이다.
- 모두가 직접 대면하여 미팅하는 방식이기 때문에 세계 여러 곳에 분산된 팀들과의 협업 방식에서는 적합하지 않다.
- 공식적 문서들이 없기 때문에 유지 보수하기 어려움이 있다.
- 개발팀이 사라지거나 새로운 멤버가 오게 되면, 새로운 담당자들에게 Follow-up을 할 문서가 없으므로 knowledge를 전달하는 데 한계가 있다.
- 새 sw 개발 방식에서 고객을 involve 시키는 것은 가능했지만 유지보수 관점에서 매번 customer를 invovle 시키기 쉽지 않다.
2) 더 큰 시스템은 어떠한 특징을 갖고 있는가
(1) Systems of systems
서로 분리된 팀들이 각각 다른 장소에서 다른 시간대에 일을 한다. 각각의 팀이 모두 동일한 view를 보는것은 어렵다.
(2) Brownfield Development
기존의 시스템에 코드를 더하고, 작은 sw를 큰 sw에 통합하는 경우가 많다.
(3) System Configuration
개발을 함에 있어 system configuration을 고려해야한다.
(4) Reuglatory Constraints
법적 이슈와 라이센스 등을 고려하며 sw를 개발해야 한다.
(5) Prolonged Procurement
팀이 계속 유지되기 어려우므로 follow up을 위한 문서가 필요하다
(6) Diverse Stakeholders
이해관계자가 많기 때문에 모든 요구사항을 들어주기 어려워서 일정 부분 타협이 필요하다.
3) Large Scale을 위한 Agile 방법론
(1) 완전한 incremental 접근은 불가능하다.
(2) single product owner나 customer representative는 존재하지 못한다.
(3) 오롯이 코드에만 집중하는 것이 어렵고 문서가 필요하다.
(4) 팀 간의 커뮤니케이션 메커니즘이 필요하다.
(5) Continuous Integration은 비용이 크기 때문에 매번 CI를 진행하기 어렵다.
4) Multi-team Scrum
(1) Role Replication
각 팀마다 Product Owner와 Scrum Master가 존재한다.
(2) Product Architects
각 팀은 product architect를 선택하고, 그것이 전체적 시스템 아키텍쳐와 잘 어우러지도록 해야한다.
(3) Release Allignment
프로덕트 릴리즈 일정 종류이 필요하다
(4) Scrum of Scrums
각 팀의 대표들이 만나 진행상황을 토론하고 공유하는 Scrum of Scrum이 있다.
