애자일(Agile) 방법론 정리

애자일(Agile)

 

소프트웨어 개발 기법으로 많이 들어본 단어다. 특히 소프트웨어 공학 수업을 들을 때 분명 배웠다. (근데 기억이 안남..)

폭포수 모델, 애자일 기법 등등.. 무엇인지 알아보자

등장배경

초기 소프트웨어 개발 방법은 계획 중심의 프로세스였다.

 

마치 도시 계획으로 건축에서 사용하는 방법과 유사하며, 당시에는 이런 프로세스를 활용하는 프로젝트가 대부분이었다.

하지만 지금은?

90년대 이후, 소프트웨어 분야가 넓어지면서 소프트웨어 사용자들이 '일반 대중들'로 바뀌지 시작했다. 이제 모든 사람들이 소프트웨어 사용자들의 대상으로 되면서 트렌드가 급격하게 빨리 변화하는 시대가 도달했다.

 

이로써 비즈니스 사이클(제품 수명)이 짧아졌고, SW 개발의 불확실성이 높아지게 되었다.

새로운 개발 방법 등장

개발의 불확실성이 높아지면서, 옛날의 전통적 개발 방법 적용이 어려워졌고 사람들은 새로운 자신만의 SW 개발 방법을 구축해 사용하게 된다.

• 창의성이나 혁신은 계획에서 나오는 것이 아니라고 생각했기 때문!

 

그래서 경량 방법론 주의자들은 일단 해보고 고쳐나가자는 방식으로 개발하게 되었다.

규칙을 적게 만들고, 가볍게 대응을 잘하는 방법을 적용하는 것

아주 잘하는 단계에 이르게 되면, 겉으로 보기엔 미리 큰 그림을 만들어 놓고 하는 것처럼 보이게 됨

 

ex)

즉흥연기를 잘하게 되면, 겉에서 봤을 때 사람들이 '저거 대본아니야?'라는 생각을 할 수도 있음

 

이런 경량 방법론 주의자들이 모여 자신들이 사용하는 개발 방법론을 공유하고, 공통점을 추려서 애자일이라는 용어에 의미가 담기게 된 것이다.

애자일이란?

---

**'협력'과 '피드백'**을 더 자주하고, 일찍하고, 잘하는 것!

 

애자일의 핵심은 바로 '협력'과 '피드백'이다.

1. 협력

소프트웨어를 개발한 사람들 안에서의 협력을 말함(직무 역할을 넘어선 협력)

스스로 느낀 좋은 통찰은 협력을 통해 다른 사람에게도 전해줄 수 있음

 

예상치 못한 팀의 기대 효과를 가져옴

 

ex) 좋은 일은 x2가 된다.

 

어떤 사람이 2배의 속도로 개발할 수 있는 방법을 발견함

 

협력이 약하면? → 혼자만 좋은 보상과 칭찬을 받음. 하지만 그 사람 코드와 다른 사람의 코드의 이질감이 생겨서 시스템 문제 발생 가능성

 

협력이 강하면? → 다른 사람과 공유해서 모두 같이 빠르게 개발하고 더 나은 발전점을 찾기에 용이함. 팀 전체 개선이 일어나는 긍정적 효과 발생

 

ex) 안 좋은 일은 /2가 된다.

 

문제가 발생하는 부분을 찾기 쉬워짐

예상치 못한 문제를 협력으로 막을 수 있음

 

실수를 했는데 어딘지 찾기 힘들거나, 개선점이 생각나지 않을 때 서로 다른 사람들과 협력하면 새로운 방안이 탄생할 수도 있음

2. 피드백

학습의 가장 큰 전제조건이 '피드백'. 내가 어떻게 했는지 확인하면서 학습을 진행해야 함

 

소프트웨어의 불확실성이 높을 수록 학습의 중요도는 올라간다. (모르는 게 많으면 더 빨리 배워나가야 하기 때문!!)

 

일을 잘하는 사람은 이처럼 피드백을 찾는 능력 뛰어남. 더 많은 사람들에게 피드백을 구하고 발전시켜 나간다.

피드백 진행 방법

내부적으로는 내가 만든 것이 어떻게 됐는지 확인하고, 외부적으로는 내가 만든 것을 고객이나 다른 부서가 사용해보고 나온 산출물을 통해 또 다른 것을 배워나가는 것!

불확실성

애자일에서는 소프트웨어 개발의 불확실성이 중요함

불확실성이 높으면, 우리가 생각한거랑 다르다..라는 상황에 직면한다.

이때 전통적인 방법론과 애자일의 방법론의 차이는 아래와 같다.

 

전통적 방법론 : '그때 계획 세울 때 좀 더 잘 세워둘껄..

이런 리스크도 생각했어야 했는데ㅠ 일단 계속 진행하자'

 

애자일 방법론 : '이건 생각 못했네. 어쩔 수 없지. 다시 빨리 수정해보자'

 

전통적 방법에 속하는 '폭포수 모델'은 요구분석단계에서 한번에 모든 요구사항을 정확하게 전달하는 것이 원칙이다. 하지만 요즘같이 변화가 많은 프로젝트에서는 현실적으로 불가능에 가깝다.

 

이런 한계점을 극복해주는 애자일은, 개발 과정에 있어서 시스템 변경사항을 유연하게 or 기민하게 대응할 수 있도록 방법론을 제공해준다.

진행 방법

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로 한다.
3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
4. 주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
5. 프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로 한다.

 

애자일을 통한 가장 많이 사용하는 개발 방법론이 '스크럼'

럭비 경기에서 사용되던 용어인데, 반칙으로 인해 경기가 중단됐을 때 쓰는 대형을 말함

즉, 소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고, 효율적인 성과를 얻기 위한 것

 

 

1. 제품 기능 목록 작성

   개발할 제품에 대한 요구사항 목록 작성

   우선순위가 매겨진, 사용자의 요구사항 목록이라고 말할 수 있음

    

   
   개발 중에 수정이 가능하기는 하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙

2. 스프린트 Backlog

   스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록

   • 세부적으로 어떤 것을 구현해야 하는지
   • 작업자
   • 예상 작업 시간

   최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능

3. 스프린트

   작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발한다

   한달동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면 이것이 스크럼에서 스프린트에 해당함

   • 주기가 회의를 통해 결정되면 (보통 2주 ~ 4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의 없이 바꿀 수 없는 것이 원칙
4. 일일 스크럼 회의

   몇가지 규칙이 있다.

   모든 팀원이 참석하여 매일하고, 짧게(15분)하고, 진행 상황 점검한다.

   한사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기함

   완료된 세부 작업 항목을 스프린트 현황판에서 업데이트 시킴

5. 제품완성 및 스프린트 검토 회의

   모든 스프린트 주기가 끝나면, 제품 기능 목록에서 작성한 제품이 완성된다.

   최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의 진행

   • 고객의 요구사항에 얼마나 부합했는가?
   • 개선점 및 피드백
6. 스프린트 회고

   스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토

   팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다

스크럼 장점

---

• 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있음
• 회의를 통해 팀원들간 신속한 협조와 조율이 가능
• 자신의 일정을 직접 발표함으로써 업무 집중 환경 조성
• 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이함

스크럼 단점

---

• 추가 작업 시간이 필요함 (스프린트마다 테스트 제품을 만들어야하기 때문)
• 15분이라는 회의 시간을 지키기 힘듬 ( 시간이 초과되면 그만큼 작업 시간이 줄어듬)
• 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약함

요약

---

스크럼 모델은 애자일 개발 방법론 중 하나

회의를 통해 스프린트 개발 주기를 정한 뒤, 이 주기마다 회의 때 정했던 계획들을 구현해나감

하나의 스프린트가 끝날 때마다 검토 회의를 통해, 생산되는 프로토타입으로 사용자들의 피드백을 받으며 더 나은 결과물을 구현해낼 수 있음

애자일(Agile)이란 무엇인가?

이 글의 목표는 Agile을 이해하는 것이다. 아래의 내용을 종합하여, Agile이 무엇인지 한 문장으로 정의할 수 있어야 한다.

---

#0 Software Development Life Cycle (SDLC)

책 한권이 나오기 위해서는 집필 -> 디자인 -> 인쇄 -> 마케팅 의 과정이 필요하다. 소프트웨어 또한 개발 과정이 존재한다. 각 과정 (=단계 = task) 을 정의한 framework가 SDLC이다.

여기서 당신은 반드시 SDLC와 Approach를 구분할 수 있어야 한다. SDLC는 구체적인 방법과 방법론 (개발 과정의 단계와 순서를 명확히 구분) 을 의미하고, Approach는 그런 SDLC를 유사한 개념적 특징에 따라 그룹지은 것을 의미한다.

 

Agile은 Approach이다. Aglie에 속하는 방법론이 Scrum, XP이다.

 

결론 1 : Agile은 SW Development Approach 중의 하나이다.

---

#1 Agile이 될 조건 (Agile Manifesto)

모든 법은 헌법이 수호하는 가치를 위반해서는 안된다. 마찬가지로, Agile 또한 Agile이기 위해 헌법과 같은 4 Value와 12 Principle이 존재한다.

4 Value

• Individuals and interactions over Process and tools (프로세스나 도구보다 개인과 상호 작용)
• Working software over Comprehensive documentation (포괄적인 문서보다 작동 소프트웨어)
• Customer collaboration over Contract negotiation (계약 협상보다 고객과의 협력)
• Responding to change over Following a plan (계획 고수보다 변화에 대응)

4 value 모두, 뛰어넘어야 하는 대상을 명시하고 있다. 비교 대상은 기존의 개발 방법론에서 거쳤던 과정이다. 우리는 이를 통해, Agile 방법론이, 기존 프로젝트 개발 방법론의 문제점을 극복하기 위해 탄생한 것임을 알 수 있다.

결론 2 : Agile은 다른 SW Development Approach의 한계를 극복하기 위해 탄생하였다.

---

#2 기존 Approach (접근법)

Agile의 핵심 가치들이 모두 기존 개발 접근법의 한계를 극복하기 위해 탄생하였다. 그러므로, 기존의 접근법을 알아야 한다.

핵심 접근법 4가지

• Predictive (SDLC : Waterfall) 분석, 디자인, 빌드, 테스트, deliver로 이어지는 전형적인 방식

• Iterative (SDLC : Spiral) 요구 사항과 일치할 때까지 분석과 디자인 반복 이후 빌드와 테스트 마찬가지 반복

• Incremental 분석, 디자인, 빌드, 테스트, deliver을 조금씩 추가.

• Agile 중요 Timebox의 단위로 제품을 만들고, 동시에 피드백 받음

Approach	고객의 요구 사항	시행	Delivery	목표
Predictive	Fixed	전체 프로젝트에서 한 번만 시행	Single Delivery	비용 관리
Iterative	Dynamic	옳을 때까지 반복	Single Delivery	해결책의 정확성
Incremental	Dynamic	주어진 수행 횟수에서 한번 실행	Frequent smaller deliveries	속도
Agile	Dynamic	옳을 때까지 반복	Frequent small deliveries	잦은 피드백과 delivery를 통한 고객 가치 제공

• Iterative와 Incremental의 차이는 Delivery에 있음.
• Agile과 Iterative, Incremental의 차이는 Goal에 있음.

결론 3 : Agile의 목표는 고객 가치 제공이며, 이를 가능케하는 가장 큰 특징은 Timeboxing이라는 개념이다. (Agile 개발 접근법을 통해, 비용, 품질, 생산성이 증가한다고 말하는 것은 무리이며, 애초에 Agile의 목표도 아니다.)

---

#3 Scrum을 통해 이해하는 Agile 핵심 개념

이 그림을 통해 3가지를 이해해야한다.

1. Scrum 의 구성 단계 이해 : Product Backlog, Sprint Backlog 등
2. Scrum에서 정의하는 2가지 Role : Product Owner, Scrum Maste
3. Project 진행 상황을 파악하는 tool : Burn Down chart 등

1. Product Backlog : 제품에 대한 요구 사항 목록 Sprint : 반복적인 개발 주기 Sprint Backlog : 개발 주기에 맞게 수행할 작업의 목록 및 목표 Shippable Product (그림에 없음) : Sprint 후 개발된 실행 가능한 결과물
2. Product Owner : Backlog 정의 후 우선순위를 세우는 역할 Scrum Master : 전통적인 프로젝트 관리자와 유사하나, Servant leadership이 요구됨
3. BurnDown Chart : 남은 일 (Y축) - 시간 (X축) 그래프를 통해, 진행 사항 확인 -> 이런 tool은 Project Owner가 프로젝트 예상 진행 상황과, 실제 진행 상황을 비교함으로써, 프로젝트 기간을 연장할 것인지, 추가 Resource를 투입할 것인지, 아니면 마무리 할 것인지를 결정하는 데 근거 자료가 되므로 중요하다.

 

결론 4 : 일정한 주기 (Scrum에서는 Sprint)로 Shippable Product를 만들고, 고객의 요구를 더하고 수정하는 과정을 반복한다.

---

#4 Agile의 5가지 Top Techniques

Scrum을 통해 Agile의 기본 과정을 이해했다면, 그 세부 내용을 구성하는 Iteration (= Sprint) 및 반복의 과정에서 어떤 technique이 쓰이는지 이해해야한다.

• Daily Standup : 매일 아침 15분 정도 아래와 같은 형식으로 진행 상황을 공유한다.

어제 ~을 했고, 오늘 ~을 할 것이며, 현재 ~ 어려움이 있습니다.

 

• Retrospective : 고객이 없는 상황에서, Iteration이 끝난 후, 팀에서 어떤 것이 문제였고, 무엇을 고칠 수 있는지 이야기한다.
• Iteration Review : 고객이 함께 있는 상황에서 Iteration의 결과물로 나온 Shippable Product에 대한 피드백, 평가를 받는다.

결론 5 : Agile 접근법의 성공을 위해서는 세부적인 Technique을 전체 process에서 실행해야한다.

 

출처 : https://github.com/gyoogle/tech-interview-for-developer
[참고 자료] : 링크1, 링크2