파이널 프로젝트 다들 고생 많으셨습니다😄
정든 프로젝트를 마무리하며, 아쉬웠던 점과 개선해야 할 점을 나누어보는 시간을 가지려고 합니다
정은
폴
하정
시영
정은
폴
이번 프로젝트의 SR는 일주일간 여유를 갖고 준비했었어요. 준비했던 문서는 Wireframe, UI Design, Story Board, Flow Chart(server, client), DB Schema 등이 있었네요. 여유를 갖고 준비하려고 했었지만 되돌아보니 반성 할 점이 많았던것 같아요. 다들 어떻게 생각하시나요?
1 회차 때는 SR 을 짧게해서, 이번 프로젝트 때 SR을 1 주일 하면 조금 더 나을꺼라고 생각하는데 여전히 아쉬운 생각이 드는 것은 어쩔 수 없는 것 같습니다. 단순히 SR 의 길이 문제도 있지만, GraphQL 이나 우리가 새로 사용하는 기술에 대한 이해가 부족하다보니 초기 기획이 탄탄하길 바랬던 것은 조금 과욕이었던 것 같습니다. 단 이러한 과정들이 소프트웨어를 개발하는 관점에서는 크게 도움이 된 것 같습니다.
모든 페이지마다 꼼꼼히 기획을 했다고 생각했는데, 막상 개발을 하고 나니 미처 고려하지 못했던 부분이 조금씩 있었던 것 같아요. 예를 들어 유저 초대 모달의 디자인과 플로우차트까지는 기획했지만 어느 페이지에 어떻게 구현할지에 대해서는 기록으로 남기지 않아서 개발 단계에서 임의로 추가해넣었던 경우처럼요. 생각보다 많은 페이지에서 그런 일이 발생하니까 화면 단계에서도 플로우를 구성하면 좋을 것 같다는 생각이 들었어요. 이 버튼을 누르면 어떤 일이 일어난다, 이 제목을 수정하려면 어떤 행동을 취해야한다 등의 화면 중심 기획도 기회가 되면 고려해보는 게 좋을 것 같아요.
먼저 지난 번보다 좋아진 점이라고 한다면, 각각의 페이지와 관련된 Server 관련 플로우 차트를 작성했던 점이 큰 도움이 되었던 것 같습니다. 이번 프로젝트에 가장 큰 변수는 GraphQL과 Apollo framework였다고 생각이 드는데, 미리 API 문서를 작성하지 않아도 되었지만, 대신에 그 시간에 버금가는 만큼 논의를 많이하고 개발을 진행했었기 때문에 저희가 유연하게 잘 대처하지 않았나 싶습니다. 또한, 지난번에는 State Management와 관련해서 깊은 논의를 못한 점이 아쉬웠는데, 이번에는 Apollo로 Remote State을 관리하다 보니... 생각보다 많은 일들이 쉽게 해결이 되었지 않나..
저도 SR기간의 60%는 사실 새로운 스킬을 배우는데 사용했던 것 같아요😅 처음부터 학습 기간과 함께 진행하려 했었지만 실질적으로 SR에 투자한 시간은 크게 변동이 없었지 않나 싶기도 해요.. 하지만 두 번의 프로젝트에서 배운 것이 있다면 SR은 반드시 기획하고 넘어가야하는 부분도 있지만 상황에 따른 유연성도 필요한 것 같아요. 저희가 다른 팀과 다른 점이 있었다면 모든 팀원이 풀스텍으로 참여했던 덕에 서버 개발을 우선적으로 마무리하고 프론트 개발을 시작했던 점이었어요. 그 과정에서 과감하게 api document를 생략하고 graphql이 생성해주는 playground에 의존하게 되었는데, 위험한 선택이었지만 flow chart를 꼼꼼하게 짜두었던 덕에 오히려 중복 작업을 줄일 수 있었네요.
항상 선택의 기로에 놓였을 때 만약 기존에 의도했던 방향과 다시 흘러가게 된다면 문서에 대한 수정도 동시에 이루어졌어야 한다는 느낌이 듭니다. 하지만 @정은님 께서 말씀하신대로 시간이라는 제한 된 자원을 고려한다면 어쩔 수 없었던 부분이었고, 때문에 유연성과 빠른 손발력이 필요했던 프로젝트가 아니었나 싶습니다. 개인적으로 GraphQL 의 자동 문서화는 정말 다행으로 느껴졌었습니다.
폴
정은
정은
하정
폴
시영
하정
폴