Agile의 기반환경 기반환경
1. 프로젝트 특성에 맞는 Life Cycle 모델 선정
2. 서비스 단위의 팀(Scrum Team)구성
Scrum Master
- Agile Facilitator
- 팀원의 장애요소 제거, 지원
- 전통적 PM/PL 역할 대비. 명령,지시 → 코칭, 촉진, Sercvant Leadership
Product Owner
- 요구사항 도출, 우선순위 결정
- Sprint 결과물 검토 및 피드백
- 전통적 고객 역할 대비
- 프로젝트 후반 참여 → sprint 계획/리뷰 참여
Development Team
- Sprint 마다 잠재적 출시가능 제품 개발
- 다 기능 수행 팀
- 전통적 팀원대비
- 개인별 업무 성과 → 팀공통 성과
- 역할별 단계별 투입
3. 지속적 통합, 자동화, 가시성 확보 기반 시스템
4. 협업/공유 환경 및 자율적 개선 문화
- 가치 중심 개발 문화
- 자율관리 팀 문화
- 몰입 환경 제공
- 회고 & 개선 문화
Product Backlog = 제품에 담고자 하는 기능 및 요구사항의 우선순위를 정리한 목록
제품과 관련하여 해야 할 일을 의미하는 것은 무엇이나 제품 백로그에 포함됨
백로그
- 스토리(Story) - 제품 기능 요구사항
- 테스크(Task) - 비기능 요구사항
- 결함(Bug) - 개발 진행 중 또는 완료 후 도출된 결함
백로그 작성 원칙(INVEST원칙)
I(Independent) : 독립적이다.
- 스토리 간에 의존성을 배제하도록 한다. 스토리 사이에 의존성이 있으면 우선순위 결정과 계획수립에 문제를 야기한다.
N(Negotiable) : 협상가능하다.
- 스토리는 계약서나 요구사항 명세서처럼 꼭 구현해야 한다고 기록하는 것이 아니다. 스토리는 기능에 대한 짧은 설명일 뿐이다. 세부사항은 고객과 개발팀이 대화를 통해 협상해야 한다.
V(Valueable) : 사용자 및 고객에게 가치가 있다.
- 모든 스토리는 사용자, 구매자에게 가치가 평가되어야 한다.
- 정말 피해야 할 스토리는 개발자에게만 가치 있는 스토리다.
E(Estimable) : 추정 가능하다.
- 개발자들은 각 스토리의 크기 혹은 작업소요 시간을 추정할 수 있어야 한다.
S(Small) : 작다.
- 스토리는 한두 명의 개발자가 반나절에 길어야 2주일 안에 구현하고 테스트할 수 있는 정도의 크기가 적당하다.
T(Testable) : 테스트 가능하다.
- 스토리는 테스트 가능하도록 작성해야 한다. 테스트를 성공적으로 통과해야 그 스토리가 성공적으로 성공할 수 있다.