스프린트를 잘 운영하는 것이 경력으로서 큰 메리트가 있어서 이번 프로젝트에서 스프린트 운영 자체가 메리트가 되지는 않을 것이다. 핵심적인 역량의 +@ 느낌이라 큰 메리트를 느끼지 못 할 수 있다. 취지자체는 나쁘지 않다.
개개인의 목표를 잘 세우기
제안하시고 싶은 목표 : 프로젝트로서 경험을 많이 하는 것
수능 같은 것이 아니다. 지금 실패했다고 망하는 것이 아님
서류 면접 / 취직이 혼자서 이겨내야 하기 때문에 더 많이 힘들고 괴로움
프로젝트 이후에도 계속해서 공부해야한다
프로젝트를 잘 만들었냐 못 만들었냐는 중요하지 않을 수 있다.
여럿이 있을 때, 팀으로 있을 때 경험하면 좋으면 좋다.
1대 1 상담을 해줄 수 있다. 프로젝트가 끝나더라도 🥹 (준프님은 신인가..?)
스프린트를 할 때 가장 중요한 점은 회고
팀 단위 일기를 써야한다. 주기여도 상관 없다.
개개인은 매일 하는 것도 좋다.
기록을 해둬야 이 프로젝트를 끝나고 얻은 것을 기억해낼 수 없다. 단순히 말하면 까먹는다.
내가 왜 이렇게 코드 작성했는 지 이해하지 못한다.
면접 때 대답을 못 하는 상황이 생길 수 있다.
내가 뭐 때문에 누구랑 싸웠는 지, 내가 뭐 때문에 생산성이 낮아졌는 지, 내가 코드를 작성할 때 어떤 단점이 있었는 지, 내가 코드를 잘 썼을 때 어떤 환경에 있었는 지,
다른 분들에게 나랑 일 했을 때 어땠는 지 물어본다. → 솔직히 대답해줘야 한다. 험담이 아닌, 개선점을 주는 것
내가 알 지 못한 나의 모습을 알게 된다.
나의 장점을 알 수 있고, 단점도 알게 되서 남들보다 더 치고 나갈 수 있고
팀 단위 회고는 지금 밖에 못 한다.
자기의 객관화를 할 수 있다.
회고 내용 : 진행한 작업들과 회고, 종합 회고..
회고를 적다보면 분기별 회고를 적을 수 있다. 실무를 할 때도 꼭 해야한다.
코드리뷰 중요하다.
필요시 준프님이 코드리뷰도 해주실 수 있다.
100이면 100 같이 일하기 힘든 코드가 많다. 🥲
내 코드를 다른 이들에게 리뷰를 부탁해서 내 코드가 남들에게 잘 읽을 수 있는 지에 대한 역량을 키워야한다.
기본이 되어있지 않으면 첫 인상이 좋지 않다.
우선순위를 잘 설정해서 성공하는 경험을 잘 세우자.
제품으로서 의미가 있어야한다.
기능의 갯수가 많지 않아도 되고, 만든 것은 완성도 높게 작동 해야한다.
회원가입, 로그인 밖에 못 만들어도 괜찮다.
우리가 어떤 기능을 많이 만들었는 지는 정말 중요하지 않다.
포트폴리오를 하나하나 뜯어볼 시간이 없다.
포트폴리오를 안 봐도 생각보다 파악할 수 있는 것이 많다.
코드를 보면 ‘바쁘니까 대충 하자’라는걸 확인할 수 있다.
내가 특장점을 보여줄 수 있는 것이 중요하다. 회고를 쓰면 알 수 있음!
제출하기 전 마지막 한 주는, 테스트 기간으로 생각해야한다. 제출하기 일주일 전에 제출한다고 생각해야 한다. 테스트하는 경험이 신기하면서도 좋은 경험이 될 것이라 확신한다.
새로운 코드를 만드는 것보다 내가 만든 것을 리팩토링하는 것이 더욱 좋은 경험이 될 것이다.
멘토링 주에 1시간 반이 의무
1대 1 상담 요청도 시간 난다면 가능합니다.
멘토링 기간 외적으로도 괜찮으시다 🥹 (준프님의 철자는 GOD..)
Q&A
은비 : 회고는 프론트, 백 같이하는게 좋나요?
→ 그렇다! 사이가 좋더라도 어떻게 일하면 더 효율이 증가할 지 알 수 있다.
선아 : 유어클래스에서 보면 회고를 할 때 부드러운 분위기로 하는게 좋다고 하는데 어떻게 분위기 조성을 하면 좋을까요?
→ 각 잡고 해도 된다. 카메라를 켜고 하면 좋다. 그래야 사람 표정을 보면서 할 수 있다.
선아 : 일과 시간에 스프린트를 5일로 잡고 35시간 업무량을 이슈카드 생성한다고 했을 때, 작업하다가 이 기능을 빼서 추가해야 할 때 스프린트는 다음 스프린트에서 해야한다고 할 때 어떻게 융통성 있게 해야할 지?
→ 다음 스프린트로 무조건 넘겨야 한다. 무조건 산출물이 나와야 한다. 그렇기 때문에 플래닝을 잘해야한다. 처음에 꼼꼼히 체크를 해야한다.
→ A라는 기능을 만들다가 A라는 기능을 위해 B라는 다른 기능이 필요하다는걸 느낄 때 그건 외부 기능이 들어온 것이 아닌 A라는 기능에 포함되는 것이기 때문에 정했던 시간 내에 끝내야 한다.
현석 : 스프린트를 시작했는데 하다보니까 기획부터 망가진다면?
→ 애초에 그렇게 빗나가지 않게 기획해야한다. 실무에서는 꼼꼼하게 한다.
→ 우리는 엄청 작은 조직이기 때문에 어쩔 수 없이 스프린트 계획을 바꿔야할 수 있다. 애자일은 유연하게 하려하는 것이다. 어떤 점이 비용적으로 더 나은 것인지 고민해볼 시간이 필요하다.
선아 : 멘토님이 생각하시기에 기획, 설계, 프로그래밍이 각각 비율이 어느 정도는 되야할까요?
→ 다 중요하다. 우린 디자인 역량이 없다면 1로 줄이고 신경 쓰지 않는다. 기획을 덜하면 계속해서 회의하느라 시간이 빈다. 1주 기획, 2주 개발, 1주 테스트
내가 뭘 만드려고 하는 지 키보드 위에 손 올리고 생각 먼저 해야한다. if문을 하나 쓰더라도 → 이런 얘기는 회고 때 해야한다.
현석 : Next.js 13버전으로는 CSR이 된다고 들었는데 개발이 가능 할 지
우리 : 쓰고 싶은 이유 말함
→ 지금 수준에서 어떤걸 쓰든 상관은 없다. SSR은 서버를 운영하는 것이기 때문에 모니터툴? 이슈가 있고 API 서버랑 통신할 때 이슈가 있다. 잘해서 얻는거든 잘못해서 얻는 거든 많을 것이다. 그래도 완성은 해야한다. 만약 완성을 못 해도, 기술 선택을 도입하면서 실패해서 부정적인 면을 알게 되는 것도 공부가 될 수 있다.
선아 : 멘토님이 Next.js 13버전으로 배포하신 적이 있으신 지 궁금합니다.
→ 리액트에서 손 떼신지 1.5년 정도 되셨다. 인프런은 Node.js 바닐라 JS로 되어있다.
기술도 프로에게 있어서는 하나의 도구이다. 우리 회사 기술이 그 기술로 안 되어 있지만 내가 맡고 있는 코드를 책임감 있게 유지보수 하는 기술도 굉장히 중요하다.
Next.js 서버에서 렌더링 하는 방식에 대해 이해도가 필요하다. 네트워킹 바운더리에 대해 이해가 필요하다. 어느 영역까지가 서버고, 어느 영역이 브라우저에서 돌아가는 코드인 지 이해하는 것이 중요하다. 배포도 방법이 다르다. next.js는 s3에서 배포 못 하고 인스턴스에서 할 수 있다. 인프라에 대한 이해도가 필요하다. 운영, 배포, 통합 모두 할 줄 알아야한다. 제품으로 운영할 수 있는 지가 중요하다. 우리 책임 하에 EC2 인스턴스를 만들든, next.js를 위한 docker 파일을 만들고 운영할 수 있어야한다. 그렇지 않으면 next.js를 선택함으로 백엔드 개발자분들의 리소스를 뺏을 수 있다.
→ 선택하는 것에 있어서 나쁜 점은 없다고 생각한다.
현석 : 컨플루언스? 가 얼만큼 점유율이 있는 지 궁금하다
→ 기업에 맞춰야 한다. 기술도 마찬가지다. 노션은 슬랙, jira랑 많이 연동이 안 된다. jira를 쓰면 노션을 쓴다? 나쁘진 않음. 기술적으론 컨플런스가 짱~ 대부분의 조직은 컨플런스와 jira를 사용할 것이다.