개발 스터디 'TimCookie' 저장소 정리 전 백업_23.07.11
발단
유데미x웅진x스나이퍼팩토리의 프로젝트 부트캠프의 최종 프로젝트에서 결과적으로 팀장을 맡게 되었다..
멋사 리액트 최종 프로젝트 때처럼 능력자 한명이 멋지고 편한 템플릿을 가져와 그대로 쓸 수 있으면 좋았겠으나,
아쉽게도 깃 플로우나 깃헙 플로우로 프로젝트를 세팅할 수 있는 인원이 없는것 같았다.
사실상 취업 직전 마지막 프로젝트로 생각하고 있는 만큼 이번만큼은 제대로 된 이해를 가지고 프로젝트를 이끌고 싶었다.
그래서 오래 전 멋사 프론트엔드 스쿨 4기 당시 바닐라JS 이전 진행되었던 프로젝트 특강의 녹화본 부터 시작해 보고자 한다.
오늘 개발 공부를 안해서 잔디가 안 심어졌다..
특강의 내용을 바탕으로 하지만 철저히 주관적인 해석과 정리 방식이기 때문에 읽으면서 주의가 필요합니다.
23.01.27 21:00 프로젝트 특강
야무쌤 파트
목차
- 프로젝트 오버뷰
- 스크럼 프레임 워크
- 프로젝트 관리
- 발표
- 프로젝트를 튼튼히 하는 법
1. 프로젝트 오버뷰
- 공동/개인 목표
- 프로젝트 목표
- 프로젝트 관리
- 그라운드 규칙
- 트러블 슈팅
- 효과적 발표
공동/개인 목표
- 프로젝트 예행 연습 : 프로젝트는 훈련이 필요한 과정, 당시 지식을 축적만 하던 상황에서 준비하지 않고 리액트 최종 프로젝트를 들어가게 될 때 겉잡을 수 없이 무너지는 것을 방지하기 위한 바닐라JS 프로젝트의 의의.
- 팀 단합과 화합 : 필드 또한 그렇지만, 혼자 하는 작업은 큰 의미가 없음. 팀워크는 중요한 부분.
- 합리적 목표 설정 : 할 수 있는것과 할 수 없는 것을 구분하는 것은 프로젝트의 성패를 결정. 할 수 있는 것에 집중할 것.
- 결과보다 과정 :
어짜피 필드의 실전이 아니면 꼬꼬마 소꿉장난이다. 완벽하게 성공하지 못할것이라면 실패라도 제대로 해라.절대 이렇게 예기 하시진 않았다. - 이슈 해결 경험 : 문제 상황을 마주하는 것은 필연, 문제 해결 능력은 주니어, 시니어를 가리지 않고 필요한 능력
- 기억보단 기록을 : 기억할 수 있는 것은 한계가 있다. 기록하는 습관이 중요하다.
프로젝트 목표
- 요구사항 분석/구현 : 당시의 프로젝트는 기획과 디자인 과정이 없었으나, 기획과 디자인 이전에 클라이언트 혹은 시장의 요구사항 분석은 필요한 과정
- 웹 표준 준수 :
슬비쌤에게 배운것을 기억하자 - 시멘틱 마크업 : 표준 문법에 따른다고 하여 잘 작성된 코드라고 할 수는 없음. 의미있는 구조와 분석과 판단에 따른 합리적인 구조를 만들어야 할 것.
- 웹 접근성 체크리스트 : 23.01.26 21:00 웹 접근성 특강에서 제공된 리스트와 자료들을 활용할 것.
- 검색 엔진 최적화 : SEO는 중대사항, 클라이언트의 클레임이 많은 부분이자, 놓친다면 잘 만든 결과물도 빛을 발하지 못할 수 있음.
- 성능 최적화 : 느린 서비스가 나쁜 서비스는 서비스 품질 저하의 큰 부분 중 하나는 속도
- 코드 품질 관리 : 범쌤의 수업중 끊임없이 교육 받았던 내용
왜 나는 놓쳤을까..
프로젝트 관리
- Git & GitHub : 깃을 통한 팀원 공동의 버전 관리를 해야 하며, 깃헙을 통해 깃을 관리할 수 있음.
- 프로젝트 생성 : 깃헙에서 생성하여 프로젝트 기능을 사용하자, 이것에 대한 내용은 이후 뒤에서.
- 마일스톤/레이블 관리 : 프로젝트에 탑재된 기능들, 뒤쪽에서 다룰 스크럼 프로세스, 프레임 워크에 대한 부분과 맞물리는 개념.
- 위클리 스프린트 계획/리뷰/회고 : 스프린트의 기준은 1주, 1주간의 작업에 대한 계획과 1주간의 결과물에 대한 리뷰, 1주간의 기간에 대한 회고는 필요.
- 데일리 스크럼 작성 : 매일 스크럼은 필요함. 스크럼의 의미와 의의는 뒤에서.
- 이슈/토론 작성 : 각자의 생각과 논의의 축적은 필요한 과정, 이슈와 디스커션 기능의 유용함.
- 위키 작성 : '기억보단 기록을', 기록의 저장소, 깃헙에서 제공하는 기능
그라운드 규칙
팀 공동의 규칙을 통한 질서의 확립, 질서는 단체의 근원적인 힘
- 브랜치 컨벤션 : 깃 활용 전략에 있어서 필수적인 부분, 뒤에서 더 다뤄짐.
- 커밋 컨벤션 : 커밋 메시지는 작업 행적의 추적에 큰 도움을 줌. 공통의 커밋 규칙은 기록을 한 눈에 보이게 함.
- 코딩 컨벤션 : 코딩 스타일을 뜻함. 서재원 멘토님과 범쌤의 수업 중에 녹아 있었음. 일관적인 코드는 프로젝트 완성도의 한 부분.
- 데일리 스크럼 템플릿 : 매일 시행하는 스크럼 안에서 불규칙적인 리듬의 기록이 아닌 일관화된 패턴으로 기록하는 것이 기록의 의미가 있음.
- 이슈/토론 템플릿 : 논의와 사고의 기록의 패턴화, 질서는 중요함. 여러 각자의 목소리를 하나로 모을 수 있는 것이 그라운드 룰의 역할.
일관화된 패턴에서 나오는 한계 또한 그 패턴이 없으면 발견 불가 - 체크리스트 활용 : 각 이슈에서 고려해야 할 사항들이 있을것, 그것을 스스로만 알고 머리로 추적하는 것이 아닌 명시적인 표시를 통해 공유하고 놓치지 않게 할것.
트러블 슈팅
- 문제 발생 원인에 대한 고찰 : 타인의 힘을 빌리기 이전에 스스로 고민하고 생각해 볼 것.
- 문제 키워드 도출 및 검색 : 문제에 대한 발견에 이어 해결 법을 찾기 위해 문제의 '키워드'를 도출하여 찾는 것이 문제 해결 능력의 한 부분
- 팀원과 문제에 대해 토의 : 키워드 도출 이후 검색과 시도 끝에 해결 불가 시에, 공유하고 같이 고민할 것. 그것을 위한 키워드 도출과 문제의 명확화.
- 정확한 진단 및 해결 방법 기록 : 해결 여부를 떠나 문제 추적과 시도들에 대한 기록은 필요, 이러한 기록을 더듬는 과정에서 해결책이 나올 수도 있음
- 해결이 안 될 경우, 멘토에게 질문 : 도움의 손길은 의외로 언제나 멀지 않은 곳에 있음. 위 과정을 거친 질문들은 잘 정제되어 이해하기 쉬울 것임.
- 알기 쉽고 이해하기 좋게 정리 : 실수와 실패는 필수적, 하지만 그것을 반복할지는 선택적, 그것을 위해 돌아봤을 때 이해할 수 있는 기록을 남길 것.
효과적 발표
여정에 대한 마침표, 조지면 그 기간동안 고생한 것을 한순간에 초라하게 만들 수 있음.
- 발표 시간 10~15분 : 당시 팀당 제공된 시간은 10분에서 15분, 의외로 짧은 시간
- 불필요한 내용 걷어내기 : 채우기 보단 걷어낼 것, 제공된 시간을 헛되이 쓰지 말 것. 그것은 나눠 받은 타인의 시간이자 관심이자 에너지.
- 전달할 핵심 내용 요약 : 걷어 낼 때는 핵심적인 부분만을 남기기 위해 작업할 것.
- 발표 내용 작성 및 리허설 : 대본은 원고로 작성하고 반드시 리허설 해 볼 것. 실수를 줄이는 방법 중 하나.
- 적절한 제스쳐와 자신감 : 무엇을 말하고자 하는지 명확화하는 데에 도움이 됨. 프로가 아니더라도 프로페셔널리즘은 필요.
- 좋았던 경험과 아쉬웠던 경험에 대한 공유 : 여정의 과정을 풀어내는 방법 중 하나가 될 것.
어짜피 완벽하게 완성 못할 것이니 꼴사납고 뻔하게 포장하기 보다, 제대로 까라.
2. 스크럼 프레임 워크
프로젝트 관리에 대한 구체적이고 방법론적인 부분, 애자일 스크럼 프로세스 프레임 워크
"스크럼은 짧은 주기(스프린트)로 개발 및 검토를 진행하는 효율적인 방법."
스프린트는 개발 및 검토의 반복, 그 여러 사이클 안에서 효율적인 협업의 모습에 대해 찾을 것.
스크럼?
럭비에서 유래, 팀원이 서로 밀착하여 형성한 전술 대형을 뜻함.
목표를 위해 취할 전략에 대한 부분
팀이 경험을 통해 학습하거나 문제를 해결하면서,
스스로 구성하고 얻은 것과 잃은 것을 되돌아보며, 개선 할 수 있도록 (같은 실수를 반복하지 않도록) 유도함.
애자일 스크럼 프로세스
- 프로덕트 백로그 : 제품 요구사항 분석(우선 순위 관리)
- 스프린트 백로그 : 제품 전체의 요구사항 중 일부를 스프린트 별로 나누는 과정, 목표 작업 목록 작성
- 스프린트 계획 회의 : 하나의 스프린트 형성 후 첫번째 스프린트의 목표와 달성 테스트 설정
- 데일리 스크럼 : 매일 어제 한 일, 오늘 할 일, 해결해야 할 이슈 회의 (약 15분)(각 회의는 길어지는 것을 주의할 것.)
- 구현 : 필요한 회의 및 논의 이후 매일의 작업 시간 (데일리 스크럼과 구현의 반복 안에 하나의 스프린트 기간은 종료.)
- 스프린트 마지막 날 리뷰(시연, 검토) : 데일리 스크럼과 구현의 반복중 하나의 스프린트 기간이 끝나면, 스프린트 마지막 날 구현 여부 보단 사용성 및 UX적 관점에서 시연, 리뷰, 검토.
- 스프린트 마지막 날 회고 : 이번 스프린트 동안의 좋았던 점, 아쉬웠던 점 / 개선 사항 논의.
이러한 스프린트 과정의 반복을 통해 프로젝트를 마무리 짓고, 프로덕트를 완성.
역할
실제 프로덕트에서는 사용자(고객), 마케팅(세일즈)팀, 프로덕트 오우너, 팀장, 멘토, 디자인 팀, 개발 팀 등등 이 존재.
하지만 현재의 과정에서 우리는 개발 팀의 역할을 맡아 다른 팀 및 역할들은 제외.
팀장이 곧 스크럼 마스터, 팀원들은 개발 팀의 구성원, 팀 내부에서 해결이 안된 문제를 시니어 관리자(멘토)에게 전달.
1. 프로덕트 백로그
프로덕트 백로그와 스프린트 백로그
프로덕트 각각의 페이지 마다 요구사항과 특징이 있음, 그것을 중요도에 따라 구분하여 나열.
우선과 차선을 구분, 스프린트 별 분배, 상태 칸에 임무의 진행 상황에 대한 상태를 표기.
스크럼 프로세스의 첫 단계가 이러한 백로그를 구성하는 것.
2. 스프린트 백로그
일정량의 작업을 완료하는 시간이 정해진 짧은 기간.
프로덕트 백로그를 바탕으로 스프린트 백로그를 작성.
각 스프린트 기간마다 무엇을 할 지 논의하는 시간.
4. 데일리 스크럼 + 5. 구현
위클리 스프린트의 목표와 작업 내용에 대해서 매일 작업한 혹은 구현된 내용에 대해서 기록하고 정리하는 것.
매일 아침 15분 가량 진행, 공통의 업무와 개인적 업무 기록.
개인의 상황및 사정에 따라 부재 발생 시에도 기록.
다음 회의(데일리 스크럼)까지 할 일 또한 기록
- 매일의 작업.
6. 스프린트 마지막 날 리뷰
담당 작업자의 시연, 다른 팀원들은 관찰하여 리뷰(좋았던 점, 아쉬운 점 등의 피드백)
7. 스프린트 마지막 날 회고
스프린트 구간마다 반성 및 개선
3. 프로젝트 관리
GitHub은 프로젝트 관리에 필요한 여러 구성 요소를 제공함
프로젝트
깃헙 프로젝트 탭은 테이블, 칸반 보드 등 다양한 뷰를 제공(위는 테이블 뷰)
- 스프린트 주차별 주제를 타이틀에, 작업 예정자를 담당자에, 상태를 통해 현재의 상태를 기록, 레이블을 통해 작업 내용을 구분 및 표기
- 프로젝트의 칸반 보드 형 뷰 페이지
마일스톤
주차별 계획 및 설계
스프린트는 각각의 주차 별로 수행했던 이슈들이 묶에게 됨.
레이블
팀별로 팀 안에서 필요한 내용에 따라 구성
이슈
각자 중구난방의 양식이 아닌 일관된 형식에 따라 정리해야만 팀의 하나의 목소리로서 작동함. -> 템플릿!
커밋 컨벤션
접두사(prefix)를 통한 일관성 유지
브랜치 컨벤션
git-flow 설치 및 사용
코딩 컨벤션
(예시)
위키
일종의 회의록으로 작동 할 수 있음. 깃헙 기능의 일종
4. 발표
접근성이 중요.
구글 슬라이드, slides.com, canva.com 등의 온라인 URL로 접근 가능하도록 슬라이드를 작성할 것.
5. 프로젝트를 튼튼히 하는 법
[다음 게시물에서 작성] 결국 미완성된 글로 정리되었다..
