Task 쪼개기
팀에서는 문제를 해결하기 위해 팀원들간에 협업을 수행합니다. 그리고 팀은 주어지는 문제를 여러 Task로 쪼개어 병렬로 처리합니다. 다시 말해, 팀원들이 각 Task들을 할당 받아 처리하는 것입니다.
이때 Issue를 Task들로 쪼개는 방법은 특별해야합니다. 만약 이 Task들이 잘못 쪼개어진다면, 의도한 대로 병렬 처리를 할 수 없을 것입니다. 이건 곧 협업의 문제로 이어지기에 썩 유쾌한 일은 아닐 것입니다.
그리고 Task를 쪼개기 위해서는 Issue 처리 방법에 대한 전체적인 구상이 필요합니다.
Issue를 처리하는 흐름
주어지는 Issue를 처리하는 흐름은 팀마다 다릅니다. 이 글에서는 제가 사용하는 범용적인 처리 흐름을 사용하겠습니다.
제가 활용하는 범용적인 처리 흐름은 아래와 같습니다.
위 그림을 통해 확인할 수 있는건 Task 쪼개기는 작업 스케치를 선행 작업으로 참조한다는 것입니다.
작업 스케치
작업 스케치는 해당 Issue를 해결하기 위해 어떠한 작업들을 진행해야하는지 스케치하는 과정입니다.
이 작업 스케치를 수행하는 가장 손쉬운 방법은 작업의 단위를 오브젝트로써 표현해보는 것입니다.
예를 들어 `개발자를 채용하라` 라는 Issue가 주어진다고 가정해보겠습니다. 추가적으로 해당 팀에는 프로그래머가 없습니다. 이러한 가정에서는 아래와 같이 전체 작업을 스케치해볼 수 있습니다.
이 작업 스케치에서 가장 중요한 요소는 바로 작업들간의 `선행 작업`입니다.
프로그래머라면 클래스 다이어그램으로 작업 스케치를 진행할 수 있습니다.
그리고 선행작업은 곧 의존성 방향입니다.
Task 쪼개기: 선행 작업
우리는 작업 스케치를 통해 각 작업들의 선행 작업을 파악했습니다.
Task를 쪼갤 때 이 선행 작업 파악은 매우 중요합니다. 실제로 해당 Issue를 처리할 때 가능한 최대 병렬 수를 파악할 수 있습니다.
앞서 예시로 스케치했던 내용을 살펴봅시다. 위쪽에 위치한 주황색 작업들과 아래쪽에 위치한 보라색 작업들은 병렬로 처리가 가능해보입니다.
이 경우 이 작업 스케치의 최대 병렬 수는 2입니다. 우리 팀이 만약 2명으로 이이루어진 팀이라면 매우 알맞는 병렬 수죠. 같은 색상에 해당하는 작업들을 한 Task로 묶어서 각 팀원에게 할당하면 될 것 같습니다.
그러나 문제는 다음입니다.
공고 게시 이후부터의 작업은 병렬 처리가 불가능합니다.
Task 쪼개기: 극도의 병렬성과 Pair Working
우리 팀의 인원이 다섯 명이라면, 우리팀의 최대 병렬 처리 수는 5입니다. 그러나 항상 모든 작업들이 우리가 희망하는 최대 병렬 처리 수인 5에 맞추어지지는 않습니다. 그런 Issue는 나타나지 않습니다.
앞서 살펴보았던 Task 쪼개기에서 `공고 게시` 이후의 작업들은 더 이상 팀의 병렬 처리가 불가능해 보입니다.
이럴 경우 두 가지를 사용하는 전략을 택해야 합니다.
첫번째는 극도의 병렬성을 얻기 위해 다시 한번 더 해당 작업을 더 세분화된 작업으로 분할하는 것입니다. 그리고 그 안에서 다시 한번 Task 쪼개기를 시행할 수 있습니다.
프로그래머라면 함수 단위까지 쪼갤 수 있습니다.
두번째는 Pair working입니다. 더이상 분할할 수 없다고 판단되는 작업을 2명이 함께 작업하는 것입니다. 이 관행을 통해 서로의 의견을 민첩하게 나눌 수 있는 부수적인 효과도 얻을 수 있습니다. 또한 내가 아닌 다른 사람의 일하는 방법을 살펴볼 수 있습니다.
프로그래머라면 Pair programming이 됩니다.
Task 쪼개기: 강제 병렬성 발휘
직렬로 연결된 작업들은 병렬로 처리할 수 없습니다. 즉 팀의 한사람이 전담해서 처리해야한다는 것을 일컫습니다. 저는 이러한 직렬로 연결된 작업에 강제적인 병렬성을 적용할 수 있는 방법을 소개하려 합니다.
바로 ‘미래에 그렇게 될 것이다’라는 가정을 계약으로 맺고 강제 병렬 진행하는 것입니다.
`물건의 위치 선정`이 중요한 요소로 작용하는 Task가 있다고 가정해봅시다. 선행 작업의 작업자는 `물건의 위치 선정`을 결과물로 내어줄 것입니다. 그리고 그것이 결과나면 내게 할당된 Task를 진행할 수 있죠.
그런데 만약 선행 작업의 작업자가 `물건이 아직 거기 있는건 아닌데, 꼭 그쪽에 둘 것이다`라고 이야기 한다면 우리는 그 `미래 계약`을 통해 Task를 강제로 진행할 수 있습니다.
그러나 이것은 매우 조심스러운 결정으로 이루어져야합니다. 미래는 예측된 계약일뿐 실제가 아니기 때문입니다. 미래의 계약은 충분히 바뀔 수 있습니다. 또한 미래의 계약이 너무 커서는 안됩니다. 해당 계약이 크면 변경되었을 때 우린 더 많은 것을 재작업해야할지도 모릅니다.
프로그래머라면 Interface를 통해 미래 계약을 맺을 수 있습니다.
마치며
저는 소프트웨어 엔지니어입니다.
우리 팀은 `팀의 엔지니어링 방법`으로 이 Task 쪼개기를 활용하고 있습니다. 실제로 저는 팀원들에게 이렇게 쪼개어진 Task들을 할당하고 있습니다.
엔지니어링은 더이상 코딩에만 국한된 단어가 아닙니다. 다양한 직군, 다양한 상황에서 효율적으로 일을 처리하기 위한 방법을 찾아나가는 과정이라고 저는 생각합니다.
