| Info |
|---|
개발 조직이 성장함에 따라 분할 된 작업 단위를 효율적으로 관리 할 수있는 소규모 팀으로 재구성해야합니다. 이러한 팀은 일반적으로 조직의 더 큰 목표의 맥락에서 고유 한 요구 사항을 충족하는 자체 작업 일정, 이사회 및 기타 프로세스를 갖습니다. 시간이 지남에 따라 조직은 일관된 프레임 워크를 중심으로 프로세스를 통합하여 네트워크 이점을 누릴 수 있습니다. 전달 계획은 하나 이상의 작업 일정의 시각화입니다. 이는 각 팀이 생산할 계획과시기에 대한 전체적인 관점을 팀과 경영진에게 제공하기위한 것입니다. 이를 통해 조직 전체의 투자를 최적화하는 결정을 내릴 수 있습니다. 작업 일정이 다른 팀의 일정과 일치하는지 확인하기 위해 팀이 정기적으로 전달 계획을 검토하는 것이 중요합니다. 이러한 리뷰는 다음과 같은 질문을해야합니다.
제공 계획은 프로젝트 수명주기의 어느 시점에서나 가치를 추가합니다. 팀 백 로그를 기반으로 동적으로 생성되기 때문에 항상 최신 상태를 유지하고 최신 통찰력을 제공합니다. 그들의 토론에 Tailspin 웹 팀에 참여합시다. |
| 팀원 | 대화 내용 | 비고 |
|---|---|---|
| "방금 엔지니어링 경영진과 멋진 만남을 가졌습니다. 저는 Azure Boards로 우리가하고있는 작업을 시연했고 그들은 다른 팀이 합류 할 것이라는 전망에 흥분했습니다." | |
| "대단해! 언제 시작됩니까?" | |
| "그게 가장 좋은 부분입니다. 이미 가지고 있습니다! 어제 밤에 게임 엔진 프로젝트 책임자는 스프린트가있는 팀을 만들고 작업 항목을 추가하기 시작했습니다. 나는 오늘 아침에 훑어 보았고 그것은 멋지게 형성되고있다. 그들이 무엇을하는지 보여 드리겠습니다." (Andy는 게임 엔진의 현재 스프린트 보드로 이동합니다. 그와 Mara는 큰 관심을 가지고 작업 항목을 검토합니다.) | |
| 흠 ... 이번 스프린트가 끝날 때까지 베타를 배포 할 계획이 없다는 것을 방금 알았어요. 다음 스프린트 동안 리더 보드를 베타 데이터베이스와 통합 할 것으로 기대하지 않습니까? 베타를 먼저 출시하지 않으면 그렇게 할 수 없습니다. | |
| 좋은 지적입니다. 우리는 우리 자신의 것을 생산할 수 있도록 그 결과물을 생산하기 위해 그 팀에 의존하고 있습니다. | |
| 이로 인해 다음 스프린트의 생산성이 크게 떨어질 수 있습니다. 나는 그들에게 무슨 일이 일어나고 있는지 알아보기 위해 전화를 할 것입니다. 안타깝게도 더 정교한 팀 구조는 의사 소통에 공백이나 지연을 초래할 수 있습니다. | |
| 좋아, 방금 개발 책임자와 이야기를 나눴다. 그녀는 아트 팀이 Cliffchella에서 돌아올 때까지 베타 출시가 차단되었다고 말했습니다. | |
| 산 꼭대기 음악 축제? | |
| 예, 분명히 디자인 커뮤니티에서 엄청난 일이며 전체 팀이 참석하기 위해 일주일 동안 그리드에서 떨어집니다. 게임 엔진 팀은 일정을 3 주 앞당겨서 꽤 화가났습니다. 그들이오고 있다는 것을 알았 더라면 그들은 필요한 유물을 미리 확보했을 것입니다. 그들은 또한 우리에게 더 일찍 알리지 않은 것에 대해 사과했습니다. 그들은 우리가 우리 부품을 출시하기 위해 베타를 기다리고 있다는 것을 깨닫지 못했습니다. | |
| 적어도 우리는 게임 엔진 팀이 스프린트 계획을 발표하고 있다는 사실에 기뻐할 수 있습니다. 일정을 조정할 수있을만큼 일찍이 종속성 문제를 찾는 데 도움이되었습니다. | |
| 저는 이러한 잠재적 위험이 더 쉽게 다가오는 것을 볼 수있는 방법이 있었으면합니다. 우리 팀은 회사 전체에 너무 많은 종속성을 가지고있어서 모든 회의에 참석하고 모든 메일 그룹에 가입 할 수있는 방법이 없습니다. | |
| 팀 스프린트를 나란히 볼 수 있도록 배달 계획을 세워야합니다. 이렇게하면 두 팀이 일정이 서로에 미치는 영향을 더 쉽게 식별 할 수 있습니다. 그리고이 작업을 위한 완벽한 Azure DevOps 확장을 알고 있습니다. |
여러 Agile 팀 관리를위한 권장 사항
| Info |
|---|
애자일 접근 방식은 Azure DevOps와 함께 프로젝트 투명성과 예측 가능성을 크게 향상시킬 수 있습니다. 그러나 프로젝트는 종종 인력이나 잘못된 의사 소통과 관련된 전통적인 문제에 직면 할 수 있습니다. Agile 노력을 확장 할 때 고려해야 할 몇 가지 사항이 있습니다. |
사람과 프로세스에 대한 신뢰 구축
| Info |
|---|
애자일 구현의 초기 비방 자들은 종종 팀 성과를 향상시키는 능력에 회의적입니다. 조직 내 사고 리더가 도구와 프로세스가 결과를 생성하는 방법을 보여줌으로써 신뢰를 구축하는 것이 중요합니다. 때때로 이러한 결과는 생산성 향상이며 정량화하기 쉽습니다. 그러나 피할 수있는 일정 미끄러짐이나 품질 문제와 같은 잠재적 인 문제를 피함으로써 발생하는 팀의 승리를 강조하는 것을 잊지 마십시오. 사람들이 혜택을 달성 한 프로세스와 연관시키기 시작하면 더 많은 열정을 갖게됩니다. |
팀 (및 개인)보다 높은 조직
| Info |
|---|
일부 팀과 개인은 새로운 프로세스 또는 정책이 제안 될 때 영토가됩니다. 특정 팀이나 개인의 성과를 부정적으로 노출하는 것으로 새로운 정책을 구성하는 대신 조직 전체의 새로운 투명성이 모든 사람에게 기대치를 어떻게 알려주는지 강조하십시오. 누구나 자신의 업무가 목표를 달성하는 조직과 어떤 관련이 있는지 추적 할 수있는 단일 장소를 확보하면 프로세스에 대한 헌신의 중요성이 높아집니다. |
투명성 문화 조성
| Info |
|---|
안타깝게도 "투명성"이라는 용어는 잘 정리되지 않았습니다. 모든 것이 잘 될 때 더 많은 투명성을 요구하는 사람은 없습니다. 대신 투명성 (또는 투명성 부족)은 팀이 어려움을 겪을 때 종종 비난을받습니다. 애자일 팀에 제공되는 모든 투명성 기회에도 불구하고 여전히 개인과 팀의 정직성에 따릅니다. 투명성의 이유 중 하나는 너무 늦기 전에 잠재적 인 문제를 식별하고 해결할 수 있기 때문이라는 점을 강조합니다. 사람들은 때때로 일정 마감일을 지키지 못하는 상황에 처하게된다는 것을 누구나 이해합니다. 그러나 가능한 마지막 순간까지 실망스러운 뉴스를 보도하는 것이 안전하다고 느끼지 않는다면 훨씬 더 파괴적인 영향을 미칠 수 있습니다. |