아래 내용은 언제든지 팀원과 논의해서 추가하거나, 수정할 수 있습니다.
- 동료를 존중해야 합니다.
- 동료에게 항상 감사하는 마음을 가지고 표현합니다.
- 서로에게 임팩트를 줄 수 있는 사람이 되어야 합니다.
- 항상 높은 목표를 지향하고, 자랑스러운 일을 해야 합니다.
- 논리적으로 이해가 되지 않는 부분은 언제든지 챌린지합니다.
- 함께 성장할 수 있는 기회는 서로 공유합니다.
- 업무의 목적을 명확히 하고 일을 합니다.
- 무엇이 가장 중요한지 우선순위를 살피고, 지금 해야 할 일을 합니다.
- 항상 적극적으로 먼저 공유하고, 자주 소통합니다.
- 해결책이 아니라 문제에 대해 근본적인 질문을 해야 합니다.
- 동료와 함께 공개적으로 일하며, 혼자서 문제를 해결하려고 하지 않습니다.
- 일을 진행하기 어려운 문제가 생긴 경우에 즉시 공유를 해야 합니다.
- 문제를 같이 해결하거나, 일정 조율을 해야 합니다.
프로젝트 관리에 대한 기본 원칙을 아래 문서에서 정리합니다. 프로젝트 관리를 일관성 있게 하며, 이를 통해 좀 더 효율적으로 프로젝트를 진행하고자 합니다.
업무의 목표와 목적을 확실히 하고, 주기적인 공유와 피드백 반영으로 프로젝트 방향이 올바르게 진행될 수 있도록 합니다. 또한 과정에서 배우는 것들을 함께 나누고 성장할 수 있도록 하는 것에 목적이 있습니다.
- 업무에 대한 테크 스펙을 만들고, 공유해야 합니다. (기능 구현을 하기 위한 방법이 포함됩니다)
- 실제 구현을 진행합니다.
- 테스트 코드가 함께 작성되어야 하고, 테스트 코드를 통해 성공/예외 상황에 대한 검증이 이루어져야 합니다.
- 특히, 테스트 케이스는 성공하는 사례보다 실패하는 사례를 5배 이상 만들어야 합니다. - Code Complete 2nd 참조 (개인적으로도 힘드니, 우선은 같은 수의 실패하는 케이스를 만들어야 합니다)
- 구현에 대한 리뷰를 진행하고, 피드백을 반영합니다.
- 결과물로 동작하는 소프트웨어를 보일 수 있어야 합니다.
- 코드 리뷰는 항상 진행해야 합니다.
- 기본적으로 PR 형태의 코드 리뷰를 진행합니다.
- 코드 리뷰 요청 시에 테스트 코드를 함께 제공해야 합니다.
- 작업자가 PR 형태로 진행하기 어렵다고 판단하는 경우에는 코드 리뷰 미팅을 진행합니다.
- PR 은 JIRA 티켓 단위로 만듭니다.
- JIRA 티켓은 최대한 가볍게 만듭니다.
- 하나의 PR 에는 여러 티켓이 섞이지 않아야 합니다.
- JIRA 티켓 사이에 의존성이 있는 경우에는 빠르게 코드 리뷰를 요청해서 머지를 진행하거나, 의존성이 있는 브랜치 위에서 작업을 진행합니다.
- BP 팀의 코드는 모범이 되어야 합니다.
- 항상 Readable Code 로 만들기 위해 노력해야 합니다.
- Design Patterns 를 적용하여 구조적이고, 확장 가능하게 만들어야 합니다.
- 꼭 필요한 Comments 는 항상 남겨야 합니다. (의미없는 Comments 는 없는게 낫습니다)
- github flow + develop branch를 같이 운용합니다.
- feature → develop → master
- github flow의 master 위치에 develop이 들어갑니다.
- develop 배포시에는 Commit hash를 사용합니다.
- tag는 master 에서만 붙입니다.
- feature → develop → master