버퍼는 중요한 것에 두자

(아래 내용은 2024년 11월 15일 mountain goat software의 이메일을 기반으로 작성하였습니다)

큰 금액이 걸려있는 프로젝트를 할 때, 버퍼를 두는 것이 유용합니다--그러나 전체적인 산출물에 버퍼를 두는 것이 낫죠. 여러분이 거기에 도달하기 위한 모든 세부 단계들에 두기보다는요.

이걸 아주 간단한 예로 설명해 보겠습니다. 

오늘 저는 점심시간에 아내를 만날 계획힙니다. 그러나 그전에 짐 (gym)에 가서 운동을 하고 뜨거운 물에 몸을 담그고 쉬다가, 샤워하고 면도하고 옷을 입고 우리가 만날 레스토랑으로 차를 몰고 갈 겁니다.

제가 묘사한 작업들의 집합 전체에 저는 버퍼를 둬야할 것입니다. 만약 제가 열거한 모든 것을 하는데 두 시간 반이 걸린다고 해보죠. 저는 아마 15분의 버퍼를 두고 우리가 만날 시간보다 2시간 45분전에 짐으로 출발할 겁니다.

저는 중요한 것에 버퍼를 두었습니다--그건 레스토랑에 제시간에 도착하는 것이죠.

저는 각각의 작업에 버퍼를 둘 필요가 없습니다. 저는 짐까지 운전해 가는데 보통 15분이 걸리니까 안전하게 도착하기 위해서 20분을 계획할 필요가 없는 것이죠.

제 아내는 점심에 만나기로 했는데 제가 늦는지 신경쓸 것입니다. 그녀는 운전하는데 15분대신 20분 걸리는 것을 신경쓰지 않죠. 

그래서 저는 중요한 것에 버퍼를 둘 필요가 있죠--그건 운전과, 운동 등등을 포함한 오전의 전체 시간입니다.

애자일 프로젝트에서, 관리팀은 하나의 프로덕트 백로그가 예상보다 오래 걸릴 것인 지를 신경써서는 안됩니다. 그들은 반드시 그 백로그 아이템을 완성하기 위해 필요한 많은 작업들 중 하나가 예상보다 오래 걸리는지 신경써서는 안되는 것이죠.

테스팅에 8시간 대신 12시간 걸린다는 것은 아무에게도 중요하지 않습니다. 그것은 짐까지 운전하는데 오래 걸리는 것과 비슷할 것입니다. 누가 신경쓰나요? 

불행하게도, 너무 많은 매니저들과 리더들이 신경씁니다.--그들은 마이크로매니지하고--이 문제를 만들죠.

만약 제가 뭔가를 코딩하는데 오래 걸렸다고 저한테 소리지르는 매니저가 있다면 저는 코딩 예측에 패딩(pad)을 할 것입니다.

만약 제 매니저가 프로덕트 백로그 아이템이 예상보다 오래 걸렸다고 미치는 사람이라면, 저는 그 백로그 아이템의 예측에 패딩할 것입니다.

더 큰 그림에서, 이런 것들에 늦는 것은 중요하지 않아야 합니다. 하나의 태스크 혹은 백로그 아이템이 예상보다 오래 걸리는 것은 예상보다 적게 걸리는 다른 것에 의해 상쇄되어야 합니다.

관리자들은 대신 팀의 더 큰 목표에 신경써야 합니다. 예를 들면, 팀이 6개의 이터레이션만에 어떤 비즈니스 결과를 달성하기에 필요한,그들이 약속한 그 기능을 끝낼 수 있는가입니다.

그것이 중요합니다. 그리고 만약 그것을 끝낼 플랜이 의사소통되고, 지연되는 것에 대한 상당한 부정적인 점이 있다면, 그 계획에 버퍼를 추가하는 것을 고려하고 싶을 것입니다.

중요한 것에 버퍼를 두고 매니저들과 리더들이 중요한 것에 신경을 집중하도록 하는 것이 여러분의 팀이 애자일로 성공하는데 도움이 될 것입니다.

Mike