스크럼에서 프로젝트 관리자가 유용합니까?

Scrum에는 Team, Product Owner 및 Scrum Master의 세 가지 역할이 정의되어 있습니다. 프로젝트 관리자가 없으며 대신 프로젝트 관리자 작업이 세 가지 역할로 분산 됩니다.

예를 들어 :

• 스크럼 마스터 : 프로세스를 담당합니다. 장애를 제거합니다.
• 제품 소유자 : ROI를 최대화하기 위해 수행 할 작업 목록을 관리하고 우선 순위를 지정합니다. 모든 이해 당사자 (고객, 이해 관계자)를 나타냅니다.
• 팀 : 자체적으로 작업을 추정하고 배포하여 자체 관리합니다. 자신의 약속을 충족시킬 책임이 있습니다.

따라서 Scrum에는 더 이상 프로젝트 성공을 책임지는 사람이 없습니다. 적절한 명령 및 제어 구조가 없습니다. 그것은 많은 사람들, 특히 민첩한 방법에 익숙하지 않은 사람들, 물론 PM의 사람들을 당황스럽게하는 것 같습니다.

나는 이것이 Scrum 구현을 만들거나 깨뜨릴 수있는 것들 중 하나라고 생각하기 때문에 이것과 당신의 경험에 정말로 관심이 있습니다.

프로젝트 관리자가 필요하지 않다는 Scrum에 동의하십니까? 그런 역할이 여전히 필요하다고 생각하십니까? 왜?

어쩌면 다음과 같은 것을 제시해야합니다.

프로젝트 관리자는 Scrum 에서 사라지지 않았습니다 . 그는 여전히 거기에 있습니다. 이 세 가지 지금의!

• 스크럼 마스터 : 프로세스를 관리하고 장애를 해결합니다. 그것은 전에 프로젝트 관리자의 책임이었습니다.

• 제품 소유자 : 백 로그를 관리합니다. 그는 Microsoft Project의 모든 것을 예측하기 전에 프로젝트 관리자의 책임이었습니다.

• 팀 : 자체 생산 관리. 특정 사용자 스토리가 누가 그리고 어떻게 출시 될 수있는 제품 증분으로 변환되는지. 작업을 할당 할 때 프로젝트 관리자의 책임이었습니다.

나에게 이것은 프로젝트 관리자의 역할과 PM 타이틀의 일반적인 특성에 대한 이해 부족에서 비롯됩니다. 저는 SCRUM의 전문가는 아니지만 항상 SCRUM Master가 프로젝트 관리자가 아닌 개발 관리자 / 팀장을 대체하는 것으로 보았습니다.

프로젝트 관리자 (Agile 방법론과 거의 호환되는 PRINCE2와 같은 방법론에 의해 정의 됨)는 실제로 개발 프로세스와 관련이 없으며, IT뿐만 아니라 광범위한 제공 관점에서 프로젝트를 검토하고 있습니다. 짓다. 프로젝트 관리자 역할에는 스크럼 내의 다른 곳에서는 다루지 않는 많은 것들이 있습니다 (비즈니스 사례 관리 및 모니터링, 비즈니스 이해 관계자 관리, IT 빌드 외부의 프로젝트 요소, 비즈니스 프로세스 재 작업, 지원, 훈련 등).

PM이 개발자를 돌보고 그 이상을 수행하지 않는 사람이라면 (예를 들어 범위가 꽤 잘 정의 된 곳에서만 주로 IT 인 프로젝트), 그가 필요하지 않을 수도 있습니다. 스크럼 프로젝트에서.

그러나 누군가가 SCRUM에 PM이 필요 없다고 말하기 전에 프로젝트의 비 IT 요소를 다루는 방법과 특히 비즈니스 사례를 관리하는 사람에 대해 명확하게 설명하고 싶습니다 (사용자가 원하기 때문에) 해야 할 일이 다릅니다.)

PM이 프로젝트의 비즈니스 측면에 더 많은 영향을 줄 수 있습니다. 제품 소유자는 Scrum Master보다 PM의 역할을 더 많이 수행 할 수 있지만 완전히 사라질 것 같지는 않습니다.

스크럼 마스터 나 제품 소유자가 할 수없는 프로젝트 관리자가 할 수있는 일이 몇 가지 있습니다.

• 프로젝트 관리자는 일반적으로 프로젝트를 실행 한 경험이 풍부합니다 (서프라이즈!).
• 그들은 일반적인 함정을 알고 있으며, 그것들을 발견하고 그들이 일어나기 전에 그들을 이탈시킬 수 있습니다.
• 이들은 일반적으로 경험이 풍부한 협상가이며 마감일, 범위 및 상충되는 요구 사항 (PO가 역할에서 상당히 새로운 경우)에 관한 토론에서 다른 팀 구성원을 지원할 수 있습니다.
• 그들은 돈을 관리 할 수 ​​있습니다. 그들은 고용 및 해고의 권한이 있으며, 팀의 누군가가 (훈련 준비, 상담 등을 통해) 자신의 역할을 수행 할 수없는 경우 도움을 줄 수 있습니다.
• 프로젝트가 더 큰 규모의 작업 프로그램에 효과적으로 적용되도록 보장 할 수 있습니다.
• 그들은 팀의 길에서 물건을 얻을 수 있습니다.
• 또한 스크럼과 함께 회사 정책이 효과적 이도록 안내 할 수 있습니다 (예 : 테스터가 여전히 발견 된 버그 수로 측정되는 경우).
• 거버넌스를 관리 할 수 ​​있습니다.
• 그들은 가구를 움직일 수 있습니다.
• 그들의 어휘는 대기업의 어휘이며, 위험, 영향, ROI, 옵션 및 차별화 측면에서 프로젝트와 스크럼 접근법에 대해 토론 할 수 있습니다.
• 그들은 녹색 보고서를 통해 갑자기 투명성과 때때로 실패에 대한 소식이 유익하고 유용한 이유를위원회에 설명 할 수있다.
• 좋은 PM은 안전하고, 차갑고, 멋지게 보이도록 도와줍니다.

스크럼은 PM을 요구하지 않습니다. 그러나 어쨌든 하나를 원할 수도 있습니다.

내가 일한 프로젝트 중 하나에서 Scrum으로 전환했을 때 초기 프로젝트 관리자는 제품 소유자와 Scrum Master의 역할을 대신했습니다. 이상적이지는 않았지만 그 팀과 함께 보낸 6 개월 동안 일했습니다. 그는 일을 엄격히 통제하고 싶었지만 상당히 잘 해냈습니다 (즉, 팀이 업무를 수행하고 적절할 때 결정을 내림).

그 배경은 회사가 심각한 재정 상황에 처해 있었지만 우리 (팀)는 얼마 후에 그것에 대해 알게되었습니다. 따라서 꼭 필요한 것만 제작하고 제품의 첫 번째 버전이 제 시간에 제공되도록 모든 것을 엄격하게 통제해야 할 이유가있었습니다.

공정하고 나는 내 관점에서 나에게 도움이되는 것은 프로젝트 매니저 역할을하는 스크럼 마스터라고 말한다. 스크럼 마스터가되는 것은 정규직이 아닙니다. 일단 팀이 성숙하면 스크럼 마스터는 일일 스탠드 업에 참석할 필요조차 없습니다.
회사가 이러한 역할을 차별화하기를 원하지 않는 프로젝트 관리자 / 스크럼 마스터에 대해 점점 더 많은 공석이 있습니다. 오히려 같은 사람이 두 역할을 모두 처리해야합니다.

프로젝트 관리자 : 전통적인 조직 또는 기업 내 역할.

스크럼 마스터 : 스크럼 방법론을 사용하는 소프트웨어 개발 팀 내 역할.

프로젝트 관리자 대 스크럼 마스터에 대해 이야기하는 것은 실제로 역할이 다른 컨텍스트이기 때문에 사과와 오렌지에 대해 이야기하는 것입니다. 공식 타이틀 또는 급여 등급으로 "Scrum master"가있는 조직에 대해서는 들어 본 적이 없습니다. 그리고 Scrum 또는 기타 프로젝트의 프로젝트 관리자는 일상적인 소프트웨어 개발 활동에서 다소 제거되는 경우가 많습니다.

정확히 프로젝트 관리자의 역할과 그 역할이 스크럼 마스터 또는 프로젝트 소유자의 역할과 겹치는 정도는 프로젝트의 규모와 성격에 따라 크게 다르지만 일반적으로 프로젝트 관리자가 특별히 지정하지 않은 작업이 있습니다. Scrum 마스터 또는 프로젝트 소유자 역할의 일부. 소규모 프로젝트에서는 Scrum 마스터 또는 프로젝트 소유자 역할의 직무를 확장하여 이러한 작업 (채용, 해고, 구매, 계약 관리, 고위 임원과의 인터페이스 등)을 포함시킬 수 있습니다. 더 큰 프로젝트에서 소프트웨어 개발은 ​​프로젝트 관리의 일부일 뿐이며 프로젝트 관리자와 Scrum 마스터의 업무는 전혀 중복되지 않을 것입니다.

프로젝트 관리자는 조직에 대한 Scrum 마스터의 인터페이스 여야합니다. Scrum 마스터는 프로젝트 관리자의 팀 인터페이스입니다.

그렇다면 스크럼에서 프로젝트 관리자가 유용합니까? 아니요, 프로젝트 관리자는 Scrum 외부에서 유용합니다. 이들은 Scrum 소프트웨어 개발 방법론의 일부는 아니지만 Scrum이 작동 할 수있는 리소스를 제공합니다.

이 질문은 Scrumbut의 냄새가 난다 .

스크럼은 프로젝트 관리 방법 (Prince2 / PMP 등)에 포함 된 것의 일부입니다. 실제로 Prince2 프로세스 MP (제품 배송 관리)를 보면 Scrum의 모든 요소를 ​​포함 할 수 있습니다.

Scrum Master는 공급 업체, 직원, 법률, 재무, 공급 업체, 경영진 또는 BAU 활동 과의 회의에서 혼란에 빠지기를 원하지 않습니다 . FY2011 / 12의 고용 기관이 계약자 요율을 얼마만큼 낮출 수 있는지 협상하지 않거나 공급 업체 x와의 에스크로 계약을 확인하지 않고 현재 스프린트에서 팀에서 장애를 제거하는 데 집중해야합니다.

Scrum Master가 위의 작업을 수행하는 경우 Scrum을 실행하지 않고 있고 Scrumbut를 실행 중입니다.

경험상 최상의 조합은 각 팀 리더를위한 스크럼 마스터와 프로젝트 관리자가 스크럼 마스터를 스크럼 스크럼 방식으로 조정하는 것입니다. 위에서 언급 한 이유와 그 경험의 깊이로 인해이 역할에 프로젝트 관리자를 더 효과적으로 배치 할 수 있습니다. 차례로,이 프로젝트 관리자는 포트폴리오 / 프로그램 관리자 등으로보고하며 모든 명령 체인은 최소한 인증 된 Scrum 마스터입니다.

Scrum은 제품 전달을 관리하기위한 도구이며, 추상화 계층에서 프로젝트를 실행하는 데 사용할 수 있지만 이미 훨씬 더 나은 프로세스가 있습니다.

전통적인 프로젝트 관리자 역할의 주요 문제점 중 하나는 권한과 책임을 분리한다는 것입니다. PM은 프로젝트 조직에 대한 완전한 권한을가집니다.-어떤 작업을 누가, 어떤 순서로 수행해야하는지 결정합니다. 그러나 이러한 작업의 완료 나 소프트웨어의 품질에 대해 책임을지지 않습니다. 생산됩니다. 팀원 만이 책임이 있습니다. 이로 인해 운영 작업과 동기화 된 권한 및 의사 결정을 취소 할 수있는 엄청난 커뮤니케이션 오버 헤드가 발생합니다. 또한 좌절감과 낙담의 큰 원천 인 팀원들에게 해방감, 무력감 및 목적 상실감을 유발합니다.

애자일은 어쨌든 이러한 개념을한데 모아 놓았습니다. 작업 조직에 대한 권한은 팀이 전체적으로 (릴리스, 반복 및 일일 회의를 통해) 보유하므로 모든 사람이 문제에 대해 말할 수있는 것처럼 느끼게됩니다. 팀 구성원은 작동하고 그 목표에 대해 강력한 헌신을하는 양질의 소프트웨어를 생산해야합니다. 따라서 이론적으로 프로젝트 관리자를 제거 할 수 있습니다.

당신이 말한 후에도 여전히 PM에 할당 된 의무가 여전히 있습니다. 루니 보어는 여전히 정확하게 설명해야합니다.

마찬가지로 이 문서가 제안, 진정한 멀티 숙련 된 팀, 당신이 할 수있는 한 가지 팀 구성원들 사이의 의무를 재배포 및 이전의 PM은 정기적으로 팀 회원이 될 수 있고, 프로젝트 관리자 역할을 폐기된다.

Scrum의 역할은 매우 잘 정의되어 있으며 (모호한 경우 다른 유형의 조직에 적용 할 수 있기 때문에), Scrum 팀의 크기는 거의 동일합니다. 기본 조직에 따라 다를지라도 포함하는 내용에 대해 비교적 쉽게 동의 할 수 있습니다.

위의 질문, 답변 및 의견을 읽으면 프로젝트 관리자 역할의 정의가 훨씬 어려워집니다. PM의 역할에 대한 훌륭하고 포괄적 인 일반 정의를 찾을 수 있다고 확신하지만 실제로 실제 상황은 완전히 다른 이야기입니다.

어쨌든, 직장에서 일할 때 프로젝트 관리자는 실제 "스크 러밍"에 거의 관여하지 않습니다. 그들은 스크럼 마스터가 될 수 없으며 (우리 모두가 좋아하는 지역 이해 상충 규칙) 예외적 인 경우에만 제품 소유자입니다.

그래서 제가 일하는 곳에서 프로젝트 관리자는 여전히하던 일을합니다. 즉, 프로젝트를 제대로 진행하고 너무 많은 편집증과 소액 관리 경향에 대한 필터 역할을함으로써 우리가 해결하고자하는 것보다 더 큰 영향력이 필요한 문제를 해결하는 것입니다.

나는 이것이 다른 곳에서 상당히 다르다는 것을 확신하지만, 우리에게는 훌륭하게 작동합니다.

편집 : 어쩌면 Scrum 팀이 프로젝트 팀을 대체 하지 않는다는 것을 분명히해야합니다 . 하나 개 이상의 스크럼 팀은 실제 개발 작업을 수행하기 시작하는 대한 (일반적으로) 프로젝트를. Scrum 팀은 프로젝트 리더를 제외하고는 이전 팀원으로 구성 될 수 있습니다.