* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.

* 원활한 내용 이해를 위해 수업에서 제시된 자료 이외에, 개인적으로 조사한 자료 등을 덧붙이고 있음.

1. 협업 Tool

• 여러 개발자들이 같은 프로젝트에서 효율적으로 협업할 수 있도록 지원하는 소프트웨어나 플랫폼.

• 팀원 간의 의사소통, 코드 관리, 작업 흐름 조율 등을 원활하게 하고, 프로젝트의 품질과 진행 속도를 높이는 데 중요한 역할을 수행한다.

• 버전 관리, 프로젝트 관리, 의사소통, 코드 리뷰, 문서화, 테스트, CI/CD 등등.. 각각의 역할에 특화된 협업툴들이 존재한다.

1. 버전 관리 도구

• Git, GitHub, GitLab, Bitbucket 등등.
• 여러 개발자들이 각자 작성한 코드를 쉽게 통합하고 관리할 수 있는 Tool.
• 코드의 버전을 관리하고, 변경 이력을 기록하며, 충돌을 해결할 수 있도록 지원.

2. 프로젝트 관리 도구

• Jira, Trello, Asana, Notion 등등.
• 프로젝트의 일정과 작업 할당을 관리하고, 작업 상태를 추적하는 기능을 제공.
• 개발자는 이 도구를 통해 할 일 목록, 버그 트래킹, 마일스톤 등을 설정하고 진행 상황을 공유.
• 팀원들이 각자 작업 중인 내용을 시각적으로 한눈에 파악하고, 우선순위를 관리하기 용이.

3. 의사소통 도구

• Slack, Microsoft Teams, Discord 등등.
• 빠른 질문, 토론, 파일 공유 등을 통해 신속한 의사소통이 가능, 원격 근무에서도 유용하게 활용.
• 특정 주제별로 채널을 생성하여 주제를 구분할 수 있고, 영상 및 음성 통화 기능을 통해 비대면 회의도 할 수 있다.

4. 코드 리뷰 도구

• GitHub Pull Request, GitLab Merge Request, Crucible 등등.
• 개발자들이 작성한 코드가 병합되기 전 다른 개발자들이 리뷰하여 품질을 확인, 오류나 개선 사항을 논의할 수 있다.
• 코드의 품질을 높이고, 학습을 통해 개발 역량을 강화할 수 있는 기회를 제공.

5. 문서화 도구

• Confluence, Google Docs, Notion, Wiki 등등.
• 프로젝트 관련 문서나 기술적 사양, 가이드라인 등을 작성하고 공유할 수 있다.
• 코드와 관련된 지식이 체계적으로 정리되어, 팀원들이 필요한 정보를 쉽게 찾고 활용할 수 있다.

6. 테스트 및 CI/CD 도구

• Jenkins, Travis CI, GitHub Actions 등등.
• 코드의 빌드와 테스트, 배포 과정을 자동화하여, 코드가 변경될 때마다 안정성을 보장할 수 있습니다.
• 개발자들은 코드 수정 후 자동으로 테스트와 배포가 이루어지기 때문에 개발 효율성을 높일 수 있습니다.

2. Trello, Jira, Notion 개념

Trello

• 취준 관련 작업들을 총괄하는 Trello의 사용 예시.

• 웹 기반의 프로젝트 관리 도구, 팀 협업과 개인 작업 관리를 효율적으로 지원.

• 사용자는 '보드(Board)'를 생성하고, 그 안에 '리스트(List)'와 '카드(Card)'를 추가하여 작업을 체계적으로 관리할 수 있다.

• 각 카드는 특정 작업이나 아이디어를 나타내며, 마감일 설정, 첨부 파일 추가, 체크리스트 작성, 라벨 지정 등의 기능을 제공합니다. 또한, 팀원들을 카드에 멤버로 추가하여 협업을 강화할 수 있음.

• 리스트를 '할 일(To Do)', '진행 중(Doing)', '완료(Done)' 등으로 구성하여 카드들을 해당 리스트로 이동시키며 작업 흐름을 관리. 프로젝트의 전반적인 상태를 한눈에 확인하고, 우선순위를 설정하며, 팀원 간의 원활한 소통을 지원.

Jira

• 기초 사용방법 설명 및 이미지 출처

• 프로젝트 관리와 버그 추적을 효과적으로 수행할 수 있도록 지원하는 도구.

• 프로젝트를 체계적으로 계획하고 관리하는 데 초점을 맞춘 도구로, 특히 애자일(Agile) 방식의 관리에 특화.

Jira가 애자일 작업에서 쓰기 좋은 이유

• 스크럼 보드와 칸반 보드를 기본적으로 제공하여, 팀이 자신들에게 적합한 애자일 프레임워크를 선택할 수 있다.

• 스크럼 보드는 스프린트 관리, 백로그 정리, 속도 차트 등을 통해 특정 기간 내에 달성해야 할 작업 목표를 세우고, 이를 추적할 수 있다.

• 칸반 보드는 팀이 작업을 진행 중인 항목과 완료된 항목을 시각적으로 쉽게 파악할 수 있도록 지원하여 작업 흐름 관리에 유용하다.

• 프로덕트 백로그(Product Backlog)를 체계적으로 관리할 수 있는 기능을 제공하여, 각 작업 항목(이슈)의 우선순위와 상태를 설정하고 쉽게 업데이트할 수 있다.

• 백로그 정리(Backlog Grooming) 세션을 통해 작업의 우선순위를 조정하고, 스프린트에 포함할 항목을 선별할 수 있다.

• 스프린트(일정 기간 동안 완료해야 하는 작업)를 계획하고 관리하는 데 최적화되어 있다.

• 팀은 각 작업 항목에 스토리 포인트(작업의 예상 소요 시간)나 추정 시간을 설정하여, 스프린트 동안 완료할 수 있는 작업량을 계획할 수 있다.

• 스프린트가 진행되는 동안 팀은 작업의 진척도를 추적하고 조정할 수 있다.

• 이외에도 Jira는 자동화 및 통합 기능, 보고서 및 분석 도구, 워크플로우 커스터마이징 기능을 제공하여 애자일 환경에서 특히 유용한 협업 툴로 사용되고 있다.

Notion

• 노트 작성, 데이터베이스 관리, 프로젝트 계획, 일정 관리 등 다양한 기능을 한 플랫폼에서 제공하는 올인원 생산성 도구.

• 개인, 팀, 회사 모두 사용 가능하며, 작업을 체계적으로 관리하고 협업할 수 있는 강력한 기능을 제공.

• 사용자는 문서 작성, 태스크 관리, 프로젝트 협업 등을 Notion 안에서 통합하여 관리할 수 있다.

3. Trello, Jira, Notion 비교분석

공통점

• 프로젝트 관리에 특화된 기능을 제공하여, 작업 항목을 체계적으로 구성하고 관리할 수 있다.

• 팀원들이 실시간으로 작업 내용을 업데이트하고 공유할 수 있도록 지원한다.

• 시각적으로 작업 흐름을 관리할 수 있는 기능을 제공한다.

• 태그, 라벨, 우선순위 설정을 통해 작업을 분류하고 중요한 항목을 식별할 수 있다.

• 다양한 외부 서비스와의 통합을 지원하여, 필요한 기능을 추가하거나 타 도구와 연결해 사용할 수 있다.

• 템플릿을 제공하여 사용자들이 빠르게 프로젝트를 시작할 수 있도록 돕는다.

• 사용자 권한 설정 기능을 제공하여, 특정 작업에 접근하거나 수정할 수 있는 팀원을 제한할 수 있다.

차이점

주요 용도

• Trello : 간단한 프로젝트 관리.
• Jira : 애자일 기반 소프트웨어 개발.
• Notion : 올인원 문서/프로젝트 관리.

핵심 특징

• Trello : 칸반 보드 중심의 직관적 인터페이스.
  - 간단하고 사용하기 쉽다.

• Jira : 스크럼/칸반 보드, 버그 및 이슈 추적.
  - 스크럼 방식의 개발팀이라면 가장 추천되는 툴.

• Notion : 문서화, 데이터베이스, 다중 뷰 등의 여러가지 하위 툴을 제공.
  - 올인원 도구로서의 유연한 문서화와 데이터 관리에 특화. 다목적 활용성 그 자체가 특징.
  

비용

• Trello : 무료 플랜은 물론 유료도 큰 부담이 되지 않음.
• Jira : 10명까지 무료, 유료라고 해도 부담이 크지 않다.
• Notion : 규모가 큰 개발팀일 수록 부담되는 금액이 크다.

적합한 팀/프로젝트

• Trello : 마케팅, 개인 및 작은 팀의 프로젝트 관리.
• Jira : 소프트웨어 개발팀.
• Notion : 다양한 데이터 관리가 필요한 팀.

한계

• Trello : 복잡한 워크플로우에서 사용하기 어렵다.
  - 단순한 칸반 방식으로 작업 흐름을 시각화하는 데 최적화되어 있어, 복잡한 상호 의존성이 있는 작업이나 다단계 승인 프로세스가 있는 프로젝트에서는 다소 비효율적.
  - 소프트웨어 개발 프로젝트에서 여러 팀(디자인, 개발, QA, 마케팅 등)이 동시에 참여해야 하고, 각 작업이 팀 간의 승인 절차나 검토 단계를 거쳐야 하는 경우 Trello만으로는 이를 효과적으로 관리하기 어렵다.
  - 벨이나 체크리스트로 간단히 작업을 정리할 수 있지만, 세부적인 권한 설정, 다수의 워크플로우 단계, 팀 간의 승인 절차 관리 등에는 한계가 있다.

• Jira : UI가 복잡하고, 사용 난이도가 높다.
  - 애자일, 스크럼 등의 개념과 사용 경험이 있다면 사용이 쉽지만 그렇지 않다면 사용이 상당히 힘들다.
  - 이슈 추적과 애자일 관리에 특화되어 있지만, 기능이 많아 사용자 인터페이스(UI)가 복잡.
  - 스프린트와 백로그 관리, 이슈 추적, 버그 수정, 워크플로우 설정 등 다양한 기능이 통합되어 있어, 애자일 프로젝트 관리에 익숙하지 않은 팀원들에게는 학습 곡선이 다소 높다.

• Notion : 소프트웨어 개발 과정의 협업 툴로 사용하기에는 기능이 제한적.
  - 문서 관리와 데이터베이스 기능에 강점이 있지만, 개발 프로젝트 관리를 위한 기능이 제한적.
  - 이슈 추적, 버그 관리, 코드 리뷰 등 개발 작업을 체계적으로 관리할 수 있는 기능이 부족.
  - 버전 관리나 스프린트 관리 등의 기능도 제공되지 않기 때문에 소프트웨어 개발팀이 애자일 방식으로 프로젝트를 진행하기는 어렵다.
  

툴 혼용 예시

• Notion은 프로젝트 초기 단계에서 요구 사항 수집과 아이디어 정리, 프로젝트 문서화에 사용. Trello는 Notion에서 정리된 요구 사항과 아이디어를 실제로 시각화하여 관리하는 단계에서 유용하게 활용.

• Notion은 프로젝트 초기 단계에서 요구 사항 수집과 아이디어 정리, 프로젝트 문서화에 사용. Jira는 Notion에서 정리된 요구 사항을 구체적인 개발 작업으로 세분화하고 관리하는 단계에서 유용하게 활용

결론

• 사실 Notion은 프로젝트 개발 관리 툴이라기 보다는 프로젝트 계획 수립이나 요구 사항 정리, 문서화 작업에 적합한 툴이다. 프로젝트 개발 관리가 목적이라면 Jira나 Trello를 사용해야한다.

• 하나만 사용하고 싶다면, 간단한 작업 관리에는 Trello, 소프트웨어 개발에는 Jira, 다양한 데이터를 통합 관리하고 문서화를 병행해야 하는 프로젝트에는 Notion이 유리하다.

• 가장 좋은 방법은 Notion은 문서화 및 데이터베이스 등의 목적으로 사용하고, Trello나 Jira를 병행하는게 좋다.

• 물론 협업 툴이라는 것은 프로젝트의 목적, 팀원들의 사용능력 등에 맞춰 결정해야한다. 어지간한 숙련 개발자가 아니라면 해당 툴의 사용 능력이나 경험이 그렇게 깊지 않거나, 제대로 써보지 않아서 모르겠다 하는 경우가 많기 때문에 대강 훑어보고 이게 좋겠다 하는 식으로 결정하는 것을 피하는게 최선.

4. 애자일 프로젝트 관리의 필수 구성 요소

• 애자일에 대한 기본 개념은 이전 포스팅 참조.

로드맵 설정 -> 프로적트 백로그 작성 -> 릴리즈 플래닝 구성 -> 스프린트 계획 수립 -> 스프린트 진행 -> 스프린트 리뷰 및 회고 -> 다음 스프린트 진행 -> 모든 스프린트 완료 후 릴리즈

• 애자일 개발 방법론으로 프로젝트를 개발한다고 하면 대략 위와 같은 과정을 거쳐 구현된다.

1. 로드맵 (Roadmap)

• 개념: 프로젝트의 큰 방향을 잡고 목표와 주요 마일스톤(Milestones, 이정표)을 설정하는 단계.

• 목적: 팀이 전체 프로젝트의 비전과 주요 이정표를 공유하고, 목표를 설정하며 장기적인 진행 방향을 계획.

• 주요 요소: 프로젝트 목표, 주요 단계 및 이정표, 타임라인, 피드백 반영 등이 포함.

• 역할: 팀원 간 목표 공유, 효율적인 자원 배분, 진척 상황 확인, 피드백 반영 등을 지원.

• Trello, Jira, Notion 모두 로드맵 제작에 유용하게 사용할 수 있다.

• 그 중에서도 Notion의 경우 문서화 특화 툴답게 아예 다수의 로드맵 템플릿들을 제공해주고 있으니 편하게 골라서 사용하면 된다. (무료/유료 구분을 잘 해둘 것.)

2. 프로덕트 백로그 (Product Backlog)

• 개념: 프로젝트의 모든 요구 사항, 작업 항목, 기능 등을 모아 놓은 목록.

• 목적: 프로젝트의 진행 방향과 작업의 우선순위를 관리하여 팀이 단계적으로 작업을 수행할 수 있게 한다.

• 구성 요소: 사용자 스토리, 기능, 버그, 기술적 작업 및 개선 사항, 우선순위, 추정 시간 등이 포함.

• 역할: 프로덕트 오너가 우선순위를 정리하여 팀이 단계적으로 우선순위가 높은 작업부터 수행하도록 한다.

• Jira는 각 이슈를 카드 형식으로 관리하며, 스크럼과 칸반 보드에서 백로그 항목을 쉽게 이동하고, 스프린트 계획에 포함시킬 수 있다.
• Trello: 각 카드가 백로그 항목이 되어 칸반 보드에서 우선순위에 따라 이동하며 작업을 관리할 수 있다.
• Notion: 데이터베이스 기능을 사용하면 각 작업 항목에 세부 정보, 우선순위, 작업량 등을 설정하고, 팀이 손쉽게 접근하여 업데이트할 수 있다.

3. 릴리즈 플래닝 (Release Planning)

• 개념: 제품의 주요 기능이나 새로운 버전을 출시하기 위한 계획을 세우는 과정.

• 목적: 릴리즈할 기능과 작업 항목을 결정하고, 일정과 릴리즈 시점을 설정하여 목표를 명확히 한다.

• 작업 순서 예시
  - 릴리즈 목표 설정.
  - 프로덕트 백로그 검토.
  - 릴리즈 항목 우선순위 설정.
  - 작업 분량과 일정 추정.
  - 스프린트 계획 수립.
  - 릴리즈 리스크 평가 및 대응 전략 수립.
  - 릴리즈 플랜 공유 및 승인.
  - 릴리즈 작업 시작 및 스프린트 진행.

• 역할: 정해진 릴리즈 시점에 맞춰 팀이 목표를 공유하고, 각 스프린트에 포함할 주요 기능을 결정하도록 한다.

4. 스프린트 (Sprint)

• 개념: 짧은 기간 동안 수행할 작업을 계획하고 집중해서 완료하는 반복적인 작업 주기입.

• 목적: 일정한 기간 내에 달성 가능한 작업을 완료하여 제품을 점진적으로 발전시키고, 고객 요구에 빠르게 대응할 수 있게 한다.

• 스프린트를 통해 팀은 주어진 시간 내에 명확한 목표를 세우고, 해당 목표를 달성하기 위해 작업을 집중해서 수행
• 너무 짧으면 업무를 수행하기 어렵고, 너무 길면 목표에 집중하기 어렵다. 목표에 맞춰 1에서 4주 사이 정도로 지정.
• 달성해야하는 구체적인 목표, 한 스프린트 주기에 완료 가능한 작업 단위로 나뉜다.

5. 스프린트 플래닝 (Sprint Planning)

• 개념: 스프린트를 시작하기 전에, 해당 스프린트에서 수행할 작업을 구체적으로 계획하는 과정입니다.

• 목적: 스프린트 동안 수행할 작업을 명확히 하고, 각 작업의 목표와 완료 기준을 설정합니다.

• 방법 예시
  - 스프린트 동안 수행할 작업을 백로그에서 선택.
  - 각 작업 항목의 중요도와 소요 시간, 팀의 역량을 고려해 선택하며, 선택된 작업의 목표를 설정.
  - 스프린트가 시작되면 모든 팀원이 설정된 작업에 집중. 도중에 목표가 변경되어서는 안됨.
  - 이후 스프린트 리뷰. 이번 스프린트에서 수행한 작업을 점검하고, 팀이나 이해관계자들과 공유.
  - 또한, 스프린트 회고(Retrospective)를 통해 스프린트 동안의 작업 방식이나 협업 방식을 되돌아보고 개선할 부분을 파악.
  - 스프린트를 반복하면서 제품을 점진적으로 발전시키며, 매 스프린트마다 팀은 추가된 기능이나 개선 사항을 완료된 형태로 출시할 준비를 마침.
  - 이를 통해 점진적으로 제품을 개선하며, 변경 사항에 유연하게 대응할 수 있다.

6. 백로그 (Backlog)

• 개념: 스프린트 백로그와 프로덕트 백로그가 포함된 프로젝트의 모든 작업 항목 목록.

• 목적: 팀이 앞으로 수행할 작업 항목을 체계적으로 관리하고, 우선순위에 따라 작업이 진행되도록 한다.

• 구성 요소
  - 프로덕트 백로그: 프로젝트 전체의 기능, 요구 사항, 버그 등을 포함.
  - 스프린트 백로그: 스프린트 동안 수행할 작업만을 따로 정리한 목록.

• 방법 예시
  - 정기적으로 백로그를 검토(백로그 그루밍)하고, 필요 없는 작업을 제거하거나 새로운 작업을 추가.
  - 우선순위를 높게 설정한 작업부터 스프린트에 포함시켜 작업.

7. 테스크 보드 (Task Board)

• 개념: 프로젝트의 각 작업 항목을 시각적으로 관리하고, 작업의 진행 상황을 한눈에 볼 수 있도록 돕는 도구.

• 목적: 각 작업의 진행 상태를 쉽게 파악하여 팀원 간의 소통과 작업 진행을 원활히 한다.

• 구성 요소
  - 프로덕트 백로그: 프로젝트 전체의 기능, 요구 사항, 버그 등을 포함.
  - 스프린트 백로그: 스프린트 동안 수행할 작업만을 따로 정리한 목록.
  

• 방법 예시
  - 일반적으로 칸반 보드 형식으로 구성되며, "할 일(To Do)", "진행 중(In Progress)", "완료(Done)" 등의 열로 구분.
  - 각 작업 항목을 카드 형태로 추가하고, 상태에 따라 열을 이동시킴으로써 진행 상황을 관리.
  - 작업 중인 항목을 시각적으로 확인할 수 있어 팀원들 간의 투명한 진행 관리가 가능.

• 역할: 작업 상태를 시각적으로 파악하고, 팀원 간의 투명한 진행 관리를 가능하게 한다.

5. 용어 설명

스크럼 (Scrum)

• 소프트웨어 개발과 같은 프로젝트에서 애자일(Agile) 방법론을 실현하기 위한 대표적인 프레임워크.

• 스크럼은 프로젝트를 작은 반복 주기로 나누고, 팀원들이 자율적으로 작업을 관리하여 빠르게 변화하는 요구 사항에 유연하게 대응하는 것을 목표로 한다.

• 스프린트(Sprint), 스크럼 팀, 프로덕트 백로그(Product Backlog), 스프린트 백로그(Sprint Backlog), 스탠드업 미팅 (Daily Stand-up), 스프린트 리뷰(Sprint Review)와 회고(Sprint Retrospective) 등을 핵심 개념으로 포함하고 있다.

• 유연한 대응, 자율성과 협업, 투명성, 지속적인 개선의 장점을 갖는다.

• 예를 들어, 로그인 기능을 포함한 사용자 인증 시스템을 개발한다고 가정해보자. 프로덕트 오너는 사용자 로그인, 비밀번호 복구, 계정 설정 기능 등을 백로그에 추가하고, 우선순위에 따라 다음 스프린트에 로그인 기능 구현을 목표로 정할 수 있다. 개발 팀은 로그인 기능을 스프린트 동안 구현하고, 스프린트가 끝난 후 스프린트 리뷰에서 결과를 검토하고, 회고를 통해 문제점을 개선해 나가는 식이 스크럼의 사용 예시이다.

유저 스토리(User Story)

• 소프트웨어 개발 프로젝트에서 사용자의 관점에서 요구 사항을 간단하게 설명하는 문구.

• 애자일(Agile) 방식에서 주로 사용되며, 사용자 스토리는 개발팀이 어떤 기능을 구현해야 하는지 명확하게 이해하도록 돕는 역할을 수행.

"사용자로서, "무엇을 원하는지", "왜 필요한지""

"사용자로서, 비밀번호를 재설정할 수 있기를 원해요, 계정에 접근할 수 없을 때 이를 복구하기 위해서요."

• 누가 (사용자 또는 역할), 무엇을 (구현할 기능 또는 작업), 왜 (기능의 목적 또는 이유)의 3가지 요소를 포함해야 한다.

• 유저 스토리는 작성된 이후, 개발팀이 구현할 작업 단위로 세분화되고 우선순위에 따라 프로덕트 백로그에 추가된다. 이후, 각 유저 스토리를 완료하기 위한 구체적인 작업들이 스프린트 백로그로 이동하여 개발이 진행하는데 사용된다.

• 사용자 중심의 개발을 가능하게 하여, 개발팀이 실제 사용자 요구를 반영하는 데 집중할 수 있다. 단순하고 명확한 형식으로 요구 사항을 전달하여 개발 속도를 높이고, 의사소통 비용을 줄일 수 있다. 작업의 우선순위를 쉽게 파악할 수 있어, 팀이 가장 중요한 기능부터 집중하여 작업할 수 있다.

유저 스토리를 사용하여 개발이 진행되는 과정 예시

• 온라인 쇼핑몰에서 "사용자가 상품을 장바구니에 추가할 수 있는 기능"을 구현하려고 할 때라고 가정해보자.

1. 유저 스토리 작성

"사용자로서, 상품을 장바구니에 추가할 수 있기를 원해요, 필요한 상품을 나중에 한번에 결제하기 위해서요."

2. 유저 스토리 세분화

• 유저 스토리를 기반으로 이 기능을 구현하기 위해 필요한 구체적인 작업 단위를 나눕니다. 이 과정에서 구현 세부 사항이나 기술적 작업을 정의한다.

3. 구체적인 작업 단위

• UI 설계: 장바구니 버튼의 디자인과 위치를 결정하고, 사용자 경험을 고려해 UI 설계를 진행합니다.
• 장바구니 데이터베이스 설계: 장바구니에 추가된 상품 정보를 저장하는 데이터베이스 구조를 설계합니다.
• 장바구니에 상품 추가 기능 구현: 사용자가 버튼을 클릭하면 해당 상품이 장바구니에 저장되도록 기능을 구현합니다.
• 장바구니 페이지 구현: 장바구니에 담긴 상품을 확인하고, 수량 변경이나 삭제 등을 할 수 있는 장바구니 페이지를 개발합니다.
• 테스트 작성: 장바구니 기능이 제대로 작동하는지 확인하기 위한 테스트 코드를 작성합니다.

4. 프로덕트 백로그에 추가

• 각 세분화된 작업 단위는 프로덕트 백로그(Product Backlog)에 추가됩니다. 프로덕트 오너는 각 작업의 우선순위를 설정하여 팀이 어떤 작업을 먼저 처리할지 결정한다.

• 프로덕트 오너는 "장바구니에 상품 추가 기능 구현"을 가장 높은 우선순위로 설정
• 다음으로는 "장바구니 페이지 구현"과 "테스트 작성"을 높은 우선순위로 설정하고, UI 설계와 데이터베이스 설계 작업을 나중에 수행할 수 있도록 우선순위를 조정한다.

5. 스프린트 백로그로 이동 및 스프린트 진행

• 스프린트 플래닝 회의에서 팀은 다음 스프린트에 수행할 작업을 스프린트 백로그(Sprint Backlog)에 옮긴다.

• 예를 들어, 2주간의 스프린트 동안 다음과 같은 작업들을 완료하기로 합니다:
  - 장바구니에 상품 추가 기능 구현
  - 장바구니 페이지 구현
  - 테스트 작성

• 이후, 팀은 스프린트를 진행하며 매일 스탠드업 미팅을 통해 작업 상황을 공유하고, 스프린트가 끝날 때까지 작업을 완료하도록 집중한다.

6. 스프린트 리뷰 및 회고

• 스프린트가 끝나면 팀은 스프린트 리뷰를 통해 작업 결과를 검토하고, 이해관계자들과 공유한다.
  - 리뷰에서 장바구니 기능이 잘 구현되었는지 검토하고, 필요한 피드백을 반영한다.
  - 회고에서 작업 방식을 돌아보고, 개선할 점이 있는지 논의한다.

회고

• KPT, PMI, 4Ls, DAKI의 4가지 방법론

• KPT: 계속할 것(Keep), 문제점(Problem), 새로 시도할 것(Try)을 찾음.

• PMI: 긍정적(Plus), 부정적(Minus), 흥미로운 점(Interesting)을 통해 분석.

• 4Ls: 좋았던 점(Liked), 배운 점(Learned), 부족했던 점(Lacked), 필요했던 점(Longed For)을 되돌아봄.

• DAKI: 버릴 것(Drop), 추가할 것(Add), 유지할 것(Keep), 개선할 것(Improve)을 결정

KPT (Keep, Problem, Try)

• 팀이 계속 유지할 부분, 개선해야 할 문제점, 새로 시도해볼 방법을 찾는 방식
  • 구성 요소:
  • Keep: 잘된 점이나 효과가 있었던 부분을 식별하여 앞으로도 계속 유지
  • Problem: 문제점이나 개선이 필요한 부분을 파악
  • Try: 앞으로 시도해볼 새로운 아이디어나 실험할 개선점을 제안
    • 예시
    • Keep: "매일 짧은 스탠드업 미팅을 진행하여 의사소통이 원활해짐."
    • Problem: "QA 과정에서 시간이 많이 소요됨."
    • Try: "QA 절차를 간소화하거나 자동화 도구를 도입해보기."

PMI (Plus, Minus, Interesting)

• 긍정적 측면, 부정적 측면, 흥미로운 관점을 분석하여 팀이 학습할 점을 찾는 방법.
  • 구성 요소:
  • Plus (긍정적인 점): 성공적이었던 부분, 효과가 있었던 부분을 기록.
  • Minus (부정적인 점): 아쉬웠던 점이나 예상대로 되지 않은 부분을 기록.
  • Interesting (흥미로운 점): 새롭거나 흥미로운 점, 또는 학습할 점을 기록.
    • 사용 예시:
    • Plus: "팀원 간 협업이 원활하게 이루어짐."
    • Minus: "기술적 부채가 쌓여 작업 속도가 늦어짐."
    • Interesting: "새로운 툴을 시도했는데 일정 부분 효율성을 높임."

4Ls (Liked, Learned, Lacked, Longed For)

• 팀의 작업에서 좋았던 점과 부족했던 점, 배운 점, 원했던 것을 찾아 회고.
  • 구성 요소:
  • Liked (좋았던 점): 효과적이거나 좋았던 부분을 공유.
  • Learned (배운 점): 프로젝트를 통해 새롭게 배운 점을 기록.
  • Lacked (부족했던 점): 아쉬운 점이나 부족했던 부분을 확인.
  • Longed For (원했던 점): 있었으면 좋았을 부분이나 추가적인 필요 사항을 제안.
    • 사용 예시:
    • Liked: "팀의 적극적인 피드백 공유 문화."
    • Learned: "새로운 애자일 기법을 통해 프로젝트 속도가 빨라짐."
    • Lacked: "적절한 테스트 리소스가 부족해 테스트 시간이 지연됨."
    • Longed For: "자동화된 테스트 환경이 있었으면 좋겠음."

DAKI (Drop, Add, Keep, Improve)

• 팀의 작업 방식을 개선하기 위해 무엇을 유지하고, 개선하거나 추가할지, 버릴지를 결정.
  • 구성 요소:
  • Drop: 불필요하거나 비효율적인 부분을 버림.
  • Add: 새로운 요소나 개선 사항을 추가.
  • Keep: 잘되고 있는 부분을 유지.
  • Improve: 개선이 필요한 점을 식별.
    • 사용 예시:
    • Drop: "중복된 회의 일정."
    • Add: "새로운 코드 리뷰 프로세스 도입."
    • Keep: "현재 사용 중인 작업 관리 툴."
    • Improve: "프로젝트 초기의 요구사항 분석 방법."