Agile Process란?
상황(요구사항) 변화에 민감하게 반응하여 불필요한 문서작업을 줄이고 고객에게 빠르게 코드를 제공하고자 하는 프로세스
1. Individuals and interations over Process and tools
불필요한 작업을 줄이고 개인의 역량을 최대한 발휘할 수 있도록 하는 것
2. Working software over comprehensive
이해가능한 문서보다 작동하는 소프트웨어에 초점을 맞추는 것
3. Customer collaboration over Contract negotiation
고객과의 협력을 중요시하는 것
4. Responding to change over following a plan
계획을 따르기보다 변화에 적응하는 것
1. Scrum란?
작은 목표를 짧은 주기로 점진적이고 경험적으로 개발할 수 있게 하는 관리 프레임워크이다.
개발에 참여하는 사람들이 효과적으로 협업할 수 있게 한다.
Product backlog: 개발할 제품의 요구사항을 product backlog로 쪼갠다.
Sprint: 개발주기(약 1~4주)안에 개발할 수 있는 단위로 나눈다.
그리고 Sprint들은 우선순위별로 관리된다.
Agile 개발 방법론은 일반적으로 Simple~Complicated 사이의 단계에서 적합하다.
대규모 프로젝트에는 적합하지 않다.
*Anarchy: 통제불능 상태
주요 역할자
1.Product Owner(제품 책임자, 고객)
제품 백로그를 관리하고 설명한다.
제품 백로그의 우선순위를 정한다.
제품을 검토한다.
2.Scrum Master
팀을 이끈다.
팀을 보호하고 장애요소를 제거한다.
일일 스크럼 회의를 진행한다.
모니터링한다.
3.Developer
최신 기술로 제품 백로그를 구현한다.
주요 일정
1.Sprint planning
스프린트 목표를 논의한다.
2.Sprint review
스프린트의 요구사항을 만족하는지 확인한다.
3.Sprint retrospective
스프린트에서 잘한 점과 부족한 점을 논의한다.
4.Daily Scrum Meeting
어제 한 일, 오늘 할 일, 해결해야할 문제를 논의한다.
주요 구성요소
1.Product Backlog: 제품의 요구사항을 나눈다.
2.Sprint Backlog: 개발주기(1~4주) 단위로 제품의 요구사항을 나눈다.
3.Burndown/up Charts: 진행상황을 나타낸다.
Agile 모델, Scrum 모델 자체가 요구사항(상황)의 변화에 민감하게 반응하는 모델이지만 고객의 과도한 간섭이 개발 실패로 이어질 가능성이 있기 때문에 적절하게 외압을 차단하는 것이 좋다.
*꼭 지켜져야 하는 것
-Sprint 기간은 항상 고정적으로 지켜져야 한다.
→초보자는 이 기간을 명확하게 알 수 없다. 경험이 있는 개발자가 투입되어야 하는 이유이다.
2.Scrum Detail
(1)Product Owner(고객측)
ROI(Return of Investment)제품 관리자는 상품의 수익성에 대한 책임을 진다.
우선순위는 시장 가치에 따라 정한다.
작업 실패에 대한 책임을 감당한다.
(2)Scrum Master(개발팀장)
프로젝트 관리를 대표한다.
팀을 보호하고 장애요소를 제거한다.
팀의 능률을 높인다. 팀을 이끈다.
일일 스크럼 회의를 한다.
(3)The Team(개발팀)
일반적으로 5~9명의 사람으로 구성된다.
Cross-functional이다.
(4)Sprint planning meeting
Sprint prioritization: 제품의 요구사항을 분석하여, 스프린트 우선순위를 정한다.
Sprint planning: 어떻게 스프린트 목표를 달성할 것인지 정한다.
예를 들어, 다음과 같은 호텔 시스템 개발 상황이라고 가정하자.
다음과 같은 제품의 요구사항(Product backlog)에서 스프린트를 만들 수 있다.
(5)Daily Scrum Meeting
매일 10~15분씩 어제 한 일, 오늘 할 일, 해결해야할 문제상황을 논의한다. 단, 문제해결을 위한 자리가 아니다. 문제가 해결되지 않는다면 관련된 사람이 따로 모여서 회의한다.
(6)The Sprint review
스프린트 동안 무엇을 달성했는지 평가한다.
(7)Sprint retrospective
스프린트 동안 무엇을 잘 했고, 무엇을 잘 못했는지 평가한다.
(8)Product Backlog
개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리된다.
*사용자 스토리(User Story): 과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명
(9)Sprint
개발주기(1~4주)단위의 최소 Cycle
(10)Burndown charts
일의 진행상황을 나타낸다.
Comments