애자일 파트 업로드합니다😄

[KimDaBin]

애자일

애자일 이란?

• ‘Agile = 기민한, 날렵한’ 이란 뜻으로 좋은 것을 빠르게 취하고, 낭비 없게 만드는 다양한 방법론을 통칭해 일컫는 말

• 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하며, 효율적인 시스템을 개발하는 방법론

• 반복적/점증적인 짧은 개발주기, 위험도를 감소시키고 고객의 요구사항 수용의 민첩성이 강조된 개발 방법론

애자일 방법론의 진행 과정

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

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

애자일 방법론의 특징

• 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
• 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
• 팀원들과의 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
• 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
• 내부 구조 형성을 통한 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.

애자일 방법론의 장/단점

장점 👍

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

단점 👎

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

애자일 방법론의 종류

익스트림 프로그래밍(Extreme Programming, XP)

• 문서를 강조하지 않고 테스트를 우선하는 개발 방식, 개발 초기부터 테스트를 병행하는 개발 방법론
• 고객과 함께 2주 정도의 반복개발
• 의사소통, 피드백, 단순성, 용기, 존중 강조

1. 유저스토리 : 사용자 요구사항 수집, 의사소통 도구
2. 구조적 스파이크 : 설계상,기술상 잠재적 위험을 탐지하기 위한 간단한 프로그램, 기술적인 문제를 줄이고 유저 스토리 기반 개발일정에 대한 신뢰도 상승
3. 릴리즈 계획 : 전체 프로젝트 배포계획 확립
4. 주기 : XP핵심, 상황에 따른 릴리즈 및 계획수정
5. 승인 테스트 : 릴리즈 전의 인수 테스트(블랙박스 테스트), 고객수행
6. 작은 릴리즈 : 주기의 마지막 단계, 빠른 피드백

스크럼(Scrum)

• 30일마다 동작 가능한 제품을 제공하는 스플린트를 중심, 팀을 중심으로 한 반복적이고 점진적인 개발 방법론
• 제품 백로그를 바탕으로 기술적으로 분할되고 재해석된 스프린트를 통해 구현하는 개발 방법론
• XP는 변화수용, 스크럼은 선감지 처리 관점

구성요소

• Sprint : 반복주기 (Iteration, 30days)
• Product Backlog : 제품의 요구사항 목록
• Sprint Backlog : 해당 Sprint기간에 수행해야하는 Task 목록
• Daily Scrum Meeting : 매일 15분 정도 짧게 진행하는 미팅 (계획, 실적, 위험 공유)
• Review : Sprint 완료 시 고객 검토, Feedback을 받아 다음 Product Backlog에 적용
• Retrospective Meeting : Scrum Team에서 운영중인 시험 리뷰 및 개선 미팅
• Burn Down/Up Chart : 하나의 스프린트에 대한 소멸/완성 그래프

역할자

• Product Owner : 요구사항을 정의하고 Product Backlog 업데이트
• Scrum Team : Product Backlog 구현
• Scrum Master : 제 3자 입장에서 Product Owner와 Scrum Team이 Scrum방법론을 제대로 진행 할 수 있도록 지원

따라서 Scrum을 적용하려면 조직의 역할/구성/감리/산출물 등 다양한 영역에서 변화를 주어야 함

KANBAN (칸반)

• 연속적 흐름 처리 방식. 칸반 보드로 시각화되고 각각 단계는 열로 표시

구성요소

• Kanban Board : 프로세스를 가진 Board와 스토리카드를 이용하여 업무 흐름제어
• Process : 실제 업무가 이루어지는 단계 및 업무 수행을 통한 산출물 작성
• Work Queue : 대기형렬, 개발 대기, 테스트 대기, 배포/릴리즈 대기 과정
• Total Work Time (총 주기 시간) : 총 작업의 수행시간, 개별 업무의 Cycle Time의 합으로 구성