[특강] Git/Github 익히기 한기용 강사님

data_hamster·2023년 4월 26일

특강

목록 보기

1/1

학습주제

학습내용

근본적인 이야기.
다음주 부터 프로젝트 시작.
협업을 하게될텐데 어떻게 일을 나누어서 할 것인지.

리포지토리 만들고, 코드 업로드 하고, 풀 리퀘스트 코드 리뷰

오늘은 웹 UI만 사용해서 깃허브 사용

내일은 CLI를 이용해서 작업

금요일 내가만든 코드 리포지토리, 코드가 바뀔 때마다 코드가 돌게끔.
Github actions

실제로 현업에서 프로젝트를 하다보면 굉장히 중요한 포인트.

과거엔 세상이 그렇게 빠르게 돌지 않다보니 Water-Fall 모델이 적합했음.
디자인이 끝날 무렵 요구조건이 바뀌는 경우가 있음.

Water-Fall을 하다보면 테스트 과정에서 큰 결함이 발견되는 경우가 있음.

짧은 사이클 (보통 2주): 스프린트(Sprint)라고 부름.
짧게 한바퀴 돌림.
code가 merge되는 대로 바로 코드 배포
test coverage가 75% 이상은 되어야함.
CI/CD를 구현해서 코드의 변경사항이 생겼을 때 테스트 돌려보고 잘 돌아가면 바로 배포.

이런 느낌으로 진행시킴. 이번 스프린트에 할 일들, 진행중, 테스트, 종료.
매일 아침에 모여서
어제 한일
오늘 할일
장애 사항
회의함.

Backlog 보드가 따로 하나 더 있음 Backlog는 우선순위 순으로 정렬되어 있는 task들이 있음.
매 스프린트가 시작될 때마다 중요한 task부터 to do로 옮김.

Planning: Backlog의 task를 to do 보드로 옮기는 것. 스프린트 길이가 2주라고 하면, 월요일에 모여, 그 전 스프린트 회고를 함. 그다음 새 스프린트 플래닝을 함. 각 팀원들은 To do에서 In progress로 옮김.

Demo 미팅: 각자 자기가 했던 일들을 자랑하는 듯한 미팅.
그다음은 회고 미팅: 지난 2주들 돌이켜봤을 때 아쉬웠던 점 등을 논의.

Backlog 보드의 일들을 만들고 우선순위 정리 : Backlog grooming. 시니어들이 함. 이때 스프린트 카드를 만듬

그럼 포스트잇에 어떤 내용이 들어가나? task는 어떤것이?

포인트: 숫자. 클수록 난이도가 높고 중요함. 팀마다 숫자를 주는 방법이 다름. 애자일 방법론에서 이 포인트를 부여하는 것이 가장 어려움. 어떤 회사는 중요도는 안보고 시간만 얼마나 걸리느냐. 2시간에 1점. 또는 시간은 안보고 중요도만 보고 점수를 매기는 경우도 있음.
성공의 정의: 지금이 task가 끝났다고 했을 때 어떤 것들이 끝나있어야 하는가. 구체적으로 체크리스트를 만들기도 함.
포인트를 주는 방법: 플랜닝 포커

팀이 성숙하게 되면 점수차이가 크게 나지 않음. 가장 낮게 준 사람. 가장 높게 준 사람에 대해 물어보게 됨. 충분히 듣고 낫나서 다시 voting을 하게 됨. 좁혀지지 않을경우, projuct owner가 재량으로 정함. 그러나 논쟁을 좋아하는 사람이 있는 경우 이거 정하는 데에만 30분 넘게 걸림. 비효율적. 강사님의 경우 6시간 걸리는 경우도 있음. 결국 해고당함. 너무 완전한 합의, 모든 의문을 해결하는 자리는 아님.

피보나치 수열을 갖고 있음. 21보다 큰 수는 없음. 일련번호를 주는 것이 아니라. 복잡할 수록 값을 크게 부여함. 요새는 모바일 앱으로 연결을 해서 처리.