[TIL] First Project, 아직 SR 짜기 단계
카테고리: TIL
오늘의 일정
- 하루 종일 회의를 하는 느낌
회의라고 할 만한, 입이 바빠 물을 자주 찾는 시간으로 다 보낸 날이었다.
입뿐만이 아니라 다른 것도 바밨는데, 생각하느라 굴린 머리는 물론이요, 화면 공유를 하는 팀원은 손이 바빴고, 화면 공유를 보는 팀원들은 가이드를 제시하기 바빴다.
이렇게나 열심히 했음에도 SR을 다 완성하지 못하여 파이널 때는 더 힘들겠다는 생각도 했다. 괜히 크루님께서 3~4일을 잡아도 된다고 한 게 아닌가 보다.
오늘 겪었던 일, 느낀점
- 어떻게든 돌아가긴 하는구나
프로토타입? 와이어프레임? - 프론트엔드 SR 준비하기
- figma 사이트를 쓰자!
첫날 2시간 동안은 프로젝트를 어떻게 할지 정했으니 다음은 본격적인 SR을 해야 했다.
전체적인 목표는 깃헙 레포지토리에 있는 wiki, 이슈 컨텐츠들을 작성하고 담당 엔지니어님께 가게 될 설문조사를 작성하는 것이었다.
처음 figma로 각 페이지 틀을 짰다. 프로토타입과 와이어프레임을 완성시키기.
틀을 짜기 전까진 말로는 뭐든 할 수 있을 것 같았지만, 틀을 그리게 되니 부족한 것, 필요한 것, 있으면 힘든 것 등이 보이기 시작했다.
뭔가 페이지가 하나 완성될 때마다 백엔드와의 교류도 생각해야 했고, 워크 플로우(Work Flow)도 갱신하고, 자신의 파트가 아니더라도 모두가 함께 열심히 머리를 굴려야 했다.
다행히 어느 정도의 간략한 틀을 만들 수 있었고, 와이어프레임도 모두가 합심하여 하나씩 넣다 보니 정말 팀플을 하는 기분이었다.
DB Schema는 어떻게 짤까?
- dbdiagram 사이트를 쓰자!
일명 스키마라고 불리우는, 백엔드 쪽의 데이터 관계도를 어떻게 할지 정해야 했다.
어떤 외부키로 연결할 것이며, 어떤 포스팅으로 어떤 겟으로 그 데이터들을 저장하고 불러오고 업데이트 할지를 짜야 한다.
이 또한 SR의 과정으로, 프론트엔드와 백엔드 둘 다 함께 작업해야 한다.
기본적인 시스템과 틀은 백엔드쪽에서 다 할 것 같지만, 결국 프론트엔드 부분도 알아야 그걸 짤 수 있으며, 프론트엔드 쪽도 이 스키마 구조를 알고, 요청해야 사이트를 다룰 수 있다.
예전에 N:M(다대다)을 배우면서 써본 적 있는 dbdiagram을 사용하여 스키마 틀을 짜기 시작했다.
백엔드 파트 담당분을 주체로 작성을 하다가 상황이 많이 복잡해지고, 사람들의 뇌 한계도 다다라서 내일 마저 하기로 했다.
KPT 작성을 합시다!
- KEEP, PROBLEM, TRY
주에 한 번씩은 하게 될 KPT 작성은 반드시 해야 할 과제이며, 팀의 출석체크에도 반영되는 중요한 투두(ToDo)이다.
각 세 가지는 아래와 같다.
- Keep (장점, 유지할 점) : 프로젝트 팀 활동 및 코드적으로 좋았던 경험을 기록합니다.
- Problem (단점, 변경 또는 버릴 점) : 프로젝트 팀 활동 및 코드, 스택 사용에서 좋지 않았던 경험을 솔직하게 기록합니다.
- Try (시도할 점, 앞으로의 행동) : Keep, Problem 항목을 기반으로 한 주간, 주말간 시도해볼 Action Item을 설정합니다.
여기서 중요한 점 중 하나는 Try이다. Keep, Problem 항목에 대해서 매주 정기적인 날에 회고를 진행하여 기록하고, 그것을 기반으로 Try (Action Items) 이슈를 생성하는 것이다.
우리는 다음과 같이 제출하여 냈다.
Keep (유지할 항목)
- 팀룰이 떠오르는게 있으면 바로 적용
- 프론트엔드랑 백엔드랑 서로가 소통하며 진행한다
- 공동으로 할 수 있는 부분에는 모두가 적극적이다
- 서로가 서로에게 칭찬해주며 동기부여 해준다
Problem (문제라고 생각하는 항목)
- 작업과 휴식의 밸런스가 맞지 않아서 갈수록 능률이 떨어진다
- 데이터베이스 설계쪽의 개념이 부족해서 어려움을 겪는다
- 정해진 시간내에 스케줄을 소화하지 못하는 경우가 있다
Try (Action Items)
- 모호한 팀룰을 확실히 지킬수 있도록 조정하고 준수하자
- 코드에 대한 기본세팅을 할 때 프론트,백을 가리지 않고 모여서 진행하자
- 정규시간이 지나거나 개인시간을 보낼때도 모자란 부분을 채우려 노력하자
팀장님은 팀장으로서의 글을 쓰는 분 같고, 팀원 모두가 팀장!
위 제목에서 하나 벗어나는 게 있다면, 네 팀원 중 한 팀원은 자신의 파트일 때 빼고는 거의 묵묵부답이었기에 이분은 팀장 느낌은 아니었다.
실제 팀장님도 적극적으로 나서고 의견을 냈지만, 실제 ‘팀장이다’ 싶은 분위기 조성 + 의견 조정은 다른 팀원분이 잘하셨고, 이분이 제대로 이해 못한 건 내가 이해시켜 주는 역할을 자주 했었다. 쉬는 시간을 갖자는 말도 내가 주로 시작했다.
누구나 만족하는 이상적인 팀장의 기준은 없다지만, 내 기준에서의 이상적인 팀장 한 명이 우리 팀에 존재하기보다는, 그 능력 조각들이 팀 내에서 모두 갖춰져 있는 느낌이 있었다.
우리 쉬는 시간을 가져요
뭔가 시작하면 기본 2시간은 지났고, 내가 쉬는 시간을 갖자고 하면 그제서야 쉬는 게 반복되었다.
분명 지쳐보이는 기색이 역력한데도 불구하고 사람들 누구 하나 ‘쉬어요!’라는 말을 하지 않는다.
팀룰에도 쉬는시간을 일정시간마다 정한 게 아니라, 누가 쉬자고 하면 쉬자는 룰만 정한 상태였다.
팀룰을 그렇게 정한 데에는 나름의 이유가 있었다. 일정 시간마다 쉬게 되면 흐름이 끊길 수 있기 때문이다. 이 외에도 누구 하나 일정시간마다 쉬어야 한다, 라는 얘기를 아예 하지 않았기에… 정확히는 내가 아무도 얘기 안 하기에 쉬자고 하면 꼭 쉬자는 얘기를 하니 그제서야 쉬는 시간 룰이 정해진 거였다.
아무래도 내일은 좀 더 빠르게 쉬는 시간을 가져야 할 듯하다. 뭔가를 해냈다, 싶으면 쉬는 것이다. 그리고 이 효율이 좋다면 팀룰로 내세우는 것도 고려 중이다.
다음에 해야 할 일, 각자 생각하기로 한 일
- 와이어프레임이 완벽하지 않아서 좀 더 만져보기로 했다.
- 데이터베이스 스키마를 어떻게 할지 생각해보기로 했다.
댓글남기기