애자일 방법론

애자일 방법론 이란, 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론

• 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구 사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발해 프로세스 모델 방식
• 개발 기간이 짧고 신속하다.
• 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있다.
• 가장 고객의 요구에 잘 대응할 수 있는 방법론
• 애자일 방법론은 미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인 폭포수의 프로세스와는 비교가 많이 되는 반대의 개념이다. 계획이나 문서가 아닌 실질적인 코딩을 중요시하고 짧은 개발 주기를 반복하여 위험 요소를 최소화 시킨다.

유형	XP, 스크럼, 린	폭포수, 나선형, 프로토타입
계획 수립	유동적 범위 설정	확정적 범위 설정
업무 수행	팀 중심 업무 수행	관리자 주도적 명령과 통제
개인 단위로 업무 수행
개발/검증	반복 주기 단위로 소프트웨어를 개발/검증	경쟁, 개별 평가
문서화	문서화보다는 코드를 강조	상세한 문서화를 강조
성공 요소	고객 가치 전달	계획/일정 준수

💡 애자일 방법론은 기존 개발 방법론의 한계를 극복하기 위해 등장

전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어렵기 때문에 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성이 증가

 

폭포수 방법론 이란, 각 단계가 마치 폭포수처럼 위에서 아래로 물이 떨어지듯 차례대로 진행되어 이름이 붙여졌다. 폭포수 방법론은 계획 → 분석 → 설계 → 개발 → 시험 → 운영/유지 보수 순으로 진행된다.

폭포수 모델에 테스트 단계가 추가된 폭포수 모델의 확장 형태-V모델

• 폭포수 모델은 문서, 산출물 중심으로 진행
• 단계가 명확하고 모든 단계마다 검증 작업이 있어 오류를 줄이는 장점
• 테스트를 마지막 단계에 하기 때문에 치명적인 문제가 처음에 간과 될 수 도 있는 단점

애자일 방법론의 진행 과정

애자일 방법론은 계획 → 설계(디자인) → 개발(발전) → 테스트 → 검토(피드백) 순으로 반복적으로 진행된다. 계획을 세운 후 다음 단계까지 기다려서 절차대로 진행하는 폭포수 모델과 달리 먼저 진행 후 분석, 시험, 피드백을 통하여 개선하여 나가는 진행 모델이다.

• 계획 및 분석 : 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약 조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는 task를 이해하는 단계
• 설계(디자인) : 기획 의도에 맞는 설계 및 디자인 추가 및 수정하는 단계
• 개발(발전) : 설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합 테스트 수행
• 테스트 : 발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계
• 검토(피드백) : 기획 의도를 파악하고 시험 결과와 기획의 따라 수정할 부분을 제시하는 단계

애자일의 유형

애자일 방법론은 대표적으로 XP, 린(lean), 스크럼(SCRUM)등 이 있다.

 

XP

의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론으로 1~3주의 반복적인 개발 주기를 가지며 5가지 가치와 12개의 실천 항목이 존재

• 5가지 가치
  • 용기 ⇒ 용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링 할 수 있는 용기)
  • 단순성 ⇒ 필요한 것만 하고 그 이상의 것들은 하지 않음
  • 의사소통 ⇒ 개발자, 관리자, 고객 간의 원활한 소통
  • 피드백 ⇒ 의사소통에 대한 빠른 피드백
  • 존중 ⇒ 팀원 간의 상호 존중
• 12개의 실천 항목
  • 짝 프로그래밍 ⇒ 개발자 둘이서 짝으로 코딩하는 원리
  • 공동 코드 소유 ⇒ 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
  • 지속적인 통합 ⇒ 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
  • 계획 세우기 ⇒ 고객이 원하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
  • 작은 릴리즈 ⇒ 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 해야한다는 원리
  • 메타포어 ⇒ 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
  • 간단한 디자인 ⇒ 현재 요구 사항에 적합한 가장 단순한 시스템을 설계
  • TDD ⇒ 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
  • 리팩토링 ⇒ 프로그램의 기능을 바꾸지 않으면서 중복 제거, 단순화 등을 위해 시스템 재구성
  • 40시간 작업 ⇒ 일주일에 40시간 이상을 일하지 말아야 한다는 원리
  • 고객 상주 ⇒ 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
  • 코드 표준 ⇒ 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의

스크럼

• 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

주요 개념

스크럼 주요 개념스프린트(Sprint) ⇒ 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발 품질 향상스크럼 마스터(Scrum Master) ⇒ 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람스프린트 회고(Sprint Retrospective) ⇒ 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 확인

번 다운 차트(Burn Down Chart) ⇒ 남아 있는 백로그 대비 시간을 그래픽적으로 표현한 차트

제품 책임자(Product Owner) ⇒ 비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 백 로그를 관리하고 제품을 검토합니다.

스크럼 미팅(Scrum Meeting) ⇒ 매일 15분 정도 미팅으로 To-Do-List 계획 수립

백로그(Backlog) ⇒ 제품과 프로젝트에 대한 요구 사항

1. PO(Product Owner)는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선 사항을 이해 한다.
6. 제품의 리뷰를 통해 제품의 지속적 개선 사항 도출이 끝나면, 스프린트 회고를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다.
7. 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.

스크럼의 추구 가치

• 용기 : 옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 위한 용기를 가진다. ⇒해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.
• 집중 : 할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 신경 쓰지 않는다. ⇒ 한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.
• 약속(헌신/책임) : 팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 헌신하며, 이를 달성 위해 필요한 모든 권한을 부여한다. ⇒ 개인보다는 팀성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.
• 존중 : 경력과 경험이 사람을 만든다. 팀원들을 존중한다. ⇒ 개개인 별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을 것이다
• 투명성/개방성 : 프로젝트에 대한 모든 내용을 투명하게 공개한다. ⇒ 제품 백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.

린

도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상 시킨 방법론

7가지 원칙 => 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

 

애자일 방법론 장단점

장점

• 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
• 점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
• 계획 혹은 기능에 대한 수정과 변경에 유연하다.
• 고객 요구 사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.
• 빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.

단점

• 확정되지 않은 계획 및 요구 사항으로 인한 반복적인 유지 보수 작업이 많다.
• 고객의 요구 사항 및 계획이 크게 변경될 경우 모델이 무너질 수 있다.
• 개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업들이 많을 수 있다.
• 반복 적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
• 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.