김민태 개발자 멘토님 피드백 내용 정리
Closed this issue · 7 comments
nakyeonko3 commented
- 팀원 모두 김민태 개발자 멘토님 피드백 내용 각자 생각나는 대로 적어 보기
- 피드백 내용 정리해서 slack 스레드에 올리기
dhkim511 commented
일 별로 이슈를 검토하고 관리하면 프로젝트를 보다 더 역동적으로 진행할 수 있다.
어느 접근 방식이 더 좋은지 그런 부분이 중요한게 아니라 다른 방식으로 접근했을 때 나올 수 있는 장단점을 알아보고 생각하는 과정이 중요하다라고 하셨습니다
BES9507 commented
마크다운 문법을 통해서 유저플로우,다이어그램을 만들어보면서 마크다운 문법에 조금이라도 익숙해지기를 바란다고 하셨습니다. 마크다운 문법의 중요성을 알려주셨습니다.
티켓을 만들때 3주짜리 긴 티켓보다 기간이 짧은 티켓으로 팀원들에게 내가 무슨일을 어느만큼 진행했는지 서로 공유 할수 있게끔 하는것이 좋은 티켓이라고 하셨습니다.
nakyeonko3 commented
김민태 개발자 멘토님의 피드백 내용정리
온보딩 프로젝트의 의도
- 비개발자가 작성한 기획서를 개발자에 맞게 바꾸는 과정이 항상 필요함
- 고객의 요구사항의 정확하게 파악하는 것이 필요함.
요구사항을 제대로 파악하지 않은 탓에 요구사항이 변형되서 프로젝트 진행중 차질이 생기는 경우가 생기기도 함
- 요구사항이 하나하나가 매우 크다면 역할 분담이 이루어지도록 작게 쪼개는 것이 필요함 -> 온보딩 프로젝트 이슈 작성하는 이유임.
- 중요! 개발자는 글쓰기가 중요하다: 일의 생산성이 오르고, 글쓰기 능력이 취직후 승진과도 관련되어 있음
- 항상 일에 납득할만한 근거가 필요하다: 예시) 마크다운을 사용하는 것이 좋다. 근거로는 github readme 작성, noiton 작성할 때 편함. 문서 정리가 쉽다.
중요! 깃허브 이슈를 이용해서 TODO 관리하기
- 일의 크기에 맞게 프로젝트의 크기에 맞게 이슈 크기 정하기
- 이슈에 대한 룰 정하기
- 하나의 이슈로 만들만큼 일을 구체화 하고 담당자 정하기 -> 이를 통해 일을 역할분담을 통해 일을 병렬적으로 수행할 수 있음
- 모두가 해야되는 이슈: 구체화되지 않고 힘든 일들임.
- 담당자가 정해진 이슈: 구체화 되고 몇명이 담당할 수 있는 일임
Mearmaid를 figma 보다 추천하는 이유
- 마크 다운 문법에 적용 되는 곳(notion, github readme) 등에 쉽게 내용을 작성할 수 있음
- git을 이용한 형상관리가 가능함
- 많이 쓰이고 표준적인 다이어그램툴임. 나중에 프로젝트나 실무를 할 때도 도움될 가능성이 높음.
그외 피드백
- Mermaid | Diagramming and charting tool 를 사용해서 다이어그램, 유저플로우, 컴포넌트 다이어그램들을 그려 보기
- 프로젝트를 이용해서 어떤 툴들을 사용하는 것이 좋을 지 생각 해보기
- 질문에 대한 기준을 정하는 연습. 항상 일에 대한 완성 기준, 기준을 정하는 일을 해보기
앞으로 어떻게 할 것인가
- Mermaid를 이용해서 유저 플로우 다이어그램 작성 해보기
- 지금 당장 이슈를 통해 TODO 1,2개 만들기
HSjjs98 commented
- onBoarding project가 가지는 의미
- 프로젝트를 실제로 구현하는 것이 아니기 때문에 구현 가능성 또는 기능에 크게 집착하지 않고 팀원들과 함께 어떤 서비스를 제공하고 싶은지, 서비스를 구조적으로 어떻게 설계하면 좋을지, 사용자가 어떤 flow로 서비스를 사용하게 될지 고민하고 해결해나가는 과정이 중요하다.
- team project 에서의 역할 분담
- 해야 되는 일이 있을 때 특정 인원이 책임지고 맡아서 하는 것이 좋은 것일까 아니면 다 같이 하는 것이 좋은 것일까?
일의 특성에 따라 다르다. 밥을 하는 것과 같이 누가해도 비슷한 결과물이 나올 일은 특정 인원이 맡아서 하는 것이 좋다. 반면 누가 하느냐에 따라 완전히 다른 결과물이 나올 수 있는 일은 다같이 하는 것이 좋다.
- github issue를 통한 일정 관리
- github isuue를 통한 일정 관리의 핵심은 누가 어떤 일을 하고 있는지 명확하게 알 수 있는가 이다. Project 진행에 있어서 issue를 작게 나누지 않고 크게 덩어리로 나눈다고 생각해보자. 각 팀원이 한달이 걸릴만한 issue를 해결하는 중이라고 하면 외부에서 봤을 때 프로젝트 진행이 불투명하게 보일 수 밖에 없고 내부적으로도 돌발상황 발생 시 관리하기 매우 어려워진다. 여러 개의 작은 issue로 큰 project를 나눠서 각 팀원이 진행하게 된다면 누가 어떤 issue를 해결하고 있는지 바로바로 알 수 있게 되고 이것이 일정관리의 핵심이다.
- 선택에 대한 근거
- 개발함에 있어서 좋은 것들을 다 사용할 수는 없다. 각 선택지마다의 장점과 단점이 있고 개발자는 그 선택지 중 하나를 선택해야 한다. 다만 선택함에 있어서 반드시 근거가 있어야 하고 타당한 근거가 뒷받침된 선택은 옳은 선택이다.
nakyeonko3 commented
피드백 내용 정리중
nakyeonko3 commented
이슈 완료