git + Pull Request + Code Review and Project Management with Agile
3 likes194 views
2015/11/11 고석주 교수님 SW 특강 자료입니다. Part 1: git + Pull Request + Code Review Part 2: Project Management(Scrum, Kanban, Trello)
git + Pull Request + Code Review and Project Management with Agile
- 1. git을 통한 협업 프로세스와 프로젝트 매니징 Yooii Studios 김우성
- 2. About me • 유이스튜디오 CTO (2011. 11 ~ ) • iOS, Android - 4개 앱 개발 & PM(약 4년) • 경북대 도서관 iOS/Android
- 3. 경북대 도서관
- 5. 경북대 도서관 • iOS - 2012년 졸프. Scrum 처음으로 적용. • Android - 2014년 후배 졸프 팀에 멘토로 참여, 이후 이어받아 리뉴얼을 통해 출시 이후 업데이트 • 경북대 도서관 페이스북 페이지 관리
- 6. 개발했던 앱들 • iOS - Morning Kit • Android - Morning Kit, News Kit, Swish • 현재 Swish iOS 개발 중
- 7. Morning Kit News Kit Swish
- 8. Today’s outline • Part 1: git + github • Part 2: Project Management
- 9. Part 1: git, Pull Request, Code Review
- 10. git?
- 11. git? 현존하는 가장 진보적 버전 관리 시스템: DVCS = Distributed Version Control System
- 12. VCS, CVCS, DVCS • VCS = 소스 코드 관리 시스템 • SVN = Centralized VCS • git = Distributed VCS
- 13. SVN = CVCS • 중앙 서버에 오류가 생기면 작업 중지 • 인터넷 없이 커밋 불가능 • 서버 데이터가 날라가면 끝
- 14. git = DVCS • 1 로컬 저장소 / 1 프로그래머 • 인터넷 없이 버전 관리 가능 • 빠르다! • 복구가 아주 쉬움
- 15. 한번도 git을 사용해보지 않은 사 람은 있어도 한 번만 사용해 본 사람은 없다!
- 17. Linux
- 18. Linus Torvalds
- 19. git - Built for Linux • 대부분의 시절: 원시적인 패치와 압축파일로 관리 • 2002년: 상용 DVCS BitKeeper 사용 • 사이가 틀어진 후 리눅스 커뮤니티에서 2005년 자체 개발에 성공 • 개발 초기엔 리누스 토발즈가 직접 많이 참여
- 20. Goals for git • 빠른 속도 • 단순한 구조 • 비선형적인 개발(수천 개의 동시다발적인 브랜치) • 완벽한 분산 • 리눅스 커널 같은 초대형 프로젝트도 사용 가능
- 21. SVN vs git +
- 22. 2011. 3
- 26. 무려 3년 2개월의 차이
- 27. 무려 3년 2개월의 차이 ➤ 이미 전세계에서는 git이 중심
- 37. Pull Request
- 38. Pull Request
- 39. Pull Request 독립적인 기능을 독립적인 코드에.
- 43. Code Review
- 44. Code Review 코드 퀄리티 향상, 코드 컨벤션 일치, 지식 공유
- 48. git + Pull Request + Code Review
- 49. + Agile Dev. ➤ Global Standard git + Pull Request + Code Review
- 50. 1부 Q & A git, Pull Request, Code Review
- 52. Project Management • Agile • Moves like Scrum • Kanban on the way
- 53. 1. Agile
- 54. Agile Software Development • 프로세스와 도구보다 각 개인과 상호작용을 • 문서작업보다 실제 작동하는 소프트웨어를 • 계약 협상보다 고객과의 협력을 • 계획에 따르기보다 변화에 반응을
- 55. Agile Software Development • 프로세스와 도구보다 각 개인과 상호작용을 • 문서작업보다 실제 작동하는 소프트웨어를 • 계약 협상보다 고객과의 협력을 • 계획에 따르기보다 변화에 반응을 형식과 겉보기 보다는 정말 중요한 것들에 집중하자!
- 56. Agile in projects • Agile = 기민한, 낭비없는 • Code-oriented • 지속적인 배포
- 57. 2. Moves like Scrum
- 58. Scrum in Agile • Agile은 소프트웨어 개발 철학 • Scrum은 Agile의 방법론 중 하나 • Sprint = Scrum의 한 개발 주기 단위
- 59. Scrum • 일을 가능한 작게 나누고 우선순위 정렬 • 각 일에 대해서 소요시간 추정(ex: 2점 = 2시간) • 한 스프린트 동안 해낼 수 있는 양 추정(ex: 25점) • 해당 스프린트가 끝나면 배포 가능한 제품 출시
- 60. 한 스프린트가 끝나면 스프린트 리뷰 회의, 스프린트 계획 회의 진행
- 61. Pivotal Tracker Redmine, Basecamp, Trac, etc.
- 65. 강력하지만 복잡 스크럼 마스터 필요 시간 소요가 큼
- 66. 3. Kanban on the way
- 67. Scrum의 단점 • 오버헤드: 시간 소요, 스크럼 마스터 필요, 스프린트 회의 • 추정의 미신: 예측을 위해 추정, 하지만 항상 부정확함, 아까운 시간 소모 • 사기와 번아웃: 틀린 추정, 우선순위/기획 변경이 있음에 도 푸시, 스프린트 후 사기 저하 및 번아웃
- 68. Scrum의 단점 • 시간 기준 반복 개발이 내포하는 문제점 • 짧은 개발 주기: 기간 내에 개발 가능한 개발 항목만 • 실제 작업은 연속적, Scrum은 스프린트 내 끝낼 일만 추가 가능
- 69. Kanban = 신호 카드 토요타의 생산 시스템 기법 중 하나
- 70. Kanban = 신호 카드 프로세스 뒤쪽 단계에서 앞쪽으로 신호를 보내 생산 요청
- 71. Kanban on Software • Scrum 단점을 개선하기 위한 방법론 • 뒤쪽 공정이 완료되면 앞쪽 공정에 요청 • Scrum보다 협업을 강조 • 만능은 아니다. 장단점이 다를 뿐
- 72. Kanban의 특징 • 워크 플로우 시각화 • 진행중인 작업 수(WIP) 제한 • 부드러운 흐름으로 개발 가능
- 74. 시각화 트렐로와 유사하게 현재 작업하고 있는 흐름을 한 눈에 파악
- 75. 진행중인 작업 수 제한 각 열에 할당 가능한 이슈 수가 제한해 품질을 향상. 이전보다 더 빠른 작업 완료. 재작업이 줄어듬
- 78. 칸반 나라의 하루 도서 ‘칸반과 스크럼’ 에서 발췌
- 83. Kanban Tools • Redmine • Trac • JIRA - 유료, 하지만 강력 $10 / year on your server
- 84. Kanban in JIRA Agile
- 89. WIP를 정하는 법?
- 90. 정답은 없습니다.
- 91. 각 팀원이 협업을 해야할 정도의 병목현상이 생길 정도 조정
- 92. 중요한 것은 적절한 WIP를 찾기 위해 계속 조정해야 한다는 것
- 93. Morning Kit, News Kit, Swish Boards ➤ Whole Projects Board
- 95. +
- 104. To Do(Maybe) To Do(Must) In Progress Done In Testing
- 108. Summary • git, Pull Request, Code Review • Trello, Scrum(Pivotal Tracker), Kanban(JIRA) • Kanban in Trello • PM 경험은 현업에서도, 면접에서도 중요
- 109. 2부 Q & A Agile Dev. - Scrum, Kanban