애자일 스크럼과 JIRA
Download as PPTX, PDF118 likes46,166 views
스크럼에 대한 개념과, JIRA를 이용한 스크럼 구현
![6. 스프린트 진행
• 코드 리뷰
• 코드 리뷰는 피어 리뷰 방식으로 진행
• 문제 발생시 피어와 커미터 양쪽 공동 책임
• Reviewboard,gitlab, …
[reviewboard]](https://image.slidesharecdn.com/random-160428023018/85/JIRA-28-320.jpg)
애자일 스크럼과 JIRA
- 1. 소프트웨어 개발 스크럼과 JIRA 기반의 소프트웨어 개발 프로세스
- 2. #목표 “애자일 스크럼과 협업 도구인 JIRA를 이용한 소프트웨어 개발 프로세스를 이해한다.”
- 3. 스크럼 개발 방법론 요약
- 4. 개발 방법론의 변화 <Insert Picture Here> 그래서… 저명한 박사님들께서.. 방법론을 만드시니.. RUP,CBD,CMMI
- 5. 개발 방법론의 변화 But… 그러나 현실은 방법론은 방법론… 우리는 조금 더 현실적인 방법론이 필요합니다.
- 6. 개발 방법론의 변화 • 실용주의 방법론 • Erich Gamma, Joel Spolsky, Kent beck, Andrew Hunt • Iterative & Incremental • 애자일 기반 • 기존 방법론과 차이 • 요구 사항이 변화할 것을 가정 • 에러가 있을 것을 가정하여, 자주 테스트 • 협업과 커뮤니케이션 실용주의 방법론 구세주 등장!!
- 7. 개발 방법론의 변화 스크럼이 대세!! 관리자 입장에서는 예측 불가 조직에 맞게 바꿔서 쓰세요 http://agilescout.com/learn-more-agile-software- development-methods-this-year/
- 8. 스크럼 프로세스 개요 • Product BackLog • Sprint Meeting • Sprint BackLog • Sprint • Review • Restrospective
- 9. 스크럼 프로세스 스프린트 VOTING 스토리등록 회고 일일 스크럼 스프린트 스토리 그루밍 회고 일일 스크럼 스토리 그루밍 스프린트 종료 스프린트 시작 스프린트 준비 기간
- 10. 조직 구조 • 2 피자 팀 (5~7명) • Cross functional team (기획 + 개발 + 디자인 + QA + 운영) • Self Organized team (스스로 결정하고 진행) • 스크럼 마스터, 프로덕트 오너 (PO) • 애자일 코치가 있으면 효과가 높음 (EX. OO슬라이드)
- 11. 스크럼 프로세스
- 12. 1. 그루밍 • ”다음 스프린트에 들어가기전에, PO가 다음 스프린트에 개발할 기능에 대해서 대 략적으로 리뷰를 하는 행위”. 스프린트 진행중 일어남 • WHY • 다음 스프린트에 대한 가시성 확보 (미리 생각할 시간을 준다) • 개발 개시전 리뷰를 통해서 개발 가능성, 기획상 구멍등을 찾아서 수정할 시간을 갖는다. • 어떻게 ? • 1시간 정도로, 사용자 스토리나 UX 프로토타입을 리뷰 • 가급적 실제로 돌아가는 UX 목업이 좋음 (애니메이션 복잡도등을 미리 예측 가능)
- 13. 2. 사용자 스토리 작성 • 사용자 스토리 : 주요 기능을 사용자 관점에서 기술 “As a {user}, I want do {something}”. “나는 {사용자로써}, {무엇}을 한다”. • 특징 • 직관적으로 이해가 되어야 하며 • 테스트가 가능해야 함 • 분류, 스토리, 설명 형태로 기술 하는 것이 좋음 기능 분류 상세 설명사용자 기능 스토리 진행 순서
- 14. 3. 스토리 보팅 • 플래닝포커 (PLANNING POKER) • 개발팀 전체가 모여서, 각각의 사용자 스토리에 대해서 개발 기간을 투표 • 포인트의 의미는 알아서 정함. (EX 1포인트 = 1일) • 포인트는 0.5,1,2,3,5 단위로 띄워서 정의 • 전체 팀원이 서로 설득 당할때 까지 계속 진행 • 사용자 스토리에 대한 디테일은 PO에게 그 자리에서 질의 • 점수가 가장 높은 사람과, 가장 낮은 사람의 의견을 듣고 다 시 보팅. 가장 낮은 사람 (빠른 개발 방식을 알고 있을 수 있음), 가장 높은 사람 (놓친 무언가를 알 수 있음) • 정확하지 않으나, 정확함 plantit.com
- 15. 4. 개발 범위(일정 지정) • 산출된 포인트로 개발 일정 지정 (2~4주) • 버퍼 (회의, 문서, 배포, 오류 수정 등) 배정 필요 (1.5~2배) • 4주가 넘는 일정은 우선순위에 따라 자름
- 16. 5. 스프린트 시작 • JIRA에 등록 • 요건 UX 확인은 JIRA 로 핑퐁, UX 시안도 JIRA로 전달 • JIRA ISSUE 구조 정의
- 17. 5. 스프린트 시작 • JIRA의 이슈 타입 • EPIC : 스토리의 집합 • STORY : 사용자 중심의 기능 목록 • CHORE : 사용자 기능 중심이 아닌, 기술적인 태스크 • ISSUE : 메니져가 관리하는 이슈 • BUG : 버그 • SUB-TASK : 태스크들의 서브 태스크
- 18. 5. 스프린트 시작 • EPIC 등록
- 19. 5. 스프린트 시작 • 이슈 등록 / 컴포넌트 정의 • 컴포넌트는 제품 단위 또는 팀 단위로 분리하는 것이 좋음 • EX) IOS,안드로이드,웹 • EX) 관리자 포탈
- 20. 5. 스프린트 시작 • 이슈 등록 / Priority (우선순위) • Blocker의 경우 해결되지 않으면 프로젝트가 진행될 수 없는 경우 • Critical은 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우 • Major 꼭 개발해야 하는 경우 • Minor 개발은 해야 하나 없어도 상관 없는 경우 • Trivial 있으나 없으나 크게 상관 없는 경우
- 21. 5. 스프린트 시작 • 이슈 등록 • Summary : 제목 입력 • Priority : 우선 순위 생성 • Issue Type : 보통은 Story로 • Assignee : 개발 담당 (또는 스크럼 마스터로 정해 놓고, 나중에 ASSIGN하거나, 각 개발자가 알아서 당겨가는 PULLING 방식) • Description : Issue에 대한 상세 내용 * 액셀로 벌크 업로드 가능
- 22. 5. 스프린트 시작 • 이슈 등록 / 스토리 포인트 부여 • 스토리 보팅 단계에서 산출한 스토리 포인 트를 스토리별로 부여
- 23. 5. 스프린트 시작 • 이슈 등록 / 스프린트 맵핑 • 스프린트를 생성하고, 백로그에서 스프린트를 끌어 올려서, 스프린트에 맵핑
- 24. 5. 스프린트 시작 • 이슈 등록 / EPIC 맵핑 • 등록된 이슈들을 EPIC에 맵핑 • 처음 스토리 작성시 그룹핑을 그대로 사용
- 25. 5. 스프린트 시작 • 이슈 등록 / 릴리즈 버전 맵핑 • 릴리즈 버전을 정의해놓고, 버전에 스토리를 맵핑 • 어느 기능이 어느 버전에 들어 가는지 추적 가능 • 어느 버그가 어느 버전에서 발생해서 어느 버전에 서 수정이 가능한지 추적 가능
- 26. 5. 스프린트 시작 • 칸반 보드 세팅 • 진행중인 스크럼 태스크의 상태를 칠판에 표시 해놓는 방식 (포스트잇) • JIRA 애자일 보드로도 가능하지만, 가시성이 떨어짐. (태스크 & 서브 태스크들이 많아서 잘 안보게됨. 또는 자기것만 보게됨) JIRA를 쓰더라도 칸반보드는 별도 운영하는게 좋음 • 칸반 보드의 스타일은 팀과 개발 방식에 맞게 끊임없 이 변화해야 함
- 27. 6. 스프린트 진행 • 일일 스크럼 미팅 • 약속한 시간에 스탠드업 미팅 • 칸반 보드를 보고 • “어제 한일, 오늘 할일, 일처리에 장애 요인” 을 간단하 게 이야기 함. • 끼어들거나 질문 금지… (마이크를 드는것도 좋음) • 추가 회의가 필요하면 스크럼 미팅 끝나고 • 생각보다 잘 안됨. (회의는 하지만 컨택스트 공유가 잘 안됨) 될때까지…
- 28. 6. 스프린트 진행 • 코드 리뷰 • 코드 리뷰는 피어 리뷰 방식으로 진행 • 문제 발생시 피어와 커미터 양쪽 공동 책임 • Reviewboard,gitlab, … [reviewboard]
- 29. 6. 스프린트 진행 • DAILY COMMIT (with TICKET #) • 매일 코드 커밋 • 코드 커밋시에 JIRA TICKET #를 적어 넣으면, JIRA 티켓에서 코드 변경 사항 추적이 용이함.
- 30. 6. 스프린트 진행 • JIRA 티켓 업데이트 • 보통 여기서 망함 • 잘못된 사용예 • 티켓에 아무 내용이 없음 • 상태를 업데이트 하지 않음 (나중에 몰아 닫기) • 옳은 사용예 • 티켓을 통해서 요구사항에 질문이 있을때, PO에게 다시 지정, UX가 필요하면 UX 디자이너에게 지정 (또는 서브 태스크 사용) • 나한테 ASSIGN 된 티켓은 항상 업데이트 • 스크럼 코치가 있으면 효과적 (티켓 업데이트를 종용)
- 31. 7. QA • 근래에 QA 방식은 다양화됨 • 개발팀이 직접 QA 하는 방식 (별도의 QA를 두지 않음) : 이상적.빡셈. 다양한 단말 테스트가 쉽지 않음 • 개발팀내에 QA를 둬서 스토리가 개발 완료되는 데로 QA : 막판에 몰리는 현상이 발생함 • 개발팀 외에 QA를 두고, 개발 종료 시점에 QA를 하는 방식 : 당근 막판에 몰리고, QA팀 일정 조정이 어려움.
- 32. 8. 데모
- 33. 9. 릴리즈 및 배포 • 코드 프리즈 및 배포 • 앱 릴리즈 • 안드로이드 단계적 릴리즈 (10%, 30%, … 100%) • 앱 크래쉬 리포팅 (Twitter Crashtycs)
- 34. 10. 회고 • 잘한것, 고마운것,잘못한것, 아쉬운점을 정리해서 다음 스프린트에 개선 방향을 정 하고 세부 액션 아이템을 정해서 수행 • 진행자가 있는 것이 좋음 • 포스트잇으로 잘한것,고마운것, 잘못한것, 아쉬운점을 각자 적어서 붙여놓고 그룹핑 • 잘한것을 더 잘하게, 미진했던 점을 극복할 수 있는 방안을 써놓고 그룹핑 • 투표를 통해서 다음 기간에 실행에 옮길 아이템을 선정 • 다음 회고 프로세스를 개선할 수 있는 방안을 추가로 기술 • 일반적으로 회고때 푸념만 이야기 하고 구체적으로 실행되지 않는 경우가 많음 • 액션 아이템에 대한 오너(OWNER)를 정하는 것이 좋음
- 35. 10. 회고 • 총 3시간 프레임웍 • 스프린트에 대한 감상 공유 (10) • ESVP (10) • 좋았던점, 나빴던점 모으기 (20) : 포스트잇 3장 • 잘된점,나빴던점,고칠내용,불확정 (30) • 화남,기쁨,슬픔 (20) : 포스트잇 3장씩 • 팀워크 만족도 (20) : LV1~5 • 점스티커 투표(10) : 인당 스티커 한장씩, 도움이 된거 하나, 방해된거 하나 • SMART 회의 (20) : 4명씩 • EXACT 목표 (20) : 4인 • 회고에 대한 회고 (10)
- 36. 백로그 회의
- 37. 백로그 회의 • 목적과 의미 • 3개월 이상의 장기 제품 개발 로드맵을 정의 • 수행 방법 • 주요 경영진과, 개발리드가 참여 • 매주 또는 격주에 한번 • 우선 순위 조정 및, 주요 기능에 대한 사전 리뷰 • 에픽 단위의 기능을 정의하고, 우선순위를 비지니스 상황에 따라서 변동 • 운영 • JIRA에 백로그 프로젝트를 별도 구성 • 위아래 순서로 우선 순위 지정 • 릴리즈 버전을 부여함으로써 릴리즈에 대한 대략적인 일정 예측
- 38. 애자일 팀 모델의 변화
- 39. 팀모델의 변화 • 기술 분류에 따른 팀 (Functioanl Team) • 프론트,백앤드,앱,운영,QA 등 모바일 앱 백앤드 웹 페이지 관리도구 댓글 포스팅 댓글 포스팅 앱개발팀 프론트 개발팀 백앤드 개발팀
- 40. 팀모델의 변화 • Cross functional Team (Product based) • 한팀내에 프론트,백앤드,앱,운영,QA를 다 넣음 • MSA에 적용되는 팀모델
- 41. 팀모델의 변화 • Cross functional Team (Product based) • Product 간에 복잡한 코디네이션이 필요함 • Program manager, Chief Architect 등
- 42. 팀모델의 변화 • Cross functional team (Feature based) • 기능 단위로 팀을 묶고, 한팀이 전체 컴포넌트를 개발 • 플랫폼화 필수 (쉽게 기능 추가가 필요한 구조)
- 43. 개발 운영 프로세스의 변화
- 44. 개발 운영팀의 변화 모델 • 1단계. 스타트업
- 45. 개발 운영팀의 변화 모델 • 2단계. 펀딩 받았다
- 46. 개발 운영팀의 변화 모델 • 3단계. 깨달았다. CD & DEVOPS
- 47. End of document