내부 세션에서 발표한 내용

1. 애자일 스크럼 회고

2. 목차
• 애자일 스크럼 소개
• 팀 구성
• 스프린트 경험
• JIRA 번다운 차트 리포팅
• 결론

3. 비즈니스 환경은 빠르게 변화
전통적 IT 프로젝트 개발 방식의 한계
다양한 애자일 개발 방법 발표
DSDM(Dynamic Systems Development Methods, 1994)
스크럼(scrum, 1995)
크리스털 방법론(Crystal Clear, 1996)
…
XP(Extreme Programming, 1996)
칸반(SW Kanban, 2006)
린 스타트업(Lean Startup, 2011)

4. 애자일 소프트웨어 개발 선언문(요약)
• 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다.
• 포괄적 문서화보다는 동작하는 소프트웨어 더 큰 가치를 둔다.
• 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다.
• 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다.

5. 스크럼(scrum, 1995)
왜 해야하나요?
팀의 속도(Velocity)
애자일을 구현할 때 가장 선호되는 프레임워크

6. 팀 구성
총괄 프로젝트 리더
• 소규모 팀으로 동시접속 peak 600명 서비스 DevOps
• AWS Scale out 더 많은 사용자 수용가능!
제품 책임자
개발자
기획자
디자이너
스크럼 마스터

7. 스프린트 기획
일일 스탠드업 미팅
스프린트 데모
스프린트 회고
Four ceremonies

8. • 스프린트 데모
• 스프린트 회고• 일일 스탠드업 미팅
• 스프린트 기획
스프린트 주기는 2주
화요일 오전부터 시작
JIRA, Confluence 사용
백로그, 이슈 관리
6시간 이상 걸림
JIRA에서 관리되는 이슈기반
Daily Did List Confluence 기록
어제 한 일, 오늘 할 일, 이슈 공유
QA팀, 스프린트 기획일에 확인
스프린트 기획이 끝나면
무중단 패치(QA->OP)
스프린트 기획 때 진행
직전 스프린트에서 느낀점
아쉬움, 좋음, 서로 칭찬

9. 스프린트 기획
• 2주 스프린트 실시 (스프린트 길이는 절충되어야 한다)
• 백로그에서 이번 스프린트에서 해야 할 일 정리
• 1일 작업은 1 Story Point 계산
• 업무에 집중 할 수 있는 시간은 최대 70%
• 한 스프린트 Working Day는 10일
• 한 사람이 한 스프린트에 소화할 수 있는 포인트는 7 Point
• JIRA를 이용해서 이슈를 할당하고 작업 시간을 추정
• 이슈는 1 Point 가 넘지 않도록 관리
• 스프린트 중간에 변경사항은 스크럼마스터가 관리

10. 번다운 차트
“스프린트는 심장박동처럼 항상 일정해야 한다.”

11. 번다운 차트
“스프린트는 심장박동처럼 항상 일정해야 한다.”

12. 번다운 차트
“스프린트는 심장박동처럼 항상 일정해야 한다.”

13. 번다운 차트
“스프린트는 심장박동처럼 항상 일정해야 한다.”

14. 결론
애자일 스크럼 best practices 없다
앞으로도 없을 것이다.
시행착오를 겪으면서
팀에 적용 해야한다.