🧐Agile이란
애자일은 기민한, 좋은 것을 빠르고 낭비없게 만든다는 뜻이다.
구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다.
‘애자일(Agile)’이란 용어는 소프트웨어 개발 방식의 하나로 통용되던 말이다. 작업 계획을 짧은 단위로 세우고 시제품을 만들어 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고도 신속하게 대응하는 개발 방법론이다. 이와 반대되는 개념이 전통적 개발 방법론이라 할 ‘워터폴(Waterfall) 방식’이다. 우리 기업에 익숙한 이 방식은 장기적 관점에서 계획을 정교하게 세우고 사전에 단계별로 정해놓은 기준을 충족하지 않으면 다음으로 넘어가지 않는 특징이 있다.
변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법으로 문서화보다 코드, 프로그램, 소프트웨어 자체를 중요시 한다.
환경의 빠른 변화에 대응하는 것이 중요하다.
애자일 선언문(Agile Manifesto)
프로세스와 툴보다 개인과 개인간의 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
작동하는 소프트웨어가 포괄적인 문서보다 우선
고객과의 협업이 계약 협상보다 우선
변화에 대응하는 것이 계획을 따르는 것보다 우선
Agile 방법론의 종류
- 익스트림 프로그래밍(Extreme Programming, XP)
- 짝 프로그래밍(Pair Programming)
- 테스트 주도 개발(Test Driven Development, TDD)
- 스크럼(Scrum)
- 익스트림 프로그래밍(Extreme Programming, XP)
- 좋은 실천 지침들(good practices)을 적극적으로 적용
- XP의 실천 지침
- 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선
- 고객도 개발 팀의 일원
- 프로세스 중심이 아닌 사람 중심의 작업
- 짝 프로그래밍(pair programming)
- 단순한 설계와 테스트 주도 개발(Test Driven Development, TDD)
- 리팩토링을 통한 코드 품질 개선
- 짝 프로그래밍(Pair Programming)
- 두 사람이 짝이 되어 한 사람이 코딩을, 다른 사람은 검사를 수행
- 30분마다 역할 교체
- 장점
- 코드에 대한 책임 공유
- 비형식적 검토 수행
- 코드 개선을 위한 리팩토링 장려
- 생산성 - 두 사람이 짝을 이뤄 개발하지만 각각 개발하는 경우에 비해 생산성이 떨어지지 않는다.
- 테스트 주도 개발(Test Driven Development, TDD)
- 테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 개발
- Task 별로 테스트 케이스를 만듦
- 요구사항 ➡️ 스토리 카드 ➡️ Tasks
- 요구사항은 스토리 카드로 표현되고 스토리 카드는 태스크들로 분해됨
- 요구사항 - 코드 관계가 명확해 짐 - 통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류 유입 방지
- scrum
Scrum
scrum이란
스크럼은 복잡한 제품을 개발(배포)하고, 유지하기 위한 프레임워크.
비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발(전달)하는 관리 프레임워크(기법)이다.
Scrum의 주요 역할
- 제품 책임자(Product Owner)
비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토한다. 이해관리자로부터 요구사항을 추출하여 제품 백로그에 반영한다.
- 제품 백로그(요구사항) 관리/설명
- 제품 백로그의 우선순위 관리
- 만족스럽게 개발되었는지 확인
- 스크럼 마스터(ScrumMaster)
일반적인 프로젝트 관리자들과는 다르게 개발 팀원들을 코칭하고 개발팀이 프로젝트 진행중 문제가 생겼을 때 잘 해결할 수 있도록 도와주는 역할을 한다. 개발팀원들이나 스크럼에 참여하는 사람들이 스크럼을 제대로 알고 수행하고 있는지에 대한 책임을 가지며 스크럼의 이론, 규칙들을 잘 따르도록 보장해야한다.
- 팀을 보호하고 장애 요소를 해결
- 일일 스크럼 회의를 진행
- 모니터링 및 Tracking
3.개발 팀 (Developer)
고객으로부터 받은 요구사항을 가지고 제품을 개발, 테스트하는 팀으로 주로 5~7명으로 이루어진다. 개발팀에는 따로 리더가 정해져 있지 않으며, 팀원들이 자기 조직화(self-organization)되어 있어 외부의 명령 없이 스스로 스프린트 목표를 달성하기 위해 최상의 방법을 결정한다.
Scrum 주요 용어
제품 백로그(Product Backlog)
개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리
사용자 스토리(User Story)
과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명
예를 들면,
완료 기준(Definition of Done), 인수 기준(Acceptance Criteria)
사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)
스프린트(Sprint)
계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택
잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP)
팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품
스프린트 계획 회의(Sprint Planning Meeting)
스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)
스프린트 백로그(Sprint Backlog)
각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
칸반 보드(Kanban Board) : 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판
일일 스크럼 회의(Daily Scrum Meeting)
매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도 수행)
스프린트 리뷰(Sprint Review)
스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)
스프린트 회고(Sprint Restospective)
스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)
스크럼 진행 순서
1.PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
2.PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
3.스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
(해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.)
4.스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5.매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
6.제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다.
(해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
7.다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.
