배달 계획이란?

완료됨

개발 조직이 성장함에 따라 분할된 작업 단위를 효율적으로 관리할 수 있는 소규모 팀으로 재구성해야 합니다. 해당 팀에는 일반적으로 조직의 더 큰 목표의 맥락에서 고유한 요구 사항을 충족하는 작업 일정, 보드, 기타 프로세스가 있습니다. 시간이 지남에 따라 조직은 일관된 프레임워크를 중심으로 프로세스를 통합함으로써 네트워크 이점을 누릴 수 있다는 것을 알게 됩니다.

‘배달 계획’은 하나 이상의 작업 일정에 대한 시각화이며, 각 팀이 언제 무엇을 생산할 계획인지에 대한 전체적인 전망을 팀 및 경영진에게 제공하기 위한 것입니다. 배달 계획을 활용하면 조직 전체의 투자를 최적화하는 결정을 내릴 수 있습니다.

팀은 정기적으로 배달 계획을 검토하여 작업 일정이 다른 팀의 일정과 일치하는지 확인해야 합니다. 이러한 검토는 다음과 같은 질문을 해결해야 합니다.

• 현재 일정에 맞춰 약속한 사항을 이행할 수 있나요?
• 참여하는 팀이 현재 일정에 맞춰 필요한 사항을 이행할 것이라고 확신하나요?
• 작업으로 채운 일정에 일시적인 중단이 있나요?
• 팀 내 또는 팀 간 종속성에 문제가 있나요?

배달 계획은 프로젝트 수명 주기의 어느 시점에서든 가치를 추가합니다. 또한 팀 백로그를 기반으로 동적으로 생성되기 때문에 항상 최신 상태를 유지하고 최신 인사이트를 제공합니다.

Tailspin 웹 팀의 토론에 참여해 보겠습니다.

Andy: 엔지니어링 경영진과 멋진 만남을 가졌어요. 저는 Azure Boards로 우리가 하고 있는 작업을 시연했고 그들은 다른 팀이 동참할 것이라는 전망에 매우 기뻐했죠.

Mara: 잘됐네요! 언제 시작하나요?

Andy: 이것이 가장 좋은 부분입니다. 이미 가지고 있습니다! 어젯밤 게임 엔진 프로젝트 잠재 고객이 몇 가지 스프린트로 팀을 만들고 작업 항목을 추가하기 시작했어요. 오늘 아침에 간단히 살펴보았는데 잘 돼가고 있어요. 고객 팀이 무엇을 하려고 하는지 보여드릴게요.

Andy가 게임 엔진의 현재 스프린트 보드로 이동합니다. Andy와 Mara는 큰 관심을 가지고 작업 항목을 검토합니다.

Andy: 음...저는 고객 팀이 이번 스프린트가 끝날 때까지 베타를 배포할 계획이 없다는 것을 지금 막 알아차렸어요. 다음 스프린트 동안 순위표를 베타 데이터베이스와 통합할 것으로 기대하고 있지 않나요? 고객 팀이 먼저 베타를 제공하지 않으면 우리는 통합할 수 없어요.

Mara: 좋은 지적이네요. 우리는 그 결과물을 생산하기 위해 해당 팀에 의존하고 있기 때문에 우리 자신의 결과물을 생산할 수 있습니다.

Andy: 이로 인해 다음 스프린트의 생산성이 크게 저하될 수 있어요. 제가 고객 팀에 전화를 걸어 진행 상황을 확인해 볼게요.

안타깝지만 더 정교한 팀 구조는 전파 과정에 공백이나 지연을 초래할 수 있습니다. 한 팀이 막히면 이에 종속된 다른 팀이 결과물을 내놓지 못할 수 있습니다. 이는 모든 관계자가 매일 회의를 하는 소규모 그룹의 팀에게는 큰 문제가 아닐 수 있습니다. 그러나 팀의 규모 및 위치가 확장됨에 따라 모든 사람이 모든 곳에서 진행되는 모든 일을 아는 것은 현실적이지 않습니다. 이 시점에서 조직은 순수한 “푸시” 모델(예: 대면 발표 또는 메일 공지)에서 “풀” 모델(팀이 서로의 일정을 검토하고 추적할 수 있음)로 전환해야 합니다.

Andy: 방금 개발 책임자와 통화했어요. 그녀는 아트 팀이 Cliffchella에서 돌아올 때까지 자신의 팀이 베타를 제공할 수 없게 됐다고 말했어요.

Mara: 마운틴탑 음악 축제 말이죠?

Andy: 네, 듣자 하니 디자인 커뮤니티에서는 굉장한 일이더라고요. 그래서 팀 전체가 참석하기 위해 일주일 동안 업무를 처리할 수 없대요. 게임 엔진 팀은 일정이 3주나 늦어져서 꽤 화가 났어요. 행사가 예정되어 있던 것을 알았더라면 미리 필요한 아티팩트를 확보했을 텐데요. 개발 책임자는 우리에게 더 일찍 알리지 않은 것에 대해서도 사과했어요. 우리가 맡은 부분을 제공하기 위해 베타를 기다리고 있다는 것을 인식하지 못했다고 해요.

Mara: 적어도 우리는 게임 엔진 팀이 스프린트 계획을 게시하고 있다는 사실에 고마워해야겠네요. 우리가 일정을 조정할 수 있을 만큼 조기에 이 종속성 문제를 찾는 데 도움이 되었어요.

Andy: 이러한 잠재적인 위험이 다가오는 것을 더 쉽게 확인할 수 있는 방법이 있었으면 좋겠어요. 우리 팀은 회사 전체에 걸쳐 너무 많은 종속성을 가지고 있어서 우리가 모든 회의에 참석하고 모든 메일 그룹에 가입할 수는 없어요.

Mara: 팀 스프린트를 나란히 볼 수 있도록 배달 계획을 만들어야 해요. 그렇게 하면 두 팀 모두가 일정이 서로에게 어떻게 영향을 주는지 더 쉽게 파악할 수 있어요.

여러 Agile 팀을 관리하기 위한 권장 사항

Agile 접근 방식은 Azure DevOps와 함께 프로젝트 투명성 및 예측 가능성을 크게 개선할 수 있습니다. 그러나 프로젝트를 진행하는 동안 여전히 기존의 인력 또는 소통 오류와 관련된 문제에 직면하는 경우가 많습니다. Agile 활동을 스케일링할 때 다음과 같이 고려해야 할 몇 가지 사항이 있습니다.

직원 및 프로세스에서 신뢰 구축

초기의 Agile 구현 비방자들은 흔히 팀 성과를 향상할 수 있는지에 대해 회의적입니다. 조직 내 선구적 이론가가 도구 및 프로세스를 통해 어떻게 결과를 내놓는지 보여 줌으로써 신뢰를 구축하는 것이 중요합니다. 때로 그 결과는 생산성 향상입니다. 그리고 정량화하기 쉬운 성과입니다. 그러나 방지할 수 있는 일정 차질 또는 품질 문제와 같은 잠재적인 문제를 방지함으로써 달성하게 되는 팀의 성공을 강조하는 것을 잊지 마세요. 직원이 성공을 달성한 프로세스와 혜택을 연결할 수 있게 되면 더 많은 열정을 갖게 됩니다.

팀(및 개인)보다 조직 강조

일부 팀과 개인은 새로운 프로세스 또는 정책이 제안될 때 영역을 얻습니다. 특정 팀이나 개인의 성과를 부정적으로 알리는 것으로 새로운 정책을 구성하는 대신 조직 전체의 새로운 투명성이 모든 사람에게 어떻게 기대치를 전달하는지 강조하세요. 누구나 자신의 업무가 목표를 달성하는 조직과 어떤 관련이 있는지 추적할 수 있는 단일 위치가 있다면 프로세스에 대한 헌신의 중요성을 제대로 인식하게 됩니다.

투명성 문화 조성

안타깝지만 “투명성”이라는 용어는 안 좋은 상황과 연결됩니다. 모든 것이 좋은 경우에는 누구도 더 많은 투명성을 요구하지 않습니다. 대신, 투명성(또는 투명성 부족)은 흔히 팀이 어려움을 겪을 때 비난을 받습니다. Agile 팀에 제공되는 모든 투명성 기회에도 불구하고 투명성은 여전히 개인 및 팀의 정직성에 달려 있습니다. 투명성의 이유 중 하나는 너무 늦기 전에 잠재적인 문제를 파악하고 해결할 수 있는 것임을 강조하세요. 모든 사람은 누구나 때로 일정 마감일을 지키지 못하는 상황에 처하게 된다는 것을 이해합니다. 그러나 사람은 최대한 마지막 순간까지 실망스러운 소식을 보고하는 것을 불안하게 느끼는 경우 훨씬 더 파괴적인 영향을 줄 수 있습니다. 투명성과 관련하여 편안하고 솔직하게 말할 수 있는 분위기 조성은 예상되는 지연을 가능한 한 빨리 보고한 사람에게 감사하는 것부터 시작할 수 있습니다.