210712(월) - 페어 프로그래밍, 감정 회고

1. 페어 프로그래밍 (프론트)

2. 감정 회고 (프론트)

---

1. 페어 프로그래밍 (프론트)

다시 페어 프로그래밍으로

프로젝트를 시작하면서 페어와 나 모두 데모 데이(210719)까지 시간적 여유가 많지 않다고 느껴서 조급한 마음을 가지고 있었다. 이런 이유로 기본적인 디자인만 논의하고 바로 각자 컴포넌트를 제작하기로 결정했다. 그리고 어제 다시 만나서 서로가 만들었던 부분을 확인했다. 예상보다 컴포넌트를 제작하는 속도가 더뎠다. 기본적인 컴포넌트처럼 보여도 생각보다 신경 쓸 부분이 많았기 때문이다. 또한 각자가 생각하는 컴포넌트의 형태(props 등)가 달랐기 때문에, 페어가 만든 컴포넌트를 이용해서 내가 새로 컴포넌트를 만드는 상황에서 서로 매끄럽게 이어지지 못했다. 그래서 오늘 논의를 통해 페어 프로그래밍을 진행하자고 제안했다. 각자 컴포넌트를 만들고 이후에 다시 맞춰가는 비용이 페어 프로그래밍을 하는 것보다 더 크다고 느껴졌기 때문이다. 결과적으로는 페어 프로그래밍으로 진행된 부분은 만족스러웠다. 처음에 생각하기로는 두 명이라는 우리가 갖고 있는 자원이 페어 프로그래밍으로 효율적으로 쓰일 수 없다고 생각했다. 하지만 이전 미션들에서 페어 프로그래밍을 너무 당연하게 진행하여, 그것이 주는 큰 장점을 잊고 있었다. 바로 합의 비용이었다. 작업이 투 트랙으로 진행되면 빠를 것처럼 보이지만, 합의를 통해 다시 맞춰가는 과정에서 드는 비용이 생각보다 상당했고 직접 느낄 수 있었다. 

프로젝트를 진행하면서 어떤 시점에서 어떻게 분업을 해야 효율을 극대화할 수 있는지 고민하고 있다. 이번 계기를 통해 처음부터 병렬적으로 진행하는 것은 아니라는 생각을 갖게 됐다. 그렇다면 언제 어떻게 진행해야 비용을 최소로 줄일 수 있을까. 일단, 우리는 전체적인 베이스 레이아웃을 구성하고 각자 페이지를 제작하는 시점에서 각자 일을 맡자고 결정했다. 기본적인 베이스 컴포넌트가 만들어졌고, 그것을 조립하여 컴포넌트를 만드는 시점이라고 생각했기 때문이다. 이게 해결책인 것은 당연히 모르고, 일단 해보기로 했다. 그런데 사실 또 의문이 드는 부분이 있다. 컴포넌트를 만들면서 많은 비용이 소모됐던 것은 props을 어떻게 가져갈지였는데, 현업에서는 이 부분에 대해서 어떻게 논의를 하고, 컴포넌트를 만들면서 수정되는 부분에 어떻게 대처할지이다. 일단 우리는 이 부분을 해결하기 위해서 페어 프로그래밍을 도입했는데, 현업에서는 어떤 과정을 거칠지 궁금하다. (유동적인 props에 대한 합의를 어떻게 가져갈지? 현업은 유동적이지 않나? 모두 완벽히 정하고 시작해서? 완벽할 수가 있나?)

2. 감정 회고 (프론트)

서로를 더 알 수 있었다.

사실 이전에 제대로 된 감정 회고가 굳이 필요하지 않았다. 디자인적인 부분을 주로 같이하기도 했고, 서로 즐겁게 작업했기 때문이다. 페어 프로그래밍을 하면서 즐겁게 하지 못했던 것은 아니지만, 감정 회고를 통해서 커뮤니케이션의 방식에 대해서 서로를 더 알아갈 수 있었다. 의견을 제시하는 주장의 강도, 제안에 대해서 서로의 행동(예를 들어, 특별한 반응 없음)이 의미하는 동의 또는 비동의의 정도 등 알려주지 않으면 알 수 없는 것들이었다. 서로 잘 통하고 즐겁게 프로그래밍을 하면 감정 회고가 필요하지 않을 수도 없겠다고 생각한 나였지만, 그럼에도 감정 회고는 꼭 필요하다고 느낄 수 있었다.