Home
코드스쿼드 그룹 프로젝트, second hand입니다. second hand는 중고 거래 플랫폼 서비스입니다.(작성 예정)
| 제이든(FE) | 훈딩(FE) | 코어(BE) | 감자(BE) | 에디(iOS) | 하림(iOS) |
-
main: default branch -
release: 배포 branch -
develop: 개발 branch-
dev-fe: 프론트엔드 branch -
dev-be: 백엔드 branch -
dev-ios: iOS branch
-
- 각 클래스별 기술에 대한 내용들
- 항상 위키에 업로드한다는 마인드로 노션 작성!
10시 15분 - 스크럼 시작.
순서 : FE → iOS → BE
스크럼은 인당 5분을 넘기면 안된다!!!!
시간: 10시 15분부터 10시 30분.
얘기해야할 내용
- 각 클래스 별 상황 공유
- 현재 나의 컨디션, 상황, 미션 해결 과정의 문제점, 오늘 할 일 등을 짧게 나누기
- 시간이 남는다면 잡담도 권장. 단 예의를 갖추자.
회의는 필요할때 서로 요청하기!
그룹 리뷰 (수/목 17:00 ~ 18:00)
- 전날 풀었던 미션을 그룹원과 함께 리뷰
- 한 사람씩 돌아가면서 자신의 코드를 설명하기
- 어떤 과정을 통해, 어떻게 문제를 해결했는지 이야기 나누기
- 그룹원이 풀었던 코드를 보며 궁금한 점을 질문하고 대답하기
- 모두가 동의한다면 좀 더 길게 진행도 가능
데이터 수집 : 각 클래스별로 상의
피드백 전달 : 스크럼시간, 회의시간 때 진행, 상시 진행도 고려해봐야함.
FE, BE, iOS feature별로 브랜치를 파서 진행한다.
feat/fe/이슈이름, feat/be/이슈이름, feat/ios/이슈이름
- merge 후 브랜치 삭제하지 맙시다.
-
dev-fe,dev-ios,dev-be -
main브랜치는 main으로 두기!- 아무것도 README 작업만!
-
develop:release에 merge하기 전 최종 확인하는 브랜치- iOS는
develop에만 하기!
- iOS는
-
release브랜치는 매일매일 작업한 내용 merge 시키기!
그런데 솔직히 둘다 상관이 없는게 ISSUE를 브랜치 명으로 생각하면 브랜치명을 그다지 생각 안해도 된다.
신경쓸것은 그냥 브랜치명만 안겹치게 만들면 될듯.
[[함께 일하기] 온라인 근무와 회고 | 우아한형제들 기술블로그](https://techblog.woowahan.com/2713/)
-
회고방식
개인적으로 회고는 항상 하려고 합니다. 바쁘다면 한 번은 미루고 지나갈 수 있지만, 두 번 연속은 안 된다는 기준을 가지고 있습니다. 이전 회사에서 지나온 팀들을 돌아 보면, 매 스프린트 마다 회고를 하다가 회고를 안 하기 시작하는 순간 팀이 무너졌습니다. (제가 있던 모든 팀에서는 그랬습니다.) 하나 둘 팀을 떠나고, 심할 때는 모든 팀원이 다른 팀으로 떠나기도 했습니다. 물론 선후 관계나 인과 관계는 모르겠지만.. 내가 힘들고 바쁜데 회고할 시간이 어디 있으며, 다른 팀원들의 생각을 듣고 감정소모 까지 할 여력이 없을지도 모르겠습니다. 잡담도 많이 하면서 보내는 회고 시간이 팀이 무너지거나 번아웃이 오는걸 조금이라도 늦추는 방법 중 하나이지 않을까 하고 생각합니다.
최근에 엄청난 피로감의 프로젝트가 있었습니다. 팀원들 모두 스트레스를 많이 받았을 것 같습니다. 그래서 이번엔 조금 다른 방법으로 회고를 해보려고 했습니다. 회고가 끝나면 다음 회고 진행자를 사다리타기로 뽑고 있지만, 왠지 요즘 제가 자주 걸리는 이상한 현상이.. =_= 이번에 또 회고 진행자로 걸렸고, 마침 프로젝트가 끝나가는 시점이기도 해서 평소와는 조금 다른 방법으로 진행해 봤습니다.
회고 방식은 여러 방식이 있지만, 일반적으로 우리팀은 다음 순서로 회고를 진행합니다.
아이스브레이킹 게임- 각자의 스프린트 소감 공유 (좋은점, 아쉬운점, 배운점, XX에게 고마워요)
- KPT (Keep, Problem, Try) : 상황(하고 있는 것, 할 것), 미션 해결 과정의 문제점, 할 일(시도)
(Try를 통한) Action Item 뽑기회고에 대한 회고
이번엔 순서를 조금 바꿔서 진행해 봤습니다. 아이스브레이킹을 살짝 뒤로 밀고, 스프린트 회고가 아닌 2개월 넘게 달려온 프로젝트 회고로 할 얘기들이 많을 것 같아서 속얘기들을 더 많이 끄집어 내보려고 했습니다.
- 각자의 스프린트 소감 공유
- 아이스브레이킹 게임
- 좋았던 점 / 나빴던 점 돌아보기 (Good/Bad)
- 각자의 스프린트 소감 공유 (좋은점, 아쉬운점, 배운점, XX에게 고마워요)
- KPT (Keep, Problem, Try) : 상황(하고 있는 것, 할 것), 미션 해결 과정의 문제점, 할 일(시도)
- 각 클래스 별 상황 공유
- 현재 나의 컨디션, 상황, 미션 해결 과정의 문제점, 오늘 할 일 등을 짧게 나누기
- 시간이 남는다면 잡담도 권장. 단 예의를 갖추자.
스크럼 마스터 & 서기 : 클래스별로 돌아가면서.
스크럼 마스터
- 진행을 하는거 아닐까요?
- 시간 잘 배분하기!!!
스크럼 서기
- 스크럼 내용 작성하기 - wiki에 작성!
- 예의를 지키자!
- 동료에 대한 존중.
- 서약 내용 숙지.
gitmoji type (#issue-number): Subject
(한 줄 띄기)
body
Ex)
✨ feat #3: 메인 페이지 토글 기능 추가
(한 줄 띄기)
- 토글 버튼 클릭 시, 팝업창 on
- 토글 버튼 클릭 시, 팝업창 off
-
✨ feat: 새로운 기능 추가 -
🐛 fix: 버그 수정 -
♻️ refactor: 코드 리팩토링 -
🎨 style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 -
💄 design: CSS 등 사용자 UI 디자인 변경 -
✅ test: 테스트 코드 -
📝 docs: 문서 수정 -
🔧 chore: 빌드 업무 수정, 패키지 매니저 수정 → 패키지 설치할때 chore 쓴다!, lint, prettier 설치 등.. -
🔥 remove: 디렉토리 및 파일명 변경
- Git-issue 사용
- 제목 양식
[FE] 프로젝트 초기 설정
- 클래스 별 라벨 부착