📌 1. 스프린트

• 스프린트 시작 전, 명확한 데일리 목표 및 작업 우선순위를 설정합니다.
• 스프린트 목표와 현실 간의 차이를 분석하여 지속적으로 개선합니다.

✅ 1. 명확한 목표 설정

• 명확하고 달성 가능한 목표: 초보 개발자는 추상적인 목표에 혼란을 느낄 수 있으므로, 작은 단위로 목표를 명확히 설정해야 합니다.
• 단계적 접근: 큰 작업을 여러 단계로 나누어 스프린트 단위로 목표를 설정합니다.
• 작업 우선순위 지정: 중요도와 긴급도를 기준으로 작업을 우선순위에 따라 배치합니다.

✅ 2. 코드리뷰 및 멘토링 강화

• 일상적 코드리뷰: PR 기반의 코드리뷰를 일상적으로 진행합니다.
• 건설적인 피드백 제공: 초보 개발자의 성장을 돕기 위해 명확하고 건설적인 피드백을 제공합니다.
• 페어 프로그래밍: 초보 개발자와 숙련 개발자가 함께 작업하도록 페어 프로그래밍을 진행합니다.

✅ 3. 학습 시간 보장

• 주간 학습 시간: 매주 2~4시간은 학습 및 기술적 문제 해결에 투자할 수 있도록 보장합니다.
• 기술 문서화: 팀 내에 참고할 수 있는 기술 문서를 체계적으로 정리합니다.
• 지속적인 질문 허용: 초보 개발자가 자유롭게 질문할 수 있는 문화를 조성합니다.

✅ 4. 주간 체크인 (Weekly Check-in)

• 진행 상황 확인: 매주 팀 리더와의 1:1 미팅을 통해 진척도를 확인합니다.
• 문제 해결 지원: 개발 과정에서 발생한 문제나 어려움을 즉시 해결할 수 있도록 지원합니다.
• 목표 조정: 진행 속도에 따라 목표를 유연하게 조정합니다.

✅ 5. 지속적인 회고 문화 (Retrospective)

• 정기적 회고: 스프린트 종료 후 KPT 회고(Keeps, Problems, Tries)를 통해 개선점을 도출합니다.
• 개선 사항 적용: 다음 스프린트에 도출된 개선사항을 즉시 반영합니다.
• 개발 문화 피드백: 초보 개발자의 의견을 적극적으로 수렴하여 개발 문화를 개선합니다.

📌 2. 회의 문화

• 목적 중심: 모든 회의는 명확한 목표와 아젠다를 설정하고 시작합니다.

• 시간 엄수: 회의는 정해진 시간 내에 끝내며, 필요 이상으로 길어지지 않도록 합니다.

• 참여자 명확화: 필요 인원만 회의에 참석하여 비효율을 방지합니다.

• 백엔드 전략 회의: 백엔드 팀은 세부 업무 전략을 논의할 별도의 시간을 가집니다.

• 문서화: 회의 결과는 반드시 문서로 기록 및 공유합니다.

• 회의 내용과 결론은 명확하게 문서화하고, 후속 조치를 설정합니다. (액션아이템 필수)

• 데일리 스크럼

  • 시간: 매일 10~15분.
  • 목적: 팀원별 진행 상황 공유 및 장애 요소 확인.
  • 형식: "어제 무엇을 했는가?", "오늘 무엇을 할 것인가?", "문제는 없는가?"

• 주간회의

  • 시간: 주 1회, 30분~1시간.
  • 목적: 주간 목표 달성 현황 점검 및 문제 해결.
  • 형식: 팀별 주요 이슈 공유 및 다음 주 계획 설정.

• 월간회의

  • 시간: 월 1회, 1~2시간.
  • 목적: 월간 성과 리뷰 및 팀 단위 목표 설정.
  • 형식: 주요 이슈 및 성과 공유, 중장기 계획 검토.

• 스팟회의

  • 시간: 필요 시, 최소한의 시간.
  • 목적: 긴급 이슈 해결 및 즉각적인 의사결정.
  • 형식: 빠른 해결이 필요한 문제에 집중.

• 스프린트 회고

  • 시간: 스프린트 종료 직후, 1시간.
  • 목적: 스프린트 목표 달성 여부 검토 및 개선 방안 논의.
  • 형식: KPT (Keep, Problem, Try) 프레임워크를 활용한 회고.

📌 3. 코드리뷰

• 목적: 코드리뷰는 코드 품질을 높이고, 버그를 사전에 방지하며, 팀원 간의 기술 공유를 목적으로 진행합니다.
• 주기: 주요 기능 배포 전에는 반드시 코드리뷰를 거칩니다.
• 방식:
  • PR(Pull Request) 기반 코드리뷰를 실시합니다.
  • 리뷰어는 코드의 가독성, 유지보수성, 일관성을 검토합니다.
• 리뷰 피드백:
  • 리뷰어는 구체적이고 건설적인 피드백을 제공합니다.
  • 리뷰를 완료한 코드만 병합(Merge)됩니다.
• 팀원 교육: 코드리뷰를 통해 팀원 간 기술 공유 및 학습을 장려합니다.

💡 추가 제안:

• 팀 내에서 코드리뷰 가이드라인을 명확하게 정의합니다.
• 반복되는 문제는 회고를 통해 공유하고 개선책을 마련합니다.

📌 4. 기능점수(Story Points)

• **기능점수(Story Points)**는 스프린트 내에서 특정 기능이나 작업의 복잡도, 노력, 위험도를 수치화한 값입니다.
• 이 점수는 작업의 규모와 예상 소요 시간을 대략적으로 나타냅니다.
• 일반적으로 **피보나치 수열(1, 2, 3, 5, 8, 13, …)**을 사용하여 기능점수를 부여합니다.

✅ 목적:

• 스프린트의 작업량 예측
• 팀의 작업 속도(벤치마킹) 파악
• 작업 우선순위 설정

📊 기능점수 계산을 위한 주요 요소

✅ 1. 복잡도(Complexity)

• 해당 기능이 얼마나 복잡한가?
• 구현에 필요한 기술적 난이도가 어느 정도인가?

✅ 2. 노력(Effort)

• 이 기능을 구현하기 위해 얼마나 많은 시간이 필요한가?
• 작업이 몇 단계로 나누어져야 하는가?

✅ 3. 위험도(Risk)

• 예상치 못한 문제가 발생할 가능성이 있는가?
• 기술 부채나 기존 코드와의 충돌 가능성이 있는가?

✅ 4. 경험 및 예측 정확도(Experience & Estimation Accuracy)

• 팀원들이 해당 기술에 얼마나 익숙한가?
• 비슷한 작업을 이전에 수행한 경험이 있는가?

🛠️ 3. 기능점수 산정 방법

✅ 1. 피보나치 수열 사용법 (1, 2, 3, 5, 8, 13)

• 1점: 매우 간단한 작업 (예: 버튼 하나 추가)
• 2점: 간단하지만 몇 가지 고려 사항이 있는 작업
• 3점: 중간 복잡도, 한 명이 하루 이내에 해결 가능한 작업
• 5점: 복잡한 작업, 며칠이 소요될 수 있음
• 8점: 매우 복잡한 작업, 주간 단위로 관리해야 함
• 13점 이상: 너무 크거나 불명확한 작업, 세분화 필요

예시:

📌 4. 협업 도구 사용 (추가 항목)

• 프로젝트 관리: Jira, 프로젝트 관리 도구를 사용해 작업을 체계적으로 관리합니다.
• 커뮤니케이션: Microsoft Teams 등 실시간 커뮤니케이션 도구를 적극 활용합니다.
• 문서화: Confluence 등 협업 문서를 사용하여 정보와 지식을 체계적으로 공유합니다.
• 버전 관리: Git을 사용해 소스코드를 관리하고 협업합니다.

💡 추가 제안:

• 도구 사용 가이드라인을 명확히 정의하고 팀원 모두가 일관되게 사용하도록 합니다.
• 주요 변경 사항은 도구를 통해 팀원에게 즉각 공유됩니다.