애자일한 그룹 만들기

칸반보드가 너무 매력적이라서 5월에 팀의 개발 프로세스에 칸반 보드를 도입했어요. 한눈에 트랙들을 보기에도 편하고, 에픽 별로 분류하여 트랙들을 파악하는 것도 쉬웠어요.

5월 중순에 칸반 보드을 어떻게 사용하면 좋을지 방안을 건의했어요.

• 개발 분야, 기획, 디자인 별로 별도의 트랙을 사용하다보니 하나의 userStory라는 목적을 가진 “트랙”이 명확하게 보이지 않았어요.
• userStory가 다소 추상적인 느낌이 들어서 “기능”이라는 이름으로 하나의 트랙을 만들고, 각 영역(디자인, 프런트엔드, 백엔드)의 진행들을 하위 이슈에서 관리하는 방안을 제안했어요.

애자일한 프로세스로 일한지 한 달, 돌아보면 프로세스가 썩 훌륭하지는 않았던 모양이에요.

문제점이 몇개 있었어요.

1. 프런트엔드와 백엔드 api 인터페이스 문서의 한계
   • api 선 개발 후 swagger 에 올려두었는데, api 개발까지 프런트엔드 개발자는 단순히 형태를 추측할 수밖에 없었어요. api 개발 속도가 진척되자 이는 아주 치명적이었어요.
2. 프런트엔드와 백엔드 api 설계 과정에서 생긴 애로사항들
   • 기획안을 확인하고 백엔드 측에서 api를 추출해내었는데, 이 과정에서 클라이언트 측에서 사용하기에 부적절한 api 형태들이 생성되었어요.
3. 기획안을 개발자들이 적절하게 해석하지 못해 발생한 잘못된 구현체들
   • 의도한 방향과 다른 결과물이 만들어지기도 했어요.

이러한 문제점의 궁극적인 원인을 소통의 부재에서 찾았어요. 이렇게 보완해나가기로 했어요.

1. 기획안을 클라이언트에서도 먼저 확인하고, 필요한 데이터의 형태를 백엔드와 먼저 협상할 것. 협상한 api를 바로 개발하지 않고, swagger 에 올린 후 param/return 형태를 재검토할 것. 프런트엔드는 mock 데이터를 만들어 개발할 것
2. 구체적인 기능명세서를 피그마 상에서 작업해낼 것(ppt는 버전관리가 어렵고, 로딩이 느리고 무거움). 기획 수준에서 기능명세서를 작성하고 userStory를 도출해내 칸반보도 backlog에 올려두면, PM이 이를 중요도에 따라 “해야할 일” 칼럼에 이동시켜두고, 각 개발자는 하위 이슈로 구체적인 기능들을 서술할 것(ex. 사용자의 학습 히스토리 가져오기, 버튼 클릭시 알맞은 세션으로 이동시키기). 기능명세서 → userStory 의 방식은 QA의 꼭지도 제공해줄 수 있어 테스팅에도 유리할 것 같아요.

DB 구조에 대해서 논의했어요.

• 파닉스 세션을 별도의 테이블로 가져가야 할 것 같은데, 현재 리더스 세션의 DB에 욱여넣는 방식으로 설계하는 방식을 선호하는 동료도 있었어요.
  • 별도의 테이블로 가져가는 것이 좋겠다고 생각한 이유는:
    1. 비록 기능적으로는 유사하지만, 도메인(엔터티)의 영역에서 생각한다면 리더스와 파닉스는 별도의 도메인이에요.
    2. 게다가 지금 사양 상으로는 기능적으로 유사해보이나, 어떤 방향으로 확장될 지 아무도 몰라요. 또 욱여넣기에 적합하지 않은 상황들이 발생할 가능성이 있구요(당장 액티비티 파트만 하더라도 리더스와 맞지 않는 부분이 있어서 별도의 테이블로 빼기로 했거든요). 일단 별도의 테이블로 가져가서 테이블이 변경되어야 하는 경우 자유롭게 변경하고, 변경이 필요하지 않았다면 리더스 테이블과 합치는 방식이 좀더 안정적이라고 생각했어요. 아무래도 있던 걸 분리해서 재구조하는 것보다는 만들어두고 삭제하는 편이 더 간단하니까요.
  • 결국 아무래도 설득에는 실패한 것 같지만, 그래도 제 의견을 논리적으로는 잘 전달한 것 같아요. 합당한 의견이라고 생각했는지 몇몇 다른 팀원분들도 제 의견에 찬성해주셨어요.