Agile Methodology

서동현·2023년 1월 4일

What is Agile Methodology?

신속하고 변화에 유연한(Adaptive) 소프트웨어 개발을 목표로 하는 다양한 경량개발 방법론 전체를 일컫는 총징
Ailge Methodology들은 Iteration으로 불리는 단기 단위를 채택하여 Risk를 최소화한다.

SCRUM
Backlog, Sprint, Teamwork를 강조하여 프로젝트가 어떻게 조직되고 실행되어야하는지에 중점을 둔다.
XP
개발관점에서 가장 주목받는 방법론이다. 의사소통개선, 즉각적인 피드백을 단순하게 반영하여 SW품질을 높이는 것이 목적이다.
TDD
Test Driven Development
Test Case를 먼저 개발하여 Test Case를 통과하는 간단한 실제코드를 나중에 개발하는 방법이다.
Kanban
Just In Time Development를 지원하는 방법론
Lean
LEAN Software development
낭비제거를 키워드로 개발조직 전반에 걸친 실천과정에 관한 방법론이다.

Agile 방법론 특징

1) 가변적 요구 대응 : Predictive보다 Adaptive에 중점을 두어 고객의 니즈를 빠르게 반영한다.
2) 위험 완화 : 단기 Iteration을 통해 개발 초기부터 고객을 상대로 Demo를 함으로써 Snowball Effect를 최소화한다.
3) 고객 만족 : 실행되는 SW를 고객에게 자주 전달하여 고객의 적극적인 참여를 이끌어 냄으로써 개발 후반부라도 요구사항의 변화를 적극 반영한다.
4) 개발자 동기부여 : 개발자가 책임을 완수할 것을 신뢰하고, 개발자에게 적합한 개발환경을 구성한다.
5) PM 역할변화 : 프로젝트 계획 수립 및 통제 책임이 팀원에게 이양됨으로써 프로젝트 관리자에서 촉진자로 역할이 변경된다.
6) Sweet Spots : Key User가 상주하는 한 작업실에 5~8명의 작업자가 상주하여 개발자와 사용자 간의 신속한 피드백이 가능하다.

Why Agile Methodolgy?

정보시스템에 대한 사용자의 요구가 다양해지고 정보시스템의 수명주기가 짧아지면서
정보시스템의 적시성(time-to-market)과 Product의 적시배포의 중요성이 강조되는
SW 개발환경으로 변하였다.
변화된 환경에서 기존의 문서위주, 절차중심, 관리자 중심의 기계적 방법론은
훌륭한 아이디어나 개선안이 프로젝트 후반기에 발견되었을 때 대응이 어렵고, 리스크를 초반에 발견하기 어려워
변화에 빠르게 대응할 수 없고 효율적인 시스템이 개발되기 어려운 문제를 가지고 있었다.

Bigbang Waterfall model로 대표되는 기존 SW 개발 방법론은 예측가능한 프로세스를 위해서 성공가능성이 낮은 시도에 높은 리스크를 부담하는 구조였기 때문에
리스크를 줄이기 위하여 반복적인 프로세스를 통해 Adaptive한 SW개발을 완성하자는 Agile 방법론이 대두되었다.

햄 장사를 하자는 닭과 돼지의 이야기로 비유되는 기존 SW개발과정에서 관리자와 개발자간의 관계를 개선하고자 Agile Menifesto가 선언되었다.

Agile Menifesto

1) 프로세스와 도구보다 상호 소통이 더 중요하다.
2) 포괄적인 문서화보다 제대로 동작하는 소프트웨어가 더 중요하다.
3) 계약협상보다 고객과의 협력이 더 중요하다.
4) 세워진 계획을 따르기 보다 변화에 대응하는 것이 더 중요하다.

Why occured schedule delay?

1) Student Syndrome : 시험이 코앞에 닥쳐야 열심히 공부하는 경향
2) Parkinson's Syndrome : 빨리 끝낼 수 있지만 주어진 기간을 모두 사용하여 일을 마치는 경향
3) Self-Defending : 다른 작업이 추가될 것을 우려해 작업이 일찍 완료된 사실을 숨기는 경향
4) Insufficient Preparation for following-up process work : 일찍 작업이 완료되어도 그 다음 작업이 준비되지 않아 프로세스가 진행되지 못하는 현상

보통 개발 프로세스는 위와 같은 원인으로 지연되기 때문에
일정지연을 방지할 수있는 Agile Methology에 주목한다.

1. SCRUM

Scrum은 럭비선수들이 떼를 지어 엎드려, 공을 조금씩 상대 진영으로 옮기는 형태를 의미한다.
Agile Methology로서 Scrum은 Scrum team을 통해 Product Backlog(계획)을 바탕으로 기술적으로 분할되고 재해석된 단기 Sprint를 실행하여 프로젝트를 완성해가는 방법론을 의미한다.

*출처 : https://www.pm-partners.com.au/the-agile-journey-a-scrum-overview/

1) Project Backlog
요구사항의 우선순위, 기능, 특성, 기술에 대한 모든 사항을 나열한 것으로 프로젝트 진행과정에서 변경되는 것이 default인 것이 특징이다.
2) Sprint Planning
Project Backlog를 기반으로 Sprint 기간에 수행되어야할 Task의 목록을 선택한다.
3) Planning Poker
선택한 Task의 수행기간을 여러 엔지니어들의 수평적 의견교환으로 예측한다.
숙련된 관리자가 일방적으로 정하는 것과 다르게 시간이 적힌 poker card를 이용해 수평적 의견교환이 가능한 것이 특징이다.
4) Sprint
종료시 새로운 기능이 추가되어 실행가능한 제품을 배포하는 것을 목표로하는 3~4주 또는 4~6주 정도의 Timebox 성격을 가진 개발주기를 의미한다.
5) Daily Meeting
15분 정도의 짧은 Standing Meeting으로 어제한 일, 오늘할 일, 위험요소 등 Issue를 체크한다.

Scrum role
(1) Product Owner : Product Backlog를 작성 및 관리하고 product에 잘 반영되었는지 확인하는 역할을 수행한다.
(2) Scrum master : 업무지시보다 업무 조정 및 상담을 하며 팀원들을 대표하는 수평적 역할로, 팀원들을 코칭하고 문제를 해결한다.
(3) Team : 책임감 있는 프로젝트 개발 실무자로 Product Backlog에 따라 Sprint 기간 내에 Product를 개발한다.
5) Kanban Board
6) Burn Down Chart
7) Review Sprint
8) Update Project Backlog
9) Retrospective

*출처 : https://www.pinterest.co.kr/pin/sprint-review-diagram--771452611177352934/