TIL 2023.06.02

프로젝트 매니지먼트 세션

 

리더 부리더 정하셨을 것이고

팀 배정이 되면 팀장도 다 정하실 거 잖아요

리더 역할을 하게 될 것 같다 생각하시면 더더욱 잘 들어 주세요

 

시간이 빠르죠 여러분들 개강하고 얼마 안돼서 학습법 특강하려고 들어왔던게 얼마 되지 않은 것 같은데 벌써 최종 프로젝트

 

커리큘럼매니저 이전에 1기 수료생

제가 요거는 제가 수강생일 때 했던 것들도 있고 지나고 나서 아 이런것들을 알았으면 좀 더 도움이 되었겠다 하는게 섞여 있다.

 

준비

진행

마무리

 

툴이나 템플릿을 적재적소에 사용하자

우리는 백엔드 개발자가 될 것이기에 백엔드에 집중하자

 

프로젝트 S.A. 작성

공통적으로는 프로젝트 소개, 소개하는 도중에 어떻게 기획하게 되었고 그 배경

서비시를 어떻게 구성했고 기능은 어떻게 구성되어 있는지

이런 것들 세세하게 쓸 필요 없었지만 이런 것들 잘 작성을 해주시면 좋고

역할 분담

DB 테이블

와이어 프레임

아키텍쳐

 

여기서 중요한 게 역할 분담에 대해 말씀 드리고 싶은 게

이런 게 있다.

조금 잘 하시는 분들은 이런 말씀들을 많이 하세요

내가 내 역할을 다 하면 뭐하냐 다른 사람이 역할 다 하지 못하면 어떻게 해야할 지 모르겠다. 이 사람을 과외를 해서 완성을 시켜야하냐, 아니면 내가 실력이 부족해서 팀에 기여를 못할까봐 고민을 하시는 분들이 계신다

 

처음 S.A. 작성하실 때 합의를 미리 해 놓는 게 좋다.

누가 못 했을 때 누가 대신 하겠다.

crud를 하겠다. 회원관리 쪽을 하겠다. 최선을 다 해서 할 텐데 못 하면 누가 이어 받아서 할 건지 합의를

회사에서도 어떤 일을 할 때 주어진 기간에 맞춰서 일을 해야 하죠. 그걸 못 했을 때 그 일을 다른 사람이 넘겨 받아서 하게 되어있다. 그래서 그런 것들을 미리 합의를 하는 게 중요하다.

 

한 가지 더,

스파르타 크래프톤 카이스트 같이 해서 정글이라는 부트캠프 있는 거 아시나요?

정글에서는 장병규 의장님이라고 크래프톤 의장님께서 멘토로 코멘트를 해주시는데 어떤 시간이 있냐면 수강생들이 사전질문을 남기면 장의장님이 코멘트를 달아 주는 시간이 있다.

어떤 분이 나는 사실 실력이 아무리 노력해도 늘지 않아서 팀에 기여를 못할까봐 걱정된다고 글을 남겨 주셨는데, 장의장님은 기여는 기능을 만드는 것만으로 기여가 되는 게 아니다. 라고 남겨 주셨다. 내가 문서 작업을 잘한다면 피그마를 잘 한다면 자료를 잘 수집한다면 툴을 잘 다룬다면 노션 erd 그런 것들을 더 맡아서 하는 것도 팀에 기여가 될 수 있다.

 

빠른 개발을 위한 팁

S.A. 작성 시에 필요한 내용을 순서에 맞춰 빠르게 정한다.

1. 프로젝트 기획
2. 필수 기능, 부가 기능 (우선 순위)
3. 역할 분담
4. 개발 일정
5. ERD 작성 
6. repo 만들고 브랜치 어떻게 나눌 지 정하기
7. 와이어프레임 

위를 토대로 S.A. 작성을 빠르게 끝내고 초안을 튜터님에게 검토 요청 드린다.

피드백을 반영하여 S.A. 완성 후 제출하고 바로 개발에 들어간다.

erd 노션 와이어프레임 이런 거 다 같이 하지 말고 erd 두 명 와이어프레임 한 명 이렇게 잘 하는 사람이 맡아서 하는 게 좋다. 그 후 내부 검토

이 작업을 보통 3 일 정도. 

다 같이 이야기해야하는 부분은 다 같이 하되, 나눠서 할 수 있는 건 나눠서 하고 검토

 

S.A. 작성시 활용하면 좋은 툴

노션이죠

피그마 활용할 수 있으면 피그마도 좋다

구글 스프레드 시트 갤러리(갠트 차트)

깃허브 리드미

moqup 와이어프레임 템플릿

ERDCloud

 

커밋 메세지 컨벤션을 만들자

우리 팀만의 커밋 메세지 컨벤션

[추가] [수정] [변경] [add] [modify] [fix] 등

말머리 뒤에는 핵심 내용만 간결하게

[add] 로그인, 회원 가입 추가

[fix] 소셜 로그인 오류 수정

 

브랜치는 어떻게 관리?

밀반적으로 main - dev - 기능별 branch 로 나눈다

• 너무 많다면 main - dev - 개인별 branch

브랜치를 상위 브랜치로 병합 완료 했다면 해당 브랜치는 반드시 삭제

일반적으로 dev 브랜치를 메인 브랜치 처럼 생가갛고 병합한 뒤 최정 병함만 메인 브랜치에 해주시면 됩니다 그 전까진 메인 건질지 맙시다

 

 

프론트에 고통 받는 여러분들을 위하여

https://youtu.be/s8CdkSRnU1k

• 컬러 파레트 만들기
  3가지 색( 많으면 5 🍆) 흰색 회색 포인트 말라
  버튼, 강조할 글자, 로고, 아이콘 정도 포인트
• 여백 적절히
• 폰트는 타이틀, 본문 두 가지만
  산세리프(고딕체) 한 가지만 해도 됨
• 폰트 강조하고 싶으면 그라데이션
• 폰트는 안중요한 건 작게, 회색으로
  자간 조절
  이미지는 width만 조절
• 사진 위에 흰글씨 넣으면 굳
  사진 너무 밝으면 밝기 조절 css
• 디자인 레퍼런스 참고

 

아이콘

flaticon 무료 로고, 아이콘 만들어 주는 사이트 png로 받는 게 좋다

m3.material.io

 

폰트

dafont.com 영문폰트

noonnu.cc 웹 폰트로 쓸 수 있는 폰트도 있다

구글 폰트

 

부트스트랩, 테일윈드 적극 사용 권장

 

 

발표

미리캔버스

canva.com 무료 템플릿

협력사도 보기 때문에 대충 노션 켜 놓고 하는 것 보단 좀 잘 하는 게 낫겠지

 

 

프로젝트 회고

 

KPT

jamboard.google.com k p t 만들고 메모지로 한 사람 당 두 개 씩

 

코드 리뷰

주석 처리를 잘하자

코드 리뷰는 보통 프로젝트 진행 중에 핵심 기능 PR 전이나 브랜치 병합 전 진행

물론 프로젝트 중간에 코드 리뷰를 하면 매우 좋지만 여유가 안될 때는 회고 후에 꼭 하고 넘어갑시다!

회고를 위한 코드 리뷰의 목적

• 본인이 맡은 부분을 제외하고 제대로 알고 지나가기 어려움
• 설명하면서 부족한 부분 파악 -> 보충 학습할 부분 파악 가능

 

유지보수

회사에서 유의미한 프로젝트를 판단하는 기준

• 만들고 끝인 토이 프로젝트는 무의미하게 생각함
• 운영 경험 또는 유지 보수 개선 경험을 중요하게 생각

이런 것들을 해보세요

• 코드 리뷰를 통해 개선할 점을 파악하고 추가로 구현해보기
• 완성하지 못한 부분을 끝까지 구현해보기
• 그 밖에 추가로 넣고 싶었던 기능 구현해보기
• > 그리고 이런 것들을 했다면 반드시 깃허브 이슈에 기록을 남겨주세요

 

 

끝으로

협업의 중요석

모든 일은 혼자 할 수 없습니다. 어떤 회사에서도 협업이 어려운 개발자는 원하지 않습니다. 프리랜서로 활동할 지라도 협업해야 합니다.(오히려 프리랜서가 소통을 더 잘해야 함)

이 사람이 어떤 협업을 했고 협업하는 과정에 어떤 일이 있었고 그래서 어떻게 성장했고 다른 사람에게 어떤 영향을 줬는 지가 중요

옳은 말을 예쁘게 할 때 당해낼 사람은 없습니다