Agile 애자일 과 스크럼

소프트웨어 개발 기법 중 한가지

 

애자일 등장 배경

• 초기 소프트웨어 개발 방법은 계획 중심의 프로세스
• 90년대 이후 소프트웨어 분야가 넓어지면서 소프트웨어 사용자들이 일반 대중들로 바뀌기 시작하여 트랜드가 급격히 변하는 시대가 되었다. 비즈니스 사이클(제품 수명)이 짧아졌고 SW 개발의 불확실성이 높아지게 되었다.
• 개발의 불확실성이 높아지면서 옛날의 전통적 개발 방법 적용이 어려워졌고 사람들은 자신만의 SW 개발 방법을 구축하여 사용하게 된다. 그 중 경량 방법론 주의자들은 일반 해보고 고쳐나가는 방식으로 개발하게 되었다. (규칙은 적게, 가볍고 대응을 잘하는 방법을 적용)

 

애자일이란

협력과 피드백을 자주하고 일찍하고 잘하는 것

1. 협력
   • 소프트웨어를 개발한 사람들 안에서 협력을 의미
   • 스스로 느낀 좋은 통찰은 협력을 통해 다른 사람에게도 전해줄 수 있어 예상치 못한 팀의 기대 효과를 가져옴
2. 피드백
   • 학습의 가장 큰 전제조건이 피드백으로 내가 어떻게 했는지 확인하면서 학습을 진행해야 한다.
   • 소프트웨어의 불확실성이 높을수록 학습의 중요도는 올라간다.

소프트웨어 개발의 불확실성은 애자일에서 중요하다.

불확실성이 높으면 우리가 생각한거랑 다르다라는 상황에 직면하고, 시스템 변경사항을 유연하게 기민하게 대응하도록 방법론을 제공해준다.

 

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

 

애자일의 진행 방법

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

 

 

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

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

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

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

1. 제품 기능 목록 작성
   • 개발할 제품에 대한 요구사항 목록 작성
   • 우선순위가 매겨진 사용자의 요구사항 목록이라고 말할 수 있음
   • 개발 중 수정이 가능하기는 하지만 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙
2. 스프린트 Backlog
   • 스프린트 각각의 목표에 도달하기 위해 필요한 작업 목록
   • 세부적으로 어떤 것을 구현해야 하는지/ 작업자/ 예상 작업 시간
   • 최종적으로 개발이 어떻게 진행되고 있는지 상황 파악 가능
3. 스프린트
   • 작은 단위의 개발 업무를 단기간 내 전력질주하여 개발
   • 한달동안 큰 계획을 3-5일 단위로 반복 주기를 정했다면 이것이 스크럼에서 스프린트에 해당
   • 주기가 회의를 통해 결정되면 목표와 내용이 개발 도중에 바뀌지 않아야 하고 팀원들 동의 없이 바꿀 수 없는 것이 원칙
4. 일일 스크럼 회의
   • 모든 팀원이 참석하여 매일, 짧게, 진행 상황 점검
   • 한사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기
   • 완료된 세부 작업 항목을 스프린트 현황판에서 업데이트 시킴
5. 제품 완성 및 스프린트 검토 회의
   • 모든 스프린트 주기가 끝나면 제품 기능 목록에서 작성한 제품이 완성
   • 최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의 진행
   • 고객의 요구사항에 얼마나 부합하는가/ 개선점 및 피드백
6. 스프린트 회고
   • 스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토
   • 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다

 

 

스크럼 장점	스크럼 단점
		스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있음	추가 작업 시간이 필요 (스프린트마다 테스트 제품을 만들어야 하기에)
회의를 통해 팀원들간 신속한 협조와 조율이 가능	15분이라는 회의 시간을 지키기 힘듦, 시간이 초과되면 그만큼 작업 시간이 줄어든다
자신의 일정을 직접 발표함으로써 업무 집중 환경 조성	스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약함
프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이함

 

Agile이 될 조건

4 Value

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

비교의 대상은 기존의 개발 방법론에서 거쳤던 과정으로 이를 통하여 애자일 방법론이 기존 프로젝트 개발 방법론의 문제점을 극복하기 위해 탄생한 것임

 

 

기존 Approach 접근법

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

• 핵심 접근법 4가지
  1. Predictive (SDLC : Waterfall) 분석, 디자인, 빌드, 테스트, deliver로 이어지는 전형적 방식
  2. Iterative (SDLC : Spiral) 요구 사항과 일치할 때까지 분석과 디자인 반복 이후 빌드와 테스트를 마찬가지로 반복
  3. Incremental 분석, 디자인, 빌드, 테스트, deliver를 조금씩 추가
  4. Agile Timebox의 단위로 제품을 만들고 동시에 피드백을 받음

애자일 목표는 고객 가치 제공이며 이를 가능케하는 가장 큰 특징은 Timeboxing이라는 개념이다.

즉, 애자일 개발 접근법을 통해 비용, 품질, 생산성이 증가한다고 말하는 것은 옳지 않으며 목표도 아니다.

 

 

애자일의 5가지 기술

• 스크럼을 통해 애자일의 기본 과정을 이해했다면, 그 세부 내용을 구성하는 Iteration (=Sprint) 및 반복의 과정에서 어떤 기술이 쓰이는지 이해해야한다.
• Daily Standup (매일 아침 15분 진행상황 발표)
• Retrospective : 고객이 없는 상황에서 Iteration이 끝난 후 팀에서 어떤 것이 문제였고 무엇을 고칠 수 있는지
• Iteration Review : 고객이 함께 있는 상황에서 Iteration 의 결과물로 나온 Shippable Product에 대한 피드백, 평가를 받는다.

애자일 접근법의 성공을 위해선 세부적인 기술을 전체 프로세스에서 실행해야 한다.