회고

10월 둘째 주 회고 글을 작성한다.
 
9월 마지막 주 기술지원본부에서 이슈를 넘겨줬다. 고객사에서 나온 이슈는 아니지만 솔루션을 사용하는데 있어서 일관성이 없어서 불편하다는 이슈였다.
8월에 인수인계 받은 우리 팀의 솔루션은 사실 이슈가 너무 많았고, 이슈를 단순히 덮어 놓은 부분들도 많이 발견했다.
이번 이슈는 그 이슈의 일환으로 솔루션의 코어 컴포넌트인 테이블에서의 액션과 로우 선택, 체크가 페이지마다 일관성이 없다는 것 이였다.
 
개인적으로 특정 컴포넌트의 특정 기능은 잘 추상화 되어 하나의 비즈니스 로직으로 간단하게 컴포넌트(페이지)에서 사용할 수 있어야 한다고 생각한다.
하지만 현재 개발된 테이블과 비즈니스 로직은 기능을 직접 페이지 컴포넌트에서 구현하고 있기 때문에 수 많은 페이지를 다양한 개발자들이 개발했던 탓인지 일관성이 없는 UX가 많았다.
하여 주간 회의에서 테이블의 일관성을 유지하기 위해 정책을 수립하자는 의견을 냈고, 테이블 정책을 수립해 페이지 컴포넌트를 수정하기 시작했다. (대략.. 80개가 넘는 컴포넌트를 수정해야 했다.)
 
그렇게 수정을 시작하니 생각보다 이슈가 있는 화면이 더욱 많았고, 수정하다보니 덮어있던 이슈들도 하나씩 들어나고는 했다. 결국엔 왜 이런 이슈를 해결하지 않고 지금까지 유지했던 것일까? 라는 궁금증마저 들기 시작했다.
해당 이슈를 리딩하며 두 분의 프론트엔드 개발자분과 함께 이슈를 진행하고 있었다. 현재 스프린트를 진행하는 것도 아니고, 데드라인이 정해진 이슈도 아니여서 이슈에 이슈가 발생하면 해당 이슈까지 픽스를 하려고 했었다. (현재 고치고자 하는 이슈도 아니였음에도 불구하고) 그러다보니 10월 둘째 주까지 이슈를 끝내지 못하며 이슈가 너무 늘어지고 있다는 생각이 들기 시작했다. 이렇게 꼬리를 무는 이슈까지 다 해결하려고 하다가 원래의 이슈를 해결하지 못하겠다는 생각이 들었던 것이다.
 
결국 결단을 내렸다. 현재 리포팅 된 이슈를 우선적으로만 픽스하고, 추가적으로 발생하는 이슈건들은 기록으로 남겨놓고 현재 이슈를 쳐내고 개선 건으로 진행하기로 결정했다. 이슈가 늘어지면 늘어질수록 목표를 달성하지 못하고 늘어지는 상황에 공수와 힘만 빼고 있던 상황이였기 때문이다.
 
어제, 10월 11일(금) 일자로 현재 리포팅 된 이슈를 수정하는 것을 종료했다. 물론 차주에 해당 이슈건을 테스트를 해야겠지만, 테스트로 인해 발생하는 이슈는 다른 이슈로 진행할 예정이다.
 
왜 이슈가 이렇게 늘어졌을까 생각해봤다. 소프트웨어 개발자라면 진행중인 이슈가 지연되거나 늘어지는 상황을 반드시 피해야 한다고 생각하기 때문에 회고를 통해 두번 다시 이런 상황을 만들지 말아야 겠다는 생각을 했다.
1. 이슈의 범위를 제대로 예측하지 못했다.
2. 이슈에서 또 다른 이슈가 발생했을 때 함께 처리하려고 하여 이슈의 진행도가 늘어졌다.
3. 함께 작업하는 개발자들과 초기에 제대로 합을 맞추지 못했다.
4. 이슈의 단위를 쉽게 생각했다. 해당 이슈를 하위 이슈가 아닌 에픽단위로 생각을 했어야 했다.
 
원인을 네 가지로 좁혀봤다.
첫 번째 원인은 개발중인 솔루션에 익숙하지 않아서라고 생각한다. 현재 팀에서 근무중인 프론트엔드 개발자는 나 포함 모두 8월 중순에 인수인계를 받아서 코드를 확인했다. 그러다보니 솔루션이 익숙하지 못했고 아무도 범위를 제대로 예측할 수 없었다. 앞으로 제품을 계속 개발하다보면 솔루션에 익숙해져 이슈의 범위를 제대로 예측할 수 있지 않을까 싶다. 이 부분은 익숙함의 문제이기에 시간이 흐르면 해결할 수 있을 것 같다.
두 번째 원인은 결단력이 부족해서 였다고 생각한다. 이슈 단위로 일을 할 것이면 해당 이슈에서 리포팅 된 이슈에 한해서 작업을 진행해야 했다. 또 다른 이슈가 발생한다면 이슈로 리포팅 한 후 진행해야 이슈가 늘어지지 않을 것이다. 앞으로는 이슈의 커버리지에 한해서 일을 해야겠다는 생각이 들었다.
세 번째 원인은 커뮤니케이션의 부족이였다. 컨플루언스 페이지에 정리를 해서 공유를 하면 괜찮을 것 이라고 생각했는데 오판이였던 것 같다. 앞으로 함께 이슈를 진행할 경우에는 반드시 이슈에 관련된 간단한 스탠드 업 미팅이라도 진행해야겠다는 생각이 들었다.
네 번째 원인은 판단 미스이다. 현재 지라를 사용하고 있고 백로그에서 이슈를 에픽 > 스토리,작업,버그 > 하위 이슈 로 나눠서 작업하고 있었다. 해당 이슈를 하위 이슈로 진행했는데, 적어도 중간 단계의 작업으로 분류하고 이슈를 더 잘게 쪼개서 진행했어야 했다는 생각이 들었다.
 
이번 교훈을 바탕으로 다음번에는 더욱 정교하게 일을 진행해야겠다는 생각이 들었다.
지금 팀이 팀장님도 없고 아직 혼란스러워서 뭔가 진행이 계획적으로 되고 있지는 않다. 프론트엔드 파트 만이라도 예전에 경험했던 방식대로 에자일하게 일을 해볼까라는 생각도 하고 있다. 주 단위 스프린트를 통해 이슈를 정확히 예측하고 스토리 포인트를 산정해 이슈를 진행하며 데일리 스탠드업 미팅을 진행해볼까도 생각하고 있다.
 
이번에 했던 고민을 바탕으로 나는 더 나은 소프트웨어 개발자가 될 것이다.