무엇이 문제인가
아침부터 작업 진척속도를 빠르게 할 수 있는 방안을 생각하면서 하루가 시작되었다. 결국 작업은 모든 팀원들의 동의를 얻어야 통과가 될 수 있기 때문에, 전날 코드리뷰에서 팀 동료들과 의견이 달랐던 부분을 리스트업하자는 생각을 했다. PR 을 보면서 두가지 사항을 캐치해내서 간단히 메모를 하고, 아침 스크럼에서 공유했다. 두가지 주제중 하나에 대해서 시간을 두고 이야기 할 수 있었던 것 같다.
그 주제는 화면의 세로 컨텐츠 폭을 제한하는 '공통 레이아웃 컴포넌트'를 부모 컴포넌트에 지정해줄 필요가 있는가였다. 사실 논의의 구체적인 내용도 중요했지만 더 중요했던 것은, 팀원들이 모두 해당 문제에 대해 공감하고, 해결책을 생각했던 시간이었다. 이 시간에 우리는 레이아웃 지정에 대한 두가지 정도의 전략에 대해서 공통의 지식을 같이 알고 있는 상태가 될 수 있었다.
이 경험을 통해 공통으로 문제를 정의 하는 과정의 중요성에 대해 생각한 것 같다. 문제가 정의되자 여러 의견이 나오기 시작했고, 각자가 이것을 어떻게 바라보고 해결하고자 하는지가 공유되었다. (다 알아 듣지는 못해서 아쉽다, 메모해둘걸) 문제의 정의까지 갈 필요도 없는것 같긴 하다. 무엇이 문제인지를 명확하게 정리해서 공유하는 것만으로도 문제해결의 많은 진척을 가져오는 것을 느꼈다.
팀에서 무엇이 문제인지를 이야기 할 수 있는 기회는 사실 너무 많다. 아침 스크럼도 있고, 뽀모도로가 끝날때마다 갖는 공유타임도 있다. 뭘했는지 보고하고 나열하기 보다 겪고 있는 문제상황이나 장애물을 공유해서 빠르게 벗어나는 편이 좋다는 것을 다시 느낀다. (특히 네이밍은 항상 장애물이라고 느낀다.)
급할수록 제대로
작업시간이 많지 않은 하루였다. 정확하게 하나씩 해결하기 위해서 짝프로그래밍 동료와 체크리스트를 작성했고, 그 중 가장 쉬운것 부터 처리하면서 작업 리듬을 높여나갔다. 체크리스트의 항목이 줄어들고, 항목 개수가 세개 정도 되었을때, 남은 것들은 모두 시간과 노력이 드는 것들 뿐이었다. 그 세개에 집중해서 궁리를 하니, 하나의 행동으로 체크리스트 두개를 없애는 방법을 궁리해서 적용했다. 여기까지는 좋았다...
그 다음이 문제였다. 다음 작업으로의 이동을 빨리 서두른 탓에 마무리로 작업완료 여부를 확인하는 과정이 어설펐다. 마무리 셀프 코드 리뷰가 부족해서 네이밍 상의 여러 자잘한 미스들과 에셋 파일들의 이름 일관성 같은 것들을 놓쳤다. 특히 치명적이었던 것은, 다른 사이즈의 화면에서 레이아웃 문제가 발생한다는 것도 놓쳤던 것이다. (덕분에 반응형 처리에 대해 몰랐던 것을 알게 되긴 했다.)
위의 것들을 체크하는 마무리 체크가 과연 오래걸릴까? 짝프로그래밍 동료와 나눠서 한다면 10분내외의 시간이 될것이다. 이 시간에 서둘러 다음작업을 한 대가로 동료들의 소중한 시간에 이상한 네이밍 미스와 명백한 화면 오류를 지적하게 만든것이 아쉬웠다.
마무리 체크 10분은 아무리 바빠도 확보해야할 시간이라는 것을 다시 느낀다. 작업 시작 지점에 미리, 완료시에 어떤 것을 확인해보아야 하는지를 생각해보는것도 좋을 것이다. 작업 시작전에 보통 완료조건을 정의하는 작업 일지를 작성하곤하는데, 이때 완료조건과 함께 확인방법까지 작성해두면 더 좋을 것 같다. TDD 에서도 배우는 것이지만, 행동전에 피드백을 먼저 고려하지 않고서는 좋은 피드백을 받을 수 없는 경우가 너무 많기 때문이다.
