엔지니어링 팀 집중의 기술: 적게 하면 더 많이 할 수 있음
(resources.github.com/developer-productivity)- 엔지니어링 팀은 종종 "더 많은 기능을 더 빠르게 출시"해야 한다는 압박을 받음
- 하지만 너무 많은 작업을 동시에 진행하면 오히려 생산성이 떨어짐
-
"더 많이 출시하는 비결은 오히려 덜 하는 것" -
Less is More
핵심 원칙
- 모든 작업을 가시화함
- 작업을 작은 단위로 정의
- 진행 중인 작업을 제한함
- 용량에 맞게 자원을 할당함
- 보너스: 혹시 모를 것을 위해 여유 공간을 확보함
# 모든 작업을 가시화함
- 작업을 가시화하면 현실을 직시하게 됨
- 모든 작업이 한눈에 보이면 다음과 같은 장점이 있음
- 우선순위를 명확히 설정 가능
- 불필요한 작업을 중단하거나 일시 중지 가능
- 팀이 시작한 작업을 완료하도록 집중 가능
- 목표는 모든 작업을 영원히 추적하는 것이 아님 → 현실을 명확히 파악하고 더 나은 의사 결정을 내리기 위함
# 작업을 작은 단위로 정의함
- 작업이 너무 크면 팀의 에너지가 소진되고 진행 상황이 명확하지 않음
-
작업 단위를 1~2주 정도로 제한
- 개발자는 단기적 성과를 통해 동기 유지
- 빠르게 피드백 받고 수정 가능
- 작은 작업 단위의 장점
- 코드 리뷰가 더 쉬워짐
- 자연스러운 지식 공유
- 팀원 간의 협력이 강화됨
- 배포 위험 감소
- 작업 단위를 줄이면 속도가 빨라짐 → 복잡한 기능에 압도되지 않고 모멘텀 유지 가능
# 진행 중인 작업을 제한함
- 여러 기능을 동시에 처리하면 오히려 생산성이 저하됨
- 맥락 전환 비용이 발생 → 새로운 작업에 적응하는 데 최대 23분 소요됨
- 진행 중인 작업이 많아질수록 다음과 같은 문제가 발생
- 품질 저하
- 버그 증가
- 팀의 사기 저하
- 팀 수준의 과부하 신호
- 개발자당 4개 이상의 작업 수행
- 예상보다 완료 시간이 길어짐
- 완료된 기능보다 진행 중인 기능이 많음
- 개인 수준의 과부하 신호
- 집중력 저하
- 코드 리뷰 응답 시간 증가
- 상태 회의에서 우선순위 설명 어려움
# 용량에 맞게 자원을 할당함
- "한 명의 개발자가 하나의 기능을 맡는다"는 접근 방식은 비효율적임
-
가장 중요한 작업에 팀의 리소스를 집중
- 협업 강화 → 문제 해결 속도 향상
- 코드 품질 향상 → 실시간 피어 리뷰 활성화
- 작업 완료 속도가 빨라짐
- 개발자들이 협업을 통해 더 깊은 이해 가능
- 팀 단위 성과를 장려해야 함 → 개인 성과보다는 팀 성과에 중점
# 여유 공간을 확보함
- 100% 용량으로 운영하면 오히려 성과가 저하됨
- 예상치 못한 작업은 불가피함 → 언제 발생할지 모를 뿐임
- 여유 공간이 없으면 발생하는 문제
- 팀이 반응적으로 일하게 됨
- 품질 저하
- 혁신 감소
- 기술 부채 증가
- 여유 공간이 있으면 다음과 같은 장점이 있음
- 예상치 못한 문제에도 유연하게 대응 가능
- 창의적인 문제 해결 가능
- 높은 품질 유지
- 지속 가능한 작업 속도 유지
- 적정 여유 공간은 약 20% → 팀 특성에 따라 조정 가능
핵심 전략 요약
- 작업을 가시화 → 현실을 직시할수 있게
- 작업을 작은 단위로 정의 → 모멘텀을 유지
- 진행 중인 작업 제한 → 집중력을 높임
- 용량에 맞게 자원 할당 → 우선순위에 맞춰 집중
- 여유 공간 확보 → 유연성 확보
결론
- 더 많은 작업을 하기 위해서는 덜 하는 전략이 필요함
- 팀의 성과는 얼마나 많은 기능을 동시에 처리했는지가 아니라, 얼마나 효과적으로 고객에게 가치를 제공했는지로 측정됨
- 리더의 역할은 팀에 더 많은 작업을 추가하는 것이 아니라, 불필요한 작업을 덜어내는 것임
긱뉴스에서 여러번 언급 되었던 책 <피닉스 프로젝트>에서도 비슷한 이야기가 나옵니다. 100% 용량에 가까울수록 응답시간이 기하급수적으로 길어진다고.
80%의 업무 그리고 20% 여유 공간을 두고자 노력하지만, 어떤 기준으로 할지.. 매번 고민이 되긴하네요. 단순 시간으로 해야하나 싶기도하구요
비슷한 글이 반복되지만, 인간의 욕심은 끝이 없고 같은 실수를 반복하죠
컴퓨터의 CPU로드 100%는 정상이 아니지만,
인간의 업무로드 100%는 더 열심히 해야 한다..는 결론이 나오니까요
이렇게 작은 태스크로 나누게 되면 큰 그림을 가지고 있는 리더가 큰 권한을 가지게 됩니다. 같이 있는 엔지니어들은 오히려 동기가 박탈되고 "우리는 대체 어딜 향해 가는거지" 가 됩니다. 스프린트 기반 애자일의 대표적인 단점.
너무 리더의 관점으로만 쓰여진 것 같네요, 제목 그대로.
엔지니어의 모멘텀은 리더가 깃발을 어느 방향으로 들고 있는지도 크게 영향을 받습니다. 고객에게 주고싶은 가치가 무엇인지, 스프린트마다의 output 과 딜리버리 outcome이 무엇인지 제시 할 수 있는 방법에 대해서도 조금 더 고민이 필요해보입니다. 물론 어려운 소프트스킬이라 제대로 하는 리더도 보기 힘들고 글도 잘 없긴 하지만.
1-2 주로 나누게 되면 자연스럽게 하나의 기능에 대한 그림은 제한적인 사람만 알게 될 것 같습니다. 프로세스와 쓰레드의 차이처럼요. 관심을 제한하면서 생산성을 높이는거니까요.
그림을 공유하더라도 그 그림에 대해 의문을 가질거라는 전제이긴 한데, 매 스프린트 플래닝마다 조금씩 달라지는 방향에 따라 큰 그림을 어떻게 추적해가고 있는지 맞추지 못한다는 전제도 제가 자연스럽게 한 것 같습니다.
저는 이 글에서 제시하는 바에 전적으로 동의하면서도, 말씀해주신 문제도 동의합니다,
실제로 제가 고민하고 있는 포인트이기도 합니다.
스쿼드마다 다르긴 했지만 스프린트 플래닝에 팀원들을 적극적으로 참여시키면 말씀해주신 문제가 발생하지는 않았습니다. 프로젝트의 맥락을 공유하고 매 스프린트마다 변화하는 상황을 공유하면서 바뀌는 작업들을 충분히 인지할 수 있게 노력하면서도 작업은 굉장히 세분화해서 나눠보자고 요구했습니다.
말씀하신대로 관리하는 측면에서 진행 상황, 작업 속도 측정, 예상치 못한 상황에 대한 대처, 작업 내용이 의도대로 안되었을 때의 기회 비용을 생각하면 잘게 나누어야 결국 잘 진행되긴 하더라구요.