⚖️ Ground Rule

우리들의 공통 목표와 그에 따른 행동 강령입니다. 팀의 모든 의사결정은 그라운드 룰에 입각해서 판단합니다.

<aside> ❓

제 1 원칙

❓ No Dummy Qeustion!

• 세상에 바보같은 질문은 없습니다. 그 태도에 문제가 있을 뿐.
• 저희는 절대 그 어떠한 질문에도 비웃음, 조소 등을 표하지 않습니다..!
• 어떠한 질문에도 최선의 답을 제공합니다.
• 반대로, 질문자는 반드시 질문하는 것에 대한 근거를 마련한 상태로 질문합니다.
• 상호 예의를 존중합니다.

</aside>

<aside> 📝

프로젝트에 대한 공통의 목표

🚀 포트폴리오에 쓸 수 있는 실사용자를 위한 서비스

• 포트폴리오에 담을 가치 있는 프로젝트를 개발: 모든 팀원은 포트폴리오로 활용할 수 있는 완성도 높은 프로젝트를 목표로 한다.
• 실사용자에게 의미 있는 서비스: 프로젝트는 실제 사용자에게 도움이 될 수 있는 기능을 제공해야 한다. 재미를 위한 프로젝트일지라도, 명확한 사용자 경험(UX)을 기반으로 해야 함.
• 유지보수 가능성: 프로젝트는 지속적으로 유지보수될 수 있도록 설계하며, 최소 1년간 유지보수할 수 있도록 계획을 세운다.

</aside>

<aside> 📝

기술적인 목표

🚀 최소한의 라이브러리, 프레임워크 사용

• 기술보다는 문제 자체에 집중: 문제를 기술에 끼워맞추기 보다는, 문제 해결 자체에 집중한다. 그렇기에, 새로운 기술을 배우기보다는 이미 아는 기술을 최대한 활용하며, 필요에 따라서 기술을 도입하는 방식으로 간다.
• 논리적인 생각, 판단 근거의 명확성: 관성처럼 기술을 적용하는 것이 아닌, 문제에 맞추어서 명확하게 왜 이런 기술을 썼는지 근거를 확실히 한다.
• 사용자 경험 중시(UI/UX): FrontEnd 4명이 모인 만큼, 사용자의 경험을 최우선으로 한다. UI/UX 적으로 사용자가 서비스를 이용하는 데 불편함이 없는 것을 목표로 하며, 이를 완성도의 기준으로 삼는다.

</aside>

<aside> 📝

팀 문화

😆 싱글벙글 하하호호 우리들

• 즐겁고 활발한 팀 분위기: 팀원들 간에 소통이 원활하고 편안한 분위기를 유지한다. 스몰톡이나 비공식적인 대화를 통해 팀 분위기를 활기차게 유지하며, 서로의 동기부여를 위해 노력한다.
• 건강과 워라밸 존중: 과도한 업무보다는 건강을 최우선으로 고려하며, 휴식이 필요한 경우 언제든 자유롭게 쉬는 문화를 장려한다. 장기적으로 지속 가능한 프로젝트를 목표로 한다. 단, 마감 직전이나 스프린트 때는 달린다.
• 각자의 의견 존중: 서로의 의견을 경청하고, 의견 충돌이 발생했을 때는 둘 사이에서 해결보다는 반드시 팀원 전체가 참여하여 논의한다. 이때, 다수결 또는 협의를 통해 해결한다. 필요한 경우 카드를 사용한 의사결정 방식(ex: "나 말 좀 하게 해줘 카드")을 도입해 원활한 의사결정을 진행할 수 있도록 한다.

</aside>

<aside> 📝

협업 및 의사소통 규칙

💬 잦은 커뮤니케이션을 할 수 있어야 한다.

• 슬랙 및 협업 도구 활용: 슬랙을 기본 소통 도구로 사용하며, 메시지를 읽었을 때는 이모지 대신 명확한 답변을 남겨 소통의 명확성을 유지한다.
• 실시간 협업 도구 사용: 실시간 소통이 필요한 경우, Zep 을 사용해 비대면 상황에서도 실시간 피드백과 소통이 이루어지도록 한다.
• 코어 타임 준수: 매일 10시부터 7시까지 코어 타임을 운영하며, 이 시간 동안에는 집중적으로 프로젝트에 참여하고 빠른 피드백을 제공한다. 코어 타임 외에는 자율적으로 활동할 수 있지만, 긴급한 상황에서는 Zep, 슬랙을 통해 즉각적인 소통이 이루어져야 한다.
• 신뢰: 주변의 반응 및 생각에 흔들리지 말고, 팀이 결정한 내용을 전적으로 신뢰한다.

</aside>

<aside> 📝

의사결정 방식

🤝 팀 전체가 동의하는 의사결정

• 의사결정은 팀 전체가 참여: 주요 결정은 팀원 모두가 논의하며, GitHub Issue를 통해 정리된 문제점과 해결 방안을 공유한 후, 충분한 근거를 바탕으로 결정한다.
• 데일리 스크럼: 매일 아침 데일리 스크럼을 통해 각자의 작업 진행 상황을 공유하고, 문제점 및 해결책을 논의한다.
• 긴급 의사결정: 필요시 Zep 또는 슬랙 언급을 통해 팀원들을 소집해 긴급 의사결정을 빠르게 내린다.
• 내 말좀 들어줘 카드!: 각자 2 장의 카드가 부여되며, 서로가 납득할만한 수준에서 의견이 대립될 때 사용한다. 사용한 사람의 의견을 무조건적으로 수용한다. (”서로가 납득 가능한 상식선”이라는 전제)

</aside>

<aside> 📝

프로젝트 개발 원칙

😇 사용자 경험(UX) 중심의 개발

• 사용자 경험(UX) 중심 개발: 기술적인 완성도뿐만 아니라 사용자의 관점에서 서비스의 유용성을 고려한다. 기능이 잘 동작할 뿐 아니라, 사용자가 쉽게 이해하고 사용할 수 있어야 한다.
• 작업 공유 및 문서화: 모든 작업은 명확히 공유되어야 하며, GitHub Issue와 노션을 통해 진행 상황과 문제점을 기록한다. 트러블슈팅, 배운 기술, 이슈 등을 꼼꼼히 문서화해 프로젝트의 전체 진행을 기록한다.

</aside>

<aside> 📝

작업 분배 및 기록 관리

🧑‍🤝‍🧑 분업이 아닌 협업

• 작업 기록 관리: 모든 작업은 노션과 GitHub Pull Request, Issue 등을 통해 투명하게 관리된다. 이를 통해 프로젝트의 진행 상황을 쉽게 파악하고, 작업의 흐름을 유지할 수 있다.
• 스프린트 방식 도입: 코어 타임 내에서 주어진 작업을 마무리하고, 주 단위로 목표를 설정해 달성 여부를 확인한다. 스프린트 종료 후 회고를 진행해 다음 스프린트에 반영할 개선점을 도출한다.

</aside>

<aside> 📝

코드 리뷰 및 PR 규칙

🧑‍💻 4명의 PR Approve 및 최소 주 2회의 코드 리뷰

• 최소 주 2회의 컨벤션 및 맥락 파악 목적의 코드 리뷰: 팀원들이 서로의 코드를 리뷰하며, 코드의 품질도 중요하지만, 이때의 핵심은 우리의 컨벤션을 서로 얼마나 잘 지키고 있는지 이다.. 코드 리뷰는 팀원의 성장뿐 아니라, 서로의 작업을 이해하고 소통하는 과정으로 삼는다. 즉, 각자의 개발 맥락을 파악하는 목적을 주로 한다.
• PR 승인 규칙: 4명 모두의 PR 승인이 있어야만 기능을 머지할 수 있으며, 모든 팀원이 해당 기능에 대한 충분한 이해를 갖출 수 있도록 한다.
• 작업의 투명성 유지: 코드 리뷰와 PR을 통해 프로젝트의 모든 진행이 투명하게 공유되며, 이는 팀원 간의 신뢰를 강화하는 중요한 요소로 작용한다.
• 데일리 스크럼의 활용: 이슈나, 코드 공유 등은 데일리 스크럼 시간에 더하여, 아침에 소통하도록 한다.

</aside>

<aside> 📝

프로젝트 회고

🎨 Figma, Miro 등을 이용한 시각적인 회고

• 회고 방식: 프로젝트 진행 중 KPT(Keep, Problem, Try) 방식으로 주기적인 회고를 진행해, 잘한 부분과 개선할 점을 분석하고 다음 스프린트에 반영한다. 피드백은 GitHub 또는 피그마 등을 활용해 시각적으로 정리한다.
• 결과 기록: 회고 내용과 함께 프로젝트 과정에서의 문제점과 해결 방안을 기록하여 포트폴리오에서 활용할 수 있는 자료로 남긴다.

</aside>

<aside> 📝

긴급 상황 대응

‼️ ”이의있소!”

• TMT, TMI 방지 카드: 각 팀원은 필요시 언제든지 **"나 힘들다 카드"**를 사용해 TMT, TMI를 막을 수 있다. 이때, 😪, 😴 와 같은 이모지나 기능을 사용해서 알린다.
• 스톱 카드: 기술에 대한 학습이나, 구현이 요구사항을 넘어서 너무 깊어질 경우 **"스톱 카드"**를 사용해 중단시키고, 본래 해야하는 업무에 집중시킨다. 이는 PR 리뷰를 하면서든, 언제든지 자유롭게 제안할 수 있다.

</aside>