애자일 방법론 (feat. 개발 경험)

애자일 방법론

Agile 의 사전적 의미는 민첩한, 재빠른, 좋은 것을 빠르고 낭비없게 만드는 것 이다.
즉, 애자일 방법론은 변화하는 요구사항에 맞게 민첩하고 재빠르게 대응하여 소프트웨어 개발을 하기 위한 방법론이다.
(애자일의 핵심 용기,자신감,잦은 소통,짧은 회의 등에 맞게 개발과 함께 즉시 피드백을 받아 유동적으로 개발하는 방법론)

하나의 개발 모델이라기보단 여러가지의 개발 방법론 전체를 가리키며
대표적으로 스크럼, 칸반, XP, TDD, BDD 등이 있다.

애자일 방법론의 등장

이전의 형식적인 단계, 절차(문서)에 의존하는(ex.폭포수 모델)의 취약점을 보안하고,
아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾아
요구사항에 유연하고 효율적인 방식으로 업무(개발)을 지향하려는 목적으로 탄생하였다.
(* 효율적인 개발? : 요구사항을 분석하여 우선순위가 높은 요구사항을 먼저 개발 등 )

애자일 프로세스 적용/도입은?

애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며 상대적으로 비용도 적기 때문에
목표 달성을 위한 프로세스를 지니고 있지 않을 때  개발 및 개선을 위한 좋은 방법이 될 수 있다.

스크럼(Scrum)

스크럼은 스프린트를 기반으로 애자일 방법론을 실행한다.
반복적인 개발 주기인 스프린트(Sprint)로 나누어 개발을 진행하고 스프린트 회고 등을 통해 요구조건의 변화를 즉각 반영하며 지속적으로 프로토타입을 개선해나아가는 방식이다.
(*스프린트: 최소 개발 단위로 1~4주 기간을 상황과 조직에 맞게 선정하고 개선해 나아간다.)

스크럼은 팀 단위의 개발 프로젝트에 있어 보다 효율적으로 업무에 집중할 수 있도록 하는 것을 지향한다.
스크럼 팀은 문제 해결을 위한 최적의 방법을 스스로 찾아가는 자기조직화(self-organization)을 특징으로 하여, 팀의 집중력 생산성을 유지시키고 소통을 통해 점진적으로 소프트웨어를 산출해 나아가기 때문에 팀 중심적이고(결속력), 관리적 체계가 갖춰져있다.

스크럼 프로세스
개발할 제품에 대한 요구사항 목록(Product Backlog)의 우선순위, 스프린트 목표에 맞게 나열한 작업 목록(Sprint Backlog)을 우선순위에 따라 작업을 수행한다.
개발 주기(Sprint)동안 개발을 진행하고나면 리뷰(Daily Scrum), 회고(Sprint Review) 등을 통해 개선할 점, 요구조건의 변화 등을 반영하고(개선) 다음 스프린트를 진행한다.

칸반(Kanban)

칸반은 Work In Process(WIP) 제한하여 애자일 방법론을 실행한다.
칸반은 Agile 개발 프로세스 전반에 걸친 적시개발(Just In Time)을 지원하는 방법론으로
Kanban 보드를 통하여 Workflow 를 가시화하고,
진행 중인 작업(WIP)이 동시에 진행될 수 있는 아이템의 수를 제한하여 Workflow 상의 적정한 프로세스를 관리한다.
(*JIM: 필요한 것을, 필요한 때에, 필요한 만큼만 생산하여 생산시간을 단축하고 낭비를 방지하는 생산 시스템)

스크럼이 스프린트에 이용할 수 있는 작업 시간을 제한함으로써 생산성을 제어한다면,
칸반은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 속도 및 생산성을 제어한다.

칸반 프로세스
칸반 프로세스는 하나의 스토리가 한번의 과정에서 완성된다.(WIP)
한 항목을 완료하는데 걸리는 평균 타임을 측정하고 예측하며 소요시간을 최소화하기 위해 프로세스를 최적화한다.

XP (Extreme Programming)

사용자의 요구사항을 한꺼번에 받는 방식이 아닌, 짧은 개발 주기(Iteration)를 반복하며 요구 변화에 신속하게 대응하는 Agile 방법론이다.
개발 요구사항은 한번에 정의하기에는 변화가 있을 수 있어 현재의 흐름을 제대로 대응하기 어려워 등장하게 되었다.
고객 요구사항 변경에 즉각적이다보니 개발 계획이 프로젝트 진행동안 계속 변화되고, 짧은 개발주기를 통해, 프로토타입이 자주 만들어진다. 때문에 잦은 요구사항 변경, 빠른 시장 대응, 유연한 대처 에 적합하다.
(*XP의 핵심가치: 용기, 의사소통, 피드백, 단순성)

스크럼과 비교해보자면 둘다 짧은 개발주기로 반복 개발하지만
스크럼은 개발 우선순위를 Team 이 결정한다면(조직적) XP는 Customer 에 맞춘다고 볼 수 있다.

XP 프로세스
사용자 요구사항(User Story, Test Scenario)로 릴리즈 일정을 수립하고(Relase Planning) 개발 주기(Iteration)(1~2주) 동안 개발을 진행한다.
Iteration 이 시작되면 인수 테스트를 작성하고, 주어진 스토리가 인수 테스트를 모두 통과하면 작은 릴리즈(Small Relase)를 실시한다.
만약 스토리가 업데이트되면 릴리즈 일정을 다시 수립하며 릴리즈계획-개발주기-인수테스트 를 동시에 왔다갔다 진행한다.

TDD(Test-driven Development)

TDD는 테스트 주도 개발 방법론으로 테스트로 이끌어가는 개발 환경, 작업이다.
구현, 테스트(단위 테스트 형식), 설계(리팩터링 형식)의 활동들이 밀접하게 연계되는 방식이다.
선 테스트 코드 작성, 후 구현 과정으로 이루어진다.

TDD를 사용하면 테스트를 충족하기에 충분한 코드만 작성하게 되고, 안정성과 유지보수성,확장성을 갖춘 개발이 가능하다.
테스트를 통해 결함을 조기에 포착하여 비용 낭비를 방지하고, 생산성을 향상시킨다.

TDD 프로세스
요구사항을 검증하는 테스트 케이스를 작성하고, 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다.
이후 작성한 코드를 리팩터링한다.

BDD(Behavior-driven Development)

BDD는 비즈니스 중심의 행위 주도 개발 방법론 으로 시나리오를 기반으로 테스트하는 패턴(Given,When,Then)을 권장한다.
비지니스 중심이기 때문에 비즈니스에서 요구하는 가치에 맞게 '작은 단위(시스템이 어떻게)'보다는 < '특정 기능(시스템이 무엇을)' 을 제공 하는데 초점을 둔다. 또한 테스트를 사용자 스토리의 일부로 만들어 비개발자들이 테스트를 쉽게 이해할 수 있게 작성한다.

TDD에 기반을 두고 있으나, TDD의 테스트 코드 목적은 기능 동작의 구현 및 검증으로 모듈의 기능이 중심이라면
BDD는 서비스 유저 시나리오 동작의 검증으로 서비스 사용자 행위 중심이다.

+ 애자일 선언

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응을 가치 있게 여긴다.

+ 폭포수 모형

폭포수 모형은 구성 요소에 상관없이 각각의 단계를 통해 계획에 따라 진행되는 방법론이다.
때문에 제품 테스트는 모든 개발이 완료된 후에 이루어지고, 중간의 변화에 대처하기 힘들다는 단점이 있다.
(이런 이슈들이 처리되지 않은 채로 엉키게 되면 코드 품질은 떨어지고 요구사항은 모두 충족되지 않은 상태의 결과물이 만들어지게 된다.)
때문에 이 방식의 한계를 극복하기 위해 애자일 방법론이 고려되었다.

✨ 애자일 개발 프로세스 경험 회고

애자일 프로세스를 따르며 진행했던 개발 경험에 대하여 회고해보고자 한다.

애자일 방법론을 도입해 이슈를 관리하고 팀원들과 효율적으로 협업하며 개발방법론적 사고를 향상시킬 수 있었다.

• Git&GitHub의 ISSUE, Projects를 활용하여 칸반 프로세스를 진행하며 프로젝트의 Workflow 를 관리할 수 있었다.

• 팀원들과 데일리 회고(미팅), 위클리 스크럼을 진행하며 스프린트에 맞게 프로토타입을 구현 및 개선해 나아가며 스크럼 프로세스를 따르고자 하였다.

• 기능을 구현할 때는 학습 테스트, 단위 테스트 등을 진행하며 TDD 에 맞게 개발을 진행하였다.

• 기능에 대한 요구사항은 인수테스트를 통해 명시하며 BDD 에 기반을 두고 개발을 진행하였다.

애자일하게 작업한다?

애자일은 쉽게 말하면 '요구사항에 맞게 유연하게 일하는 ' 프로세스를 지니고 작업을 하는 것이다.
때문에 개발적인 측면에서만 생각하는 것이 아니라 모든 직무,측면에서 애자일하게 일하는 방법들을 적용할 수 있다.

위에서는 개발 경험/직무에 한정하여 회고하였지만,
다른 직무나 협업을 진행할 때에도 스크럼,칸반 등을 통해 사용자의 요구사항을 지키고 생산성을 높이며 애자일하게 프로젝트 작업을 수행할 수 있다.

[참조]
https://hanseul-lee.github.io/2020/11/29/20-11-29-Agile/
https://kood-dev.tistory.com/2 / 애자일
https://needjarvis.tistory.com/193 /칸반
https://gusdnd852.tistory.com/300
https://needjarvis.tistory.com/318 /XP
https://blog.metafor.kr/159 /TDD,BDD
https://www.itworld.co.kr/news/109011 /전체
https://velog.io/@dell_mond/%EC%95%A0%EC%9E%90%EC%9D%BC%EC%9D%84-%EB%8C%80%EC%B6%A9-%EC%95%8C%EA%B3%A0-%EC%9E%88%EB%8A%94-%EB%8B%B9%EC%8B%A0%EC%9D%84-%EC%9C%84%ED%95%98%EC%97%AC /img
멘토님의 조언