애자일(Agile) 방법론과 TDD & Scrum

[ 애자일(Agile) 방법론 ]

https://velog.io/@iamminzzy/애자일Agile-방법론-이란-BDD부터-TDD까지

 

소프트웨어 개발 방식의 하나로, 작업 계획을 짧은 단위로 세우고 제품을 만들고 고쳐 나가는 사이클을 반복함으로써 고객의 요구 변화에 유연하고 신속하게 대응하는 개발 방법론

쉽게 말하면, 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더하고 수정해나가는 탄력적인 방법론

Agile는 기민한, 날렵한이라는 뜻으로 좋은 것을 빠르게 취하고 유연하고 효율적으로 개발할 수 있도록 만드는 다양한 방법론을 통칭해 일컫는 말임

애자일 프레임 워크

애자일 방법론을 따르는 개발 기법

ex) Scrum, kanban, XP(eXtreme Programming) 등등

애자일은 어떠한 규정이나 툴이 아니며 개발 업무는 어떤 방식으로 진행되는 것이 좋은지에 대한, 협업과 워크플로우를 바라보는 관점, 가치체계, 문화라고 보는 것이 더 가까움

즉, 위의 프레임워크들이 지향하는 것을 통칭하는 상위 개념이 애자일이라고 할 수 있음

 

애자일(Agile)이 나오된 이유

기존에는 워터폴 방법론이 있었는데 워터폴 방식의 한계가 드러남으로써 그에 대한 대한으로 생겨난 것이 애자일 방법론

 

워터폴(Waterfall) 방법론

https://www.codestates.com/blog/content/애자일방법론-워터폴방법론

워터폴 방법론은 폭포수 방법론이라고도 불리며 각 작업이 폭포처럼 위에서 아래로 떨어지는 단계별 개발 방법론
요구사항 정의(설계) → 디자인 → 개발 → 테스트 → 배포의 과정이 순차적으로 진행되며 이전 단계가 그다음 단계로 떨어지게 지게됨

즉, 순차적인 진행, 명확한 요구 분석이 중요시 되는 것
애자일 방법론이 등장하기 전까지는 소프트웨어 개발 뿐 아니라 자동차, 선박 등 산업 현장에서 보편적으로 사용되던 프레임워크임

 

워터폴 방법론 프로세스

1. 요구사항 정의(설계)
   • 프로세스의 가장 첫 단계로 고객의 문제를 정의하고 요구사항을 문서화하여 정리하는 단계
   • 어떤 작업이 필요한지, 필요한 리소스는 무엇인지, 우선순위는 무엇인지 등을 계획하는 단계
   • 요구사항이 명확해야 프로젝트를 시작하고 무사히 완성될 수 있기 때문에 요구사항을 분석하고 문서를 정리하는 데 많은 시간과 노력이 소요됨
2. 디자인
   • 앞에서 정리한 요구사항을 충족할 수 있는 제품을 설계하는 단계
3. 개발
   • 앞의 디자인 단계에서 설계한 내용에 따라 본격적으로 제품을 구현하고 만드는 단계
4. 테스트
   • 만들어진 제품 기능이 제대로 작동하는지 테스트하는 단계
   • 배포가 되기 전에 문제가 될 만한 버그, 오류를 찾아 수정함
5. 배포
   • 최종적으로 결과물이 출시가 되고 사용자에게 소프트웨어가 배포되는 단계

 

워터폴 방법론 장단점

• 장점
  • 단계별로 업무를 분담하기 때문에 맡은 바가 명확함
  • 계획 단계의 문서화로 단계마다 소요되는 시간이나 현재 상황을 추적하고 병목을 파악하기 쉬움
• 단점
  • 속도가 느리고 유연하지 못함
    • 아래에선 위에서 물이 떨어질 때까지 마냥 기다리고 있어야 한다거나, 떨어진 요구사항대로 기능을 만들었으나 수 개월이 지난 시점에서는 시장 상황이 변해 더 이상 고객이 그 기능을 필요로 하지 않은 경우도 발생할 수 있음
    • 결론적으로 지나치게 계획과 절차에 의존해 시간과 비용의 낭비가 증가한다는 것

 

워터폴 방법론의 한계와 애자일 방법론의 등장

90년대 이후, 워터폴 방식은 한계가 드러나기 시작함 인터넷 기술이 발달하고 개인 PC 보급이 늘어나면서 고객의 요구는 빠르게 변했지만 소프트웨어 개발은 이러한 요구사항에 민첩하게 대처하지 못했음 워터폴 방법론은 속도, 변화에 취약했고 문제가 발생했을 때 전 단계로 되돌리기 어려움 변경 사항이 생길 경우, 처음 계획 단계부터 다시 시작해야 했음.

 

이런 경직된 워터폴 방법론에 대한 대안으로 생겨난 것이 바로 애자일 방법론인 것

 

2001년, 경험 많은 소프트웨어 개발자들은 본인들이 기존의 워터폴 방법론이 아닌 새로운 프로세스로 개발하고 있다는 사실을 인식했고 애자일 선언문 (Manifesto for Agile Software Development)을 발표함

이것이 애자일 방법론의 시작이라고 할 수 있음

 

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다

이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

 

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

가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것임

 

워터폴 방법론과 애자일 방법론 비교

워터폴은 방식은 주문 → 디자인 → 기능구현 → 테스팅 → 배포
순서대로 흘러가는 방식  긴 계획을 짜고 그 안에서 순서대로 체계적으로 진행되는 전통적인 방식

애자일 방식은  (주문 → 디자인 → 기능구현 → 테스팅 → 배포) x ∞
대신, 기능을 축소하고 그 주기를 짧게하여 빠르게 한 주기가 돌게 한 후 중간 테스트(피드백)를 많이 가지는 방식그 짧은 한 주기 = 스프린트(Sprint) 라고 함

이는 짧고 반복적인 과정으로 빠르고 유연하며 수정도 쉽다는 장점이 있음
과거와는 비교조차 하기 어려울 정도로 시장과 고객 등 변화가 빨라지고 한치 앞을 예상하기 어려운 환경 때문에, 최근에는 거의 모든 IT업계에서는 애자일 방식을 선호하고 있음

 

	애자일(Agile)	워터폴(Water fall)
장점	개발과정이 빠르게 유연	팀 규모에 상관없이 따르기가 쉬움
	짧고 반복적인 스프린트로 구성 → 빠르게 결함 식별 및 수정기능	개발주기가 정해져 있기 때문에 새로운 프로젝트를 안정적으로 시작 가능
	소규모 팀들이 여러 과제를 각각 할당받아 처리 가능	요구사항이 정의되어 있기 때문에 실행하기가 수월하며 목표를 자주 변경하지 않아도 됨
	개발과정중에 신속하게 제품 변경 가능 (짧은 반복과정 거치기 때문)	필요한 예산과 자원이 초기에 확정되기 때문에 예상결과와 리스크를 통제하기 쉬움
단점	빠른 반복 작업에 익숙한 숙련된 사람이 필요	개발속도가 느리며 유연성이 떨어짐
	수많은 변경사항이 있을 수 있으므로 번거로움 발생	개발 요구사항이 초기에 정해지기 때문에 변경이 자유롭지 못함
적합한 조직	고품질의 결과물과 지속적 개선에 초점을 맞춘 조직	순차적인 프로젝트 타임라인 사전 확정 예산이 필요한 팀
	크고 복잡한 회사들이 프로세스를 간소화함으로써 변화에 신속대응 하고자 할때 (ex. IBM, AT&T, 마이크로소프트)	개발상의 변경이나 리스크에 덜 민감한 팀
	결과물에 대한 피드백이 필요한 팀	요구사항이 간단한 팀, 타임라인이 긴 프로젝트

[ TDD ]

테스트 주도 개발로 TestDrivenDevelopment 줄여서 TDD라고 함

테스트를 중요시하는 개발 방법론 프로그래밍 전에 테스트 코드를 먼저 작성하는 특징이 있음

작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현함

짧은 개발 주기의 반복에 의존하는 개발 프로세스로 애자일 방법론 중 하나인 eXtream Programming(XP)의 Test-First개념에 기반을 둔 단순한 설계를 중요시 함

 

TDD 프로세스

https://velog.io/@iamminzzy/애자일Agile-방법론-이란-BDD부터-TDD까지

 

• Red = fail test 단계 : 실패하는 테스트 코드를 먼저 작성
• Green = pass test 단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성
• Blue = refactor 단계 : 중복 코드 제거, 일반화 등의 리팩토링 수행

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하는 것 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있음

 

TDD의 장점 & 단점

• 장점
  • 재설계 시간을 단축 : 높은 품질의 소프트웨어를 보장
  • 철저한 기능별 모듈화 : 종속성이 낮은 코드
  • 추가 요구사항 반영이 비교적 쉬움
  • 디버깅 시간의 단축: 에러 및 버그가 적음
• 단점
  • 낮은 생산성 (테스트코드를 추가적으로 개발해야 함)
  • 초기 비용 증가 (초기 세팅 비용이 들고 숙련되기까지 시간이 소요됨)
  • 기한 준수가 중요한 프로젝트에는 도입이 어려움

 

[ 스크럼(Scrum) ]

프로젝트를 진행하는데 있어서 유연성과 적응성을 강조하는 방법론

스크럼은 작은 팀으로 구성되어 각 팀원이 적극적으로 참여하여 프로젝트를 진행하는 방식을 취하며 개발 주기를 일정 기간으로 나누어 각 주기마다 일정한 목표를 설정하고 그 목표를 달성하도록 팀원들이 협력하여 일하는 방식을 취함

이러한 방식으로 작업을 진행하면서 문제가 발생하면 팀원들끼리 ‘빠르게 의사소통’하여 ‘문제를 해결’하는 것이 스크럼의 핵심

 

스크럼 개발 모델 특징

• 자율적인 팀 협업
  • 애자일 스크럼은 작은 팀이 자율적으로 협업하고 결정을 내림
  • 팀은 개발을 위한 계획을 수립하고, 작업을 조율하며, 품질을 관리
• 스프린트 개발 주기
  
  • 애자일 스크럼은 짧은 개발 주기인 스프린트(Sprint)를 가지고 개발을 진행
  • 스프린트는 보통 1주에서 4주까지의 기간으로 설정되며, 실행 가능한 소프트웨어를 제공
• 백로그와 우선순위 설정
  • 개발할 기능 목록인 백로그(Backlog)를 작성하고 우선순위를 설정
  • 우선순위에 따라 각 스프린트에서 개발할 기능을 선택하고 진행
• 일일 스크럼 미팅
  • 개발 팀은 매일 짧은 시간 동안 일일 스크럼 미팅을 진행
  • 팀원은 자신의 진행 상황과 어려움을 공유하고, 작업을 조율하여 팀 전체의 진행 상황을 파악
• 스프린트 리뷰와 회고
  • 스프린트가 끝나면 개발된 소프트웨어를 검토하고, 사용자와의 스프린트 리뷰를 진행
  • 이후 팀은 회고를 통해 개선할 점을 도출하고 다음 스프린트에 반영

 

프로젝트 성공을 위한 스크럼 원칙

• 투명성
  
  • 팀으로 일하는 환경에서는 다른 팀원이 겪을 수 있는 문제를 인지할 수 있음
  • 다분야 팀원과 프로젝트 담당자 간의 정기적인 대면 대화를 통해 의사 소통 오류와 정보 병목 현상을 방지
• 반성
  
  • 팀 구성원이 진행 상황을 검토할 수 있도록, 자주 반성하게 되는 점이 프레임워크에 포함됨
  • 프로젝트 관리자는 이러한 리뷰 미팅의 인사이트를 활용하여 추정과 향후 계획을 수립
  • 결과적으로, 프로젝트를 예산 범위 내에서 일정에 따라 보다 효율적으로 실행할 수 있음
• 적응
  
  • 팀원은 변화하는 고객 요구 사항에 따라 작업의 우선 순위를 조정할 수 있음
  • 먼저 완료해야 할 작업과 나중에 보류해 두어야 할 작업을 결정함

 

프로젝트 팀의 스크럼의 가치

스크럼 팀은 5가지 핵심 가치를 따름

• 헌신
  • 스크럼 팀원은 시간이 정해진 작업과 목표에 전념하고 최상의 솔루션을 찾기 위해 지속적인 개선에 전념
• 용기
  • 스크럼 팀은 개방적이고 도전적인 질문을 함으로써 용기를 보여줌
  • 솔직하고 투명한 토론을 통해 최상의 솔루션을 찾음
• 집중
  • 팀원은 주어진 기간 동안 작업의 제품 백로그를 바탕으로 작업을 수행
  • 한정된 시간 내에 결과물을 제공하기 위해 선택한 작업에 집중
• 열린 자세
  • 스크럼 팀원은 개별 학습과 전반적인 프로젝트 품질을 뒷받침하는 새로운 아이디어와 기회를 열린 자세로 수용
• 존중
  • 팀원은 프로젝트 관리자, 다른 팀원, 스크럼 프로세스를 존중
  • 존중의 문화는 팀 내에서 상호 협력과 협업의 정신을 만듬

 

스크럼 프로세스

https://adjh54.tistory.com/147

 

1. 백로그 작성
   • 초기에 백로그를 작성함
   • 백로그는 개발할 기능 목록을 포함하며, 이를 우선순위에 따라 정렬
2. 스프린트 계획 회의
   • 각 스프린트마다 스프린트 계획 회의를 진행
   • 팀은 백로그에서 개발할 기능을 선택하고, 스프린트 목표와 작업 계획을 수립
3. 스프린트 개발
   • 스프린트 개발 기간 동안 팀은 개발 작업을 수행
   • 각 팀원은 담당 작업을 수행하고, 작업의 진행 상황을 공유
4. 일일 스크럼 미팅
   • 매일 동일한 시간과 장소에서 일일 스크럼 미팅을 진행
   • 각 팀원은 자신의 진행 상황과 어려움을 공유하며, 작업의 조율을 수행
5. 스프린트 리뷰
   • 스프린트가 끝나면 개발된 소프트웨어를 사용자와 공유하고 검토
   • 사용자의 피드백을 수용하고 개선할 점을 도출
6. 스프린트 회고
   • 스프린트 회고를 통해 팀은 개발 프로세스를 돌아보고 개선할 점을 도출
     이를 다음 스프린트에 반영하여 개발을 진행

 

스크럼의 장점 & 단점

• 장점
  • 자율적인 팀 협업: 팀의 자율성과 협업을 통해 효율적인 개발
  • 빠른 결과물 제공: 짧은 개발 주기와 스프린트를 통해 빠르게 실행 가능한 소프트웨어를 제공
  • 고객의 참여와 피드백: 고객과의 지속적인 피드백을 수용하여 요구사항을 정확히 파악해 고객 만족도를 높일 수 있 있음
• 단점
  • 적용 범위의 제한: 대규모 프로젝트나 복잡한 프로젝트에는 적합하지 않을 수 있음
  • 자원 관리의 어려움: 팀원의 역량과 업무 분배에 대한 효율적인 관리가 필요

 

더 다양한 애자일 방법론 ▷ "BDD부터 TDD까지" 다양한 애자일 기법의 장단점

 

😉🤔

취업을 위해 다양한 회사의 채용 공고를 살펴보면서 Agile 개발 문화에 대한 이해와 경험이 중요하다는 것을 점점 더 느끼게 되었음. 이에 애자일 방법론이 무엇인지에 대해 깊이 있게 조사해보기로 함. 예전에는 애자일이라는 용어가 기민한, 날렵한이라는 의미로 빠르게 제품을 출시하여 고객의 요구사항에 맞게 요구를 더하고 수정하는것이라고 알고 그 실질적인 의미와 적용 방법은 모호했음

 

애자일이란 규정이나 툴이 아닌, 개발 업무를 어떤 방식으로 진행해야 하는지에 대한 큰 관점에서 바라보는 것이라는 것을 알게 되었음. 협업과 워크플로우를 개선하고 지속적인 개선을 통해 가치를 창출하는 문화를 의미한다는 것을 깨닫게 됨. 이러한 관점에서 다양한 애자일 기법을 학습하고자 TDD와 스크럼에 대해 자세히 조사하고 왜 사용하고 어떻 흐름으로 흘러가는지 기록을 남겨야 겠다고 생각한 것

 

TDD는 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하며 테스트코드에 그치지 않고 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할수 있기에 적용하는 것이라는 것을 알게됨

 

또한 스크럼은 유연성과 적응성을 강조하는 프로젝트 관리 방법으로 작은 팀이 짧은 주기로 작업을 수행하고 결과물을 지속적으로 검토하며 개선하는 것을 중시한다는 것과 스크럼의 핵심이 문제가 발생하면 팀원들끼리 ‘빠르게 의사소통’하여 ‘문제를 해결’이기 때문에 일일 스크럼 및 미팅이 중요하다는 것을 깨달음. 즉, 일일스크럼 및 미팅을 한다는 자체가 중요한다는 것이 아닌 빠르게 의사소통 → 문제해결이 중요한 것이기에 시간이 길어지면 오히려 단점이 되어 스프린트를 개선하는 기회가 아닌 서로 격려하는 세션으로 변질될 수 있음을 명심해야함