11.04 회의록

오늘의 코어 타임

15:30 ~ 18:00

1. 금주 목표 설정 (함께)
2. 모듈 나누기 (함께)
3. 태스크 리스트 업 (석영님은 프로젝트 세팅, 나머지 진행)
4. 팀 나누기 및 개발 시작 (화요일부터 개발 시작)

---

Task 문서화 방법

논의할 부분

1. 제목 형식
2. 작업 단위 분할
3. 내용

---

의견

지혜

할 일 작성 (설계 / 로직 / 화면)

Story: 사용자는 주변 유저를 확인할 수 있다.
Task 1: Multipeer Connectivity를 통한 근거리 탐색
- Session 구현
- 근거리 유저를 초대하는 연결 버튼 구현
- ...
Task 2: 연결 수락 / 취소 로직 구현
- Alert 구현
- advertising / browsing 로직 구현
...

건우

Task는 할 일 을 의미하므로 해당 Story를 위해 우리가 무엇을 구현해야 하는지 작성하는게 좋지 않을까
스토리를 완료하기 위한 구체적인 활동
커밋을 해야 하는 단위
“Task is what is valuable to the team”, “Stepping stones to take the story to ‘Done’.”

1. [무엇] 구현하기 → 최대한 자세하고 잘게 쪼갤 수록 좋다
2. 스토리를 구현하기 위한 할 일에 따른 작업 단위
3. Task 안의 내용이 필요할까? 안의 내용이라 하면 Task보다 작은 단위를 따로 만드는 건가? 그냥 task를 잘게 쪼개면 되는거 아닌가? 요한 기술적 결정 (예를들어, VC 이름 등은 ADR에서 결정하는게 맞지 않을까?)

💡 유저는 주변에 어떤 유저가 있는지 확인할 수 있다

Task: 상단 네비게이션 바 구현하기
Task: 사용자를 의미하는 원형 도형? 구현하기
Task: 사용자 주변의 원형 실선? 구현하기
Task: 연결 가능한 다른 사용자를 사용자 주변 실선 위에 표시하기
Task: MCF를 사용한 P2PSocketInteractProvider 구현하기
Task: Browser, Advertiser를 묶는 SocketProvider 구현하기
Task: UI와 SocketProvider를 연결하는 ViewModel 구현하기

💡 유저는 주변에 유저를 성택해 Peer를 초대할 수 있다

Task: 다른 사용자를 선택 시 연결 요청

Task: 연결 요청 시 요청 및 대기 팝업

Task: 연결 상태 관리

석영

저는 Task는 우선, PR단위로 적어야 할꺼 같습니다.
Task 내부에 필요한 상황은 상세 설명의 형태로 추가 조건,
Task는 PR단위가 되어야 하지 않을까? (이슈에 연결 시킬꺼기 때문에)

• Task는 다음과 같은 항목으로 구현

💡 유저는 주변 유저를 검색할 수 있다.

Task: 주변 유저를 보여주는 화면을 구현한다. 
- 인수 조건: UI여서 Task는 필요없을 듯

💡 유저는 주변 유저를 검색할 수 있다.

Task: 주변 유저를 보여주는 기능을 구현한다.

- 상세1: Repository에 주변 유저를 보여주는 기능을 구현한다.
- 상세2: Browsing을 키고 끌 수 있는 기능을 추가한다.
- 상세2: Advertising을 키고 끌 수 있는 기능을 추가한다.

- 인수 조건: 그룹에 참여된 유저는 보여주지 않는다.
- 인수 조건: Advertising이 꺼진 상태에서 검색이 되지 않아야 한다.

윤회

태스크의 제목은 스토리를 충족시키기 위해 개발(혹은 작업)해야하는 내용을 기술합니다.

💡 Story: 유저는 주변에 어떤 유저가 있는지 확인할 수 있다.

a: 초대를 보낸 사람, b: 초대를 받는 사람

task1: 유저와 주변 유저를 보여주는 뷰를 구현한다.

task2: 연결된 유저 목록을 표시하는 뷰를 구현한다.

task3: a가 초대 수락을 기다리는 동안 alert을 띄우고, 대기하는 기능을 구현한다.

task4: b가 초대 수락을 결정하기 위한 alert을 띄우고, 수락을 결정하는 기능을 구현한다.

task5: MCborwser를 사용해 주변 유저를 탐색하는 기능을 구현한다.

💡 task1: 유저와 주변 유저를 보여주는 뷰를 구현한다.

기능성
- a외의 유저를 터치하면 초대 수락을 기다리는 동안 동안 다른 기능을 수행할 수 없어야 한다.
- a외의 유저의 위치는 랜덤이다.
- a는 항상 가운데에 위치해야 한다.

신뢰성
- a외의 유저가 advertise하지 않고 있으면, 해당 유저를 보여주지 않아야 한다.

사용성
- 

효율성
- 

사용자 그룹
-모든 유저

---

결론

1. Task는 Issue와 연결될 PR 단위를 기준으로 한다.
2. Task의 세부 내용은 완료하기 위한 필요 조건을 기준으로 하되, 상세하게 구분한다.
3. Task 완료를 위한 Commit은 자유롭게 한다.
4. 스토리의 기능 Task와 화면 Task를 분리하여 우선순위

---

금주 목표 설정

• Epic 1 + 2 우선순위(상) 구현
• 모듈화, 프로젝트 생성
• 매일 위키만 업데이트 → 목요일은 README 업데이트
• 모듈화